如何进行网站故障隔离

故障隔离程度最好的体系，是那些绝对不调用它们的功能或数据范围以外的东西并且与之没有任何交互的体系。可以想象一组混凝土衬托的房间，每个房间有一扇门，每扇门后面是一个长长的隔离通道，通道的终点有另一扇门；也就是说，一扇门可以访问混凝土衬托的房间，而另一扇门可以访问一个共享的房间，该房间中有无限多个桌子和人。在每个混凝土房间中，有一条信息，坐在那很多桌子后面的某个人，可能必须要这条信息。要得到这条信息，他就要沿着这个具有他所需信息的房间的专用通道走到其中，然后再返回本身所在的桌子。在完成这趟旅行之后，他可以决定再去那个房间，获取第二条信息，也可以决定沿着另一个通道，去另一个房间。任何人都不能直接从一个房间进人另一个房间，他必须经过远程旅行才能得到本身想要的信息。假如太多人由于要到统一个房间而被堵在统一个通道中，那么共享房间中的人马上就会知道，他们可以决定旅行到另一个房间，也可以决定就地等待。


 
在这个例子中，我们不仅展示了如何看待故障隔离的设计，还说明了这种设计的两个益处。第一个益处是，通道堵塞时，不会妨碍人们从共享房间移动到另一. 个房间。第二个益处是，每个人都会立即知道哪个房间已经满了。与这个例子相反的是，每个房间都连接到一个共享通道上，通道被壅塞了，就很难判断是哪个房间满了，而从共享房间进人这个共享通道的人口只有一个。这时虽然这里的每个房间都是隔离的，但假如 而且也不能从共享房间旅行到其他房间了。这个例子也说明了故障隔离的架构的第一个原则。
 
原则1:什么都不能共享
 
这一原则过于极端，从经济上来说不可行。但即使加此，它仍然是故障隔离的架构的起点。假如故障隔离的设计或架构的第一个原则是绝对不能共事任何东西。当然，对于某些公司来说，你想确保产能故障或体系故障不会引发多个体系的问题，就必须要隔离体系组件。对于某些组件，这样做大概特别很是困难，如边界路由器或网关路由器。也就是说，考虑到某些情况下的经济和技术束缚，这条原则应用得越周全，得到的效果就越好。
 
人们常常会忽略的方面是URI/URL。例如，考虑为不同的分组使用不同的子域。假如按照客户分组，那么可以考虑采用custl allscale.com到custNallscale.com，依此类推。理想状态下，域分组也涉及隔离的Web服务器和应用服务器以及那个URI/URL专用的数据库和存储。假如经济因素许可而又有相应的需求，那么你应该采用专门的负载均衡器、DNS和访问交换机。
 
假如你划分了两条泳道却让它们与一个共享数据库通讯，那么从全局来看它们仍然是一个泳道。大概从服务角度看，你有两个较小的故障隔离区域(如应用服务器)，当一个应用服务器发生故障时，这种方式是有帮助的，但假如数据库发生了故障，那么这两个服务泳道都会停机。
 
原则2:什么都不能跨过泳道边界
 
在设计故障隔离的体系时，还有一个紧张的原则。假如你有同步通讯的体系，甚至是有异步通讯的体系，那么它们就可能引发潜在的故障。虽然异步通讯的体系引发这种故障的可能性较小，但在需求极大的场景中，超时设置不足以完成整个通讯流程时，它们也会引发大量问题。
 
你不能构建了一个故障隔离的区域，同时却让这个区域与区域之外的东西通讯。回想一下我们那个混凝土房间的比喻，混凝土房间和它们的通道是故障隔离的区域或域。大的共享房间是Intemet。假如不返回桌子所在的位置(我们的欣赏器)，然后选择另一条通道，是不能从一个房间进人另一个房间的。这样我们就能知道瓶颈或问题所在的确切位置，然后找出处理这些问题的方式。
 
不同区域之间的任何通讯以及我们上述场景中的任何通道之间的通讯，都可能使故障隔离出现问题。一个通道中堆满了人，不仅可能引发这个通道的问题，还可能引发通过其他通道连接的房间的问题。假如没有周全的诊断，我们怎么能轻松地发现问题到底发生在哪里呢?反过来，任何一个房间堆满了人，也可能会给其他房间带来意想不到的影响，从而降低了房间的可用性。
 
原则3:在泳道内交易
 
考虑到网站建设故障隔离的名字和前面的原则，这个原则好像应该是不言而喻的，但我们在很久之前就学到了不要做任何假设。在技术领域，假设就是灾祸之母。你见到过泳者排在泳池边上预备出发，他们面前目今却横置着一条条泳道的分道线吗?当然没有。不过，这样的停滞游泳倒是挺风趣的。这对于技术泳道来说同样如此。例如，声称本身创建了一个数据库泳道，这是舛错的。交易是怎么到达数据库的?显然会有跨泳道的通讯，而根据原则2，这种情况不应该发生。对于这个例子，你可能创建了一个池，但因为交易是要跨界的，所以根据我们的定义，它不是泳道。