部署-高可用

服務高可用

1. 無狀態服務 - 分佈式微服務節點拓展
2. 數據庫高可用 - 主從等數據結構 / newSql 數據庫

部署高可用

1. 單機房
   1. 人工運維能力與 JAR 部署方式
      1. 優點
         1. 部署由專人控制，具有嚴格的流程制度，保證不會因爲誤操作等情況照成系統不可用。
      2. 問題：
         1. 運維人力分配：
            1. 正常情況運維人員壓力不大。
            2. 異常情況運維人員人力不夠。
            3. 底層思維： 關係爲多對一，需要優先的運維人員進行操作，無法並行。
   2. 容器平臺化部署方式
      1. 優點
         1. 系統恢復依靠平臺，平臺生態環境恢復，系統自動恢復。
         2. 本次故障典型案例：新倉儲
      2. 缺點
         1. 因環境重建照成歷史遺留系統程序恢復需要調整代碼難度增加。
         2. 無法做到優先恢復關鍵系統服務，只有生態環境恢復或重建後纔會自動恢復。
   3. 總體說明：
      1. 當前矛盾明顯，運維太過依賴與人力。人力有限，無法照顧與記憶住各方各面。
      2. docker虛擬化刻不容緩。
   4. 附圖： 容器平臺快速恢復方案
      1. 當前完成情況：
         1. Git or Svn 完成備份：備份點爲服務器物理磁盤
         2. docker鏡像中心 完成備份： 備份地點爲服務器物理磁盤
         3. K8s 整體配置設置 完成備份： 備份地址爲服務器物理磁盤
      2. 目前可保證：
         1. K8S集羣受到破壞後，可快速初始化一個新的集羣並直接恢復原本運行服務。
   5. 總結：
      1. 單機房部署方式，能做的只有災難發生後的快速恢復。恢復過程必然相對較長並且業務直接受阻。
2. 同城雙活
   1. 分幾種情況（自己定義的）
      1. 真雙活
         1. 請求被平均分配到兩個數據中心
      2. 主從
         1. 大部分請求被分配到一個數據中心上（主），少部分請求分配到（從）數據數據中心
      3. 主備
         1. 1%的請求會配到（備）數據中心上。只驗證（備用）數據中心是否正常（含業務驗證）
   2. 方式
      1. K8S影子服務組升級
         1. 基於K8S可以快速構建一套系統環境。
         2. 可升級本地私有影子服務組爲公有云環境。
      2. K8s多集羣模式
         1. 私有云與公有云集中管理+多集羣應用。
   3. 優點：
      1. 達到快速恢復或多活。
   4. 缺點：
      1. 需要解決很多問題
         1. 服務就近訪問（分區） PS ：spring cloud 提供該功能。
         2. 緩存等中間件共享。
         3. 網絡互通，適配。
         4. 等等。。。
3. 兩地三中心方案（城雙活+異地災備）網絡有很多案例可做參考。

公有云化

1. 數據中心環境託管
2. 交於專業的公司來做專業的事情。

總體分析

1. 同城雙活主備應該爲當前投入最小收益最高的方案。