深刻淺出講解MSE Nacos 2.0新特性

簡介：隨着雲原生時代的到來，微服務已經成爲應用架構的主流，Nacos也憑藉簡單易用、穩定可靠、性能卓越的核心競爭力成爲國內微服務領域首選的註冊中心和配置中心；Nacos2.0更是把性能作到極致，讓業務快速發展的用戶不再用擔憂性能問題；同時阿里雲MSE也提供Nacos2.0託管服務，一鍵開通享受阿里十年沉澱微服務全部能力！

微服務引擎 MSE 專業版發佈，支持 Nacos 2.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加解密插件。

    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專業版相較於基礎版在性能、可用性和安全性上都有較大提高，基礎版建議用於測試環境，對於生產環境建議使用專業版。對於用戶身份、密碼等配置敏感信息建議都開啓權限控制能力而且加密保存增強數據安全。

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

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。