仅在8台虚拟机上，就实现了原本需要100台虚拟机才能实现的工作。甚至当CPU占用高达90%时仍能快速响应，这种Paypal前所未见的事务处理密度，却仅需之前十分之一的时间。在降低成本的同时，还考虑到了无需增加相应的计算基础架构就能获得企业成长——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和微软均已采用了这种系统。
