分佈式架構碎片

轉載:https://www.cnblogs.com/imyalost/p/15318976.html

異地多活

定義:廣域的分佈式架構;

目的:容量擴展,資源彈性;

實質:多個不同地域不同規模的數據中心;

收益:更強的容災能力,用戶就近接入能力;

容器集羣

特點:開箱即用;

優點:從多業務複雜性→生產多樣性;

管理:服務標識&版本標記,便於集羣管理;

原理:基礎鏡像配置多個服務節點,可通過預分發方式達到熱啓動;

彈性調度

1、擴容

  • 垂直擴容:選擇合適的機器
    • CPU繁忙程度;
    • 網絡流量情況;
    • 內存容量情況;
    • 單節點實例數量;
  • 水平擴容

2、縮容:實例遷移合併,避免資源散碎;

3、注意事項

  • 控制每臺物理機上最大可部署實例數;
  • 高性能&核心業務集羣,單臺物理機實例數<邏輯CPU數量;
  • 非核心業務集羣,單臺物理機實例數可以>邏輯CPU數量;

監控體系

作用:指標監控、數據展示、告警訂閱通知;

支撐:爲性能測試&性能優化場景提供數據支撐和問題定位能力;

特性:實時監控、可視化、統計報表、長期存儲及覆盤支撐能力;

CICD三部曲

  • 自動化執行(提交&檢查&編譯&打包&測試&部署&運營)
  • 一切皆服務;
  • 一切皆資源;

服務框架選型

  • I/O模型
  • 代碼規範
  • 通信協議
  • 負載均衡
  • 序列化協議
  • 開源框架對比

分佈式架構改造

目的:讓系統無狀態化/有狀態的信息封裝在一定範圍內,避免影響系統水平擴展;

前提條件

  • 應用微服務化;
  • 分佈式服務框架:服務註冊&發現&管理+RPC框架+消息隊列+分佈式數據庫/文件系統
  • 分佈式session:可以通過Redis或者分佈式ID等服務來解決;

什麼是去IOE?

  • IBM小型機:分佈式緩存;
  • Oracle數據庫:MySQL&PGSQL&NOSQL&TSDB;
    • 業務數據:線上業務熱數據→關係型數據庫(事務)
    • 非業務數據:監控&離線計算&非實時性數據
  • EMS高端存儲:分佈式文件系統→HBASE、Spark等;

解決了什麼問題?

  • 水平擴展:應用層、容量規劃;
  • 垂直擴展:按業務域做垂直拆分(避免業務擴展帶來的邏輯複雜度提升);
  • 按照業務類型或者功能做劃分;
    • 應用:展示層,webview等,只做數據展示和渲染;
    • 服務:按照業務類型和邏輯劃分處理,類似DDD模型;
    • 數據:按照業務域做垂直拆分,分庫分表拆實例;

常見的架構類型

  • 主從模式:master-slave,可用性較高;
  • 選舉機制:leader選舉機制,維護機制比較複雜;

配置中心運行模式

  • 常見的配置中心組建:Apollo、Nacos;
  • config推送:主動推送最新配置數據到client(低時延,適合數據量較小的情況);
  • config拉取:client定時拉取最新的配置數據(複雜,管理client狀態/心跳,延時較高,無法及時通知,適合數據量大的情況);
  • 優化思路:通過配置信息版本號,比對決策是否需要更新(更新需要proxy);

分佈式消息框架

消息類型

  • 實時消息:MQ、kafka;
  • 延時消息:可以理解爲Job調度任務;
  • 作用:應用間的消息傳遞;

實時消息

  • 異步解耦
    • 降低系統耦合;
    • 區分調用與被調用者的處理邏輯;
    • 解決不同系統之間語言&數據結構&速率差異(削峯填谷);
  • 注意事項
    • 最終一致性:消息最終可達/不可達反饋(訂閱&投遞&確認&回執);
    • 消息有序性:接收發送消息時間的先後順序;
  • 典型問題
    • 消息是否被消費?
    • 成功/失敗(重試機制);
    • 增長消費狀態標識(ACK,失敗放單獨隊列,重試);
    • 容錯處理;
    • 失敗/異常重試;
    • 消息持久化存儲;

分佈式數據分層

解決了什麼問題?

  • 分庫分表:數據水平切割,通過sharding路由規則訪問;
  • 主備切換:一主多備高可用架構,數據寫主庫讀從庫;
  • 讀寫分離:需要注意數據一致性問題以及數據同步延時問題;

應用服務化改造

1、分層設計

  • 對DB訪問層統一抽象封裝,形成數據訪問層(DAL),降低重構和DB拆分難度;
  • 垂直劃分
    • 服務層:web(webview)和app(application);
    • 業務邏輯層;
    • 數據層;
    • 說明:上層依賴下層,下層不依賴上層;

2、分層判斷原則

  • 層級職責是否清晰;
  • 層級設計收斂(不同層的修改是否會影響其他層級);
  • 儘量使用源生數據類型;

3、微服務化改造

  • 水平劃分、服務顆粒度細化爲單一的功能單元(DDD領域驅動設計)
  • 優點是提升系統可維護性(模塊化)、擴展性(水平擴容)和研發效率;
  • 拆分時需要注意,獨立&重要&穩定的業務服務做拆分,避免高頻業務更新影響全局;

服務調度與負載均衡

服務調度:摘除故障節點,更新可用服務的地址列表;

負載均衡:隨機分配&權重選取;

服務發現:服務與提供服務的機器解耦;

服務註冊:傳遞類名、方法名、參數類型、版本號;

統一SDK:封裝統一的client/server標準接口規範(協議(http/TCP)&失敗重試機制&參數傳遞規範) ;

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