分佈式億級流量整體架構設計原則

架構目標

  1. 高可用性

整體系統可用性最低99.9%,目標99.99%。全年故障時間整個系統不超過500分鐘,單個系統故障不超過50分鐘。

  1. 高可擴展性 系統架構簡單清晰,應用系統間耦合低,容易水平擴展,業務功能增改方便快捷。

  2. 低成本 增加服務的重用性,提高開發效率,降低人力成本;

  3. 最終一致性

服務設計能滿足數據最終一致性,能方便、快捷的滿足三方、或者對方對賬需求。

  1. 質量要求

我們要求在系統設計時候要兼顧下面的各個質量要求

圖片

架構總體原則

圖片

DID原則解釋

Design(D)設計20倍的容量;Implement(I)實施3倍的容量;Deploy(D)部署1.5倍的容量

原因:DID爲產品擴展提供了經濟,有效,及時的方法

要點:在早期考慮可擴展性可以幫助團隊節省時間和金錢。在需求發生大約一個月前實施(寫代碼),在客戶蜂擁而至的幾天前部署。

例子:“什麼時候該在可擴展性上投入”有些輕率的回答是,最好在需要的前一天投入和部署。如果你能夠多做到達需要改善可擴展性方案的前一天部署,那麼 這筆投資的時機最佳,而且有助於實現公司財務和股東利益的最大化。 讓我們面對現實,及時投入和部署根本就不可能,即使可能,也無法確定具體的時間,而且會帶來很多風險。

DID(設計-實施-部署):思考問題和設計方案,爲方案構建系統和編寫代碼;實際安裝或者部署方案。

設計(Design):DID方法的設計(D)階段聚集在擴展到20倍和無限大之間,通過如今可擴展性大會,把領導者和工程師團隊聚集在一起,共同討論產品的擴展瓶頸,這是在DID設計階段發現和確定需要擴展部分的一個好辦法。

實施(I,Implement):我們把規模需求的範圍縮小到更接近現實,例如當前規模的3~20倍。

部署(D,Deploy):在部署階段資產的成本較高,如果是一家適度高增長的公司,也許我們可以把最大產能提高到1.5倍;如果是一家超高增長的公司,也許我們可以把最大產能提高到5倍。擴展具有彈性,它既可以擴張也可以收縮,因此靈活性是關鍵,因爲你需要響應客戶的請求,隨着規模的收縮和擴張,在系統之間調整容量

架構設計原則

  1. 業務平臺化
  • 業務平臺化,相互獨立。 如交易平臺、倉儲平臺、物流平臺、支付平臺、廣告平臺等
  • 基礎業務下沉,可複用。如用戶、商品、類目、促銷、訂單等 (參考目前核心繫統)。
  1. 核心業務、非核心業務分離

核心業務與非核心業務分離,核心業務精簡(利於穩定),非核心業務多樣化。

  1. 隔離不同類型的業務
  • 交易業務是簽訂買家和賣家之間的交易合同,需要優先保證高可用性,讓用戶能快速下單
  • 對高併發要求很高的業務,應該跟普通業務隔離
  1. 區分主流程、輔流程

分清哪些是主流程。運行時,優先保證主流程的順利完成,輔流程可以採用後臺異步的方式。避免輔流程的失敗導致主流程的回滾。

應用架構設計要點

  1. 穩定性原則
  • 一切以穩定爲中心
  • 架構儘可能簡單、清晰
  • 不過度設計
  1. 解耦、拆分
  • 穩定部分與易變部分分離
  • 核心業務與非核心業務分離
  • 主業務與輔業務分離
  • 應用與數據分離
  • 服務與實現細節分離
  1. 抽象化
  • 應用抽象化:應用只依賴服務抽象,不依賴服務實現細節、位置
  • 數據庫抽象化:應用只依賴邏輯數據庫,不需要關心物理庫的位置和分片
  • 服務器抽象化:應用虛擬化部署,不需要關心實體機配置,動態調配資源
  1. 松耦合
  • 同步調用時,需要設置超時時間、對調用異常時候的failover處理。
  • 非核心業務儘量異步化:核心、非核心業務之間,儘量異步解耦。
  • 跨業務線(比如分期樂、桔子、鼎盛間)調用需要採用HTTP接口方式,避免底層業務邏輯耦合和依賴。
  1. 容錯設計
  • 服務自治:服務能彼此獨立修改、部署、發佈和管理,避免一個服務發生災害引發連鎖反應(一定要對mq、rpc、db、redis的異常容錯處理、異常包括超時、業務異常、系統異常等)。
  • 集羣容錯:應用系統集羣,避免單點。
  • 多機房容災:多機房部署,多活。

6 數據的一致性原則

  • 小規模分佈或不分佈的業務確保可用、數據可靠、一致,即A & C兼顧;
  • 中型分佈系統需要考慮【BASE-最終一致性】,如果涉及到訂單、交易、清結算等數據敏感場景,保持數據最終一致性是最基本原則;
  • 大規模分佈式系統在不涉及訂單、交易、清結算等數據敏感場景上可以考慮【有損服務】;。

架構分解原則

圖片

架構依賴原則

  1. 依賴穩定部分
  • 穩定部分不依賴易變部分
  • 易變部分可以依賴穩定部分
  • 要求:避免循環依賴
  1. 跨域弱依賴

跨業務域調用時,儘可能異步弱依賴

  1. 基本服務依賴
  • 基本服務不能向上依賴流程服務
  • 組合服務、流程服務可以向下依賴基本服務
  • 條件:基本服務穩定
  1. 平臺服務依賴
  • 平臺服務不依賴上層應用
  • 上層應用可依賴平臺服務
  • 條件:平臺服務穩定
  1. 核心服務依賴
  • 核心服務不依賴非核心服務
  • 非核心服務可依賴核心服務
  • 條件:核心服務穩定

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章