何时实现网站故障隔离

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

相关行业资讯

相关视频推荐