前言
近年來伴隨着技術的不斷進步，微服務概念的深入人心，微服務技術也被大家越來越多的應用在產品中。當企業還沒有廣泛應用微服務架構的時候，那時對於配置分發的解決方案多種多樣，如腳本替換、環境變量讀取、手工修改、重啓應用等。但是隨着微服務架構的盛行，配置管理的難度越來越大，企業亟需一套配置文件管理系統，將已有的應用配置有效管理起來。
面對這個問題，我們可以藉助配置中心來管理應用配置。配置中心實現了多套環境、多套版本、多個應用的配置管理。但是隨着平臺微服務業務的進一步發展，新的問題也隨之而來。微服務應用越來越多，配置請求越來越頻繁，同時有些微服務對配置的需求更講究時效性。此外，業務上也希望能夠更精確地控制配置替換的影響範圍，例如能做到單點應用的配置修改。
爲了解決以上問題，我們基於微服務消息推送總線建設了配置中心實時配置推送系統。本文將基於該系統，深入分析配置推送的原理以及框架結構。1. 核心業務介紹
配置推送業務需求
在建立配置中心推送系統前，我們先設計了一套基於平臺微服務SDK的消息推送平臺。將配置信息作爲消息推送給微服務終端。我們希望該平臺能夠滿足以下需求：
·高性價比，在有限的硬件資源下，儘可能的提高消息系統的性能和可用性；
·推送數據的一致性；
·推送消息的實時性；
·交互簡單，學習門檻低，引入方便；
·結合配置分發的實際需求；
·推送失敗後的補救處理；
·精確地控制推送範圍。
作爲消息推送平臺的上層應用，配置中心實時推送則需要關注配置分發的業務需求：
·配置推送目標精確選擇，包括特定租戶、特定應用、特定環境等；
·保證配置推送的正確性；
·配置修改以後及時更新配置信息；
·應用掉線後能夠重新獲得推送信息。
配置推送服務流程
由配置中心決定置推送時機，如配置新建、配置更新、用戶觸發的時機等，配置信息發出後將交給終端微服務進行處理，如配置實時生效、重啓等。
配置推送請求流程
消息推送平臺由Inotify-Manager消息管理組件和Inotify-PushServer消息推送服務器組成。
其中Inotify-Manager負責接收配置中心、用戶事件、Web管理頁面傳來的配置更新事件請求，對請求進行權限校驗，並對通過權限校驗的消息進行持久化保存。
Inotify-PushServer組件則負責接收Inotify-Manager傳輸的符合要求的消息信息，並且接收微服務終端中微服務SDK發送的註冊請求，如果註冊成功則爲該終端保存一條消息傳輸通道，當其接到推送的消息時會根據推送過來的推送座標選擇相應的微服務終端進行推送。
配置推送接收SDK是微服務SDK功能的一部分，其主要邏輯由配置中心SDK和Inotify-SDK配合完成。Inotify-SDK負責根據微服務終端的配置生成消息通道ID（推送座標）並將該id作爲通道標識註冊到Inotify-PushServer.當Inotify-PushServer推送消息時SDK也負責接收。接收到的消息爲通用消息，配置中心SDK分析通用消息的類型，如果爲配置類型則攔截消息進行處理。
2. 技術選型
系統架構圖
根據配置分發業務的需求，我們的推送系統需要在硬件資源的有限的條件下具有較高的處理性能，並且滿足大量的連接數場景。爲此，在技術選型中傳統的java.io被直接排除了，改爲使用WebSocket協議的的長連接模式框架。Java的WebSocket框架選擇比較有限，基本上就是在Netty，Undertow中二選一。Undertow的內存性能比Netty稍差，但是基於代碼原因最終平臺還是選擇了Undertow作爲推送服務的基礎框架。
消息持久化
客戶端上線之後需要將上線前一段時間的消息拉取消費，同時推送的歷史消息也需要進行備份留待查詢驗證。因此消息持久化就成爲了一個不可避免的問題。
目前消息推送平臺數據量較小，且每次傳輸的數據多爲服務元數據、配置信息、通知微服務終端消息等數據量較小的信息。目前這些信息在推送的同時也存儲一份在數據庫中，方便進行消息推送失敗後的重發，以及後續數據的統計分析。
但是隨着業務的日益增加，簡單的持久化越來越滿足不了需求，在這方面我們也正在積極開展工作。期望通過合理分表分庫，使每個表的性能得到保障，並且保證總體的高分發量。在manager端也通過使用異步隊列持久化的方式取代目前使用的同步方式，減少數據庫的壓力，提高消息推送的峯值。
數據傳輸協議
由於我們的消息推送平臺需要維持長連接，因此在協議選擇上就面臨着兩個選擇：
·私有二進制協議
·基於HTTP的WebSocket
在綜合多方面的考慮以後我們最終選擇了WebSocket作爲平臺數據傳輸的協議，主要原因有以下幾點。首先私有協議雖然性能較好，但是業務上的性能瓶頸往往並不在傳輸上，而使用WebSocket協議在安全校驗、泛用性、開源工具等方面都有良好的支持，客戶在使用時門檻也較低。
在傳輸數據格式方面我們選擇了Json，這種格式比較簡單、易於擴展且應用廣泛。其實現在比較流行的Protobuf在性能上表現更好，序列化以後數據量大大減小，可以考慮在以後的版本中對其提供支持，由用戶選擇自己需要的序列化方式。
長連接
因爲硬件資源有限，又要想維持儘可能多的連接數。在服務端我們採用了Undertow非阻塞時的維持長連接，提高單機所能維持的連接數。與此同時，還需要對失效連接及時進行清理，在高連接數的前提下提高有效連接的數量。
使用WebSocket的客戶端與服務器端有可能因爲一些情況導致連接中斷，這種中斷在客戶端只有在再次發送消息時能被發現。但是在一些業務場景中，我們的客戶端完全是消息的接收端，並不發送消息。在這種情況下，客戶端下線後就永遠不會再次連接。因此爲了保證連接的可持續性和穩定性，我們使用了心跳檢測機制，客戶端定時發送心跳消息，用於檢測網絡和前後端連接問題。一旦發現異常，客戶端端持續執行重連邏輯，直到重連成功。
3. 與配置推送結合的實現細節
分佈式消息推送
消息推送隨着業務量的增多，負載必然越來越重。爲了滿足業務需要，消息平臺就需要在高性能的前提下具備水平擴展能力。因此分佈式集羣是消息平臺一項必須的能力。
早期版本的消息推送平臺由Nginx作爲Router配合使用域名來爲各個組件提供服務發現和負載均衡功能，示意圖如下：
使用這種方法的前提是需要用戶架設消息系統前，先部署一套Nginx-Router，同時還需要擁有域名。由於Client端要直連這兩個域名，因此這也導致了一系列的安全問題。另外，PushServer其實是有狀態的，故通過Nginx轉發來推送消息導致PushServer只能是單點的。
爲了解決以上問題，我們採用Zookeeper解決服務發現的問題，並在推送邏輯上加入根據消息組件信息決定的負載均衡機制，提出了新的分佈式解決方案。
消息推送平臺的各個角色都通過Zookeeper獲取所需要的連接的地址。使用這套解決方案，不僅能輕鬆實現消息平臺的集羣化，而且也爲系統的私有化提供了便利。
SDK消息處理
配置實時推送功能依託於微服務平臺的配置中心，消息推送平臺，微服務SDK完成自身的功能邏輯。其中當消息到達微服務終端時由微服務SDK對消息進行處理。
最新版本的微服務SDK在配置實時推送的功能上包含了以下兩個組件：
·消息推送SDK（Inotify-SDK）
·配置中心SDK（Proteus-SDK）
其中消息推送SDK是可以單獨使用的，不依賴微服務、Spring等其他框架。當該SDK引入微服務時則通過微服務插件機制讀取微服務的配置信息，建立一條微服務推送通道。任何向該微服務推送的消息都會複用這條通道，減少服務端的壓力。
配置中心SDK則提供了微服務配置分發的相關功能。當微服務收到配置分發消息時，同樣也是基於微服務SDK插件機制觸發相應的消息處理器，收到的消息會帶有相關的類型，決定由哪些處理器進行處理。確認類型以後會完成後面的處理邏輯，例如實時更新配置，將消息信息寫入文件等。
實質上來說，SDK的消息處理都是基於微服務SDK的插件機制來完成的。消息接收由消息SDK完成，而消息處理則通過插件機制建立一條消息處理的責任鏈，處於這條鏈上的處理器選擇合適的消息截斷進行處理。
配置推送範圍
配置文件具有環境、版本、所屬應用、租戶、狀態等多個屬性，推送配置文件就需要根據這些文件屬性裝配出一個文件消息主題，但是我們又不能在消息系統中建立每一個文件的主題，因此配置推送範圍這個問題就被提出來了。
爲了解決這個問題我們提出了子主題的概念，而這個概念則建立於推送座標的基礎上：
如圖所示，推送座標由多段字符串組成。推送配置時推送座標的精度越高，則推送範圍越小。如果需要廣播消息則只需要推送一個類型信息就可以了。
爲了提高PushServer檢索推送座標的速度，提高性能，我們使用樹形結構存儲推送座標，減少遍歷座標時耗費的時間。
4. 總結與展望
隨着微服務業務開展的如火如荼，配置分發壓力越發沉重。配置中心配置實時推送系統將拉取配置轉化爲推送配置，減少了無意義的網絡請求，提高了配置更新的實時性，並且將配置分發的數據保存下來爲數據統計與分析提供了寶貴的原材料。
與此同時，與配置推送業務一同誕生消息推送系統也多點開花，支撐了配置推送、實時下線、元數據推送、通用消息推送等業務。
基於消息平臺和微服務治理平臺的高擴展性，在未來消息平臺不僅能夠承擔平臺配置分發的工作，也能結合其他業務在功能上做進一步的擴展。爲整個開發者中心提供一個可擴展、高可用、通用、易用的的綜合消息推送平臺。
開發者中心，將因你而變得更加精彩！