如何进行网站故障隔离

发布：2018-09-30 20:50:27 浏览：3416

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

在这个例子中，我们不仅展示了如何看待故障隔离的设计，还说明了这种设计的两个好处。第一个好处是，通道堵塞时，不会妨碍人们从共享房间移动到另一.个房间。第二个好处是，每个人都会立即知道哪个房间已经满了。与这个例子相反的是，每个房间都连接到一个共享通道上，通道被阻塞了，就很难判断是哪个房间满了，而从共享房间进人这个共享通道的人口只有一个。这时虽然这里的每个房间都是隔离的，但如果而且也不能从共享房间旅行到其他房间了。这个例子也说明了故障隔离的架构的第一个原则。

原则1:什么都不能共享

这一原则过于极端，从经济上来说不可行。但即使加此，它仍然是故障隔离的架构的起点。如果故障隔离的设计或架构的第一个原则是绝对不能共事任何东西。当然，对于某些公司来说，你想确保产能故障或系统故障不会引发多个系统的问题，就需要隔离系统组件。对于某些组件，这样做也许非常困难，如边界路由器或网关路由器。也就是说，考虑到某些情况下的经济和技术约束，这条原则应用得越全面，得到的结果就越好。

人们常常会忽略的方面是URI/URL。例如，考虑为不同的分组使用不同的子域。如果按照客户分组，那么可以考虑采用custlallscale.com到custNallscale.com，依此类推。理想状况下，域分组也涉及隔离的Web服务器和应用服务器以及那个URI/URL专用的数据库和存储。如果经济因素允许而又有相应的需求，那么你应该采用专门的负载均衡器、DNS和访问交换机。

如果你划分了两条泳道却让它们与一个共享数据库通信，那么从全局来看它们仍然是一个泳道。也许从服务角度看，你有两个较小的故障隔离区域(如应用服务器)，当一个应用服务器发生故障时，这种方法是有帮助的，但如果数据库发生了故障，那么这两个服务泳道都会停机。

原则2:什么都不能跨过泳道边界

在设计故障隔离的系统时，还有一个重要的原则。如果你有同步通信的系统，甚至是有异步通信的系统，那么它们就可能引发潜在的故障。虽然异步通信的系统引发这种故障的可能性较小，但在需求极大的场景中，超时设置不足以完成整个通信流程时，它们也会引发大量问题。

你不能构建了一个故障隔离的区域，同时却让这个区域与区域之外的东西通信。回想一下我们那个混凝土房间的比喻，混凝土房间和它们的通道是故障隔离的区域或域。大的共享房间是Intemet。如果不返回桌子所在的位置(我们的浏览器)，然后选择另一条通道，是不能从一个房间进人另一个房间的。这样我们就能知道瓶颈或问题所在的确切位置，然后找出处理这些问题的方法。

不同区域之间的任何通信以及我们上述场景中的任何通道之间的通信，都可能使故障隔离出现问题。一个通道中堆满了人，不仅可能引发这个通道的问题，还可能引发通过其他通道连接的房间的问题。如果没有全面的诊断，我们怎么能轻松地发现问题到底发生在哪里呢?反过来，任何一个房间堆满了人，也可能会给其他房间带来意想不到的影响，从而降低了房间的可用性。

原则3:在泳道内交易

考虑到网站建设故障隔离的名字和前面的原则，这个原则似乎应该是不言而喻的，但我们在很久之前就学到了不要做任何假设。在技术领域，假设就是灾难之母。你见到过泳者排在泳池边上准备出发，他们眼前却横置着一条条泳道的分道线吗?当然没有。不过，这样的障碍游泳倒是挺有趣的。这对于技术泳道来说同样如此。例如，声称自己创建了一个数据库泳道，这是不对的。交易是怎么到达数据库的?显然会有跨泳道的通信，而根据原则2，这种情况不应该发生。对于这个例子，你可能创建了一个池，但由于交易是要跨界的，所以根据我们的定义，它不是泳道。