摘要：本文講述業務配置中心（下文簡述為配置中心）的關鍵技術和實現方式。
本文分享自華為雲社群《手把手教你物聯網平臺如何實現業務配置中心》，作者： 華為雲IoT專家團 。
上一篇《華為雲物聯網高階攻城獅的4年配置中心實踐分享》文章中分享了業務配置中心。
本文講述業務配置中心（下文簡述為配置中心）的關鍵技術和實現方式。華為雲物聯網平臺按照本文的實現方式實現了一個業務配置中心，該配置中心2020年1月上線，平穩執行至今。
1 概念
1.1 運維配置
和使用者無關，通常為叢集界級別的配置，程式只會進行讀取，如資料庫配置、郵箱伺服器配置、網路卡配置、子網地址配置等。
1.2 業務配置
作為SaaS 服務，每個使用者在上面都有一些業務配置。如使用者的證書配置、使用者伺服器的流控配置等，這些業務配置相對運維配置來說更加複雜，且可能會有唯一性限制，如按使用者 id 唯一。這部分配置資料一般由使用者操作觸發，程式碼動態寫入，並且通知到各個微服務例項。通常，我們希望這些配置能在介面展示，且支援人為修改。上述邏輯如果由各微服務自己實現，會存在大量重複程式碼，並且質量無法保證。我們希望由一個公共元件來統一實現這個能力。開源或體量較小的專案就不會選擇依賴一個配置中心，而是直接通過連線資料庫或etcd來解決問題。
1.3 env
代表一個部署環境。
1.4 cluster
代表環境下的叢集。常見於單環境下藍綠髮布，藍叢集、綠叢集、金絲雀叢集等。
1.5 配置
配置名稱，如使用者證書配置、使用者流控配置等。
1.6 Key
配置的唯一鍵，如使用者id。
1.7 Value
配置唯一鍵對應的值。
2 配置中心設計梗概
2.1 業務配置特點
- 雖然業務配置寫入可能存在併發，但併發量不大，頻率較低。
- 業務配置常常以使用者為id，單叢集使用者量有限，一般不超過5萬。
2.2 配置中心要解決的問題
2.3 設計要點
- 單配置要求有配置id，每個id上通過version的樂觀併發控制來解決多版本衝突問題
- 通知不追求可靠，應用程式和配置中心斷鏈無法接收通知的場景下，通過定期同步資料來保證資料的可靠
- 支援Schema的變更，因Schema變更不頻繁，也採用version的樂觀併發控制來解決多版本衝突問題
2.4 通知是否包含訊息內容
我認為應該只通知Key，具體的數值讓應用程式再去配置中心查詢。僅通知Key實現簡潔易懂。同時通知Key&Value需要多考慮定期同步和通知兩條通道併發，可能引起的競態衝突。
3 配置中心業務流程
本小節描述業務配置中心的所有業務流程，並試圖從互動中抽象出與具體實現無關的介面
3.1配置的增刪改查
3.2 配置值的增刪改查
3.3 定期同步
分散式場景下，通知有可能無法送達，如程式陷入網路中斷（或長gc），通知訊息送達超時，待程式恢復後，資料不再準確。因此需要對資料做定期同步，提高可靠性。
同步過程中，僅僅請求互動id和version，避免傳輸大量資料。應用程式接收到需要同步的資料後：
- 刪除操作，觸發刪除通知，從本地快取中移除資料。
- 新增、修改操作，向配置中心查詢最新資料，觸發通知並寫入本地快取。
3.4 服務啟動
服務啟動也可看做是一個同步的流程，只是需要同步大量的資料新增。為了避免向配置中心頻繁大量的請求，引入批量操作來減輕壓力
3.5 限制
該配置中心設計思路依賴客戶端可把資料全量放入到記憶體中，如使用者量太大，則不適合採用這種模式。
注：一個節省記憶體的思路是，記憶體中只放置全量的id和version，資料只有當用到的時候再去查詢。這個思路要求配置中心持久化一些老舊資料以供以下場景的查詢使用
- 業務流程中，需要使用該配置值的。
- 回撥業務程式修改的時候，需要提供舊值的。
除此之外沒有任何區別。
4 業務配置抽象實現
從上述描述的業務場景，我們抽象出業務配置中心的互動介面和抽象實現。介面的Swagger Yaml已上傳到Github：https://github.com/Shoothzj/config-center/tree/master/swagger
4.1配置相關介面
- 提供env、cluster、配置名稱、配置Schema、配置版本號新增配置
- 提供env、cluster、配置名稱刪除配置
- 提供env、cluster、配置名稱、新Schema、新Version來修改配置
- 提供env、cluster、配置名稱來查詢配置
4.2 配置值相關介面
- 提供env、cluster、配置名稱、Key、Value來新增配置值
- 提供env、cluster、Key、ValueVersion（可選）來刪除配置值
- 提供env、cluster、Key、Value、ValueVersion（可選）修改配置值
- 提供env、cluster、Key查詢配置值
- 根據env、cluster、應用程式當前的配置資料來做定期同步
- 根據Key列表批量查詢配置值
4.3 通知相關介面
- 通知某env某cluster下，配置項中的一個Key發生變化，新增、修改或是刪除。可選方式有HTTP長連結（Inspired by Apollo）、Mqtt、WebSocket等。
4.4 配置中心儲存層抽象實現
配置中心儲存層需要儲存配置和配置值資料，支援UpdateByVersion，且需要捕捉資料的變化，用來通知到應用程式
4.5 服務發現抽象實現
為了使應用程式連線到配置中心，需要一個發現機制可以讓應用程式感知到配置中心的地址。高可用的方式很多，如K8s發現、ZooKeeper、Etcd、ServiceComb、業務環境變數注入ELB地址（ELB後端掛載配置中心的地址）等。
4.6 抽象總結
根據這個抽象，我們可以進行關鍵技術點選型，來實現業務配置中心。
5 配置中心實現
5.1 華為雲物聯網配置中心實現
- env+cluster+config組成資料表的名稱
- 一個key、value對應一行資料
5.2 另一種實現方式
只要實現上述介面和抽象能力，都可以實現業務配置中心，也可以這麼實現
- env+cluster+config+key 組合成etcd的key
- 一個key、value對應一個鍵值對
5.3 又一種實現方式
當然也可以
- env+cluster+config+key 組合成RocksDB的key
- 一個key、value對應一個鍵值對