温故而知新-可伸缩架构的最佳实践

这些经验起源于ebay，后来在国内经淘宝发扬光大。最近几年，ebay好像没有声音了，很多年轻的架构师可能已经不知道ebay了，早个几年，它还是世界的“淘宝”，“淘宝”是中国的ebay，类似于“百度”是中国的google。

在ebay，全球数亿的用户量，每天超过10亿的pv，数据量已PB计算，这些最佳实践可以说是ebay所有开发和运维的集体经验结晶，也是ebay为整个互联网作出的极大贡献。

我拿着这些最佳实践，在不同场合做了几次分享，现在再翻出来，重新复习一遍，也分享给每天为可伸缩，高并发拼搏的同学。

 

以下内容，尽可能的照搬ebay分享的原有内容，加了部分自己实践过程中的体会（蓝色部分）。

 

最佳实践#1、按功能分隔

 

相关的功能部分应该合在一起，不相关的功能部分应该分割开来——前几年，大家习惯叫SOA或者功能拆分，最近几年大家喜欢叫微服务。按功能拆分后，将会带来以下几个好处：

1、不想关的功能，将其应用逻辑、数据存储独立成一个应用而单独部署，在应对流量、数据量大增时，就可以对其进行单独的扩容而不影响其他模块。

2、开发管理，在大规模团队开发时，可以将团队分多个团队，每个小组负责其中一个应用，小组内部的协调就会方便很多。这点好处，也许大家容易忽略。

 

举个我经历过的反面教材：

某个大型实体零售公司，做科技转型，做电商。早期的系统商品、交易、会员、促销等所有模块全在一个大包里面，100多人到200人的开发团队全在一个代码工程下工作，任何一次代码更新，都会有大量的冲突，好不容易解决冲突，想启动开发环境进行调试，半个小时还没起来，开发机资源几乎全部耗尽。各位自行脑补是一个什么场景。过完春节后，离职申请堆了好高一摞，工位最多看到1/3的熟面孔。

 

最佳实践#2、水平拆分

 

按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系 统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载分解成许多我们有能力驾驭的小单元，让每个单元都能维持良好状态。这就是水平分割出场的时候了。

在应用层次，由于 eBay 将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。

 

应用层无状态，比较简单的实现是将用户id存放cookie中，每次请求会带上cookie，应用层根据cookie从集中存储（数据库、缓存）中获取相关的数据。也许会有一些年轻的架构师和开发同学有疑问：cookie不安全啊，每次传输cookie耗带宽啊，可以做session绑定啊等等，实践当中，经常会被问类似的问题，大家可以留言交流。

举个反面例子：

还是上面例子的那个公司，由于流量大增，一台服务器肯定是无法支撑所有请求的，所以就用了集群，集群内部有100多个节点，每次发布的时候，更新到70几个节点时，就会异常的慢，常常引起发布失败。导致这个的主要原因是请求是有状态的，集群内部需要维护session同步，否则用户第一次访问到第一个服务器，第二次访问到第二台服务器，就会出问题。

 

数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户 数据目前被分割到 20 台主机上，每台主机存放 1/20 的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID 尾数为 1 的放到第一 台主机，尾数为二的放到下一台，以此类推），有些是按照 ID 的区间分割（1-1M、1-2M 等等），有些用一个查找表，还有些是综合以上的策略。不过具体 的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。

 

数据库分隔，常说的分库分表，一旦做分库分表，会带来很多问题，比如跨库查询、统计等等，这需要大家仔细分析各种应用场景，然后做出最适合的拆分策略。

 

最佳实践 #3：避免分布式事务

看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的答案是，对于不相关的系统，放宽对它们的跨系统事务的保证。

左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi 的 Eric Brewer 十年前提出的 CAP 公理是这样说的：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于 24x7 运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate consistency）。

在 eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的 ACID 属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual consistency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。

对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。

 

放弃事务控制，对于很多开发同学来说难以接受，总会举出一堆的反例来证明必须有事务控制。我们仔细理解这一句话：“周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）”，可能能够帮助理解这一条最佳实践。

举个例子：

系统提供几个微服务模块：库存、促销、订单，订单模块下单的常规逻辑如下：

 

事务开始

1、查库存是否满足 （库存微服务提供的接口）

2、查积分是否满足（库存微服务提供的接口）

3、查优惠券是否满足（库存微服务提供的接口）

4、订单表新增订单信息

5、订单明细表新增订单明细

6、扣减库存

7、扣减积分

8、优惠券设置为已使用

事务提交

 

我们根据最佳实践“周密调整数据库操作的次序、异步恢复事件”，将下单逻辑调整为：

1、扣减库存（不成功返回）//首先扣减库存，是因为大家都在下单，库存最有可能扣减失败

2、扣减积分（不成功，回滚库存）//扣减积分，积分属于客户一人，很难产生冲突，当然也会有一个账号多个地方登陆，同时下单，但可能性小很多。

3、设置优惠券为已使用（不成功，回滚库存、回滚积分）//设置优惠券同积分类似。

4、单库事务开始

1）订单表新增订单信息

2）订单明细表新增订单明细

5、提交事务（事务失败，回滚库存、回滚积分、回滚优惠券）

6、如果以上某一个回滚步骤失败，记录回滚日志，异步处理恢复，处理失败，监控报警，人工干预。

 

通过以上调整，避免了分布式事务，同时保证了最终一致性。性能得到了大幅度的提升。坏处是增加了很多回滚操作，代码确实要多很多，大多数情况下，回滚逻辑不会被执行到。

保证最终一致性的策略还有很多，大家仔细分析，总会想到很多策略，这里重点强调一点，代码经过仔细的设计、完善测试的情况下，出现异常的情况是极少数的，我们应该平衡成本产出比，对于极少的异常情况，通过非常规方法处理，是可以接受的。

 

最佳实践 #4：用异步策略解耦程序

提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件 A 同步调用组件 B，那么 A 和 B 就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分必须共同进退——要伸缩 A 必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果 A推出B，那么非 B 推出非 A。也就 是说，若 B 不可用，则 A 也不可用。如果反过来 A 和 B 的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此时A和B 的可用性特征是相互独立的——即使 B 受困或者死掉，A 仍然能够继续前进。

整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过 SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程分解为阶段（stages or phases），然后将它们异步地连接起来，这是伸缩的关键。

 

这一条简单理解就是，有些操作客户是不需要实时知道结果的，那这种操作就可以异步处理，这样带来的好处是：把耗性能的，客户无需实时知道结果的操作异步之后，整个系统的实时响应得到大幅提升。举个例子：

下单流程：

1、下单

2、付款

3、配货

4、物流

5、收货

客户只关心下单是否成功、付款是否成功，至于怎么配货，怎么物流，客户是不怎么关心的，或者不需要付款成功后就马上告诉客户的。这样，配货逻辑就可以异步操作了。

反例：

还是之前例子里提到的同一个项目，货物存放在不同的仓库、库位，还要分批次，配货的逻辑就是：

根据客户信息判断应该从哪个仓库、库位、批次出货，然后进行库存扣减，因为数据量巨大，这是一个很耗性能的操作，

下单逻辑里，实时执行了配货的逻辑，导致整个下单过程很慢，搞一个促销，下单量一上来，系统就宕机了。

解决方案就是：

下单成功后，发送MQ，配货逻辑接收到MQ消息，执行配货逻辑。也许你会问，那怎么扣减库存，异步之后，告诉用户下单成功了，但是后面没货了怎么办？请仔细理解客户并不关心货是哪个仓库、哪个库位，哪个批次的，理解了这个场景，自然就很容易解决了。

 

最佳实践 #5：将过程转变为异步的流

用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。

还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平 均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从 异步处理中得益。

 

这一条和第四条差不多，但第四条更强调两个模块之前的解耦，第五条强调系统性能削峰。

 

最佳实践 #6：虚拟化所有层次

虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象 - 关系映射层抽象了数据库。负载均衡器和虚拟 IP 抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各 种分割增加额外的虚拟层次就成为重中之重。

在 eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑，路由逻辑会把特定的记录（如用户 XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的 O/R 层上实现的。这样虚拟化之后，我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。

搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。

以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。

 

这一条实践当中用得最多是1、虚拟IP，经常应用在双击互备，2、容器虚拟化比如docker，将所有的物理资源组成资源池，根据不同模块的资源利用率，动态调整资源。

 

最佳实践 #7：适当地使用缓存

最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能 随着时间而改变。

最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在 eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在 eBay，我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。

好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一 点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否 100% 正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。

做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好 会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。

 

这一条，很多同学都深有体会，但实践过程中，往往做得不太好。后面可能会写一篇如何使用缓存的文章。使用缓存的过程中，我们应该牢记以下几点：

1、缓存不应该在多个节点之前同步，早些年缓存同步方案很常见，比如session在集群内部同步。

2、必须设计一个好的机制，保证缓存数据已数据库的同步。

3、缓存就应该干缓存的事情，不应该把缓存当成持久化存储使用，很多同学讨论redis如何持久化，如何使用持久化，这会带来很多很多不可预计的问题和系统设计复杂度。我认为redis的持久化特性，主要是应对灾备和恢复场景的，至少我是这么用的。

4、缓存失效不应该导致系统流程失败，比如缓存失效了，读不到缓存，应用应该能够从DB读取数据进行计算。

5、不应该以缓存中的数据作为最终决策的依据，比如说缓存了库存数据，不能缓存中的库存扣减成功就能下单成功。

 

 

总结

可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为 0 的需求，比一切需求的优先级都高。

 

任何一个场景，需要不同的架构策略，没有一个架构策略能解决所有问题，也没有最好的架构，只有最合适的架构。很多同学一上来就会把淘宝、阿里的各种框架、最佳实践全用上，往往忽略了当前的业务场景、业务规模、预算、团队水平等等，而导致最终效果不佳。