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

仅在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和微软均已采用了这种系统。

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2016-10-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

为什么开源可以提高程序员的编程技能?

我已经写了很多年的软件。最近我意识到,我越涉及(致力于,结合于等)开源技术,我写出来的代码就更好。这不由地让我疑惑起来:难道里面有什么相关性或因果关系吗?

10730
来自专栏花叔的专栏

解读小程序的新能力---获取群ID和群名称等群信息

5月8日微信小程序有公布了一个新功能:获取群ID和群名称等群信息,官方有一句话是这么介绍它的用处的: 现在,通过最新的接口能力,开发者可以通过群ID判断用户是否...

58160
来自专栏java达人

软件开发接力赛的最后一棒:上线发布

新产品新功能开发、测试完成后,就需要上线发布,可能中间还有个预发的过程,但一般的小团队没有精力也没有能力去维护这么多的环境。上线之后,绝非万事大吉,你将面临一大...

18780
来自专栏Kirito的技术分享

以Dubbo为例,聊聊如何为开源项目做贡献

Github 上有众多优秀的开源项目,大多数 IT 从业者将其当做了予取予求的工具库,遇到什么需求,先去 Github 搜一把,但有没有想过有一天自己也可以给开...

14730
来自专栏WeTest质量开放平台团队的专栏

TScanCode助您打造健康代码!

WeTest腾讯质量开放平台隆重推出腾讯互娱研发部自研C++静态代码扫描工具TScanCode。助力游戏开发者高效精准的打造健康游戏代码。

1.6K50
来自专栏Albert陈凯

2018-08-06 数据权限管理权限管理的目标是什么?安全与便利的矛盾,有解么?总结常见开源方案基于开发平台服务入口的权限管控思路

https://blog.csdn.net/colorant/article/details/78672404

34520
来自专栏带你撸出一手好代码

做游戏与web的区别 - 服务器篇【1】

在一间游戏公司的两个部门待过, 前一个部门以做web开发为主,后一个部门做游戏开发,我在两边都是做后端的。

25920
来自专栏申龙斌的程序人生

搞定GTD - 掌控流程之三:组织整理

在明确意义那一步,只能去掉没有意义的项目和事情,在这一步才是GTD最复杂和最核心的流程,有人将第二步和第三步合在一起。对于OmniFocus来说,经过这个步骤后...

34090
来自专栏微信终端开发团队的专栏

微信 Android 模块化架构重构实践(下)

重构整体架构不是一件容易事,通常也不太可能让整个团队停下来只做重构。本文是微信 Android 模块化架构重构实践的下篇,主要分享模块化架构重构的一点点经验。

1.7K50
来自专栏大数据挖掘DT机器学习

如何入门 Python 爬虫?

刚做完一个跟python爬虫相关的项目,也来说说自己的经验,希望对想学习python爬虫的人有所帮助。 既然问的是如何入门,我想一定是助学者,而且我觉...

39590

扫码关注云+社区

领取腾讯云代金券