微服務引擎 MSE 在阿里巴巴的技術實踐

前言

微服務引擎 MSE(官網地址>>) ，是阿里集團配置中心和服務註冊中心的雲上版本，在集團內廣泛應用於分佈式一致性協調，註冊中心，分佈式配置中心等場景。以 2019 年天貓雙十一爲例，由於 MSE 在穩定性和性能方面持續投入，單集羣最大超過 30W 長鏈接，對於業務團隊而言，運維成本大幅下降一倍，管控體驗大幅提升。MSE 產品出色的穩定性和性能，獲得了標杆客戶的高度認可，交出了一份漂亮的成績單！

雙十一戰績

1、MSE1.0 託管了阿里集團大部分 ZooKeeper 線上集羣，覆蓋的產品包括集團的多種核心基礎組件；
2、雙十一當天，所有集羣整體運行穩定，容量水位，各項指標正常， 0 故障， 0 例問題反饋；
3、在高峯期間，MSE 託管的最大容量集羣 Blink 集羣，各項指標符合預期，平穩渡過，各項指標詳趨勢如下：

鏈接數

平均請求延時

2.0 架構升級，融合雲原生賦能產品競爭力

MSE 2.0 的架構升級，是和雲原生技術體系的無縫融合；從另一個角度理解，能夠依託雲原生帶來的技術紅利，給自己的產品帶來技術創新，效率提升，性能提升，就是一種雲原生能力。

1、MSE 1.0 採用的是集團部署模式，Sigma +集團內部網絡+集團組件：

在 1.0 的架構下，在產品平臺能力，運維效率方面都比較低效，受限於平臺，產品自身能力無法突破質的提升：

• MSE1.0 的集羣交付模式，是在用戶需要部署的機房申請機器資源，然後人工在機器上面部署集羣，部署完成之後，需要去配置中心上面維護一套節點IP的映射關係，整個流程下來，最少要 3 個小時，經常會因爲資源交付的問題，協調多方。
• 集團內部用戶申請 ZooKeeper 資源，很多場景下是獨立需求，也就是，需要一個獨立的集羣即可，這種情況下，如果每個用戶給一個，維護的成本非常高，因此需要用戶單獨郵件說明場景，判斷是否可交付公共集羣，這個流程讓用戶難以達到快速安全接入的目的。
• 集團內部支持的獨立集羣有非常多，每月集羣宕機，物理機遷移後，需要人工恢復節點，由於 ZooKeeper 是有狀態應用，服務端的配置文件狀態依賴於服務器的地址，集羣之間需要數據同步，無法做到和業務應用一樣自動拉起。
• 集羣的擴縮容，需要手動修改每臺節點的配置，每臺都需要重啓才能生效，由於涉及到 ZAB 協議規則，不能出現多主的情況，否則會出現數據丟失等嚴重後果，需要嚴格控制重啓順序和配置內容，具有較高的運維技術複雜度。
• 用戶在集羣的地址發現服務時，有依賴到多種配置組件，有些爲了降低依賴，就直連集羣節點 IP ，在出現節點更換或者擴縮容時，需要額外去維護這份映射關係，如果出現紕漏，會導致服務不可用。
• 服務端的配置，由手動進行修改同步，也沒有機制保證每次人工操作的正確性，導致 ZooKeeper 集羣在重啓加載了不一致的配置，出現數據丟失，選主失敗等問題。

2019年 5 月份，我們將 MSE 1.0 進行了平臺級別的架構升級改造，希望能夠解決目前所遇到的問題，同時在支持集團內部的同時，能將產品能力對外輸出（基於公有云上引擎的存量調研數據，市場是非常大的），在技術選型時，充分考慮了底座基於K8S的雲原生架構，未來是雲時代，各種雲上能力，未來一定是都會主動對接到標準雲原生架構中的，MSE 需要藉助這些雲原生標準能力，將 MSE 產品的平臺能力整體提升，也爲後續雲原生戰役做好技術鋪墊。

2、MSE 2.0 ，基於 ACK+ 雲能力多位一體組合（ VPC，DNS，SLB，高效雲盤，ARMS ）

MSE 2.0 架構，底層容器資源通過 ACK 進行統一管理，完全兼容開源K8s標準，因此也獲得了K8s的多種高級特性支持：

• 集羣交付能力效率提升 100 倍
  K8s 的 POD 拉起，加上雲盤， SLB 等資源分配， 3 分鐘即可交付一套集羣，對比 1.0 流程，資源申請，配置同步等，最少需要半天，效率提升了百倍。
• 集羣節點多可用區部署，具備多機房容災能力
  MSE 每個 Region 都支持最少 2 個可用區，在集羣節點分配時，已配置的 K8s親和性調度，會將節點打散至多個可用區部署。
• 壓力負載均衡完美，後端穩定性大大提升
  SLB是一款成熟的產品，得到了市場的檢驗，MSE 依託它的4層負載均衡能力，客戶端能夠均勻的分佈在每臺節點上面，避免了用戶使用IP直連的情況下，出現負載不均衡的情況。
• 機器宕機，自動遷移重建
  降低了運維成本，同時提高了可用性，以往需要自己申請機器，由於需要狀態同步，需要人工修改配置手動重啓每一臺節點，複雜度非常高，同時頻繁的手工操作也給線上穩定性帶來了風險隱患
• 監控指標豐富
  在監控方案選型上，採用了雲原生標準的監控體系方案-普羅米修斯，由於和開源兼容一致，在 MSE 業務監控指標數據的採集組件上，完全複用了 ZooKeepper 開源組件的上報能力，研發效率得到了翻倍的提升。

普羅米修斯監控，提供了強大的後臺交互大盤，同時MSE 前端可通過數據查詢接口，按需重新繪製監控指標趨勢圖。

技術能力產品化，滿足客戶多層次需求

相比 MSE 1.0 ，MSE 2.0 將許多技術上的能力，進行了產品化改造，提升產品競爭力外，同時也將技術能力賦予了用戶，滿足了客戶多層次的需求。

1、集羣交付方式支持域名交付
用戶在客戶端連接 MSE 集羣時，填寫域名，在集羣的實例變化後 ，客戶端不需要修改地址，會自動解析到新地址，降低用戶使用時的切換成本。

2、集羣節點健康狀態可視化
通過狀態頁面，客戶可以看到每個節點的健康情況以及節點角色。

3、MSE 運行時參數優化，支持更高的鏈接性能及降低運維成本
用戶自維護的 64 核物理機，在遷移到 MSE 後，評估了容量及性能要求，使用了 12 核， CPU 利用率最後能夠穩定保持在 15% 左右，GC 頻率降低 80% ，同等業務規模下，只需要 1/5 的機器資源就滿足了業務需求，節省了客戶的機器資源。

4、數據節點編輯功能
MSE 提供了集羣數據管理視圖，貼合業務場景，可以方便的對數據進行白屏化操作。

5、版本升級，MSE 一鍵滾動升級
升級MSE版本時，只需要更新鏡像 ，然後在控制檯點擊升級，即可讓MSE集羣所有節點逐臺滾動升級

6、集羣監控指標趨勢圖
可以查看當前集羣監控指標的實時值，也可以查看歷史趨勢，例如集羣的鏈接數變化情況， 7 天曆史變化趨勢

7、用戶側自定義報警
可以針對不同的監控指標，設置對應的報警閥值，支持短信，釘釘羣，郵件。

新徵程，新挑戰

• 產品技術高度融合，基於 Nacos 內核，統一內部多款配置中心，服務註冊心， Nacos 產品基於 MSE 平臺商業化，集團內部集羣全部上雲，整體節省機器成本 50% ，人效提升 3 倍。
• 商業化，意味着對產品的可用性和性能有着更苛刻的要求， 需要滿足更高的SLA，99.99%讀服務可用，99.9% 寫服務可用，平均請求延時 小於50ms 99.99%。
• 雲原生技術體系的深度融合，支持彈性伸縮，服務 ServerLess 化，資源成本最少降至 50% ，配合產品配置修改不重啓的能力，做到 MSE 服務永遠在線

查看更多：https://yqh.aliyun.com/detail/6482?utm_content=g_1000105580

上雲就看雲棲號：更多雲資訊，上雲案例，最佳實踐，產品入門，訪問：https://yqh.aliyun.com/