從內部自用到對外服務，配置管理的演進和設計優化實踐

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

• 微服務給配置管理所帶來的變化
• 配置管理演進過程當中的設計思考
• 配置管理開源後的新探索
• 配置中心控制檯設計實踐

「爲何相對於傳統的軟件開發模式，微服務要強調配置中心，是出於什麼樣的訴求須要咱們專門設計一個配置中心？釐清了這些問題，咱們就知道如何去設計配置中心，並得到一個比較好的用戶體驗，和一個生產可用的結果。」

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

在單機的狀況下，咱們把配置放在代碼裏邊，發佈的時候直接重啓，很是輕量，但在微服務的狀況下，出現了兩個新的場景：

第一個是出現了多臺設備，以前改一臺設備就 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在異地多活的動態路由的典型應用場景。

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

原文連接