絕對不要實現(xiàn)且一定要減少單點數(shù)障。在架構(gòu)圖上我出單點實例。盡量采用主動/主動配置。通過多個實景大化可用性。盡量采用主動/主動配置，不要用主動被動解決方案。利用均衡器均衡跨服務實例的流量。對于單例模式，使用主動/被動配置的控制。

在數(shù)學中，單元素集合是只有一個元素的集合，如{A}。在程序設計中，單例模式指的是一種設計模式，它模仿了數(shù)學概念，限制了一個類只能實例化一個對象。這種設計模式對協(xié)調(diào)資源非常有用，但程序員常為了省事而過度使用它，這個話題我們之后再討論。在系統(tǒng)架構(gòu)中，單例模式，或者更恰當?shù)卣f是單例反模式，被稱為單點故障(SPOF)也就是說，當系統(tǒng)中的某個組件只有一個實例時，一旦該實例出故障，就會造成系統(tǒng)范圍的影響。



SPOF在系統(tǒng)中隨處可見，從單個的Web服務器到單個的網(wǎng)絡設備，但系統(tǒng)中最常見的SPOF是數(shù)據(jù)庫。其原因在于數(shù)據(jù)庫是最難擴展到多個節(jié)點上的，因此它只有一個實例。在圖9-1中，即使登錄、搜索和結(jié)賬服務器都有冗余，數(shù)據(jù)庫仍是SPOF。更精的是，所有服務池都依賴于這一個數(shù)據(jù)庫。雖然任何SPOF都不好，但數(shù)據(jù)庫SPOF的問題更大，如果數(shù)據(jù)庫速度下降或者期讀了，那么對數(shù)據(jù)庫進行同步調(diào)用的所有服務池都將受到這一事件影響。

我們常說給客戶的一句口頭禪是“一切都會出故障”。這句話適用于服務器、存儲系統(tǒng)、網(wǎng)絡設備和數(shù)據(jù)中心。只要你知道的，都會出故障。
 
雖然很多人認為數(shù)據(jù)中心是不會出故障的，但多年來，我們自己經(jīng)歷了十幾次數(shù)據(jù)中心運行中斷。高可用的存儲區(qū)域網(wǎng)絡也是如此，雖然它們比舊的SCSI硬盤陣列可靠得多，但仍舊會出故障。

大多數(shù)解決SPOF的方法是申請另一臺硬件，如X軸擴展所示的通過克隆服務，讓每種服務都有兩個或更多個實例在運行。遺憾的是，事實并非總是如此簡單。讓我們回頭再看看編寫單例模式的步驟。雖然不是所有的單例類都不允許在多臺服務器上運行一個服務，但有些實現(xiàn)絕對會讓你免于遭受可怕的后果。較簡單的情況是，如果代碼中有一個類，用于從用戶賬戶中減去基金，用單例模式實現(xiàn)它就會讓用戶的余額免于不測，如成為負數(shù)。如果把這段代碼放在兩臺獨立的服務器上，沒有額外的控制措施或聯(lián)絡信號，則很可能會造成兩個事務同時在用戶賬戶中記人借額，從而導致錯誤或不想發(fā)生的狀況。對于這種情況，我們需要修復代碼，或者依賴外部控制來預防。但最令人滿滿意的解決方案是修復代碼，在多個主機上實現(xiàn)服務，通常我們需要快速修復SPOF。作為本原則的最后一個要點，我們接下來將討論幾個快速修復方法。

第一個方法最簡單，是使用主動/被動配置。一個服務在一臺服務器上主動運行，在另外一臺服務器上被動運行(不接收流量)。這種熱/冷配置，常被用作刪除數(shù)據(jù)庫SPOF的第一步。接下來的方法是用系統(tǒng)中的另一個組件控制數(shù)據(jù)訪問。如果SPOF是服務，那么用數(shù)據(jù)庫鎖可以控制數(shù)據(jù)的訪問。如果SPOF是數(shù)據(jù)庫，那么可以設置主一從配置，由應用控制數(shù)據(jù)訪問，寫更新操作由主數(shù)據(jù)庫完成，讀選擇操作由從數(shù)據(jù)庫完成。最后一個用于修復SPOF的配置是負載均衡器。如果Web服務器或應用服務器的一個服務是SPOF，且在代碼中不能消除，那么可以利用負載均衡器把一個用戶的請求只發(fā)送給池中的一臺服務器。這是通過會話 cookie實現(xiàn)的，即設置用戶的瀏覽器，且允許負載均衡器每次都把該用戶的請求重定向到同一個Web或應用服務器，從而形成一種一致狀態(tài)。

我們介紹了幾種消除SPOF的方法，在不能及時修改代碼的情況下可以輕松地實現(xiàn)它們。但是最后的方法最好，即修復代碼，允許網(wǎng)站設計服務的多個實例在不同的物理服務器上運行，從而盡可能消除SPOF。記住，“一切都會出故障”，所以當SPOF出故障時，請不要吃驚。