【架构即未来】构建故障隔离的架构

避免故障造成更大影响的方法论

这也只是美好的愿景，就是画的大饼。——ljl

故障隔离架构

一些术语

• 泳道（swim lane）：一种形象的描述故障隔离的方式，选手不会影响到除了自己泳道外的选手。
• 豌豆荚（Pod）：代表一组客户或者一组功能。像豌豆荚中的豌豆一样。
  • 豌豆荚分类（Podding）：为了故障隔离把数据和功能进行分组的行为。
  • 豌豆荚组（Pods）：用来表示服务的群组，在其他时间表示数据的分离。

从系统的角度来看，豌豆荚的方式并不是完全隔离故障，隔离保持在组件水平。

• 碎片（Shard）：数据库结构或者存储子系统的描述。

  • 分片（Sharding）：将系统分成不同故障域，保证一个碎片的失败不会影响到其它系统的部分。

• 条（Sliver）：即碎片

• 块（Chunk）：即豌豆荚组

• 集群（Cluster）：会和群组（Pool）交替使用，特别是当有一个共享的会话或者状态概念时，但有时用来指主备配置的高可用性解决方案。

• 群组（Pool）：常被引用指一组执行类似任务的服务器。

这些术语对于初次接触的人来说可能有点难以理解，但是最终怎么称呼在你自己，喜欢就好，关键在于一个正确的设计——允许在高请求压力下可以拓展和优雅的失败。

故障隔离的好处

好处有很多，如明显提高可用性和可拓展性，减少上市时间和降低开发成本，使应用版本回滚变得容易，可以在网站/应用/平台仍然在给客户提供服务的情况下推出新功能。

故障隔离和可用性：限制影响

当你用电不当，就会跳闸，不会让你错误的用电方式影响除了你房间以外的更大区域。

就是上述道理，当故障隔离域或泳道在平台或系统架构级别失败时，你只会失去泳道服务的功能、地区和用户。
好的泳道架构会保证你危害的局部性，不好的则会造成大的影响，你不会愿意因为邻居的电饭锅短路而让你们小区都没有电可以用的。
下面给出一些实际的例子：
Healthcare.gov是美国医疗保险交易系统。
2010年3月23日*患者保护和可负担医疗法案（PPACA）*在美国被签署成法律，此后不久就开始构建医疗保险交易系统。

最初的架构是单一门户的网站，创建相互关联的网格服务，服务大多数美国人的需求。但是当时网站的可用性和响应速度都糟糕的惊人。问题主要原因如下：

• 政府未能整合和管理多个独立的承包商，没有人为整个解决方案负责。
• 政府也没有落实可以监督解决方案上线后成功运作的管理和过程。
• 政府从未想过让有经验的架构师设计故障隔离和可拓展的解决方案。
  该系统有多个服务，且这些服务相互关联并且依赖其他服务完成交易。除此之外，该系统还依赖多个其它第三方系统，如退伍军人管理局、社会安全局等。服务调用时创建一个串行同步链，这条服务支持链上结点越多，出问题的可能就越大，这种效应被称为“系统系列故障的乘法效应"。
  这是面向服务的设计中常见的故障，如果每个服务依赖都是同步的，故障将沿着同步链传播。在这个过程中出现的问题，将会来自整个环境的多个来源，各个组件之间相互关联，都有可能减缓整个解决方案。

那么该如何解决这个问题呢？

• 按州创建故障隔离区。将数据进一步分割，将显著减少响应时间。系统复杂性和排除故障难度显著降低，可拓展性将提高，大大改善平均服务恢复时间和缺陷解决时间。
• 保证基本服务的高可用和冗余度，继续分解，进一步隔离故障。
  • 超量供给。以高过系统正常服务的需要提供资源，以此提高可用性。就是可能会造成成本有“亿”点高。
  • 多重分解。推荐这种方式，如按不同地理位置分解服务和客户，如果客户搬家，就将数据迁移即可。

故障隔离与可用性：事件检测和分辨

出现问题可以立刻聚焦到对应的隔离泳道，针对泳道提问“是否刚刚在这里发布了代码？”“日志有什么异常？”等问题，大大节省工作量。

故障隔离与可拓展性

• 泳道之间不要有任何同步通信。
• 在适当的超时和放弃保护机制下与其它的泳道进行异步调用。
• 不与本泳道之外的其它服务进行任何面向连接的通信。

故障隔离与上市时间

好的架构提升灵活性。
如果你运营某个电子商务平台，你可能会有代码、对象、方法、模块、服务器和数据库集中在结账、查找、比较、浏览、运输和库存管理等。团队致力于这些方面，拥有专业的方法允许更快的新功能研发和更快的解决已知或现有的事故和问题。总体来说因为开发更快，交付速度的加快可能会导致更短的产品上市时间。

故障隔离与成本

显而易见的会降低成本。

你可能会认为运营额外的网站会比运营单一的网站耗费更多的资金，网站数量越多运营费用也越多。
这是真的，多数企业希望拥有可以经受住地理隔离的灾难的产品，在不同程度上投资灾难恢复措施，以帮助减轻这些灾难的影响。
假设有适当的故障隔离架构，运行三四个合适的故障隔离数据中心的资本支出可以显著低于运行两个完全冗余的数据中心。

可以尝试计算失去的机会（失去的收入），系统故障导致的交易量的损失和高客户流失率是可以测量的。这种当前损失和未来收入损失的比较可以用来确定实施故障隔离架构是否值得。

如何进行故障隔离

大多数的故障隔离系统绝对不与功能或数据边界之外的任何东西发生调用和互动关系。

原则1-绝不共享

当然~完全的不共享做不到。

共享可能导致一个组件的问题影响多个系统，导致大面积的问题。（如数据库的问题影响整个系统）
在一些领域，如边界或网关的路由器、财务。这可能是难以做到的。不过话说回来，在没有这个障碍的前提下，越是彻底的运用这个原则，结果会越好。

原则2-泳道的边界不可逾越

我们倾向于没有任何通信发生在故障隔离区以外和从不允许同步通信。

原则3-交易发生在泳道旁边

例如已经建立了数据库用到的说法是不正确的。交易如何到数据库？跨越泳道的通信将要发生，但是根据原则2，这是不该发生的事。在这种情况下，也许你已经创建了一个服务器群组，但因为交易越界，按照我们的定义它不是一个泳道。

何时实施故障隔离

天下没有免费的午餐。

故障隔离也不是免费的，也未必是便宜的。
虽然它有许多好处，但是想想你的平台能坚持多久，值得你花费那么多来做故障隔离吗。你的股东们得不到立即的回报，这也会是一个问题。

所以你应该实现适当数量的故障隔离，以产生积极的股东回报。
你可能会问：“好吧，谢谢，告诉我该怎么做？”
不幸的是，答案取决你的的特定需求，我们不能准确的描述在你的环境中到底需要做什么。

不过有一些简单的规则可以帮助我们提高可扩展性和可用性。

办法1-泳道与盈利

确保把和盈利关系密切的系统和可能失败产生问题的系统适当的隔离。

电子商务网站与利益最密切的是购买流程。
内容网站与利益最密切的是广告系统。
收费的反复注册网站与利益最密切的是注册到收费的过程。

办法2-泳道是事故的最大来源

某些组件多次引发事故，你一定要考虑这些组件未来的预留空间并隔离这部分。

再一再二不再三

办法3-泳道与天然隔离

对于多重SaaS系统非常有用。

通常，多重服务（multitenant）表明你试图从共享中获得成本效益。在许多情况下，这种方法意味着你可以把系统设计成在单一泳道中运行一个或多个应用。如果你的平台是这样的，应该充分的利用它。如果某个服务特别忙，那么给他分配一个专用的泳道。如果大部分服务的利用率很低，那么就把它们都分配到一个泳道。

如何测试故障隔离

一个简单的方法。
将设计概要画在平板上，然后：

1. 系统之间通信画虚线
2. 泳道存在的地方画实线
3. 画用户指向最后一个系统的箭头
   如果虚线穿过实线，那么就违反了泳道原则。
   箭头跨越了实线就违反了原则三。

结论

故障隔离架构原则如下：
原则1：绝不共享。泳道共享的越少，其故障隔离度就越高。
原则2：不跨越泳道。同步通信从不跨越泳道。如果跨越了泳道，那么边界的划分是不正确的。
原则3：交易发生在泳道。不可能建立多服务泳道，因为那些服务通信将违反原则2。
故障隔离架构的方法如下：
方法1：盈利的泳道。千万别把收款机和其它系统混在一起。
方法2：泳道是事故的最大来源。确定造成反复发生问题的根源，然后隔离它们。
方法3：泳道的天然隔离。客户的边界是最好的泳道隔离索。