何时实现网站故障隔离

要是天上掉馅饼该多好...但故障隔离不是免费的，而且并未便宜。虽然它有许多益处，但假如把平台上的每个功能都设计为故障隔离的，那成本就太高了，而且它可能还不会带来什么股东回报。
 
你应该在体系中实现适量的故障隔离，以便产生现实的股东回报。你大概接着会问:“好的，多谢，那你能告诉我如何做到这点吗?'

遗憾的是，答案取决于你特定的需求、发展速度、不可用性以及造成体系不可用的缘故原由、客户对可用性的期望值、签署的可用性承诺以及各种因素的组合，它们产生的组合数量伟大，以至于我们不能向你描述出你的环境究竟必须要什么。
 
简而言之，你可以应用一-些简单的原则来提升你的可扩展性和可用性。这里我们介绍了一些对你进行故障隔离来说最有效的原则。
 
方式1:把最赢利的功能放入泳道
 
无论你做什么，都要确保把最能赢利的功能精确地与故障和其他体系的需求束缚隔离开来。假如你运营的是一个电子商务站点，那么这可能是点击“购买”按钮触发的购买流程，也可能是处理名誉卡时的结账流程。假如你运营的是一个提供内容的站点，通过专有的广告发布体系赢利，那么就要确保广告发布体系的功能与体系其他统统功能星散开来。假如你的站点是靠日常的注册费赢利的，那么就要确保从注册到开账单的流程都被精确地故障隔离了。
 
你大概有一些次级流程也 与站点赢利的功能紧密相干，那么理所当然应该也考虑为它们施加泳道。例如，在一个电子商务站点中，可能必须要把搜索和欣赏功能都放入泳道。在一个提供内容的站点中，可能必须要把访问流量最大的区域放在它们本身的一个或多个泳道中，以帮助需求和产能推断。社交网络站点应该为最常被访问的个人信息页面悉数或部分创建泳道。
 
方式2:把最容易引发故障的功能放入泳道
 
假如你在赓续地实行季度故障回顾会议(如第8章所述)，你发现你站点中的某些组件在反复地引发故障，那么在未来的余量项目中，绝对应该考虑这些组件，并且应该把这些区域隔离起来。季度故障回顾会议的目的是从我们曩昔的错误中汲取教训。假如由需求造成的可用性问题反复发生，我们就应该把这些区域隔离起来，以防它们影响产品或平台的其他部分。
 
方式3:根据天然界限划分泳道
 
在多租户的SaaS体系中，这种方式尤其有效，这种体系通常必须要沿着Z轴扩展，必须要最大可扩展性的站点和平台通常都必须寄托沿Z轴的分段进行扩展，而最常用的是按照客户进行划分。虽然这种划分通常首先是在架构的存储或数据库层实现的，但是接下来，我们应该为从请求到数据存储或数据库的所有组件都创建泳道。
 
你可以把体系设计为在逐一条泳道中运营一个或多个“租户”。 假如你的平台适合这样做，那就充 通常，多租户意味着你试图通过共享资源而提升成本服从。在很多情况下，这种方式意味着分利用这一点。 假如你的某个租户特别很是忙，就给它单独分配一个泳道。而假如你的大多数租户对你的平台的使用率都很低，那么可以把它们分配到一个泳道中。原理大致如此。
 
故障隔离的设计备忘录故障隔离的架构的设计原则如下:
 
原则1:什么都不能共享(即尽可能少共享)。一个泳道内共享的东西越少，这个泳道的故障隔离性越好。
 
原则2:什么都不能跨过泳道边界。绝对不能跨泳道边界进行通讯，否则就是边界划分不精确。
 
原则3:在泳道内交易。你不能为服务创建泳道，由于这些服务之间的通讯违反了原则2。
 
设计故障隔离的架构的方式如下:
 
方式1:把最赢利的功能放入泳道。绝对不要让你的收款机受其他体系拖累。
 
方式2:把最容易引发故障的功能放入泳道。找出反复发作的故障的缘故原由，把它们隔离起来。
 
方式3:根据天然界限划分泳道。按照客户划分是很好的泳道划分方式。
 
虽然方式许多，但提升网站设计的可扩展性同时又不致让你的CFO心脏病发作的道路还很漫长。