作者 | 風卿

微服務引擎 MSE 專業版發佈，支持 Nacos2.0，相比基礎版，專業版具有更高的 SLA 保障，性能提升十倍，99.95%可用性，配置能力進一步增強。新用戶首購8折。

前言

MSE 從 2020年1月發佈 Nacos1.1.3 版本引擎，支持在公有云環境全託管的方式使用 Nacos 作為註冊中心。2020年7月發佈 Nacos1.2.1 版本支持元配置數據管理，支持微服務應用在運行時動態修改配置信息和路由規則等。隨著用戶的深入使用，Nacos1.X 版本的性能問題也漸漸暴露出來。通過對 1.X版本的內核改造，Nacos2.0 專業版性能提升 10倍，基本能滿足用戶對微服務場景的性能要求。

除了性能的提升，專業版具有更高的 SLA 保障，並且在配置數據上具有更高的安全性，同時通過 MCP 協議與 Istio 生態打通，作為 Istio 的註冊中心。

MSE Nacos1.X基礎版架構

整體 1.X 架構可以粗略分為五層，分別是接入層、通信層、功能層、同步層和持久化層。

• 用戶通過接入層訪問 Nacos，比如 SDK、SCA、Dubbo、Console，Nacos 也提供了 HTTP 協議的 open API 訪問方式。
• 通信層包含 HTTP 和 UDP，Nacos 主要通過 HTTP 進行通信，少部分服務推送功能會用到 UDP。
• 功能層目前有 Naming 和 Config 兩大部分，分別提供服務發現和配置管理能力。
• 同步層包含 AP 模式的 Distro 協議（服務註冊）和 CP 模式的 Raft 協議（服務元信息），以及配置通知的 Notify 同步方式。
• Nacos 的數據持久化有用到 Mysql、Derby 和本地文件，配置數據、用戶信息、權限數據存儲在 Mysql 或者 Derby 中，持久化的服務數據則存放在本地文件。

MSE Nacos1.X基礎版架構問題

目前 1.X 的架構存在幾個問題：

• 每個服務實例都通過心跳續約，在 Dubbo 場景每個接口對應一個服務，當 Dubbo 的應用接口數較多時需要心跳續約 TPS 會很高。
• 心跳續約感知時延長，需要達到續約超時時間才能刪除實例，一般需要 15S，時效性較差。
• 通過 UDP 推送變更數據不可靠，需要客戶端定時進行數據全量對賬保證數據的正確性，大量無效查詢，整體服務的 QPS 很高。
• 通信方式基於 HTTP 短鏈接的方式，當 Nacos 側釋放連接會進入 TIME_WAIT 狀態，當 QPS 較高時會有連接耗盡導致報錯的風險，當然這裡通過 SDK 引入 HTTP 連接池能緩解，但不能根治。
• 配置的長輪詢方式會導致相關數據進入 JVM Old 區申請和釋放內存，引起頻繁的 CMS GC。

MSE Nacos2.0專業版架構及新模型

1.X 架構的問題核心點在於連接模型上，2.0 架構升級為長連接模型，在通信層通過 gRPC 和 RSocket 實現長連接數據傳輸和推送能力，在連接層新增加請求處理器、流控和負載均衡等功能。

2.0 架構解決的問題：

• 應用 POD 按照長連接維度進行心跳續約，不需要按照實例級，大大降低重複請求；
• 長連接斷開時可以快速感知到，不用等待續約超時時長就可以移除實例；
• NIO 流式推送機制相對於 UDP 更可靠，並且可以降低應用對賬數據頻率；
• 沒有連接反覆創建的開銷，大幅降低 TIME_WAIT 連接多問題；
• 長連接也解決了配置模塊長輪詢 CMS GC 問題。

2.0 架構帶來的問題：

• 相對於 Tomcat HTTP 短連接模型，長連接模型需要自己管理連接狀態，增加了複雜性；
• 長連接 gRPC 基於 HTTP2.0 Stream，相對於 HTTP 的 open API 可觀測性和易用性降低了。

2.0 架構整體來說降低了資源開銷，提高了系統吞吐量，在性能上有大幅提升，但同時也增加了複雜度。

MSE Nacos2.0專業版性能

Nacos 分為服務發現模塊和配置管理模塊，這裡先對服務發現場景進行性能測試：使用 200 臺施壓機，每個施壓機模擬 500 個客戶端，每個客戶端註冊 5 個服務，訂閱 5 個服務，最高可以提供 10W 個長連接、50W 個服務實例和訂閱者壓測場景。

服務發現壓測主要壓變更態和穩定態兩種場景：

• 變更態：施壓機施壓階段會大量連接 Nacos 註冊和訂閱服務，這個階段服務端的壓力相對會比較大，需要看整體註冊和訂閱是否最終完全成功。
• 穩定態：當施壓機請求都成功之後就會進入穩定狀態，客戶端和服務端之間只需要維持長連接心跳即可，這個階段服務端的壓力會比較小。如果在變更態服務端的壓力過大會發生請求超時、連接斷開等問題，不能進入穩定態。

服務發現也會在 MSE 上對低版本做升級，對比升級前後的性能變化曲線，這樣的性能對比更直觀。配置管理模塊在實際使用中是寫少讀多的場景，主要瓶頸點在單臺機器性能上，壓測場景主要基於單臺機器的讀性能和連接支撐數。

使用 200臺 施壓機，每臺施壓機可以模擬 200個 客戶端，每個客戶端訂閱 200個 配置，發起配置訂閱和讀配置請求。

在服務發現場景對比基礎版和專業版在 2C4G、4C8G 和 8C16G 規格下的性能數據情況：這裡最大的TPS和實例數都是服務能保證高可用穩定運行的數據，大概會是最大值的一半或者三分之二，也就是說掛一臺機器也可以正常運行。

穩定運行時支持規模提升7倍，實際上最大支持規模提升7-10倍。

還有一個場景是對 3節點 2C4G MSE Nacos 升級前後的對比，主要分為三個階段：

• 第一個階段客戶端使用 1.X 版本，MSE Nacos 使用基礎版，實例數從 0->6000->10000，最後到 14000 最大值無法繼續增大，Server CPU 達到 80-90%，客戶端不斷報錯，接著降低實例數到 6000；

• 第二階段升級 MSE Nacos 基礎版到專業版，實例數到達 14000 無法繼續增大，性能壓測性能曲線差異不大；

• 第三階段在保持實例數為 14000 的狀態下，分批升級客戶端到 2.0版本，CPU 指標曲線不斷下降至 20% 左右，並且整體處於穩定態無報錯。

從升級前後的性能曲線感受 MSE Nacos2.0 專業版性能有提升較大。最後整體的壓測情況，相較於基礎版，專業版服務發現性能提升 10倍，配置管理提升 7倍。

MSE Nacos平滑升級專業版

對於新用戶可以直接創建專業版實例，老用戶則可以通過 MSE"實例變更"一鍵升級。MSE 會在後臺對 POD 升級，由於 V1V2 數據結構不一樣，在一開始的時候 Nacos 數據默認是雙寫的，在升級過程中數據會從 V1 同步到 V2，升級完成後數據會從 V2 同步 V1，最後 MSE 會關閉雙寫邏輯，整體流程都是自動。

SLB 的服務端口最後也會增加 GRPC 9848 端口，此時應用 SDK 可以從1.X版本升級到 2.0版本，整體客戶端服務端升級到 2.0架構。

版本之間的兼容性情況，整體的兼容原則是高版本的服務端兼容低版本客戶端，但是高版本客戶端不一定能訪問低版本服務端：

• 1.X 客戶端可以訪問基礎版，也可以訪問專業版
• 2.0 客戶端可以訪問專業版，但是不能訪問基礎版。

Nacos配置安全管理

之前公眾號裡分享配置權限控制，整體 MSE Nacos 通過阿里雲 RAM 主子賬號體系來做權限控制，這期我主要講一下 Nacos 的配置加密功能。

用戶在使用配置數據時可能會將用戶信息、數據庫密碼等敏感信息存放到 Nacos 中，而 Nacos 存儲配置數據都是明文傳輸、明文存儲的，在數據庫內容洩漏或者傳輸層抓包時會導致敏感配置數據項洩漏，整體安全風險非常高。

常用的 HTTPS 協議能解決傳輸安全，但解決不了存儲安全，這裡直接在客戶端進行加密，這樣在傳輸和存儲的過程中數據都是加密的。

這裡使用第三方加密系統（如阿里雲 KMS）加強加密的安全性，為了加密速度快使用對稱加密（AES 算法），由於密鑰要隨著密文傳輸，同時對密鑰進行加密，整體採用二級加密的方式。

SDK 在發佈數據時會先從 KMS 中拿到密鑰和加密後的密鑰，然後使用密鑰對數據進行加密，接著將加密數據和加密後的密鑰傳輸到 Nacos 存儲。SDK 會從 Nacos 獲取加密數據和加密後的密鑰，然後通過加密後的密鑰從 KMS 獲取明文密鑰，接著通過明文密鑰對加密數據進行解密獲取明文數據，解決了整體傳輸和存儲中的數據安全問題。

為了兼容老邏輯，並且只有敏感數據需要加密，Nacos 只對固定前綴 DataId 的數據進行加密，並且在開源側通過 SPI 插件化實現，讓用戶自己能擴展。用戶可以通過 SDK 和 MSE 控制檯對敏感數據進行加解密，整體 SDK 和 MSE 控制檯都會先訪問 KMS 再加密存儲配置數據，然後解密之後再展示明文，使用流程和之前明文存儲一致。

用戶使用 SDK 接入開啟加解密功能需要 SDK 在 1.4.2 版本及以上，同時需要引入 MSE 內部實現的 nacos-client-mse-extension 加解密插件。

<dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client</artifactId>    <version>1.4.2</version>  </dependency>  <dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client-mse-extension</artifactId>    <version>1.0.1</version>  </dependency>

初始化 SDK 時需要填入子賬號 AK/SK，並授權 KMS 加解密權限，具體細節可以參考創建和使用配置加密

Properties properties = new Properties();  properties.put("serverAddr", "mse-xxxxxx-p.nacos-ans.mse.aliyuncs.com");  properties.put("accessKey", "xxxxxxxxxxxxxx");  properties.put("secretKey", "xxxxxxxxxxxxxx");  properties.put("keyId", "alias/acs/mse");  properties.put("regionId", "cn-hangzhou");  ConfigService configService = NacosFactory.createConfigService(properties);  String content = configService.getConfig("cipher-kms-aes-256-dataid", "group", 6

總結

MSE Nacos 2.0 專業版相較於基礎版在性能、可用性和安全性上都有較大提升，基礎版建議用於測試環境，對於生產環境建議使用專業版。對於用戶身份、密碼等配置敏感信息建議都開啟權限控制能力並且加密保存加強數據安全。

更多 MSE 特性，歡迎進釘釘群交流，MSE 微服務引擎用戶交流群（二群）

群號：34754806