前言

MSE從2020年1月發(fā)布Nacos1.1.3版本引擎，支持在公有云環(huán)境全托管的方式使用Nacos作為注冊(cè)中心。2020年7月發(fā)布Nacos1.2.1版本支持元配置數(shù)據(jù)管理，支持微服務(wù)應(yīng)用在運(yùn)行時(shí)動(dòng)態(tài)修改配置信息和路由規(guī)則等。隨著用戶的深入使用，Nacos1.X版本的性能問題也漸漸暴露出來(lái)。通過(guò)對(duì)1.X版本的內(nèi)核改造，Nacos2.0專業(yè)版性能提升10倍，基本能滿足用戶對(duì)微服務(wù)場(chǎng)景的性能要求。

除了性能的提升，專業(yè)版具有更高的SLA保障，并且在配置數(shù)據(jù)上具有更高的安全性，同時(shí)通過(guò)MCP協(xié)議與Istio生態(tài)打通，作為Istio的注冊(cè)中心。

MSE Nacos1.X基礎(chǔ)版架構(gòu)

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

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

MSE Nacos1.X基礎(chǔ)版架構(gòu)問題

目前1.X的架構(gòu)存在幾個(gè)問題：

每個(gè)服務(wù)實(shí)例都通過(guò)心跳續(xù)約，在Dubbo場(chǎng)景每個(gè)接口對(duì)應(yīng)一個(gè)服務(wù)，當(dāng)Dubbo的應(yīng)用接口數(shù)較多時(shí)需要心跳續(xù)約TPS會(huì)很高。
心跳續(xù)約感知時(shí)延長(zhǎng)，需要達(dá)到續(xù)約超時(shí)時(shí)間才能刪除實(shí)例，一般需要15S，時(shí)效性較差
通過(guò)UDP推送變更數(shù)據(jù)不可靠，需要客戶端定時(shí)進(jìn)行數(shù)據(jù)全量對(duì)賬保證數(shù)據(jù)的正確性，大量無(wú)效查詢，整體服務(wù)的QPS很高
通信方式基于HTTP短鏈接的方式，Nacos側(cè)釋放連接會(huì)進(jìn)入TIME_WAIT狀態(tài)，當(dāng)QPS較高時(shí)會(huì)有連接耗盡導(dǎo)致報(bào)錯(cuò)的風(fēng)險(xiǎn)，當(dāng)然這里通過(guò)SDK引入HTTP連接池能緩解，但不能根治
配置的長(zhǎng)輪詢方式會(huì)導(dǎo)致相關(guān)數(shù)據(jù)進(jìn)入JVM Old區(qū)申請(qǐng)和釋放內(nèi)存，引起頻繁的CMS GC

MSE Nacos2.0專業(yè)版架構(gòu)及新模型

1.X架構(gòu)的問題核心點(diǎn)在于連接模型上，2.0架構(gòu)升級(jí)為長(zhǎng)連接模型，在通信層通過(guò)gRPC和RSocket實(shí)現(xiàn)長(zhǎng)連接數(shù)據(jù)傳輸和推送能力，在連接層新增加請(qǐng)求處理器、流控和負(fù)載均衡等功能

MSE Nacos1.X基礎(chǔ)版架構(gòu)問題

目前1.X的架構(gòu)存在幾個(gè)問題：

每個(gè)服務(wù)實(shí)例都通過(guò)心跳續(xù)約，在Dubbo場(chǎng)景每個(gè)接口對(duì)應(yīng)一個(gè)服務(wù)，當(dāng)Dubbo的應(yīng)用接口數(shù)較多時(shí)需要心跳續(xù)約TPS會(huì)很高。
心跳續(xù)約感知時(shí)延長(zhǎng)，需要達(dá)到續(xù)約超時(shí)時(shí)間才能刪除實(shí)例，一般需要15S，時(shí)效性較差
通過(guò)UDP推送變更數(shù)據(jù)不可靠，需要客戶端定時(shí)進(jìn)行數(shù)據(jù)全量對(duì)賬保證數(shù)據(jù)的正確性，大量無(wú)效查詢，整體服務(wù)的QPS很高
通信方式基于HTTP短鏈接的方式，Nacos側(cè)釋放連接會(huì)進(jìn)入TIME_WAIT狀態(tài)，當(dāng)QPS較高時(shí)會(huì)有連接耗盡導(dǎo)致報(bào)錯(cuò)的風(fēng)險(xiǎn)，當(dāng)然這里通過(guò)SDK引入HTTP連接池能緩解，但不能根治
配置的長(zhǎng)輪詢方式會(huì)導(dǎo)致相關(guān)數(shù)據(jù)進(jìn)入JVM Old區(qū)申請(qǐng)和釋放內(nèi)存，引起頻繁的CMS GC

MSE Nacos2.0專業(yè)版架構(gòu)及新模型

1.X架構(gòu)的問題核心點(diǎn)在于連接模型上，2.0架構(gòu)升級(jí)為長(zhǎng)連接模型，在通信層通過(guò)gRPC和RSocket實(shí)現(xiàn)長(zhǎng)連接數(shù)據(jù)傳輸和推送能力，在連接層新增加請(qǐng)求處理器、流控和負(fù)載均衡等功能

2.0架構(gòu)解決的問題：

應(yīng)用POD按照長(zhǎng)連接維度進(jìn)行心跳續(xù)約，不需要按照實(shí)例級(jí)，大大降低重復(fù)請(qǐng)求
長(zhǎng)連接斷開時(shí)可以快速感知到，不用等待續(xù)約超時(shí)時(shí)長(zhǎng)就可以移除實(shí)例
NIO流式推送機(jī)制相對(duì)于UDP更可靠，并且可以降低應(yīng)用對(duì)賬數(shù)據(jù)頻率
沒有連接反復(fù)創(chuàng)建的開銷，大幅降低TIME_WAIT連接多問題
長(zhǎng)連接也解決了配置模塊長(zhǎng)輪詢CMS GC問題
2.0架構(gòu)帶來(lái)的問題：

相對(duì)于Tomcat HTTP短連接模型，長(zhǎng)連接模型需要自己管理連接狀態(tài)，增加了復(fù)雜性
長(zhǎng)連接gRPC基于HTTP2.0 Stream，相對(duì)于HTTP的open API可觀測(cè)性和易用性降低了

2.0架構(gòu)整體來(lái)說(shuō)降低了資源開銷，提高了系統(tǒng)吞吐量，在性能上有大幅提升，但同時(shí)也增加了復(fù)雜度

MSE Nacos2.0專業(yè)版性能

Nacos分為服務(wù)發(fā)現(xiàn)模塊和配置管理模塊，這里先對(duì)服務(wù)發(fā)現(xiàn)場(chǎng)景進(jìn)行性能測(cè)試。

使用200臺(tái)施壓機(jī)，每個(gè)施壓機(jī)模擬500個(gè)客戶端，每個(gè)客戶端注冊(cè)5個(gè)服務(wù)，訂閱5個(gè)服務(wù)，最高可以提供10W個(gè)長(zhǎng)連接、50W個(gè)服務(wù)實(shí)例和訂閱者壓測(cè)場(chǎng)景

服務(wù)發(fā)現(xiàn)壓測(cè)主要壓變更態(tài)和穩(wěn)定態(tài)兩種場(chǎng)景：

變更態(tài)：施壓機(jī)施壓階段會(huì)大量連接Nacos注冊(cè)和訂閱服務(wù)，這個(gè)階段服務(wù)端的壓力相對(duì)會(huì)比較大，需要看整體注冊(cè)和訂閱是否最終完全成功。
穩(wěn)定態(tài)：當(dāng)施壓機(jī)請(qǐng)求都成功之后就會(huì)進(jìn)入穩(wěn)定狀態(tài)，客戶端和服務(wù)端之間只需要維持長(zhǎng)連接心跳即可，這個(gè)階段服務(wù)端的壓力會(huì)比較小。如果在變更態(tài)服務(wù)端的壓力過(guò)大會(huì)發(fā)生請(qǐng)求超時(shí)、連接斷開等問題，不能進(jìn)入穩(wěn)定態(tài)
服務(wù)發(fā)現(xiàn)也會(huì)在MSE上對(duì)低版本做升級(jí)，對(duì)比升級(jí)前后的性能變化曲線，這樣的性能對(duì)比更直觀

配置管理模塊在實(shí)際使用中是寫少讀多的場(chǎng)景，主要瓶頸點(diǎn)在單臺(tái)機(jī)器性能上，壓測(cè)場(chǎng)景主要基于單臺(tái)機(jī)器的讀性能和連接支撐數(shù)
使用200臺(tái)施壓機(jī)，每臺(tái)施壓機(jī)可以模擬200個(gè)客戶端，每個(gè)客戶端訂閱200個(gè)配置，發(fā)起配置訂閱和讀配置請(qǐng)求

在服務(wù)發(fā)現(xiàn)場(chǎng)景對(duì)比基礎(chǔ)版和專業(yè)版在2C4G、4C8G和8C16G規(guī)格下的性能數(shù)據(jù)情況。

這里最大的TPS和實(shí)例數(shù)都是服務(wù)能保證高可用穩(wěn)定運(yùn)行的數(shù)據(jù)，大概會(huì)是最大值的一半或者三分之二，也就是說(shuō)掛一臺(tái)機(jī)器也可以正常運(yùn)行。

穩(wěn)定運(yùn)行時(shí)支持規(guī)模提升7倍，實(shí)際上最大支持規(guī)模提升7-10倍

還有一個(gè)場(chǎng)景是對(duì)3節(jié)點(diǎn)2C4G MSE Nacos升級(jí)前后的對(duì)比，主要分為三個(gè)階段：

第一個(gè)階段客戶端使用1.X版本，MSE Nacos使用基礎(chǔ)版，實(shí)例數(shù)從0->6000->10000，最后到14000最大值無(wú)法繼續(xù)增大，Server CPU達(dá)到80-90%，客戶端不斷報(bào)錯(cuò)，接著降低實(shí)例數(shù)到6000
第二階段升級(jí)MSE Nacos基礎(chǔ)版到專業(yè)版，實(shí)例數(shù)到達(dá)14000無(wú)法繼續(xù)增大，性能壓測(cè)性能曲線差異不大
第三階段在保持實(shí)例數(shù)為14000的狀態(tài)下，分批升級(jí)客戶端到2.0版本，CPU指標(biāo)曲線不斷下降至20%左右，并且整體處于穩(wěn)定態(tài)無(wú)報(bào)錯(cuò)

從升級(jí)前后的性能曲線感受MSE Nacos2.0專業(yè)版性能有提升較大。最后整體的壓測(cè)情況，相較于基礎(chǔ)版，專業(yè)版服務(wù)發(fā)現(xiàn)性能提升10倍，配置管理提升7倍

MSE Nacos平滑升級(jí)專業(yè)版

對(duì)于新用戶可以直接創(chuàng)建專業(yè)版實(shí)例，老用戶則可以通過(guò)MSE"實(shí)例變更"一鍵升級(jí)。MSE會(huì)在后臺(tái)對(duì)POD升級(jí)，由于V1V2數(shù)據(jù)結(jié)構(gòu)不一樣，在一開始的時(shí)候Nacos數(shù)據(jù)默認(rèn)是雙寫的，在升級(jí)過(guò)程中數(shù)據(jù)會(huì)從V1同步到V2，升級(jí)完成后數(shù)據(jù)會(huì)從V2同步V1，最后MSE會(huì)關(guān)閉雙寫邏輯，整體流程都是自動(dòng)。

SLB的服務(wù)端口最后也會(huì)增加GRPC 9848端口，此時(shí)應(yīng)用SDK可以從1.X版本升級(jí)到2.0版本，整體客戶端服務(wù)端升級(jí)到2.0架構(gòu)

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

1.X客戶端可以訪問基礎(chǔ)版，也可以訪問專業(yè)版
2.0客戶端可以訪問專業(yè)版，但是不能訪問基礎(chǔ)版

Nacos配置安全管理

上一期島風(fēng)同學(xué)講解了配置權(quán)限控制，整體MSE Nacos通過(guò)阿里云RAM主子賬號(hào)體系來(lái)做權(quán)限控制，這期我主要講一下Nacos的配置加密功能。

用戶在使用配置數(shù)據(jù)時(shí)可能會(huì)將用戶信息、數(shù)據(jù)庫(kù)密碼等敏感信息存放到Nacos中，而Nacos存儲(chǔ)配置數(shù)據(jù)都是明文傳輸、明文存儲(chǔ)的，在數(shù)據(jù)庫(kù)內(nèi)容泄漏或者傳輸層抓包時(shí)會(huì)導(dǎo)致敏感配置數(shù)據(jù)項(xiàng)泄漏，整體安全風(fēng)險(xiǎn)非常高。

常用的HTTPS協(xié)議能解決傳輸安全，但解決不了存儲(chǔ)安全，這里直接在客戶端進(jìn)行加密，這樣在傳輸和存儲(chǔ)的過(guò)程中數(shù)據(jù)都是加密的。

這里使用第三方加密系統(tǒng)（如阿里云KMS）加強(qiáng)加密的安全性，為了加密速度快使用對(duì)稱加密（AES算法），由于密鑰要隨著密文傳輸，同時(shí)對(duì)密鑰進(jìn)行加密，整體采用二級(jí)加密的方式。

SDK在發(fā)布數(shù)據(jù)時(shí)會(huì)先從KMS中拿到密鑰和加密后的密鑰，然后使用密鑰對(duì)數(shù)據(jù)進(jìn)行加密，接著將加密數(shù)據(jù)和加密后的密鑰傳輸?shù)絅acos存儲(chǔ)。SDK會(huì)從Nacos獲取加密數(shù)據(jù)和加密后的密鑰，然后通過(guò)加密后的密鑰從KMS獲取明文密鑰，接著通過(guò)明文密鑰對(duì)加密數(shù)據(jù)進(jìn)行解密獲取明文數(shù)據(jù)，解決了整體傳輸和存儲(chǔ)中的數(shù)據(jù)安全問題。

為了兼容老邏輯，并且只有敏感數(shù)據(jù)需要加密，Nacos只對(duì)固定前綴DataId的數(shù)據(jù)進(jìn)行加密，并且在開源側(cè)通過(guò)SPI插件化實(shí)現(xiàn)，讓用戶自己能擴(kuò)展

用戶可以通過(guò)SDK和MSE控制臺(tái)對(duì)敏感數(shù)據(jù)進(jìn)行加解密，整體SDK和MSE控制臺(tái)都會(huì)先訪問KMS再加密存儲(chǔ)配置數(shù)據(jù)，然后解密之后再展示明文，使用流程和之前明文存儲(chǔ)一致

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

com.alibaba.nacos

nacos-client

1.4.2

com.alibaba.nacos

nacos-client-mse-extension

1.0.1

初始化SDK時(shí)需要填入子賬號(hào)AK/SK，并授權(quán)KMS加解密權(quán)限，具體細(xì)節(jié)可以參考創(chuàng)建和使用配置加密

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);

總結(jié)

MSE Nacos2.0專業(yè)版相較于基礎(chǔ)版在性能、可用性和安全性上都有較大提升，基礎(chǔ)版建議用于測(cè)試環(huán)境，對(duì)于生產(chǎn)環(huán)境建議使用專業(yè)版。對(duì)于用戶身份、密碼等配置敏感信息建議都開啟權(quán)限控制能力并且加密保存加強(qiáng)數(shù)據(jù)安全。