作者|風卿
前言
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加解密插件。
com.alibaba.nacos
nacos-client
1.4.2
com.alibaba.nacos
nacos-client-mse-extension
1.0.1
初始化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", 6000);
總結
MSE Nacos2.0專業版相較於基礎版在性能、可用性和安全性上都有較大提升，基礎版建議用於測試環境，對於生產環境建議使用專業版。對於用戶身份、密碼等配置敏感信息建議都開啟權限控制能力並且加密保存加強數據安全。
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。