(理論) 分散式架構理念與目標

1.設計理念

分散式架構的核心理念就是按一定維度（功能、業務和領域等）對系統進行拆分，通用合理的拆分結構，實現各業務模組解耦，同時通過系統級容錯設計，在與廉價硬體基礎上構建高可用、可擴充套件的開發技術體系。

2.系統拆分原因與思路

2.1 拆分原則

• 單一職責
• 服務粒度適中
• 考慮團隊結構
• 以業務模型切入
• 演進式拆分
• 避免環形依賴和雙向依賴

2.2 執行過程

• 1.明確拆分原則和拆分需求。
• 2.梳理出業務模組和之間的依賴關聯關係。
• 3.按照業務為單位，拆分實體、以及應用工程單獨部署。
• 4.按照業務為單位拆分應用服務，避免環形依賴和雙向依賴。
• 5.抽離出公用的介面、實體，以及服務單獨部署為公用服務。

3.系統容錯

容錯是為了避免系統架構和業務層面發生故障而引起其所在系統的不穩定。容錯設計主要包括兩個方面：

3.1 架構設計層面

• 3.1.1 冪等
• 大部分請求都有時效性，同樣的請求隔了幾個小時再發送過來，大概率是新的業務而不會是導致的重試；因此冪等保證只要在一定時間內，重複的請求你不再消費即可；常用方式是採用一個分散式的快取，記錄請求中唯一標識的requestId或者訂單ID，對於每個請求，都判斷一下是否有快取記錄，有則直接跳過請求，或者返回第一次消費得到的結果(看上層業務需求)；快取的超時時間即為請求的有效判斷時間；
• 3.1.2 重試
• 重試必須先實現冪等，否則會破壞業務；重試頻率一般採用“有限次”、“指數級避退”，同一個請求，成功率是逐次遞減的，因此重試的頻率也應該逐漸降低，否則會浪費系統資源，重試的次數必須有限，否則容易產生死迴圈；重試的情況建議列白名單去重試，拒絕無腦重試；
• 3.1.3 非同步處理
• 請求響應式，通過rpc框架傳送請求後立即返回(一般返回成功則表明對方已經接收到請求)，通過rpc輪詢讀取結果或者通過傳送請求時提供的回撥介面返回結果；
• 事件驅動式，通過mafka等訊息中介軟體，請求方傳送請求至訊息中介軟體，被呼叫方消費中介軟體的訊息跑業務，並且將結果放到訊息中介軟體中，請求傳送方也通過消費中介軟體訊息獲取結果；
• 實際使用中，這兩種方式是綜合使用的，比如請求響應式的結果返回可以加上訊息中介軟體作為補償，也可以直接替換成訊息中介軟體方式；
• **** 3.1.4 服務降級****
• 針對爆炸性的流量衝擊，從整體的負載考慮，對一些服務進行有策略的放棄，以此緩解系統壓力，保證目前主要業務的正常執行。它主要是針對非正常情況下的應急服務措施：當此時一些業務服務無法執行時，給出一個統一的返回結果。 3.1.5 熔斷和限流
  為了應對效能過載的情形，高壓力