PayPal如何使用8个VM每天支撑数十亿个事务?

16-08-17 banq
              

Paypal将平时需要100个VM(虚拟机)才能支撑的每天数十亿点击降低为8个VM,甚至在CPU 90%时还能保持响应性?

Paypal已经迁移到基于Akka的Actor模型,并开源了他们的Reactive框架:squbs

有态服务至今在项目开始之初都不是首要选择,人们都是倾向于无态服务,Paypal的Actor模型实际是一种有态服务实现。

从EBay经验可以得出下面观点:

1.服务使用非常小的VM,每个VM只产生很低的吞吐量,基于Actor的reactive系统能够有效利用计算机资源,这样你能有效使用你的系统,而不是依赖一些所谓自动伸缩扩展的怪物。

2.将许多压力压在网络和路由基础设施,作为服务倾向于互连接性,需要能通过许多节点,这些都会增加延迟,降低用户体验。

3.大意味着浪费,服务跨数百个VM就会有固有的内部成本,比如管理 监视和不够效率的缓存。

4.小意味着更敏捷,服务跨数百个VM部署时需要很长时间。

5.每个VM能够更好更多地利用CPU,因为CPU不会自己变得更快,所以更多充分挖掘CPU潜力就变得重要了。

6.微服务需要建立在松耦合nanoservice之上,这样才能更易于维护和快速构建。

因此Paypal的系统有如下特点:

1.可扩展,从垂直到水平,垂直到多个处理器,水平扩展到数百个节点,这样支撑每天处理数十亿个请求。

2.延迟,可控在非常细的粒度。

3.弹性应付失败。

4.灵活调整服务边界

5.一个编程模型和文化:鼓励的可扩展性和简单性,包括干净的故障和错误处理。

很显然,Paypal需要一个比较薄的技术栈,不需要很多层次和可移动部件的技术栈,Akka和基于状态系统通常适合这样情况,因为它们将原本有状态系统需要设计很多层比如缓存层、数据库层等,降低为一种技术,只需要使用Akka即可,Paypal选择Akka而不是Erlang,因为他们有很多Java经验,Akka运行在Java上,否则需要学习很多Erlang技术。

使用Akka可以做到:

1.编写代码有条理,经得起推敲逻辑质疑。

2.编写代码易于测试

3.处理错误和失败场景更加自然,这是和很多基于JVM的传统模型相比的。

4.使用流化Streamlined 错误处理能编写更快 更弹性,更简单和更少Bug的代码。

当然,Paypal基于Akka之上又编写了自己的框架squbs,以及使用cubes的rhymes,这是用来创建模块层,用来构建nano-service纳米服务,称为"cubes"。

由于大多数服务做同样的事情——接受请求,使数据库调用读写数据库,调用其他服务,调用规则引擎,从缓存读取数据,写入缓存--他们能够抽象出来变成模式如 配器/业务流程(Orchestrator )模式和永久的流(Perpetual Stream)。

Squbs已经成为Paypal构建基于Akka的Reactive应用标准,如果你考虑有态系统,可以借鉴一下。

squbs: A New, Reactive Way for PayPal to Build Applications

原文:

How PayPal Scaled to Billions of Transactions Dail

[该贴被banq于2016-08-19 17:28修改过]

              

6