架構設計：分佈式結構下，服務部署發佈

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、服務發佈簡介

分佈式系統架構下，服務發佈是一件很麻煩的事情，特別是在構建自動發佈流程和灰度測試的策略兩個核心方面。一般狀況下若是不涉及數據層面的灰度流程，服務能夠灰度上線，或者滾動上線，這兩種方式很經常使用；若是涉及到數據灰度，則可能須要中間服務作不一樣版本數據之間追平，或者停機維護一次性處理好數據和上線問題，不事後面這種方式風險較大。

2、藍綠部署

新版本上線的時候，並不停掉老版本，新舊兩個版本同時運行，一般還會在負載均衡的策略上傾向於舊版本服務處理請求，這樣新版本就有一個執行的觀察期過渡期，等到新版本平穩運行一段時間後，再把請求都發到新版服務上，舊版本服務完成下線。這種方式在分佈式架構下不多使用，對服務器要求太高。

3、滾動發佈

滾動發佈能夠避免藍綠部署的服務器資源佔用問，首先發布一臺新版本服務，而後停掉一臺老版本服務，新版服務通過觀察以後，再逐步替換掉全部老版本的服務，這樣服務的環境變更比較頻繁，相對不穩定。

4、灰度發佈

上述兩種方式在普通業務場景下都還算好操做，分佈式系統下的灰度發佈複雜程序相對高不少，基礎流程以下：

新版本上線，可能涉及分佈式下多個灰度服務，所以在服務在整個鏈路上分發時，都要判斷下個請求是路由到正常服務仍是灰度服務，還要對灰度服務作請求的權重控制，不能讓灰度服務處理大量的請求。

實際策略：在實際的分佈式系統灰度發佈流程，一般會採用以下一個策略：

• 配置一個灰度是否開啓的標識；
• 配置一批灰度帳戶，一般內部人員；
• 配置灰度服務版本標識；
• 請求在鏈路執行時，判斷灰度是否開啓；
• 判斷當前用戶身份是不是灰度測試帳號；
• 獲取當前能夠請求的服務列表；
• 根據灰度服務版本選擇請求的具體服務；

這個流程很是的複雜，須要不少自定義的策略，還要熟悉分佈式框架的底層API原理，要二次重寫來適配灰度策略，設計重寫原生API還容易觸發一些驚喜問題。

5、數據庫灰度

若是說最難處理的灰度模式是什麼，就是數據庫的版本灰度問題，一般業務對數據庫改造升級，實際都是經過停機維護來處理的，可能不少開發都經歷過，發佈停服公告，而後在指定時間內把數據所有追平或者二次搬運，再從新提供服務。可是總有些業務場景是不能停機維護的，處理灰度數據的基本策略以下：

該模式中，除了正常的灰度流程以外，須要在灰度數據庫和正常數據中間提供一個數據調配服務，用來解決以下問題：灰度數據庫缺失數據，須要臨時從正常庫拉取，灰度版本失敗，新數據須要從新整合寫入本來正常庫；灰度版本成功，舊版數據遷移等；最終保證數據的平穩升級。

6、源代碼地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：編程體系整理

序號	項目名稱	GitHub地址	GitEE地址	推薦指數
01	Java描述設計模式,算法,數據結構	GitHub·點這裏	GitEE·點這裏	☆☆☆☆☆
02	Java基礎、併發、面向對象、Web開發	GitHub·點這裏	GitEE·點這裏	☆☆☆☆
03	SpringCloud微服務基礎組件案例詳解	GitHub·點這裏	GitEE·點這裏	☆☆☆
04	SpringCloud微服務架構實戰綜合案例	GitHub·點這裏	GitEE·點這裏	☆☆☆☆☆
05	SpringBoot框架基礎應用入門到進階	GitHub·點這裏	GitEE·點這裏	☆☆☆☆
06	SpringBoot框架整合開發經常使用中間件	GitHub·點這裏	GitEE·點這裏	☆☆☆☆☆
07	數據管理、分佈式、架構設計基礎案例	GitHub·點這裏	GitEE·點這裏	☆☆☆☆☆
08	大數據系列、存儲、組件、計算等框架	GitHub·點這裏	GitEE·點這裏	☆☆☆☆☆