一、服務釋出簡介
分布式系統架構下，服務釋出是一件很麻煩的事情，特别是在建構自動釋出流程和灰階測試的政策兩個核心方面。通常情況下如果不涉及資料層面的灰階流程，服務可以灰階上線，或者滾動上線，這兩種方式很常用；如果涉及到資料灰階，則可能需要中間服務做不同版本資料之間追平，或者停機維護一次性處理好資料和上線問題，不過後面這種方式風險較大。
二、藍綠部署
新版本上線的時候，并不停掉老版本，新舊兩個版本同時運作，通常還會在負載均衡的政策上傾向于舊版本服務處理請求，這樣新版本就有一個執行的觀察期過渡期，等到新版本平穩運作一段時間後，再把請求都發到新版服務上，舊版本服務完成下線。這種方式在分布式架構下很少使用，對伺服器要求過高。
三、滾動釋出
滾動釋出可以避免藍綠部署的伺服器資源占用問，首先釋出一台新版本服務，然後停掉一台老版本服務，新版服務經過觀察之後，再逐漸替換掉所有老版本的服務，這樣服務的環境變動比較頻繁，相對不穩定。
四、灰階釋出
上述兩種方式在普通業務場景下都還算好操作，分布式系統下的灰階釋出複雜程式相對高很多，基礎流程如下：
新版本上線，可能涉及分布式下多個灰階服務，是以在服務在整個鍊路上分發時，都要判斷下個請求是路由到正常服務還是灰階服務，還要對灰階服務做請求的權重控制，不能讓灰階服務處理大量的請求。
實際政策：在實際的分布式系統灰階釋出流程，通常會采用如下一個政策：
- 配置一個灰階是否開啟的辨別；
- 配置一批灰階賬戶，通常内部人員；
- 配置灰階服務版本辨別；
- 請求在鍊路執行時，判斷灰階是否開啟；
- 判斷目前使用者身份是否是灰階測試賬号；
- 擷取目前可以請求的服務清單；
- 根據灰階服務版本選擇請求的具體服務；
這個流程非常的複雜，需要很多自定義的政策，還要熟悉分布式架構的底層API原理，要二次重寫來适配灰階政策，設計重寫原生API還容易觸發一些驚喜問題。
五、資料庫灰階
如果說最難處理的灰階模式是什麼，就是資料庫的版本灰階問題，通常業務對資料庫改造更新，實際都是通過停機維護來處理的，可能很多開發都經曆過，釋出停服公告，然後在指定時間内把資料全部追平或者二次搬運，再重新提供服務。但是總有些業務場景是不能停機維護的，處理灰階資料的基本政策如下：
該模式中，除了正常的灰階流程之外，需要在灰階資料庫和正常資料中間提供一個資料調配服務，用來解決如下問題：灰階資料庫缺失資料，需要臨時從正常庫拉取，灰階版本失敗，新資料需要重新整合寫入原本正常庫；灰階版本成功，舊版資料遷移等；最終保證資料的平穩更新。
寫在最後
以上就是我的面試過程，為了這次面試，也收集了很多的面試題，反正我已經面過了，那就免費分享出來吧！
需要的朋友：關注一下，然後點選這裡即可免費領取
以下是部分面試題截圖
ps://gitee.com/vip204888/java-p7)免費領取**
以下是部分面試題截圖