PayPal 仅用 8 个虚拟机缩放至日处理数十亿事务

测试账号

传统方式下日处理十亿笔事务的系统可能需要数百台虚拟机，PayPal 只用 8 台虚拟机就做到了这一切，CPU 占用率高达 90% 时依然可以提供快速响应，这种 PayPal 以往从未达到的事务处理密度，实现过程所需时间只是传统方法的 1/10，在降低成本的同时无须为计算基础架构扩容即可帮助该组织顺利应对增长。这是怎么做到的？



PayPal 已将系统迁移至基于 Akka 的 Actor 模式。在 Squbs：PayPal 采用全新的反应式方法构建应用程序这篇文章中(https://www.paypal-engineering.com/2016/05/11/squbs-a-new-reactive-way-for-paypal-to-build-applications/)，PayPal 介绍了整个过程的来龙去脉。目前他们已将 Squbs 开源并发布至 GitHub (https://github.com/paypal/squbs)。

当项目需要采取一种做实事的方法时，有状态的服务模式依然没能获得足够重视。若要进一步了解有状态服务，建议阅读当下继续构建可扩展有状态服务的理由(http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html)，这篇文章是根据Caitie McCaffrey 的讲话撰写的。如果这篇文章还不能让你信服，还有使用Akka 的竞品Erlang 实现极高吞吐率的WhatsApp： Facebook 斥资 190 亿美元所购买的 WhatsApp 体系结构(http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)。

推荐上述文章的原因在于，PayPal 这篇文章对体系结构的介绍不详尽，而是用了较多篇幅介绍导致他们选择 Akka 的原因，以及迁移至 Akka 所获得的收益。但这篇文章依然为“不走寻常路”的做法提供了宝贵的激励和示范。

为服务使用大量虚拟机，这种做法有什么问题？

• 使用吞吐率非常低，极小规模的虚拟机运行服务。基于 Actor 的反应式系统最大的亮点在于可以更高效地利用计算资源，这样即可大幅缩小系统规模，避免传统做法下“简单粗暴”的自动伸缩。
• 会对网络和路由基础架构造成极大压力。由于服务趋向于更高程度的互联，请求可能需要经历大量网络跃点，这会增加延迟并降低用户体验。
• 越大越贵。包含数百个虚拟机的服务在管理、监控，以及无效缓存（Ineffective caching）等方面存在极高的固有成本。
• 越小越敏捷。将服务部署到数百台虚拟机，这个过程将花费大量时间。
• 更充分地利用每台虚拟机上更多 CPU。由于 CPU 无法进一步提速，基础架构需要能更高效地利用每台虚拟机上装备的更多 CPU。
• 需要通过易于维护和快速构建，并且松散耦合的 NanoService 构建微服务。谁都不想面对包含大量层面的复杂体系，你需要对不同服务的作用获得更高能见度，而无须深入到层层叠叠的代码中。
  

考虑到上述因素，PayPal 希望搭建一套具备下列特征的系统：

• 可缩放，不仅要能横向缩放至数百个节点，还要能纵向缩放至更多处理器，借此实现每天处理数十亿请求的目标。
• 低延迟，可以通过极为细化的粒度进行控制。
• 面对故障具备弹性。
• 可灵活调整服务边界。
• 通过编程模型和企业文化促进可缩放能力和简易性，以及更简洁的故障和错误处理机制。
  

毫无疑问 PayPal 希望使用更“瘦”的堆栈，他们不想自己的堆栈包含大量不同层面的技术和活动部件。通常来说，Akka 和基于状态的系统很适合这一需求，这种方式可将包含大块组件的堆栈“分解”为某种单一技术。PayPal 选择 Akka 而非 Erlang 的原因在于他们对 Java 有更丰富的经验，而 Akka 就是在 Java 的基础上运行的。对很多人来说，从零开始学习 Erlang 并不现实。

借助 Akka 他们可以：

• 编写更易于解释的代码
• 编写更易于测试的代码
• 相比使用 JVM 的传统模式，更自然地处理错误和故障场景
• 编写更快速、更具弹性、更简单的代码，以更流畅的方式处理错误，减少 Bug 数量
  

于是 PayPal 立刻以 Akka 为基础编写了自己的框架，这个框架名为 Squbs ，使用该名称是为了与“Cubes”保持押韵。借此可为名为“Cube”的 NanoService 的构建创建模块化技术层。Cube 是相互对称的，不同 Cube 之间的依赖性也是对称且松散的，只暴露出 Akka 已经提供的消息接口。

该文还介绍了程序员在采用 Akka 代码时，此类代码非线性的本质可能造成的困难，因此你可能还需要雇佣接受过 Akka/Scala 相关培训的人员。

由于大部分服务的用途较为类似：接收请求，调用并读写数据库，调用其他服务，调用规则引擎，从缓存中获取数据，写入缓存… 因此可以通过类似 Orchestrator Pattern 和 Perpetual Stream 等模式对服务进行抽象。

Squbs 已成为 PayPal 构建基于 Akka 的反应式应用程序的标准做法。如果你的团队尚未考虑过有状态系统，也许这种做法值得一试，毕竟这种做法在 PayPal、Facebook、Uber，以及微软都取得了不错的效果。