本文整理自阿里巴巴中介軟體技術專家彥林在中國開源年會上的分享，通過此文，您將瞭解到：
- 微服務給配置管理所帶來的變化
- 配置管理演進過程中的設計思考
- 配置管理開源後的新探索
- 配置中心控制檯設計實踐
“為什麼相對於傳統的軟體開發模式，微服務要強調配置中心，是出於什麼樣的訴求需要我們專門設計一個配置中心？釐清了這些問題，我們就知道如何去設計配置中心，並獲得一個比較好的使用者體驗，和一個生產可用的結果。”
微服務給配置管理所帶來的變化
在單機的情況下，我們把配置放在程式碼裡邊，釋出的時候直接重啟，非常輕量，但在微服務的情況下，出現了兩個新的場景：
第一個是出現了多臺裝置，之前改一臺裝置就 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在異地多活的動態路由的典型應用場景。
以上就是我分享的關於配置中心演進、演進過程中的思考以及我們在服務集團內部使用者，上雲後服務企業使用者和開源後服務開發者的一些思考和探索。
