服務釋出的幾種方式

1）XML配置化 服務框架對業務程式碼0侵入、擴充套件和修改方便、修改配置不需要重新編譯程式碼

2）註解 服務框架對業務程式碼0侵入、擴充套件和修改方便、但 修改配置需要重新編譯程式碼

3）API呼叫 對業務程式碼的侵入性比較強，擴充套件和修改也不方便，修改介面的話還需要重新編譯

本地實現封裝成代理類：

1）服務釋出的流程都是類似的通過抽象代理層，可以對服務釋出行為本身進行封裝和抽象

2）通過動態代理物件，可以對服務釋出進行動態攔截，方便平臺和業務對服務釋出進行個性化定製

3）便於擴充套件和替換

服務啟動先後順序：

正常應該是註冊中心先於服務提供者和消費者啟動，但是要能夠支援亂序啟動，發生故障時服務者和消費者也要能夠自動重連伺服器

同步釋出還是非同步釋出？

1）可以採用非同步釋出來減少系統啟動的時間

2）對於不經常使用的服務可以採用延遲釋出

3）服務的懶載入，就是指釋出服務，但不初始化，等到消費者真正呼叫的時候才進行初始化服務

警惕網路風暴：

服務註冊中心可能管理了數十萬條的服務註冊資訊，若有大量資訊需要變更，就會發生頻繁的變更通知，這種海量的變更通知可能會擠佔註冊中心的網路頻寬，嚴重時還會導致網路風暴

需要注意：

1）哪些服務需要註冊到註冊中心

2）服務中心可以管理的服務上限

3）註冊中心的網路頻寬計劃

4）磁碟空間規劃

5）效能

灰度釋出：就是一部分使用者使用心得服務，另一部分使用者使用舊的服務，等待服務穩定或者有比較好的使用者反饋後再繼續釋出到新的伺服器

服務的多版本是分散式服務框架的重要特性，涉及服務的開發，部署線上升級和服務治理

對於服務提供者，釋出服務的時候需要支援指定版本號

對於服務消費者，消費的時候需要支援指定引用服務的版本號

版本號一般是  主版本+副版本+微版本

主版本變更：有大的特性或者功能變更，或許會與之前的版本有不相容的介面(應該儘量避免)

副版本：發生了少部分的功能變更，或者新增了一部分功能

微版本：主要是bug修復，對應於常見的SP補丁包



服務熱升級：就是在業務不中斷的情況加，實現系統的平滑升級，考慮到版本升級的風險，往往需要多次滾動升級，最終根據升級之後的新版本服務的執行決定是繼續升級還是回退，整個叢集環境中會有多個版本的服務同時存在

熱升級的幾個核心點：

1）由於分散式服務框架可以自動進行健康監測和自動發現，停機升級的節點會被隔離，並不會中斷業務

2）滾動式灰度釋出會在很長的一段時間內有服務的多個版本存在，哪些業務或者使用者需要路由到新的伺服器上需要通過路由策略去指定

3）滾動升級和回退機制

服務熱部署和熱升級：

1）服務是分散式叢集部署的，通常也是無狀態的，停掉其中的某一個節點，不影響整體服務的執行

2）服務的自動發現和隔離機制，有新的服務加入時，註冊中心會自動通知消費者，服務節點掛掉或者重啟時，會自動傳送服務下線給消費者，消費者將下線服務自動隔離

3）優雅停機，程序退出之前，會處理完訊息佇列積壓的訊息，不再接受新的訊息

4）叢集容錯 服務節點宕機，消費者呼叫超時會自動重試會在記錄錯誤等按照自己的失敗策略執行

5）服務多版本管理，允許叢集中一個服務的多個版本在同時執行，不同的消費者可以消費不同的版本