從內(nèi)部自用到對(duì)外服務(wù)，配置管理的演進(jìn)和設(shè)計(jì)優(yōu)化實(shí)踐

本文整理自阿里巴巴中間件技術(shù)專家彥林在中國(guó)開源年會(huì)上的分享，通過此文，您將了解到：

• 微服務(wù)給配置管理所帶來的變化

• 配置管理演進(jìn)過程中的設(shè)計(jì)思考

• 配置管理開源后的新探索

• 配置中心控制臺(tái)設(shè)計(jì)實(shí)踐

“為什么相對(duì)于傳統(tǒng)的軟件開發(fā)模式，微服務(wù)要強(qiáng)調(diào)配置中心，是出于什么樣的訴求需要我們專門設(shè)計(jì)一個(gè)配置中心？厘清了這些問題，我們就知道如何去設(shè)計(jì)配置中心，并獲得一個(gè)比較好的用戶體驗(yàn)，和一個(gè)生產(chǎn)可用的結(jié)果。”

微服務(wù)給配置管理所帶來的變化

在單機(jī)的情況下，我們把配置放在代碼里邊，發(fā)布的時(shí)候直接重啟，非常輕量，但在微服務(wù)的情況下，出現(xiàn)了兩個(gè)新的場(chǎng)景：

第一個(gè)是出現(xiàn)了多臺(tái)設(shè)備，之前改一臺(tái)設(shè)備就 OK 了，但是現(xiàn)在需要改多個(gè)設(shè)備，業(yè)務(wù)量大的時(shí)候，可能要改幾十甚至幾百臺(tái)設(shè)備。顯然，通過手動(dòng)來完成這些設(shè)備的配置是不切實(shí)際的。所以說微服務(wù)之后，產(chǎn)生了一個(gè)新的難題，設(shè)備的配置變更管理難了。

第二個(gè)是微服務(wù)之后，出現(xiàn)了路由規(guī)則。并且，服務(wù)A找服務(wù)B的過程中，路由規(guī)則、重試策略和熔斷機(jī)制，都是動(dòng)態(tài)變化的。例如，我們發(fā)現(xiàn)下游依賴的一個(gè)服務(wù)不可用了，需要把它降級(jí)，這樣對(duì)整個(gè)業(yè)務(wù)的資損影響才是最小的。通過更改一個(gè)配置，就可以實(shí)時(shí)地推到業(yè)務(wù)的進(jìn)程里邊，讓它立馬生效，進(jìn)行降級(jí)。這就是我們微服務(wù)架構(gòu)下要做配置中心的另一大原因。

配置管理演進(jìn)過程中的設(shè)計(jì)思考

面對(duì)微服務(wù)架構(gòu)下對(duì)配置中心的新訴求，我們?cè)撊绾稳M足呢？

我們的解法就是針對(duì)分散的管理模式，設(shè)計(jì)一個(gè)集中的管控平臺(tái)，即配置中心。當(dāng)有配置變更的時(shí)候，就可以在配置中心上來實(shí)現(xiàn)。配置管理的策略就是集中管控和動(dòng)態(tài)推送，以解決分散的問題。其中，動(dòng)態(tài)推送是微服務(wù)里邊配置管理的核心，改一個(gè)配置時(shí)，確保每臺(tái)機(jī)器可以收到配置更新，并實(shí)時(shí)生效。

除此之外，我們還做了一個(gè)發(fā)布管控。就是在變更之前，找線上的一臺(tái)機(jī)器，先把變更發(fā)布下去，如果沒有問題再去全網(wǎng)推。同時(shí)，對(duì)于已發(fā)布的配置變更可以一鍵逆操作，就是相當(dāng)于給了一次吃后悔藥的機(jī)會(huì)，因?yàn)楹芸赡埽覀兺棋e(cuò)的時(shí)候，忘了更改前的參數(shù)，那么可以通過一鍵逆操作來縮短恢復(fù)時(shí)間，在機(jī)制上降低了配置管理的風(fēng)險(xiǎn)。

隨后，在我們做配置中心的云化產(chǎn)品的過程中，也就是從服務(wù)集團(tuán)內(nèi)部客戶走向服務(wù)外部企業(yè)用戶的時(shí)候，我們遇到了新的挑戰(zhàn)。

服務(wù)集團(tuán)內(nèi)部用戶的時(shí)候，我們會(huì)搭幾套物理集群。但是產(chǎn)品云化后，為每一個(gè)云計(jì)算的用戶去搭一個(gè)環(huán)境，成本就太高了。于是我們?cè)O(shè)計(jì)了一套集群去支撐云上的用戶，及其多個(gè)使用環(huán)境，例如日常測(cè)試環(huán)境、預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境。

其次，為了進(jìn)一步降低用戶的使用成本，我們提供了一個(gè)邏輯隔離的能力。這和 K8S 的體系是一樣的，就是在整個(gè)配置體系下面，新增一個(gè)命名空間或是租戶。在啟動(dòng)的過程中動(dòng)態(tài)傳一些參數(shù)進(jìn)去，然后把所有的配置隔離在不同的命名空間之下，這樣大家就相互不影響了。我們看到的都是一個(gè)key ，但實(shí)際上是在前面動(dòng)態(tài)的添加了一個(gè)邏輯參數(shù)，即命名空間。

此外，在某一個(gè)環(huán)境里邊，如果某個(gè)用戶或者一個(gè)環(huán)境里邊的一個(gè)租戶變更配置很頻繁，或者是把權(quán)限搞錯(cuò)了，這個(gè)影響會(huì)是全局的。之前，我們的一個(gè)專有云用戶遇到了一個(gè)問題，就是寫了大量的配置變更數(shù)據(jù)，幾百萬條，最后把數(shù)據(jù)庫(kù)寫爆了。因此，為了避免因?yàn)槟硞€(gè)租戶更改配置影響到全局的事情發(fā)生，我們?cè)O(shè)計(jì)了流量管控和容量管控。即一個(gè)用戶默認(rèn)最多創(chuàng)建100條或者200條數(shù)據(jù)，上限由管理員來設(shè)置。進(jìn)一步的，我們把這個(gè)管控封裝成一個(gè)接口作為云產(chǎn)品的一個(gè)特性。

以上就是整個(gè)配置中心設(shè)計(jì)的演進(jìn)過程，伴隨著我們對(duì)配置中心的理解和用戶的需求而來，從配置管理到集中管控，到配置發(fā)布前的自動(dòng)校驗(yàn)，到發(fā)布管控，再到流量和容量管控。

配置管理演進(jìn)過程中的設(shè)計(jì)思考

當(dāng)我們對(duì)配置中心進(jìn)行開源（開源項(xiàng)目名稱：Nacos）的時(shí)候，有了新的思考。

項(xiàng)目開源初期，在宣講的時(shí)候我們會(huì)強(qiáng)調(diào)Nacos的性能，例如經(jīng)受了雙11的流量考驗(yàn)，支持每天上億次的配置推送，但在開源過程中和一些開發(fā)者溝通下來，大家其實(shí)并不會(huì)太考慮開源產(chǎn)品的性能，因?yàn)榇蟛糠珠_發(fā)者所處的企業(yè)，其流量規(guī)模根本沒有那么大，大家更關(guān)心的是產(chǎn)品的易用性，開發(fā)者用爽了，才會(huì)談性能的問題、安全的問題和容量的問題。

所以，我們?cè)谥蟮漠a(chǎn)品設(shè)計(jì)策略上做了些調(diào)整。就是只要用戶能看的到地方，就會(huì)用心去設(shè)計(jì)，等滿足了簡(jiǎn)單易用，滿足了中小企業(yè)對(duì)配置中心的需求后，再去強(qiáng)調(diào)Nacos的性能。

簡(jiǎn)單易用分為兩個(gè)維度，一個(gè)是各類基礎(chǔ)設(shè)計(jì)，包括模型和接口等，另一個(gè)是控制臺(tái)的使用體驗(yàn)設(shè)計(jì)。

先看下我們?cè)诮涌谠O(shè)計(jì)方面的模型。

這張圖展示的是一個(gè)最簡(jiǎn)單的配置模型，一個(gè)配置文件里邊填 value 。按大家最正常的理解來說，一個(gè)DataId ，一個(gè) Content （一個(gè)key和一個(gè) value 就可以了），為什么還出現(xiàn)了Namespace、 Group這些設(shè)置呢。原因是，做了微服務(wù)之后，大家的配置集中管控了。集中管控遇到的第一個(gè)問題就是，當(dāng)多個(gè)應(yīng)用去做拆分的時(shí)候，會(huì)有一個(gè)隔離的需求。

比如一個(gè)應(yīng)用 A 的開發(fā)，和一個(gè)應(yīng)用 B的開發(fā)，希望他們兩個(gè)的配置是相互隔離的，通過各自的應(yīng)用，能很快的實(shí)現(xiàn)相應(yīng)的配置變更。所以我們?cè)谝粋€(gè) key-value 的基礎(chǔ)上又加了一個(gè) Group ，這個(gè)Group 就是一個(gè)邏輯分組的概念，一般我們推薦填寫它的應(yīng)用名稱或者模塊名稱，便于大家把不同應(yīng)用的配置分開，也方便后邊進(jìn)行權(quán)限管控。

那Namespace是干嘛的呢？如果是一家規(guī)模較小的企業(yè)，可能連測(cè)試環(huán)境也沒有，這時(shí)候Namespace是沒有任何意義的，我默認(rèn)是你隱藏的，它是一個(gè)空串。如果說你是一家中型的或者更大一點(diǎn)的公司，有很多環(huán)境，測(cè)試、預(yù)發(fā)和生產(chǎn)等多個(gè)環(huán)境，線上還有一些梯度環(huán)境，這時(shí)候我們就可以通過一個(gè) Namespace ，讓你連到不同的環(huán)境上了，就是進(jìn)入不同的邏輯區(qū)域。Namespace 是用在環(huán)境上的， Group 是應(yīng)用，DataId 里邊就是一個(gè) key-value 。

這樣一看，模型就很簡(jiǎn)單了。

第二個(gè)是在通信協(xié)議的選型上，有 gRPC ，HTTP和rsocket等，最終選擇了HTTP。因?yàn)槲覀冋J(rèn)為配置管理是一個(gè)非常通用的需求，不僅 Java 需要，包括淘系的 C語言、Note.JS 都有同樣的需求，比如 Note.JS ，前端的一些動(dòng)態(tài)文案，需要?jiǎng)討B(tài)去更改。所以出于對(duì)多語言的兼容，我們選擇了HTTP接口 。

第三個(gè)是SDK設(shè)計(jì)上的優(yōu)化，對(duì)Java 而言，用戶關(guān)心的是體驗(yàn)，例如Spring 的用戶最關(guān)心的是本地開發(fā)的體驗(yàn)。我在剛才那個(gè) property 文件里邊寫一個(gè)東西，通過 @value 注冊(cè)進(jìn)來，它拉的是本地的一個(gè)配置，解決了本地配置的一個(gè)易用性問題。即如果配置中心里邊有，從配置中心里邊選可配置的 key ，沒有的話就用本地的，我們就是通過SDK無縫地去解決了這個(gè)問題。

以上是我們?cè)诨A(chǔ)設(shè)計(jì)做的一些設(shè)計(jì)和思考，接下來我們分享下在控制臺(tái)體驗(yàn)上的設(shè)計(jì)。

配置中心控制臺(tái)設(shè)計(jì)實(shí)踐

• 交互界面的顏色選定

我們把選擇權(quán)交給了社區(qū)，通過設(shè)置一個(gè)issue話題和投票，我們最終采用了經(jīng)典黑+藍(lán)色點(diǎn)綴的方案。

• 控制臺(tái)的使用體驗(yàn)

我們?cè)鰪?qiáng)了控制臺(tái)的易用性，比如提供 Properties 或者 JSON 格式校驗(yàn)的方法來避免，增刪改查過程中可能會(huì)出現(xiàn)的一些人為錯(cuò)誤。

此外，在一個(gè)分布式系統(tǒng)中，我們是需要協(xié)作的。創(chuàng)建完配置，需要讓大家知道創(chuàng)建者為何要?jiǎng)?chuàng)建這個(gè)配置，目的是什么。為了解決這個(gè)問題，我們給配置打了一些元信息。

舉個(gè)例子，在阿里巴巴，我們把變更風(fēng)險(xiǎn)分為四級(jí)， P1, P2, P3和 P4，P1 是風(fēng)險(xiǎn)最高的。今天的這個(gè)demo基本沒有風(fēng)險(xiǎn)，我就寫個(gè)P4 。這個(gè)標(biāo)簽就是用來說明這個(gè)變更風(fēng)險(xiǎn)不大。但如果是 P1 或者P2 的配置，我就會(huì)去做一個(gè)管控，一旦有修改是需要?jiǎng)?chuàng)建者來審評(píng)的，以降低變更風(fēng)險(xiǎn)。

• 性能體驗(yàn)

在歷經(jīng)了阿里N代程序員的開發(fā)，配置變更最終才沉淀出性能強(qiáng)、容量大和高可用體系完美結(jié)合的產(chǎn)品。當(dāng)時(shí)，我們中間件最大的 leader 給我們提一個(gè)訴求，“快遞三日達(dá)，配置推送一秒達(dá)”，就是一變更，一秒就能將配置變更推送到幾十萬臺(tái)機(jī)器，這就是我們當(dāng)時(shí)產(chǎn)品主要的迭代方向之一。那為什么，我們對(duì)配置變更的性能要求如此之高呢？

舉個(gè)例子，上圖左邊的是機(jī)房a，右邊的是機(jī)房b，其中user 1 和 user 2 是不同的用戶 ID ，當(dāng)尾號(hào)為0 的用戶訪問Region1，當(dāng)尾號(hào)為 1 的用戶訪問Region2。但是突然我發(fā)現(xiàn)線上不知道誰做了變更，沒查到原因，發(fā)生 Region2尾號(hào)為 1的所有用戶訪問全出現(xiàn)異常了。那是不是我要改變路由規(guī)則，讓所有的用戶，不管ID尾號(hào)是 0是 1 都去訪問Region1 。要實(shí)現(xiàn)這個(gè)，就需要通過通過配置變更來實(shí)現(xiàn)。且實(shí)現(xiàn)的越快，對(duì)用戶的感知影響就越小。這是Nacos在異地多活的動(dòng)態(tài)路由的典型應(yīng)用場(chǎng)景。

以上就是我分享的關(guān)于配置中心演進(jìn)、演進(jìn)過程中的思考以及我們?cè)诜?wù)集團(tuán)內(nèi)部用戶，上云后服務(wù)企業(yè)用戶和開源后服務(wù)開發(fā)者的一些思考和探索。