如何理解分布式結構下，服務部署發布

這篇文章主要介紹“如何理解分布式結構下，服務部署發布”，在日常操作中，相信很多人在如何理解分布式結構下，服務部署發布問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解分布式結構下，服務部署發布”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、服務發布簡介

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

二、藍綠部署

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

三、滾動發布

滾動發布可以避免藍綠部署的服務器資源占用問，首先發布一臺新版本服務，然后停掉一臺老版本服務，新版服務經過觀察之后，再逐步替換掉所有老版本的服務，這樣服務的環境變動比較頻繁，相對不穩定。

四、灰度發布

上述兩種方式在普通業務場景下都還算好操作，分布式系統下的灰度發布復雜程序相對高很多，基礎流程如下：

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

實際策略：在實際的分布式系統灰度發布流程，通常會采用如下一個策略：

• 配置一個灰度是否開啟的標識；

• 配置一批灰度賬戶，通常內部人員；

• 配置灰度服務版本標識；

• 請求在鏈路執行時，判斷灰度是否開啟；

• 判斷當前用戶身份是否是灰度測試賬號；

• 獲取當前可以請求的服務列表；

• 根據灰度服務版本選擇請求的具體服務；

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

五、數據庫灰度

如果說最難處理的灰度模式是什么，就是數據庫的版本灰度問題，通常業務對數據庫改造升級，實際都是通過停機維護來處理的，可能很多開發都經歷過，發布停服公告，然后在指定時間內把數據全部追平或者二次搬運，再重新提供服務。但是總有些業務場景是不能停機維護的，處理灰度數據的基本策略如下：

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

六、源代碼地址

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

到此，關于“如何理解分布式結構下，服務部署發布”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！