一、服務(wù)發(fā)布簡介

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

二、藍綠部署

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

三、滾動發(fā)布

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

四、灰度發(fā)布

上述兩種方式在普通業(yè)務(wù)場景下都還算好操作，分布式系統(tǒng)下的灰度發(fā)布復(fù)雜程序相對高很多，基礎(chǔ)流程如下：

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

實際策略：在實際的分布式系統(tǒng)灰度發(fā)布流程，通常會采用如下一個策略：

• 配置一個灰度是否開啟的標識；
• 配置一批灰度賬戶，通常內(nèi)部人員；
• 配置灰度服務(wù)版本標識；
• 請求在鏈路執(zhí)行時，判斷灰度是否開啟；
• 判斷當前用戶身份是否是灰度測試賬號；
• 獲取當前可以請求的服務(wù)列表；
• 根據(jù)灰度服務(wù)版本選擇請求的具體服務(wù)；

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

五、數(shù)據(jù)庫灰度

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

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

最后

現(xiàn)在其實從大廠招聘需求可見，在招聘要求上有高并發(fā)經(jīng)驗優(yōu)先，包括很多朋友之前都是做傳統(tǒng)行業(yè)或者外包項目，一直在小公司，技術(shù)搞的比較簡單，沒有怎么搞過分布式系統(tǒng)，但是現(xiàn)在互聯(lián)網(wǎng)公司一般都是做分布式系統(tǒng)。

所以說，如果你想進大廠，想脫離傳統(tǒng)行業(yè)，這些技術(shù)知識都是你必備的，下面自己手打了一份Java并發(fā)體系思維導(dǎo)圖，希望對你有所幫助。

資料獲取方式：戳這里免費下載

這里免費下載](https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB)**

總結(jié)

以上是生活随笔為你收集整理的企业级项目实战讲解！javamap排序规则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。