故障隔离水平最好的体系，是那些绝对不挪用它们的功效或数据规模以外的器械而且与之没有任何交互的体系。可以想象一组混凝土陪衬的房间，每个房间有一扇门，每扇门后面是一个长长的隔离通道，通道的止境有另一扇门；也就是说，一扇门可以拜访混凝土陪衬的房间，而另一扇门可以拜访一个共享的房间，该房间中有无限多个桌子和人。在每个混凝土房间中，有一条信息，坐在那很多桌子后面的某小我，可能须要这条信息。要获得这条信息，他就要沿着这个具有他所需信息的房间的专用通道走到个中，然后再返回本身地点的桌子。在完成这趟观光之后，他可以决议再去谁人房间，获取第二条信息，也可以决议沿着另一个通道，去另一个房间。任何人都不克不及直接从一个房间进人另一个房间，他必需经由远程观光能力获得本身想要的信息。假如太多人因为要到统一个房间而被堵在统一个通道中，那么共享房间中的人连忙就会知道，他们可以决议观光到另一个房间，也可以决议当场期待。

在这个例子中，我们不仅展现了若何对待故障隔离的设计，还解释了这种设计的两个利益。第一个利益是，通道堵塞时，不会妨害人们从共享房间移动到另一. 个房间。第二个利益是，每小我都邑立刻知道哪个房间已经满了。与这个例子相反的是，每个房间都衔接到一个共享通道上，通道被壅塞了，就很难断定是哪个房间满了，而从共享房间进人这个共享通道的生齿只有一个。这时固然这里的每个房间都是隔离的，但假如 并且也不克不及从共享房间观光到其他房间了。这个例子也解释了故障隔离的架构的第一个原则。

原则1:什么都不克不及共享

这一原则过于极端，从经济上来说弗成行。但即使加此，它仍然是故障隔离的架构的起点。假如故障隔离的设计或架构的第一个原则是绝对不克不及共事任何器械。当然，对于某些公司来说，你想确保产能故障或体系故障不会激发多个体系的问题，就须要隔离体系组件。对于某些组件，如许做也许异常艰苦，如界限路由器或网关路由器。也就是说，斟酌到某些情形下的经济和技巧束缚，这条原则运用得越周全，获得的成果就越好。

人们经常会疏忽的方面是URI/URL。例如，斟酌为分歧的分组应用分歧的子域。假如依照客户分组，那么可以斟酌采取custl allscale.com到custNallscale.com，依此类推。幻想状态下，域分组也涉及隔离的Web办事器和运用办事器以及谁人URI/URL专用的数据库和存储。假如经济身分许可而又有响应的需求，那么你应当采取专门的负载平衡器、DNS和拜访交流机。

假如你划分了两条泳道却让它们与一个共享数据库通讯，那么从全局来看它们仍然是一个泳道。也许从办事角度看，你有两个较小的故障隔离区域(如运用办事器)，当一个运用办事器产生故障时，这种办法是有赞助的，但假如数据库产生了故障，那么这两个办事泳道都邑停机。

原则2:什么都不克不及跨过泳道界限

在设计故障隔离的体系时，还有一个主要的原则。假如你有同步通讯的体系，甚至是有异步通讯的体系，那么它们就可能激发潜在的故障。固然异步通讯的体系激发这种故障的可能性较小，但在需求极年夜的场景中，超时设置不足以完成全部通讯流程时，它们也会激发年夜量问题。

你不克不及构建了一个故障隔离的区域，同时却让这个区域与区域之外的器械通讯。回忆一下我们谁人混凝土房间的比方，混凝土房间和它们的通道是故障隔离的区域或域。年夜的共享房间是Intemet。假如不返回桌子地点的地位(我们的阅读器)，然后选择另一条通道，是不克不及从一个房间进人另一个房间的。如许我们就能知道瓶颈或问题地点切实其实切地位，然后找出处置这些问题的办法。

分歧区域之间的任何通讯以及我们上述场景中的任何通道之间的通讯，都可能使故障隔离涌现问题。一个通道中堆满了人，不仅可能激发这个通道的问题，还可能激发经由过程其他通道衔接的房间的问题。假如没有周全的诊断，我们怎么能轻松地发明问题到底产生在哪里呢?反过来，任何一个房间堆满了人，也可能会给其他房间带来意想不到的影响，从而下降了房间的可用性。

原则3:在泳道内生意业务

斟酌到网站扶植故障隔离的名字和前面的原则，这个原则似乎应当是不问可知的，但我们在良久之前就学到了不要做任何假设。在技巧范畴，假设就是灾害之母。你见到过泳者排在泳池边上预备动身，他们面前却横置着一条条泳道的分道线吗?当然没有。不外，如许的障碍泅水却是挺有趣的。这对于技巧泳道来说同样如斯。例如，声称本身创立了一个数据库泳道，这是纰谬的。生意业务是怎么达到数据库的?显然会有跨泳道的通讯，而依据原则2，这种情形不该该产生。对于这个例子，你可能创立了一个池，但因为生意业务是要跨界的，所以依据我们的界说，它不是泳道。