何時實現網站故障隔離

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