限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

仅用 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:286036
用户头像

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

关注

评论

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

Soul网关源码阅读(十)自定义简单插件编写

Java 源码阅读 网关

关于Dapper实现读写分离的个人思考

yi念之间

重学JS | 玩转File API

梁龙先森

面试 大前端 编程语言 28天写作

认识产品经理(下)

让我思考一会儿

认识产品经理(第一章上)

让我思考一会儿

干货|更通用的P2P网络协议栈——Libp2p

QTech

IPFS Libp2p

讨论:Service层的接口是不是多此一举?

xcbeyond

Java 接口管理 28天写作

联发科推出天玑1200,新一年的头道“5G甜点”究竟滋味如何?

脑极体

Dubbo源码解析(1)-整体框架介绍

冰三郎

源码分析 dubbo RPC

简单易懂的单臂路由介绍及一看就会的实验

听了微信创始人张小龙的演讲,更加坚定Filecoin的光辉未来

时空云

分布式存储 IPFS Filecoin

Windows DHCP最佳实践(四)

BigYoung

运维 windows Windows Server 2012 R2 DHCP

大数据知识专栏 - MapReduce 的 Reduce端Join

小马哥

大数据 hadoop mapreduce 七日更

35+的测试人都去哪儿了?所谓“青春饭”真的只是在贩卖焦虑吗?

程序员阿沐

编程 程序员 软件测试 教程 测试工程师

云原生的理解

JiangX

容器 云原生 数字化转型 数字化 28天写作

剖析一站式分布式事务方案SeataFescar-Server

比伯

Java 编程 架构 面试 计算机

如果不完美,接受就好了「14/28」

道伟

28天写作

朋友问他是否该跳槽了?我是这么跟他说的

田维常

面试

Nginx实现在局域网内真正的ip_hash负载均衡​

会飞的猪

区块链交易所软件开发|区块链交易所APP系统开发

系统开发

2020出行之变(一):自动驾驶的“跃渊”时刻

脑极体

hive窗口函数/分析函数详细剖析

五分钟学大数据

Hive SQL

中金数据集团与腾讯云合力拓展信息安全、区块链业务领域

CECBC

区块链产业

虚言妙诀终虚见,面试躬行是致知,Python技术面试策略与技巧实战记录

刘悦的技术博客

Python 面试

为什么Java程序会执行一段时间后跑的更快?

Java架构师迁哥

soul数据同步(二)zookeeper同步策略

xzy

源码分析 网关 Soul网关 soul sou

做一枚旗帜Be a Flag

石君

28天写作

数字人民币带来更好支付体验 没有网络时也能使用

CECBC

数字人民币

nodejs中使用worker_threads来创建新的线程

程序那些事

多线程 nodejs 并发控制 程序那些事 子线程

团队复盘之kiss

张老蔫

28天写作

IT版“历史上的今天”

IT蜗壳-Tango

七日更

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