要是天上掉餡餅該多好...但故障隔離不是免費的，而且并不便宜。雖然它有很多好處，但如果把平臺上的每個功能都設計為故障隔離的，那成本就太高了，而且它可能還不會帶來什么股東回報。
 
你應該在系統(tǒng)中實現(xiàn)適量的故障隔離，以便產(chǎn)生實際的股東回報。你也許接著會問:“好的，多謝，那你能告訴我如何做到這點嗎?'


 
遺憾的是，答案取決于你特定的需求、發(fā)展速度、不可用性以及造成系統(tǒng)不可用的原因、客戶對可用性的期望值、簽署的可用性承諾以及各種因素的組合，它們產(chǎn)生的組合數(shù)量巨大，以至于我們不能向你描述出你的環(huán)境究竟需要什么。
 
簡而言之，你可以應用一-些簡單的原則來提高你的可擴展性和可用性。這里我們介紹了一些對你進行故障隔離來說最有用的原則。
 
方法1:把最賺錢的功能放入泳道
 
無論你做什么，都要確保把最能賺錢的功能正確地與故障和其他系統(tǒng)的需求約束隔離開來。如果你運營的是一個電子商務站點，那么這可能是點擊“購買”按鈕觸發(fā)的購買流程，也可能是處理信用卡時的結(jié)賬流程。如果你運營的是一個提供內(nèi)容的站點，通過專有的廣告發(fā)布系統(tǒng)賺錢，那么就要確保廣告發(fā)布系統(tǒng)的功能與系統(tǒng)其他一切功能分離開來。如果你的站點是靠日常的注冊費賺錢的，那么就要確保從注冊到開賬單的流程都被正確地故障隔離了。
 
你也許有一些次級流程也 與站點賺錢的功能緊密相關(guān)，那么理所當然應該也考慮為它們施加泳道。例如，在一個電子商務站點中，可能需要把搜索和瀏覽功能都放入泳道。在一個提供內(nèi)容的站點中，可能需要把訪問流量最大的區(qū)域放在它們自己的一個或多個泳道中，以幫助需求和產(chǎn)能推測。社交網(wǎng)絡站點應該為最常被訪問的個人信息頁面全部或部分創(chuàng)建泳道。
 
方法2:把最容易引發(fā)故障的功能放入泳道
 
如果你在不斷地執(zhí)行季度故障回顧會議(如第8章所述)，你發(fā)現(xiàn)你站點中的某些組件在反復地引發(fā)故障，那么在將來的余量項目中，絕對應該考慮這些組件，并且應該把這些區(qū)域隔離起來。季度故障回顧會議的目的是從我們過去的錯誤中吸取教訓。如果由需求造成的可用性問題反復發(fā)生，我們就應該把這些區(qū)域隔離起來，以防它們影響產(chǎn)品或平臺的其他部分。
 
方法3:根據(jù)自然界限劃分泳道
 
在多租戶的SaaS系統(tǒng)中，這種方法尤其有用，這種系統(tǒng)通常需要沿著Z軸擴展，需要最大可擴展性的站點和平臺通常都必須依靠沿Z軸的分段進行擴展，而最常用的是按照客戶進行劃分。雖然這種劃分通常首先是在架構(gòu)的存儲或數(shù)據(jù)庫層實現(xiàn)的，但是接下來，我們應該為從請求到數(shù)據(jù)存儲或數(shù)據(jù)庫的所有組件都創(chuàng)建泳道。
 
你可以把系統(tǒng)設計為在一一條泳道中運營一個或多個“租戶”。 如果你的平臺適合這樣做，那就充 通常，多租戶意味著你試圖通過共享資源而提高成本效率。在許多情況下，這種方法意味著分利用這一點。 如果你的某個租戶非常忙，就給它單獨分配一個泳道。而如果你的大多數(shù)租戶對你的平臺的使用率都很低，那么可以把它們分配到一個泳道中。原理大致如此。
 
故障隔離的設計備忘錄故障隔離的架構(gòu)的設計原則如下:
 
原則1:什么都不能共享(即盡可能少共享)。一個泳道內(nèi)共享的東西越少，這個泳道的故障隔離性越好。
 
原則2:什么都不能跨過泳道邊界。絕對不能跨泳道邊界進行通信，否則就是邊界劃分不正確。
 
原則3:在泳道內(nèi)交易。你不能為服務創(chuàng)建泳道，因為這些服務之間的通信違背了原則2。
 
設計故障隔離的架構(gòu)的方法如下:
 
方法1:把最賺錢的功能放入泳道。絕對不要讓你的收款機受其他系統(tǒng)拖累。
 
方法2:把最容易引發(fā)故障的功能放入泳道。找出反復發(fā)作的故障的原因，把它們隔離起來。
 
方法3:根據(jù)自然界限劃分泳道。按照客戶劃分是很好的泳道劃分方法。
 
雖然方法很多，但提高網(wǎng)站設計的可擴展性同時又不致讓你的CFO心臟病發(fā)作的道路還很漫長。