關鍵詞總結：隔離設計概念（Bulkheads/隔板）、按服務種類隔離、按用戶請求隔離
隔離設計概念
隔離設計對應的單詞是 Bulkheads，中文翻譯爲隔板。這個術語是用在造船上的，也就是船艙裏防漏水的隔板。軟件設計也存在“漏水”，爲了不讓“故障”蔓延開來，需要使用“隔板”技術，來將架構分隔成多個“船艙”來隔離故障。
一般來說，對於系統的分離有兩種方式，一種是以服務的種類來做分離，一種是以用戶來做分離。
按服務種類隔離
每個服務對應自己的數據庫，每個數據庫只保存和其業務相關的數據和處理的狀態，每個服務都對外提供業務調用接口。微服務所推薦的架構方式。這種架構在系統隔離上做得比較好，但是也存在一些問題。
- 如果多板塊數據獲取與多個服務調用
由於按服務種類隔離，同時獲得多個板塊的數據和調用多個服務，響應時間增長性能降低。 - 如果有大數據平臺
每個服務對應自己的數據庫，如果有大數據平臺，就需要把這些數據都抽取到一個數據倉庫中進行計算，增加了數據合併的複雜度。需要藉助某種框架或中間件來收集數據到一個數據倉庫。 - 如果業務邏輯或是業務流程需要跨板塊
一個板塊的故障會導致整個流程走不下去，導致整體業務故障。需要保障業務流程中各個子系統的高可用性，並且在業務流程上做成 Step-by-Step 的方式 - 如果跨板塊交互
板塊之間需要藉助消息隊列中間件來以發佈/訂閱的方式進行順暢溝通，以降低板塊之間在溝通時因爲等待其他板塊的響應而產生的阻塞問題。 - 多個板塊中分佈式事務的問題
需要類似“二階段提交” 這樣的方案來確保數據的一致性。
按用戶請求隔離
將用戶分成不同的組，在後端把同一個服務根據這些不同的組分成不同的實例。讓同一個服務對於不同的用戶進行冗餘和隔離，當服務實例掛掉時，只會影響其中一部分用戶，而不會導致所有的用戶無法訪問。即“多租戶”模式，我們可以將客戶進行分類，例如將申請大額資源服務的用戶分配至獨立的一個或多個服務實例中，將申請小額資源服務的用戶分配至共享的一個或多個服務實例中。
多租戶通常的三種做法：
- 完全獨立的設計。每個租戶有自己完全獨立的服務和數據。
- 數據分區獨立，服務共享。多租戶的服務是共享的，但數據是分開隔離的。
- 服務共享，數據分區共享。每個租戶的數據和服務都是共享的。
三種方案各有優缺點，如圖所示
隔離設計關鍵點
- 隔離粒度
對業務需求和系統進行詳細的分析，確保能定義出恰當的業務隔離粒度，過大和過小都不好。 - 取捨評估
無論是按服務種類隔離還是按用戶請求隔離，需要考慮複雜度、成本、性能、資源分配等的問題。要找到一個適合這些問題的方案，或一個折中的方案，以確定哪些事情對隔離設計來說是必須的，哪些是可以捨棄的。 - 設計模式選用
隔離模式需要與一些設計模式（高可用、重試、異步、消息中間件，流控、熔斷等）的方式配套使用。 - 自動化運維與管控工具
爲了降低分佈式系統的運維複雜度，需要藉助自動化運維工具來提高運維人員對系統指標及資源利用率方面的管理效率。 - 監控系統
需要一個非常完整的監控系統，能對所有服務進行監控
參考資料：
左耳聽風（極客時間）鏈接：
http://gk.link/a/10f5D
GitHub鏈接：
https://github.com/lichangke/LeetCode
CSDN首頁：
https://me.csdn.net/leacock1991
歡迎大家來一起交流學習