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

• 微服務給配置管理所帶來的變化

• 配置管理演進過程中的設計思考

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

• 配置中心控制臺設計實踐

“為什么相對于傳統的軟件開發模式，微服務要強調配置中心，是出于什么樣的訴求需要我們專門設計一個配置中心？厘清了這些問題，我們就知道如何去設計配置中心，并獲得一個比較好的用戶體驗，和一個生產可用的結果。”

微服務給配置管理所帶來的變化

在單機的情況下，我們把配置放在代碼里邊，發布的時候直接重啟，非常輕量，但在微服務的情況下，出現了兩個新的場景：

第一個是出現了多臺設備，之前改一臺設備就 OK 了，但是現在需要改多個設備，業務量大的時候，可能要改幾十甚至幾百臺設備。顯然，通過手動來完成這些設備的配置是不切實際的。所以說微服務之后，產生了一個新的難題，設備的配置變更管理難了。

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

配置管理演進過程中的設計思考

面對微服務架構下對配置中心的新訴求，我們該如何去滿足呢？

我們的解法就是針對分散的管理模式，設計一個集中的管控平臺，即配置中心。當有配置變更的時候，就可以在配置中心上來實現。配置管理的策略就是集中管控和動態推送，以解決分散的問題。其中，動態推送是微服務里邊配置管理的核心，改一個配置時，確保每臺機器可以收到配置更新，并實時生效。

除此之外，我們還做了一個發布管控。就是在變更之前，找線上的一臺機器，先把變更發布下去，如果沒有問題再去全網推。同時，對于已發布的配置變更可以一鍵逆操作，就是相當于給了一次吃后悔藥的機會，因為很可能，我們推錯的時候，忘了更改前的參數，那么可以通過一鍵逆操作來縮短恢復時間，在機制上降低了配置管理的風險。

隨后，在我們做配置中心的云化產品的過程中，也就是從服務集團內部客戶走向服務外部企業用戶的時候，我們遇到了新的挑戰。

服務集團內部用戶的時候，我們會搭幾套物理集群。但是產品云化后，為每一個云計算的用戶去搭一個環境，成本就太高了。于是我們設計了一套集群去支撐云上的用戶，及其多個使用環境，例如日常測試環境、預發環境和生產環境。

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

此外，在某一個環境里邊，如果某個用戶或者一個環境里邊的一個租戶變更配置很頻繁，或者是把權限搞錯了，這個影響會是全局的。之前，我們的一個專有云用戶遇到了一個問題，就是寫了大量的配置變更數據，幾百萬條，最后把數據庫寫爆了。因此，為了避免因為某個租戶更改配置影響到全局的事情發生，我們設計了流量管控和容量管控。即一個用戶默認最多創建100條或者200條數據，上限由管理員來設置。進一步的，我們把這個管控封裝成一個接口作為云產品的一個特性。

以上就是整個配置中心設計的演進過程，伴隨著我們對配置中心的理解和用戶的需求而來，從配置管理到集中管控，到配置發布前的自動校驗，到發布管控，再到流量和容量管控。

配置管理演進過程中的設計思考

當我們對配置中心進行開源（開源項目名稱：Nacos）的時候，有了新的思考。

項目開源初期，在宣講的時候我們會強調Nacos的性能，例如經受了雙11的流量考驗，支持每天上億次的配置推送，但在開源過程中和一些開發者溝通下來，大家其實并不會太考慮開源產品的性能，因為大部分開發者所處的企業，其流量規模根本沒有那么大，大家更關心的是產品的易用性，開發者用爽了，才會談性能的問題、安全的問題和容量的問題。

所以，我們在之后的產品設計策略上做了些調整。就是只要用戶能看的到地方，就會用心去設計，等滿足了簡單易用，滿足了中小企業對配置中心的需求后，再去強調Nacos的性能。

簡單易用分為兩個維度，一個是各類基礎設計，包括模型和接口等，另一個是控制臺的使用體驗設計。

先看下我們在接口設計方面的模型。

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

比如一個應用 A 的開發，和一個應用 B的開發，希望他們兩個的配置是相互隔離的，通過各自的應用，能很快的實現相應的配置變更。所以我們在一個 key-value 的基礎上又加了一個 Group ，這個Group 就是一個邏輯分組的概念，一般我們推薦填寫它的應用名稱或者模塊名稱，便于大家把不同應用的配置分開，也方便后邊進行權限管控。

那Namespace是干嘛的呢？如果是一家規模較小的企業，可能連測試環境也沒有，這時候Namespace是沒有任何意義的，我默認是你隱藏的，它是一個空串。如果說你是一家中型的或者更大一點的公司，有很多環境，測試、預發和生產等多個環境，線上還有一些梯度環境，這時候我們就可以通過一個 Namespace ，讓你連到不同的環境上了，就是進入不同的邏輯區域。Namespace 是用在環境上的， Group 是應用，DataId 里邊就是一個 key-value 。

這樣一看，模型就很簡單了。

第二個是在通信協議的選型上，有 gRPC ，HTTP和rsocket等，最終選擇了HTTP。因為我們認為配置管理是一個非常通用的需求，不僅 Java 需要，包括淘系的 C語言、Note.JS 都有同樣的需求，比如 Note.JS ，前端的一些動態文案，需要動態去更改。所以出于對多語言的兼容，我們選擇了HTTP接口 。

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

以上是我們在基礎設計做的一些設計和思考，接下來我們分享下在控制臺體驗上的設計。

配置中心控制臺設計實踐

• 交互界面的顏色選定

我們把選擇權交給了社區，通過設置一個issue話題和投票，我們最終采用了經典黑+藍色點綴的方案。

• 控制臺的使用體驗

我們增強了控制臺的易用性，比如提供 Properties 或者 JSON 格式校驗的方法來避免，增刪改查過程中可能會出現的一些人為錯誤。

此外，在一個分布式系統中，我們是需要協作的。創建完配置，需要讓大家知道創建者為何要創建這個配置，目的是什么。為了解決這個問題，我們給配置打了一些元信息。

舉個例子，在阿里巴巴，我們把變更風險分為四級， P1, P2, P3和 P4，P1 是風險最高的。今天的這個demo基本沒有風險，我就寫個P4 。這個標簽就是用來說明這個變更風險不大。但如果是 P1 或者P2 的配置，我就會去做一個管控，一旦有修改是需要創建者來審評的，以降低變更風險。

• 性能體驗

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

舉個例子，上圖左邊的是機房a，右邊的是機房b，其中user 1 和 user 2 是不同的用戶 ID ，當尾號為0 的用戶訪問Region1，當尾號為 1 的用戶訪問Region2。但是突然我發現線上不知道誰做了變更，沒查到原因，發生 Region2尾號為 1的所有用戶訪問全出現異常了。那是不是我要改變路由規則，讓所有的用戶，不管ID尾號是 0是 1 都去訪問Region1 。要實現這個，就需要通過通過配置變更來實現。且實現的越快，對用戶的感知影響就越小。這是Nacos在異地多活的動態路由的典型應用場景。

以上就是我分享的關于配置中心演進、演進過程中的思考以及我們在服務集團內部用戶，上云后服務企業用戶和開源后服務開發者的一些思考和探索。