作者：聰言
開篇：一次小小的技術討論
週末的時候，和一位在國內某互聯網公司負責運維的朋友聊天，由於工作相關，剛好聊到了公司項目中微服務架構這塊的一些問題，他們公司的微服務架構使用的是業界比較常用的 Spring Cloud Netflix 那一套作爲底座，有專門的同學負責運維一套自建的 Eureka 集羣來作爲微服務註冊中心。服務註冊中心作爲微服務領域的核心組件，承載着公司核心業務的高頻服務，一旦遇到可用性問題，就會大面積影響線上業務。
朋友說自從他接手負責這塊之後，已經慢慢在業務發展過程中感到對這個 Eureka 集羣運維上的有心無力，被拖住了人力暫且不說，日常故障頻發的狀態也搞的整個人心力交瘁。談到好幾個工作中碰到的問題，梳理了下發現基本上都是圍繞着 Eureka 集羣性能、運維能力、維護成本相關的。聊了很久在一起交流了下方案，當提議他要不考慮用 MSE Nacos 吧，朋友兩手一攤，現在公司有那麼多研發小組再去全部推動升級一遍哪有那麼容易的。我又問他，那如果什麼代碼都不需要你們改呢，0 成本，心動嗎？
見招拆招
Round 1 - 突破性能瓶頸
第一個碰到的痛點是當前朋友公司的 Eureka 集羣裏註冊的服務實例數已經過萬了，集羣水位一直居高不下，CPU 佔用率、負載都很高，時不時還會發生 Full GC 導致業務抖動。其實這是因爲 Eureka Server 是傳統的對等星型同步 AP 模型導致的，各 Server 節點角色相等完全對等，在這種多實例場景下，對於每次變更(註冊/反註冊/心跳續約/服務狀態變更等)都會生成相應的同步任務來用於所有實例數據的同步，這樣一來同步作業量隨着集羣規模、實例數正相關同步上漲。
再加上 Eureka 的二級隊列發佈模型機制和限流延遲策略，極易造成同步任務積壓從而導致服務端的高負載影響性能。如果這個時候再不湊巧，碰上網絡抖動的情況，引發了同步任務的重試風暴則會進一步加重集羣性能問題，從而最終影響正常業務的穩定性，這一點 Eureka 官方文檔也有提及。開源 Eureka 的這種廣播複製模型，不僅會導致它自身的架構脆弱性，也影響了集羣整體的橫向擴展性。
Replication algorithm limits scalability: Eureka follows a broadcast replication model i.e. all the servers replicate data and heartbeats to all the peers. This is simple and effective for the data set that eureka contains however replication is implemented by relaying all the HTTP calls that a server receives as is to all the peers. This limits scalability as every node has to withstand the entire write load on eureka.
口說無憑，特意用性能分析利器 Arthas 從線上生產環境的 Eureka Server 集羣採集了一份新鮮的 Profiler 火焰圖，可以看到紫色部分就是在處理心跳續約邏輯，拋開 Jersey 寫 IO 的部分不談，這部分的 CPU 調用棧處理佔比那是相當的高。
那麼 MSE Nacos 是如何解決這個問題呢，這就要提到自研的 AP 模型 Distro 協議了，在保留了星型同步模型的基礎上，Nacos 對所有服務註冊實例數據進行了 Hash 散列、邏輯數據分片，爲每一條服務實例數據分配一個集羣責任節點，每一個 Server 節點僅負責自己 own 的那一部分數據的同步和續約邏輯，同時集羣間數據同步的粒度相對於 Eureka 也更小。
這樣帶來的好處是即使在大規模部署、服務實例數據很多的情況下，集羣間同步的任務量也能保證相對可控，並且集羣規模越大，這樣的模式帶來的性能提升也愈發明顯。
另外 MSE Nacos 在阿里雲內部也在進行不斷產品的打磨，對讀寫性能網絡吞吐、實例索引存儲容量進行了大幅優化，根據實驗室壓測數據，MSE Nacos 專業版支持的 Eureka 註冊中心的寫性能、容量均提升達一倍以上，同樣的集羣機器配置下，集羣 CPU 開銷、負載明顯優於開源 Eureka。
Round 2 - 簡化運維
第二點就是運維成本的問題了，我們知道使用 Eureka 的很大一部分用戶羣體是運維同學，但是 Eureka 提供的運維能力、工具實在是太簡陋了，完全無法滿足日常工作中的運維需求。運維同學手上沒有趁手的兵器，可不就只能辛苦加班加點來頂上了麼。就像經常被吐槽的 Eureka 的控制檯，上面只有一些很簡單的服務註冊列表、集羣基礎信息查看功能，想方便做一些高階操作只能自己投入人力成本來定製開發。
但是相反在 MSE Nacos 的控制檯上可以看到很多豐富易用的運維功能，比如實例權重配置管理，可以很方便的根據不同實例的性能分配權重，某個實例異常的時候也可以直接操作一鍵下線；除此之外還有服務健康狀態檢查、集羣指標監控報警可對集羣狀態、服務數、TPS、請求耗時等指標進行監控，並且提供自定義告警規則及釘釘、電話、短信等告警渠道，便於排查異常。
還有一個運維同學關注比較多也是比較頭疼的問題，是關於 Eureka 集羣容量評估的，到底什麼樣的集羣機器配置才能夠保障業務的穩定運行，另外是否還可以從容的應對業務上一些突發的擴容場景需求。通常比較省事的解法就只能是提前預估好業務量，留夠足夠的資源池 buffer，那帶來的問題就是明顯的資源成本浪費，沒辦法實現降本增效的目的。
另外這些業務集羣的擴縮容往往涉及人工運維操作，也極容易因爲操作不規範而引發線上故障。爲了解決這個問題，MSE Nacos 近期剛剛上線了 Serverless 版本並開始公測， Serverless 版本實現了對集羣業務資源的精細化管理和超賣彈性調度。區別於傳統實例的規格變配需要手動操作，Serverless 版本支持基於業務資源量自動擴縮容，從此不再需要提前做複雜的容量規劃，對於中小規模業務及潮汐式場景又省事又省力。
Round 3 - 無縫遷移、安全接管
其實在考慮轉型 MSE Nacos 作爲微服務註冊發現中心的時候，不光是我朋友，大家都很容易有一個擔憂的問題，就是如果讓整個公司所有業務研發團隊都要爲了適配 MSE Nacos 升級改造一遍的話，不單單是代碼改造量的問題，還需要有配套的集成測試、性能壓力測試需要一起跟進，這些加起來需要投入的成本實在是太高了。
然而實際上這個問題其實是最不用擔心的，因爲 MSE Nacos 實現了對開源 Eureka 原生協議的完全兼容，業務模型層面把 Eureka 中的 InstanceInfo 數據模型和Nacos 的數據模型(Service 和 Instance)進行了對應的一一映射，對於 Eureka Client 的改變僅僅是需要更換一下服務端實例 Endpoint 配置的修改即可完成切換。在日常業務使用中，既可以使用原生的 Eureka 協議把 MSE Nacos 實例當成一個 Eureka 集羣來用，也可以支持 Nacos、Eureka 客戶端雙協議並存，不同協議的服務註冊信息之間支持互相轉換，從而保證業務微服務調用的連通性。
但這時肯定有人要問了，我在老的自建 Eureka 集羣上那些已有的線上服務註冊存量數據怎麼辦，如何平遷到 Nacos 上並且還能不影響到現在的業務調用。爲了解決這個問題，MSE Nacos 推薦使用官方的 MSE-Sync 解決方案， MSE-Sync 是基於開源 Nacos-Sync 優化後的遷移配套數據同步工具，支持雙向同步、自動拉取服務和一鍵同步的功能，**可以輕鬆完成自建 Eureka 集羣到 MSE Nacos 專業版的數據平滑遷移。
** 遷移方案可以參考這篇最佳實踐幫助文檔：https://help.aliyun.com/zh/mse/use-cases/migrate-the-user-created-euraka-registry-to-mse-nacos
另外這裏需要補充的是，Eureka 1.X 版本已經停止更新了，社區 2.0 版本的開源工作已經停止，而且 Eureka 2.0.0 Java 客戶端 API 不向後兼容 1.x，看到官方下面的通知就問你慌不慌。從長遠考慮繼續使用自建 Eureka 作爲服務註冊中心，顯然不是一個很好的選擇。
數據對比
爲了對比兩者產品能力上的差異，接下來我們來一起做一個很有意思的壓力測試，這次開源 Eureka(採用閉源前次新 1.X 版本 v1.10.17)和 MSE Nacos 我們都使用了同樣的 8C16G 規格容器來搭建 3 節點高可用集羣。另外施壓腳本我們統一採用 Golang 實現的模擬多 client 來併發註冊，施壓機器均是雲上普通的 ECS 機器，所有的模擬的 Eureka client 實例行爲跟實際生產環境行爲均保持一致，包含註冊、心跳續約、定時全量/增量拉取 Registry 數據等功能，其中 client 心跳上報時間間隔 3s，過期時間 10s，定時全量/增量註冊數據拉取的間隔爲 30s。
施壓程序會分若干批，均勻不斷的往集羣裏註冊新的服務數據並通過心跳保持住，直到集羣出現性能瓶頸或者是達成預期壓測目標(服務數 100，每個服務實例數 500)，壓測過程中通過實時監控大盤來觀測集羣各項系統指標數據來做一個對比。
開源 Eureka 的表現
結論： 開源 Eureka 集羣在服務註冊增長到接近 2W 附近的時候，可以看到 CPU 負載已經有飆高跡象，後面持續攀升的壓力最終導致集羣 CPU 被完全打滿，並且集羣開始頻繁出現服務實例續約失敗的錯誤，最終集羣容量也只能穩定在 1.6W 左右，不滿足壓測預期。
MSE Nacos 專業版的表現
結論： 可以看到 MSE Nacos 專業版隨着註冊規模的不斷攀升，CPU 利用率只是穩步上升，並沒有出現 CPU 負載突然飆高的情況。當到達開源 Eureka 2W 附近性能瓶頸的時候，此時 MSE Nacos 集羣的 CPU 只有 40% 不到，這就意味着同樣的集羣容量要求，使用 MSE Nacos 專業版需要的機器規格可以更低，性價比更高。當最終穩定在本次壓測目標 5W 的時候，此時集羣進入穩態不再變更，整體 CPU 利用率穩定在了 50%，內存佔用、讀寫 RT 均表現優異。
更多的差異化技術競爭力
通過上述案例、壓測數據的展示，再回到本文標題討論的內容，自建 Eureka 顯然不是一個最優的選擇，深度結合雲原生技術的 MSE Nacos 在成本、性能、彈性等多項指標上都已經完全超越了開源 Eureka， 另外像 MSE Nacos 通過支持 MCP 協議和 XDS 協議，服務網格生態領域已完全兼容專業版的 Eureka 協議，這樣搭配上 MSE 雲原生網關、微服務治理的能力，就可以搭建一套面向業界主流微服務生態的一站式微服務平臺，擁有一系列的高性能、高可用的企業級雲服務能力，節省自建網關、註冊配置中心、微服務治理體系的人力成本。
寫在最後
MSE Nacos Serverless 版本已於 2023 年 11 月 17 日正式商用！