作者：胡安祥
滿幫集團，作爲“互聯網+物流”的平臺型企業，一端承接託運人運貨需求，另一端對接貨車司機，提升貨運物流效率。2021 年美股上市，成爲數字貨運平臺上市第一股。根據公司年報，2021 年，超過 350 萬貨車司機在平臺上完成超 1.283 億個訂單，實現總交易價值 GTV 2623 億元，佔中國數字貨運平臺份額超 60%。2022 年 10 月，運滿滿司機版 MAU 達到 949.21 萬人，貨車幫司機版 MAU 爲 399.91 萬人；運滿滿貨主版 MAU 爲 218.68 萬人，貨車幫貨主版 MAU 爲 63.78 萬人。 （以下內容由子葵、聰言整理輸出）
業務增長對服務穩定性的挑戰
滿幫集團在業務生產環境中自建微服務網關，負責南北方向流量調度、安全防護以及微服務治理，同時考慮到多活容災能力還提供了諸如同機房優先調用、容災跨機房調用等機制。微服務網關作爲微服務架構前端的組件，充當了所有微服務的流量入口。客戶端的請求進來會先打到 ALB（負載均衡），然後到內部的網關，再通過網關路由到具體的業務服務模塊。
所以網關需要通過一個服務註冊中心來動態發現當前生產環境部署的所有微服務實例，當部分服務實例因故障而無法提供服務時，網關還可以跟服務註冊中心搭配工作，自動將請求轉發到健康的服務實例上，實現故障轉移和彈性，使用自研框架配合服務註冊中心實現服務間調用，同時使用自建配置中心實現配置管理和變更推送，滿幫集團最早採用了開源 Eureka，ZooKeeper 來搭建集羣實現服務註冊中心和配置中心，這套架構也很好的承接了滿幫集團前期的業務快速增長。
但是隨着業務體量的逐漸增大，業務模塊越來越多，服務註冊實例數爆發式增長，自建 Eureka 服務註冊中心集羣和 ZooKeeper 集羣在這套架構的穩定性問題也日益明顯。
滿幫集團的同學在運維的時候發現自建的 Eureka 集羣在服務註冊實例到達 2000+ 規模的時候，由於 Eureka 集羣節點之間在做實例註冊信息同步的時候，部分節點處理不過來，很容易出現節點掛掉無法提供服務最終引發故障的問題；ZooKeeper 集羣頻繁 GC 導致服務間調用和配置發佈出現抖動，影響整體穩定性，並且由於 ZooKeeper 默認沒有任何開啓鑑權和身份認證能力，配置存儲面臨安全挑戰，這些問題也給業務的穩定持久發展帶來了很大的挑戰。
業務架構平滑遷移
在上述業務背景下，滿幫同學選擇了緊急上雲，採用阿里雲 MSE Nacos，MSE ZooKeeper 產品來替換原先的 Eureka 和 Zookeeper 集羣，但是如何才能做到低成本快速的架構升級，以及上雲期間業務流量的無損平滑遷移呢？
在這個問題上，MSE Nacos實現了對開源 Eureka 原生協議的完全兼容，內核仍然由 Nacos 驅動，業務適配層把 Eureka InstanceInfo 數據模型和 Nacos 的數據模型(Service 和 Instance)做了一一映射。而這一切對於滿幫集團已經對接過自建 Eureka 集羣的業務方而言，做到了完全透明。
這就意味着，原先的業務方在代碼層面上完全不用改動，只需要把 Eureka Client 連接的服務端實例 Endpoint 配置修改成 MSE Nacos 的 Endpoint即可。使用上同樣也很靈活，既可以繼續使用原生的 Eureka 協議把 MSE Nacos 實例當成一個 Eureka 集羣來用，也可以 Nacos、Eureka 客戶端雙協議並存，不同協議的服務註冊信息之間支持互相轉換，從而保證業務微服務調用的連通性。
另外在上雲過程中，MSE 官方提供了 MSE-Sync 解決方案，是一款基於開源 Nacos-Sync 優化後的遷移配套數據同步工具，支持雙向同步、自動拉取服務和一鍵同步的功能。滿幫同學通過 MSE-Sync 很輕鬆的完成原先自建 Eureka 集羣上已有的線上服務註冊存量數據一鍵遷移到新的 MSE Nacos 集羣，同時後續在老的集羣上新註冊的增量數據也會源源不斷的自動獲取同步到新集羣，這樣就保證了在業務實際切流遷移之前，兩邊的集羣服務註冊實例信息始終是完全一致的。待數據同步 check 通過之後，將原先的 Eureka Client 的 Endpoint 配置進行替換，重新發布升級後就成功的遷移到新的 MSE Nacos 集羣了。
突破原生 Eureka 集羣架構性能瓶頸
滿幫集團在找到 MSE 團隊合作技術架構升級的時候，提出的最重要的一條訴求，就是要解決原先 Eureka 集羣間服務註冊信息同步壓力大的問題，這其是因爲 Eureka Server 是傳統的對等星型同步 AP 模型導致的，各個 Server 節點角色相等完全對等，對於每次變更（註冊/反註冊/心跳續約/服務狀態變更等）都會生成相應的同步任務來用於所有實例數據的同步，這樣一來同步作業量隨着集羣規模、實例數正相關同步上漲。
滿幫集團同學實踐下來，當集羣服務註冊規模達到 2000+ 的時候，發現部分節點 CPU 佔用率、負載都很高，時不時還會假死導致業務抖動。這一點在 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.
而 MSE Nacos 在架構選型上就考慮到這個問題並給出了更好的解決方案，那就是自研的 AP 模型 Distro 協議，保留了星型同步模型的基礎上，Nacos 對所有服務註冊實例數據進行了 Hash 散列、邏輯數據分片，爲每一條服務實例數據分配一個集羣責任節點，每一個 Server 節點僅負責自己 own 的那一部分數據的同步和續約邏輯，同時集羣間數據同步的粒度相對於 Eureka 也更小。這樣帶來的好處是即使在大規模部署、服務實例數據很多的情況下，集羣間同步的任務量也能保證相對可控，並且集羣規模越大，這樣的模式帶來的性能提升也愈發明顯。
持續迭代優化追求極致性能
MSE Nacos 和 MSE ZooKeeper 在完成了滿幫集團的全量微服務註冊中心業務的承接後，在後續的升級版本中持續迭代優化，通過大量的性能壓測對比測試，從各個細節上繼續優化服務端性能來優化業務體驗，接下來會針對升級版本的優化點逐一分析介紹。
服務註冊高可用容災保護
原生 Nacos 提供了高階功能：推空保護，服務消費者（Consumer）通過註冊中心訂閱服務提供者（Provider）的實例列表，當註冊中心進行變更或遇到突發情況， 或服務提供者與註冊中心間的鏈接因網絡、CPU 等其他因素髮生抖動時，可能會導致訂閱異常，從而使服務消費者獲取到空的服務提供者實例列表。
爲了解決這個問題，可以在 Nacos 客戶端或 MSE Nacos 服務端開啓推空保護功能，以提高整個系統的可用性。我們同樣把這個穩定性功能引入到了對 Eureka 的協議支持中，當 MSE Nacos 服務端數據出現異常的時候，Eureka 客戶端從服務端拉取數據的時候，會默認得到容災保護支持，保障業務使用的時候不會拿到不符合預期的服務提供者實例列表，而導致業務故障。
另外 MSE Nacos 和 MSE ZooKeeeper 還提供了多重高可用保障機制，如果業務方有更高的高可靠性和數據安全需求，在創建實例的時候可以選擇不少於 3 節點的方式進行部署。當其中某個實例故障的時候，節點間秒級完成切換，故障節點自動離羣。同時 MSE 每個 Region 都包含多個可用區，同一個 Region 內不同 Zone 之間的網絡延遲很小（3ms 以內），多可用區實例可以將服務節點部署在不同可用區，當可用區 A 出現故障的時候，流量會在很短的時間內切換到另外的可用區 B。整個過程業務方無感知，應用代碼層面無感知、無需變更。這一個機制只需要配置多節點部署，MSE 會自動幫你部署到多個可用區進行打散容災。
支持 Eureka 客戶端增量拉取數據
滿幫同學在遷移到 MSE Nacos 之後，原先服務端實例假死無法提供服務的問題得到了很好的解決，但是發現機房的網絡帶寬佔用過高，偶爾服務高峯期還會出現帶寬打滿的情況。後來發現是因爲每次 Eureka 客戶端從 MSE Nacos 拉取服務註冊信息的時候，每次都只支持全量拉取，大幾千級別的數據量定時拉取，導致網關層面的 FGC 次數也升高了很多。
爲了解決這個問題，MSE Nacos 上線了針對 Eureka 服務註冊信息的增量拉取機制，配合上客戶端使用方式的調整，客戶端只需要在首次啓動後拉取一次全量數據，後續只需要根據增量數據來保持本地數據和服務端數據的一致性，不再需要週期性的全量拉取，而正常生產環境中變更增量數據的數據量很小，這樣一來可以大幅降低出口帶寬的壓力。滿幫同學在升級了這個優化版本之後，發現帶寬從升級前的 40MB/s 一下子降到了 200KB/s，帶寬打滿問題迎刃而解。
充分壓測優化服務端性能
MSE 團隊後續對 MSE Nacos 集羣 For Eureka 的場景進行了更大規模的性能壓測，並通過各種性能分析工具排查業務鏈路上的性能瓶頸點，對原有功能進行了更多的性能優化和底層性能調參。
- 針對服務端的全量和增量數據註冊信息引入了緩存，並基於服務端數據 hash 來判斷是否發生變更。在 Eureka 服務端讀多寫少的場景下，可以大幅減少了 CPU 計算生成返回結果的性能開銷。
- 發現 SpringBoot 原生的 StringHttpMessageConverter 在處理大規模數據返回的時候存在性能瓶頸，提供了 EnhancedStringHttpMessageConverter 來優化字符串數據 IO 傳輸性能。
- 服務端數據返回支持 chunked。
- Tomcat 線程池數根據容器配置自適應調整。
滿幫集團在完成了以上版本迭代升級之後，服務端各項參數也取得了很棒的優化結果：
服務端 CPU 利用率從 13% 降到了 2%
註冊中心讀 RT 從原先 55ms 降至 3ms 以內
服務端 YGC Count 從原先的 10+ 降至 1
YGC Time 從原先的 125ms 降至 10ms 以內
旁路優化，保障集羣高壓下的穩定性
滿幫同學在遷移到 MSE ZooKeeper 一段時間後，集羣又出現了 Full GC，導致集羣不穩定，經過 MSE 緊急排查，發現是因爲 ZooKeeper 中 Metrics 的一個watch相關的統計指標在計算時對當前節點保存的 watch 數據進行了全量拷貝，在滿幫的場景下有非常大的 Watch 規模，metrics 計算拷貝 watch 在這樣的場景下產生了大量的內存碎片，導致最終集羣無法分配出符合條件的內存資源，最終 Full GC。
爲了解決這個問題，MSE ZooKeeper 針對非重要 metrics 採取降級的措施，保障這部分 metrics 不會影響集羣穩定性，針對 watch 拷貝的 metrics，採取動態獲取的策略，避免數據拷貝計算帶來的內存碎片問題。在應用此優化之後，集羣 Young GC 時間和次數都明顯下降。
優化之後集羣能夠平穩承接 200W QPS，GC 穩定
持續參數優化，尋找延時和吞吐量的最佳平衡點
滿幫同學將自建 ZooKeeper 遷移到 MSE ZooKeeper 之後，發現應用發佈時，客戶端讀取 ZooKeeper 中數據的延時過大，應用啓動讀取配置超時，導致應用啓動超時，爲了解決這個問題，MSE ZooKeeper 針對性進行壓測分析，在滿幫的場景下，ZooKeeper 在應用發佈時需要承接大量請求，請求產生的對象在現有的配置中導致Young GC 頻繁。
針對這種場景，MSE 團隊經過多輪壓測調整集羣配置，尋找請求延時和 TPS 最優的交點，在滿足延時需求的前提下，探索集羣最優性能，在保證請求延時 20ms 的前提下，集羣在日常 10w QPS 的水平下，CPU 從 20% 降低到 5%，集羣負載顯著降低。
後記
在數字貨運行業競爭激烈和技術快速發展的背景下，滿幫集團成功地實現了自身技術架構的升級，從自建的 Eureka 註冊中心平滑遷移到了更爲高效和穩定的 MSE Nacos 平臺。這不僅代表了滿幫集團在技術創新和業務擴展上的堅定決心，同時也展現了其對未來發展的深遠規劃。滿幫集團將微服務架構的穩定性和高性能作爲其數字化轉型的核心，全新的註冊中心架構帶來的顯著性能提高和穩定性增強，爲滿幫提供了強有力的支撐，使得平臺能夠更加從容地應對日益增長的業務需求，並且有餘力以應對未來可能出現的任何挑戰。
值得一提的是，滿幫集團在整個遷移過程中的敏捷反應和技術團隊的專業執行力也加速了架構升級的步伐。業務平臺的成功轉型不僅增強了用戶對滿幫服務的信任，也爲其他企業提供了寶貴的經驗。在未來，滿幫將繼續與 MSE 緊密合作，致力於進一步提升技術架構的穩定性、可擴展性和性能，持續爲業界樹立標杆，推動整個物流行業的數字化轉型。
在此次遷移過程中，業務能夠平穩無損遷移和性能的大幅提升，證明了 MSE 在服務註冊中心領域的卓越性能和可靠性。相信隨着 MSE 的不斷演進，其對易用性和穩定性的持續追求無疑將爲更多企業帶來巨大的商業價值，並在企業數字化進程中發揮越來越重要的作用。
此外，MSE 還全面支持微服務治理功能，包括流量防護、全鏈路灰度發佈等。通過在入口網關到後端應用配置完備的限流規則，有效地解決了突發流量帶來的系統穩定性風險，保障系統持續穩定運行，企業能夠更加專注於核心業務的發展。 滿幫集團的成功案例爲行業樹立了新的里程碑，我們懷着期待的目光，期待更多的企業都能在數字化征途上取得更輝煌的成就。
滿幫 CTO 王東（東天）寄語： 充分了解和利用雲的能力，能夠讓滿幫技術團隊從底層的持續投入中解脫出來，聚焦更上層的系統穩定性和工程效率，從架構層面實現更高的 ROI。
活動推薦：
點擊此處，報名參加飛天技術沙龍首個 AI 原生應用架構專場。