項目如何進行生産優雅釋出

1. 優雅釋出概念

   主要考慮的兩方面：系統應用無損，業務無損。

2. 優雅釋出流程

   首先看下一個應用内大緻包含哪些組織形式。

2.1.1. 叢集流量承載評估

在釋出前用前，需要對應用整體流量進行評估。

釋出過程需要停止應用，停止應用這個期間，剩下的應用叢集是否能滿足目前流量的承載。（避開高峰）

釋出啟動後灰階引流期間，新的服務引流的使用量，是否能承載引流的業務容量。

2.1.2. 應用停止

業務停止應用，切記不能直接Kill -9操作，也不能直接使用shundown操作。

被殺死的用戶端jboss或tomcat是無法及時告知服務端自己是否還存活，還是否能處理正常請求。

用戶端内還有殘留的請求（同步、異步）未被處理、線程池中線程還在運作狀态未被釋放、檔案處理到一半、本地事務還未執行完成等等。

最經典的場景就是同步請求逾時（RPC同步請求，MQ同步發送。RPC的OneWay和MQ也可以設定異步模式，這兩種是異步請求，異步請求不需要給應答，是以也無法保證是否接收到，速度比較快，一般用于可容仍丢失，如監控）。逾時分兩類，可能是應用發送方阻塞逾時（請求未送達，用戶端逾時），應用接收方收到請求後應答送不回去（請求已送達，并處理，傳回未送達，用戶端逾時）。本質上逾時問題是無解的，隻有通過重試來解決，重試必然需要幂等，還會帶來多幾倍的網絡開銷，如果是後一種逾時，可能應用接收方會被打死（必須限制重試次數、考慮降級或服務端限流）。

是以應用停止前，需要做以下處理：

2.1.2.1. 摘除外部通訊

摘除Http同步請求，圖1代理叢集模式，應從負載均衡處摘除。

摘除RPC同步請求，圖2用戶端叢集摘除請求，應用分布式資源排程服務中通知用戶端進行服務摘除。

摘除MQ訂閱，圖3消息隊列，需要進行解除訂閱，讓消息暫時持久化到消息隊列中

注意：啟動的時候，需要一切資源準備好後（RPC通訊連接配接、Redis、資料庫、檔案等等），最後啟動消息訂閱、服務加入叢集（這裡也分業務先後，看業務場景，如消息裡面有依賴服務調用，應先注冊服務，再開啟消息訂閱），不然可能發生異常

2.1.2.2. 釋放長連接配接

釋放Redis連接配接池、資料庫連接配接池、檔案連接配接（SFTP或分布式存儲）、MQ連接配接池、RPC通訊架構連接配接池。圖5，圖6（這裡比較好的是，spring架構本質都幫我們做了，在bean初始化的時候都提供了destroyMethod）

2.1.2.3. 釋放本地資源

釋放本地線程池、檔案句柄、事務處理。圖4（這裡要注意，使用容器（jboss，tomcat）關閉本質已經幫我們做了，如果自己實作的jar應用是沒有容器的，是以要實作shutdownhook進行處理（或者使用springboot可執行包））。

2.1.3. 應用測試

0灰階測試

2.1.4. 應用釋出

灰階釋出

微服務釋出的政策方式（4台、8台、16台……，預先評估業務場景，VM可以使用jenkins進行編排，Docker可以使用K8S進行容器編排）

單元化釋出，按整個單元可用為主。

2.1.5. 應用投産

生産業務驗證

2.1.6. 應用監控，報表，自主恢複

監控報警，故障報告及影響範圍，自主恢複（能自動化的一切自動化處理）