仅在8台虚拟机上,就实现了原本需要100台虚拟机才能实现的工作。甚至当CPU占用高达90%时仍能快速响应,这种Paypal前所未见的事务处理密度,却仅需之前十分之一的时间。在降低成本的同时,还考虑到了无需增加相应的计算基础架构就能获得企业成长——Paypal日处理数十亿事务的系统是如何打造出来的?
Paypal已经迁移至基于Akka框架的Actor模型上,在《squbs:Paypal构建应用的全新响应式方法》一文中,Paypal讲述了整个演变经历,目前他们对squbs进行了开源,点击这里便可查看源码。
在选择项目需采用的实现方式时,我们对有状态服务的考虑还是不够。想要了解更多关于有状态服务的内容,请参考基于Caitie McCaffrey的精彩演讲所撰写的这篇文章《如今构建可扩展有状态服务的案例》,如果还不够令人信服的话,我们可以看看这个案例:《Facebook斥资190亿美元收购WhatsApp的架构》,其中WhatsApp使用Erlang(Akka的竞品)达成了惊人的吞吐量。
本文推荐这两篇的文章的原因在于,Paypal的文章在架构细节上并未提及太多,大多是在他们选择Akka的原因,以及迁移到Akka上的好处。不过,在激励我们不甘于现状、勇于创新方面,这篇文章仍是很有价值的案例。
采用很多虚拟机来提供服务的方案到底有什么问题呢?
考虑到以上因素,PayPal需要的系统应当拥有如下特质:
很明显PayPal需要更薄的堆栈,他们不希望堆栈中的层次与可移动部件过多。一般来说,Akka以及基于状态的系统很适合这一需求,因为这类系统可以将大块的堆栈分解为某一种技术。
PayPal选择了Akka而不是Erlang的原因在于,他们在Java方面的经验更丰富,而Akka正是运行在Java之上的。对于很多人来说,从头学习Erlang并不合适。
通过Akka,他们可以做到:
因此,PayPal立即在Akka顶层构建出了自己的框架——squbs,并通过它创建了一个模块化的层面,以构建被称为“cubes”的超微服务。cubes彼此对称,之间存在着松散对称的相互依赖性,并且只暴露Akka已经提供的信息接口。
PayPal的文章还提及了程序员在适应Akka代码的非线性本质时所遇到的困难,因此在采用这类系统时,所雇人员必须能够适应Akka/Scala培训。
由于很多服务都在做类似的工作——接收请求、发送数据库调用以读取/写入数据库信息、对其它服务进行调用、调用规则引擎、从缓存中拿取数据、向缓存写入内容等,这些服务能够通过类似Orchestrator Pattern与Perpetual Stream之类的模式来进行抽象。
Squbs已成为PayPal的标准做法,用以构建基于Akka的反应式应用。因此,如果你的团队尚未考虑有状态系统,可以对此了解一下。目前PayPal、Facebook、Uber和微软均已采用了这种系统。