写点什么

仅用 8 个虚拟机缩放至日处理数十亿事务,PayPal 是怎么做到的

  • 2016-09-21
  • 本文字数:1830 字

    阅读完需:约 6 分钟

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

PayPal 已将系统迁移至基于 Akka 的 Actor 模式。在 Squbs:PayPal 采用全新的反应式方法构建应用程序这篇文章中,PayPal 介绍了整个过程的来龙去脉。目前他们已将 Squbs 开源并发布至 GitHub

当项目需要采取一种 _ 做实事的方法 _ 时,有状态的服务模式依然没能获得足够重视。若要进一步了解有状态服务,建议阅读当下继续构建可扩展有状态服务的理由,这篇文章是根据Caitie McCaffrey 的讲话撰写的。如果这篇文章还不能让你信服,还有使用Akka 的竞品Erlang 实现极高吞吐率的WhatsApp: Facebook 斥资 190 亿美元所购买的 WhatsApp 体系结构

推荐上述文章的原因在于,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,以及微软都取得了不错的效果。

作者 Todd Hoff 阅读英文原文 How PayPal Scaled To Billions Of Transactions Daily Using Just 8VMs


感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-09-21 17:286017
用户头像

发布了 283 篇内容, 共 116.3 次阅读, 收获喜欢 62 次。

关注

评论

发布
暂无评论
发现更多内容

生产环境全链路压测建设历程 27:FAQ 之 业务模型相关

数列科技杨德华

28天写作

为什么泡泡玛特是一个好生意

lidaobing

28天写作 泡泡玛特

Python解释器和IPython

程序那些事

Python 数据分析 ipython 程序那些事 Python解释器

代码编译时自动完成白盒测试,这真的可以

华为云开发者联盟

c++ 测试 代码 框架

智联招聘的微前端落地实践——Widget

智联大前端

大前端

Redis学习笔记01:SDS 简单动态字符串

架构精进之路

redis 七日更 28天写作

云上独享资源池 自主灵活更安全

产品推荐

hive JOIN操作分析

梧桐

SpringCloud 从入门到精通 06--- Eureka服务端

Felix

Dubbo 就是靠它崭露头角!

yes

dubbo 后端 RPC

Java单例7种测试实践

叫练

单例模式 单例 手写单例 饿汉式 懒汉式

5 天开发接口系统技术小结

老魚

laravel 建站 接口开发 28天写作

作为社畜,如何做好精力管理

熊斌

精力管理 28天写作

28天瞎写的第二百一五天:为了看片儿折腾 Linux 的故事

树上

28天写作

新官上任,如何开始你的管理工作(下)

一笑

团队管理 管理 28天写作

微服务该如何拆分?

xcbeyond

微服务 方法论 架构设计原则 28天写作

HDFS SHELL详解(5)

罗小龙

hadoop 28天写作 hdfs shell

kafka如何做到无消息丢失配置

topsion

kafka 消息不丢失

智能合约APP开发|智能合约系统软件开发

系统开发

技术人小故事-团队愿景篇-第4段

Ian哥

28天写作

做视频最大的困难是什么?为什么要保持日更? | 视频号 28 天 (05)

赵新龙

28天写作

距离Java开发者玩转 Serverless,到底还有多远?

博文视点Broadview

前端大佬们都在推荐的“绿宝书”你值得拥有

华章IT

JavaScript typescript 大前端 web开发 犀牛书

2021,加料!

云原生

没有调查,就没有发言权 Jan 12, 2021

王泰

28天写作

基于网络开放可编程技术构建新一代网络设备运管平台

华为云开发者联盟

运维 网络 运维自动化 金融

【JS】防止浏览器控制台被直接查看(2)

德育处主任

JavaScript chrome 大前端 js 28天写作

Elasticsearch 核心概念

escray

elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

技术干货!HDFS读写原理和代码简单实现

华为云开发者联盟

hadoop hdfs 架构 MRS 元数据

SpringCloud 从入门到精通 07--- 订单服务和支付服务注册进Eureka

Felix

这5个让人窒息的烂代码,你看完都忍不了

华为云开发者联盟

GitHub 代码 代码注释 null

仅用8个虚拟机缩放至日处理数十亿事务,PayPal是怎么做到的_语言 & 开发_Todd Hoff_InfoQ精选文章