如何進行網站故障隔離

故障隔離程度最好的系統，是那些絕對不調用它們的功能或數據范圍以外的東西并且與之沒有任何交互的系統?？梢韵胂笠唤M混凝土襯托的房間，每個房間有一扇門，每扇門后面是一個長長的隔離通道，通道的盡頭有另一扇門；也就是說，一扇門可以訪問混凝土襯托的房間，而另一扇門可以訪問一個共享的房間，該房間中有無窮多個桌子和人。在每個混凝土房間中，有一條信息，坐在那許多桌子后面的某個人，可能需要這條信息。要得到這條信息，他就要沿著這個具有他所需信息的房間的專用通道走到其中，然后再返回自己所在的桌子。在完成這趟旅行之后，他可以決定再去那個房間，獲取第二條信息，也可以決定沿著另一個通道，去另一個房間。任何人都不能直接從一個房間進人另一個房間，他必須經過長途旅行才能得到自己想要的信息。如果太多人因為要到同一個房間而被堵在同一個通道中，那么共享房間中的人立刻就會知道，他們可以決定旅行到另一個房間，也可以決定就地等待。
在這個例子中，我們不僅展示了如何看待故障隔離的設計，還說明了這種設計的兩個好處?？壳皞€好處是，通道堵塞時，不會妨礙人們從共享房間移動到另一.個房間。第二個好處是，每個人都會立即知道哪個房間已經滿了。與這個例子相反的是，每個房間都連接到一個共享通道上，通道被阻塞了，就很難判斷是哪個房間滿了，而從共享房間進人這個共享通道的人口只有一個。這時雖然這里的每個房間都是隔離的，但如果而且也不能從共享房間旅行到其他房間了。這個例子也說明了故障隔離的架構的靠前個原則。
原則1:什么都不能共享
這一原則過于極端，從經濟上來說不可行。但即使加此，它仍然是故障隔離的架構的起點。如果故障隔離的設計或架構的靠前個原則是絕對不能共事任何東西。當然，對于某些公司來說，你想確保產能故障或系統故障不會引發多個系統的問題，就需要隔離系統組件。對于某些組件，這樣做也許非常困難，如邊界路由器或***路由器。也就是說，考慮到某些情況下的經濟和技術約束，這條原則應用得越全面，得到的結果就越好。
人們常常會忽略的方面是URI/URL。例如，考慮為不同的分組使用不同的子域。如果按照客戶分組，那么可以考慮采用custlallscale.com到custNallscale.com，依此類推。理想狀況下，域分組也涉及隔離的Web服務器和應用服務器以及那個URI/URL專用的數據庫和存儲。如果經濟因素允許而又有相應的需求，那么你應該采用專門的負載均衡器、DNS和訪問交換機。
如果你劃分了兩條泳道卻讓它們與一個共享數據庫通信，那么從全局來看它們仍然是一個泳道。也許從服務角度看，你有兩個較小的故障隔離區域(如應用服務器)，當一個應用服務器發生故障時，這種方法是有幫助的，但如果數據庫發生了故障，那么這兩個服務泳道都會停機。
原則2:什么都不能跨過泳道邊界
在設計故障隔離的系統時，還有一個重要的原則。如果你有同步通信的系統，甚至是有異步通信的系統，那么它們就可能引發潛在的故障。雖然異步通信的系統引發這種故障的可能性較小，但在需求極大的場景中，超時設置不足以完成整個通信流程時，它們也會引發大量問題。
你不能構建了一個故障隔離的區域，同時卻讓這個區域與區域之外的東西通信?；叵胍幌挛覀兡莻€混凝土房間的比喻，混凝土房間和它們的通道是故障隔離的區域或域。大的共享房間是Intemet。如果不返回桌子所在的位置(我們的瀏覽器)，然后選擇另一條通道，是不能從一個房間進人另一個房間的。這樣我們就能知道瓶頸或問題所在的確切位置，然后找出處理這些問題的方法。
不同區域之間的任何通信以及我們上述場景中的任何通道之間的通信，都可能使故障隔離出現問題。一個通道中堆滿了人，不僅可能引發這個通道的問題，還可能引發通過其他通道連接的房間的問題。如果沒有全面的診斷，我們怎么能輕松地發現問題到底發生在哪里呢?反過來，任何一個房間堆滿了人，也可能會給其他房間帶來意想不到的影響，從而降低了房間的可用性。
原則3:在泳道內交易
考慮到網站建設故障隔離的名字和前面的原則，這個原則似乎應該是不言而喻的，但我們在很久之前就學到了不要做任何假設。在技術領域，假設就是災難之母。你見到過泳者排在泳池邊上準備出發，他們眼前卻橫置著一條條泳道的分道線嗎?當然沒有。不過，這樣的障礙游泳倒是挺有趣的。這對于技術泳道來說同樣如此。例如，聲稱自己創建了一個數據庫泳道，這是不對的。交易是怎么到達數據庫的?顯然會有跨泳道的通信，而根據原則2，這種情況不應該發生。對于這個例子，你可能創建了一個池，但由于交易是要跨界的，所以根據我們的定義，它不是泳道。