如果天上失落馅饼该多好…但故障隔离不是免费的，并且并未便宜。固然它有许多利益，但假如把平台上的每个功效都设计为故障隔离的，那成本就太高了，并且它可能还不会带来什么股东回报。

你应当在体系中实现适量的故障隔离，以便发生现实的股东回报。你也许接着会问:“好的，多谢，那你能告知我若何做到这点吗?'

遗憾的是，谜底取决于你特定的需求、成长速度、弗成用性以及造成体系弗成用的原因、客户对可用性的期望值、签订的可用性许诺以及各类身分的组合，它们发生的组合数目伟大，以至于我们不克不及向你描写出你的情况毕竟须要什么。

简而言之，你可以运用一-些简略的原则来进步你的可扩大性和可用性。这里我们介绍了一些对你进行故障隔离来说最有效的原则。

办法1:把最赚钱的功效放入泳道

无论你做什么，都要确保把最能赚钱的功效准确地与故障和其他体系的需求束缚隔分开来。假如你运营的是一个电子商务站点，那么这可能是点击“购置”按钮触发的购置流程，也可能是处置信誉卡时的结账流程。假如你运营的是一个供给内容的站点，经由过程专有的告白宣布体系赚钱，那么就要确保告白宣布体系的功效与体系其他一切功效分别开来。假如你的站点是靠日常的注册费赚钱的，那么就要确保从注册到开账单的流程都被准确地故障隔离了。

你也许有一些次级流程也 与站点赚钱的功效慎密相干，那么理所当然应当也斟酌为它们施加泳道。例如，在一个电子商务站点中，可能须要把搜刮和阅读功效都放入泳道。在一个供给内容的站点中，可能须要把拜访流量最年夜的区域放在它们本身的一个或多个泳道中，以赞助需乞降产能推想。社交收集站点应当为最常被拜访的小我信息页面全体或部门创立泳道。

办法2:把最轻易激发故障的功效放入泳道

假如你在赓续地履行季度故障回想会议(如第8章所述)，你发明你站点中的某些组件在重复地激发故障，那么在未来的余量项目中，绝对应当斟酌这些组件，而且应当把这些区域隔离起来。季度故障回想会议的目标是从我们曩昔的毛病中汲取教训。假如由需求造成的可用性问题重复产生，我们就应当把这些区域隔离起来，以防它们影响产物或平台的其他部门。

办法3:依据天然界线划分泳道

在多租户的SaaS体系中，这种办法尤其有效，这种体系平日须要沿着Z轴扩大，须要最年夜可扩大性的站点和平台平日都必需依附沿Z轴的分段进行扩大，而最常用的是依照客户进行划分。固然这种划分平日起首是在架构的存储或数据库层实现的，然则接下来，我们应当为从要求到数据存储或数据库的所有组件都创立泳道。

你可以把体系设计为在一一条泳道中运营一个或多个“租户”。 假如你的平台合适如许做，那就充 平日，多租户意味着你试图经由过程共享资本而进步成本效力。在很多情形下，这种办法意味着分应用这一点。 假如你的某个租户异常忙，就给它零丁分派一个泳道。而假如你的年夜多半租户对你的平台的应用率都很低，那么可以把它们分派到一个泳道中。道理年夜致如斯。

故障隔离的设计备忘录故障隔离的架构的设计原则如下:

原则1:什么都不克不及共享(即尽可能少共享)。一个泳道内共享的器械越少，这个泳道的故障隔离性越好。

原则2:什么都不克不及跨过泳道界限。绝对不克不及跨泳道界限进行通讯，不然就是界限划分不准确。

原则3:在泳道内生意业务。你不克不及为办事创立泳道，因为这些办事之间的通讯违反了原则2。

设计故障隔离的架构的办法如下:

办法1:把最赚钱的功效放入泳道。绝对不要让你的收款机受其他体系拖累。

办法2:把最轻易激发故障的功效放入泳道。找出重复发生发火的故障的原因，把它们隔离起来。

办法3:依据天然界线划分泳道。依照客户划分是很好的泳道划分办法。

固然办法许多，但进步网站设计的可扩大性同时又不致让你的CFO心脏病发生发火的途径还很漫长。