在這個例子中，我們不僅展示了如何看待故障隔離的設(shè)計，還說明了這種設(shè)計的兩個好處。第一個好處是，通道堵塞時，不會妨礙人們從共享房間移動到另一. 個房間。第二個好處是，每個人都會立即知道哪個房間已經(jīng)滿了。與這個例子相反的是，每個房間都連接到一個共享通道上，通道被阻塞了，就很難判斷是哪個房間滿了，而從共享房間進人這個共享通道的人口只有一個。這時雖然這里的每個房間都是隔離的，但如果 而且也不能從共享房間旅行到其他房間了。這個例子也說明了故障隔離的架構(gòu)的第一個原則。
原則1:什么都不能共享
這一原則過于極端，從經(jīng)濟上來說不可行。但即使加此，它仍然是故障隔離的架構(gòu)的起點。如果故障隔離的設(shè)計或架構(gòu)的第一個原則是絕對不能共事任何東西。當(dāng)然，對于某些公司來說，你想確保產(chǎn)能故障或系統(tǒng)故障不會引發(fā)多個系統(tǒng)的問題，就需要隔離系統(tǒng)組件。對于某些組件，這樣做也許非常困難，如邊界路由器或網(wǎng)關(guān)路由器。也就是說，考慮到某些情況下的經(jīng)濟和技術(shù)約束，這條原則應(yīng)用得越全面，得到的結(jié)果就越好。
人們常常會忽略的方面是URI/URL。例如，考慮為不同的分組使用不同的子域。如果按照客戶分組，那么可以考慮采用custl allscale.com到custNallscale.com，依此類推。理想狀況下，域分組也涉及隔離的Web服務(wù)器和應(yīng)用服務(wù)器以及那個URI/URL專用的數(shù)據(jù)庫和存儲。如果經(jīng)濟因素允許而又有相應(yīng)的需求，那么你應(yīng)該采用專門的負(fù)載均衡器、DNS和訪問交換機。
如果你劃分了兩條泳道卻讓它們與一個共享數(shù)據(jù)庫通信，那么從全局來看它們?nèi)匀皇且粋€泳道。也許從服務(wù)角度看，你有兩個較小的故障隔離區(qū)域(如應(yīng)用服務(wù)器)，當(dāng)一個應(yīng)用服務(wù)器發(fā)生故障時，這種方法是有幫助的，但如果數(shù)據(jù)庫發(fā)生了故障，那么這兩個服務(wù)泳道都會停機。
原則2:什么都不能跨過泳道邊界
在設(shè)計故障隔離的系統(tǒng)時，還有一個重要的原則。如果你有同步通信的系統(tǒng)，甚至是有異步通信的系統(tǒng)，那么它們就可能引發(fā)潛在的故障。雖然異步通信的系統(tǒng)引發(fā)這種故障的可能性較小，但在需求極大的場景中，超時設(shè)置不足以完成整個通信流程時，它們也會引發(fā)大量問題。
你不能構(gòu)建了一個故障隔離的區(qū)域，同時卻讓這個區(qū)域與區(qū)域之外的東西通信。回想一下我們那個混凝土房間的比喻，混凝土房間和它們的通道是故障隔離的區(qū)域或域。大的共享房間是Intemet。如果不返回桌子所在的位置(我們的瀏覽器)，然后選擇另一條通道，是不能從一個房間進人另一個房間的。這樣我們就能知道瓶頸或問題所在的確切位置，然后找出處理這些問題的方法。
不同區(qū)域之間的任何通信以及我們上述場景中的任何通道之間的通信，都可能使故障隔離出現(xiàn)問題。一個通道中堆滿了人，不僅可能引發(fā)這個通道的問題，還可能引發(fā)通過其他通道連接的房間的問題。如果沒有全面的診斷，我們怎么能輕松地發(fā)現(xiàn)問題到底發(fā)生在哪里呢?反過來，任何一個房間堆滿了人，也可能會給其他房間帶來意想不到的影響，從而降低了房間的可用性。
原則3:在泳道內(nèi)交易
考慮到網(wǎng)站建設(shè)故障隔離的名字和前面的原則，這個原則似乎應(yīng)該是不言而喻的，但我們在很久之前就學(xué)到了不要做任何假設(shè)。在技術(shù)領(lǐng)域，假設(shè)就是災(zāi)難之母。你見到過泳者排在泳池邊上準(zhǔn)備出發(fā)，他們眼前卻橫置著一條條泳道的分道線嗎?當(dāng)然沒有。不過，這樣的障礙游泳倒是挺有趣的。這對于技術(shù)泳道來說同樣如此。例如，聲稱自己創(chuàng)建了一個數(shù)據(jù)庫泳道，這是不對的。交易是怎么到達數(shù)據(jù)庫的?顯然會有跨泳道的通信，而根據(jù)原則2，這種情況不應(yīng)該發(fā)生。對于這個例子，你可能創(chuàng)建了一個池，但由于交易是要跨界的，所以根據(jù)我們的定義，它不是泳道。
本文地址：http://123beaconmarketing.com//article/3895.html
