剑客
关注科技互联网

仅用8个虚拟机,PayPal是如何扩展至日处理数十亿事务的

仅在8台虚拟机上,就实现了原本需要100台虚拟机才能实现的工作。甚至当CPU占用高达90%时仍能快速响应,这种Paypal前所未见的事务处理密度,却仅需之前十分之一的时间。在降低成本的同时,还考虑到了无需增加相应的计算基础架构就能获得企业成长——Paypal日处理数十亿事务的系统是如何打造出来的?


仅用8个虚拟机,PayPal是如何扩展至日处理数十亿事务的

Paypal已经迁移至基于Akka框架的Actor模型上,在《squbs:Paypal构建应用的全新响应式方法》一文中,Paypal讲述了整个演变经历,目前他们对squbs进行了开源,点击这里便可查看源码。

在选择项目需采用的实现方式时,我们对有状态服务的考虑还是不够。想要了解更多关于有状态服务的内容,请参考基于Caitie McCaffrey的精彩演讲所撰写的这篇文章《如今构建可扩展有状态服务的案例》,如果还不够令人信服的话,我们可以看看这个案例:《Facebook斥资190亿美元收购WhatsApp的架构》,其中WhatsApp使用Erlang(Akka的竞品)达成了惊人的吞吐量。

本文推荐这两篇的文章的原因在于,Paypal的文章在架构细节上并未提及太多,大多是在他们选择Akka的原因,以及迁移到Akka上的好处。不过,在激励我们不甘于现状、勇于创新方面,这篇文章仍是很有价值的案例。

采用很多虚拟机来提供服务的方案到底有什么问题呢?

提供服务时使用的虚拟机规模很小,每台虚拟机的吞吐量也很低:基于Actor的反应系统在有效地利用计算资源方面非常出色,因此我们可以缩减系统规模,而无需依赖于典型粗暴的自动缩放机制。

对网络和路由选择架构造成很大压力: 随着各项服务趋于互联化,请求经过重重传递之后会造成延迟增加、用户体验下降的后果。

规模越大,成本越高昂: 由数百台虚拟机联合提供的服务,由于管理、监控以及无效缓存的问题,势必会造成昂贵的开销。

规模越小,敏捷性越高: 跨越数百台虚拟机部署服务需要花费很长的时间。

每台虚拟机的CPU利用率更高: 由于CPU的处理速度不会增加,所采用的架构需要提高虚拟机CPU的利用率。

需要在松散耦合、易于维护和可快速构建的超微服务(nanoservice)基础上建立起微服务: 我们不希望结构体系层层叠叠过于复杂,而是需要对服务所做的工作有清晰的可见性,在了解服务功用时无需深入到深层代码之中。

考虑到以上因素,PayPal需要的系统应当拥有如下特质:

可扩展:可横向扩展到数百个节点,也可纵向扩展为多个处理器,以实现日处理数十亿个请求的性能。

延迟低:在非常细化的颗粒度中实现可控性。

对故障具备弹性。

在调整服务边界时具有灵活性。

借助编程模型与企业文化,促进可扩展性与简易性的实现,包括在处理故障与错误时更为简洁。

很明显PayPal需要更薄的堆栈,他们不希望堆栈中的层次与可移动部件过多。一般来说,Akka以及基于状态的系统很适合这一需求,因为这类系统可以将大块的堆栈分解为某一种技术。

PayPal选择了Akka而不是Erlang的原因在于,他们在Java方面的经验更丰富,而Akka正是运行在Java之上的。对于很多人来说,从头学习Erlang并不合适。

通过Akka,他们可以做到:

编写易于诠释的代码;

编写易于测试的代码;

相对于用于JVM的传统模型来说,更为自然地处理错误与故障情境;

以流线型的错误处理机制编写速度更快、具有弹性、更为简洁、bug更少的代码;

因此,PayPal立即在Akka顶层构建出了自己的框架——squbs,并通过它创建了一个模块化的层面,以构建被称为“cubes”的超微服务。cubes彼此对称,之间存在着松散对称的相互依赖性,并且只暴露Akka已经提供的信息接口。

PayPal的文章还提及了程序员在适应Akka代码的非线性本质时所遇到的困难,因此在采用这类系统时,所雇人员必须能够适应Akka/Scala培训。

由于很多服务都在做类似的工作——接收请求、发送数据库调用以读取/写入数据库信息、对其它服务进行调用、调用规则引擎、从缓存中拿取数据、向缓存写入内容等,这些服务能够通过类似Orchestrator Pattern与Perpetual Stream之类的模式来进行抽象。

Squbs已成为PayPal的标准做法,用以构建基于Akka的反应式应用。因此,如果你的团队尚未考虑有状态系统,可以对此了解一下。目前PayPal、Facebook、Uber和微软均已采用了这种系统。

原文链接:How PayPal Scaled To Billions Of Transactions Daily Using Just 8VMs(译/孙薇 责编/钱曙光)

仅用8个虚拟机,PayPal是如何扩展至日处理数十亿事务的

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址