隨著業(yè)務的發(fā)展，應用系統中的配置會越來越多，配置之間也有不同的業(yè)務特點，比如業(yè)務依賴的數據庫配置、緩存信息配置、索引存儲配置等。這類配置一般比較穩(wěn)定，不會頻繁更改，通常會放在工程中作為配置文件隨應用一起發(fā)布。

除了這些配置，還有一部分配置會經常發(fā)生修改，比如限流降級開關配置、業(yè)務中的白名單配置等。這些配置項除了變更頻繁，還要求實時性，如果采取和應用一起發(fā)布的方式，那么每次變更都要重新發(fā)布服務，非常不方便。

為了解決這類配置問題，出現了分布式配置管理平臺，這一課時我們就來了解一下分布式配置管理相關的內容。

一、配置管理的應用場景

在項目開發(fā)中，數據庫信息等配置管理，一般是隨著工程一起上線的，比如 Java 的 Web 系統，習慣把數據庫的配置信息放到 jdbc.properties 這個配置文件中。

在分布式場景下，配置管理的應用范圍更加廣泛。比如上面說的限流和降級配置，電商網站在舉行大型促銷活動時，由于訪問人數暴增，為了保證核心交易鏈路的穩(wěn)定性，會把一些不太重要的業(yè)務做降級處理，那么如何關閉非核心服務呢？就需要分布式配置管理系統，能夠實時管理被降級的業(yè)務，保證系統安全。

在一些異步業(yè)務場景中，配置管理也廣泛應用，比如工作中經常會有數據同步，需要控制同步的速度；在一些定時任務中，需要控制定時任務觸發(fā)的時機，以及執(zhí)行的時長等，這些都可以通過配置管理來實現。

二、配置管理如何實現

分布式配置管理的本質就是一種推送-訂閱模式的運用。配置的應用方是訂閱者，配置管理服務則是推送方，客戶端發(fā)布數據到配置中心，配置中心把配置數據推送到訂閱者。

配置管理服務往往會封裝一個客戶端，應用方則是基于該客戶端與配置管理服務進行交互。在實際實現時，客戶端可以主動拉取數據，也可以基于事件通知實現。

實現配置管理中心，一般需要下面幾個步驟:

• 提取配置信息，放到一個公共的地方存儲，比如文件系統、數據庫、Redis；
• 使用發(fā)布/訂閱模式，讓子系統訂閱這些配置信息；
• 對外開放可視化的配置管理中心，對配置信息進行操作維護。

三、分布式配置管理的特性要求

一個合格的分布式配置管理系統，除了配置發(fā)布和推送，還需要滿足以下的特性:

• 高可用性，服務器集群應該無單點故障，只要集群中還有存活的節(jié)點，就能提供服務；
• 容錯性，保證在配置平臺不可用時，也不影響客戶端的正常運行；
• 高性能，對于配置平臺，應該是盡可能低的性能開銷，不能因為獲取配置給應用帶來不可接受的性能損耗；
• 可靠存儲，包括數據的備份容災，一致性等，盡可能保證不丟失配置數據；
• 實時生效，對于配置的變更，客戶端應用能夠及時感知。
  可以看到，一個好的配置管理系統，不只是提供配置發(fā)布和推送就可以，還有許多高級特性的要求。

四、分布式配置中心選型

分布式配置管理系統可以選擇自研，也可以選擇開源組件，比如攜程開源的 Apollo、淘寶的 Diamond、百度的 Disconf 等。

1、Diamond

淘寶的 Diamond 是國內比較早的配置管理組件，設計簡單，配置信息會持久化到 MySQL 數據庫和本地磁盤中，通過數據庫加本地文件的方式來進行容災。

客戶端和服務端通過 Http 請求來交互，通過比較數據的 MD5 值感知數據變化。在運行中，客戶端會定時檢查配置是否發(fā)生變化，每次檢查時，客戶端將 MD5 傳給服務端，服務端會比較傳來的 MD5 和自身內存中的 MD5 是否相同。如果相同，則說明數據沒變，返回一個標示數據不變的字符串給客戶端；如果不同，則說明數據發(fā)生變更，返回變化數據的相關信息給客戶端，客戶端會重新請求更新后的配置文件。

Diamond 開源版本已經很久沒有更新了，比較適合小型的業(yè)務系統的配置管理，源碼規(guī)模也比較小，可以下載對應的源碼來查看，下載地址為：github-diamond。

2、Disconf

Disconf 是百度的一款分布式配置管理平臺，代碼倉庫地址為：knightliao-disconf。

Disconf 的實現是基于 ZooKeeper 的，應用安裝需要依賴 ZooKeeper 環(huán)境，配置動態(tài)更新借助 ZooKeeper 的 watch 機制實現。在初始化流程會中會對配置文件注冊 watch，這樣當配置文件更新時，ZooKeeper 會通知到客戶端，然后客戶端再從 Disconf 服務端中獲取最新的配置并更新到本地，這樣就完成了配置動態(tài)更新。

關于 Disconf 的細節(jié)，可以查看作者提供的設計文檔：https://disconf.readthedocs.io/zh_CN/latest/design/index.html。

3、Apollo

Apollo 是攜程開源的分布式配置中心，官方的描述是：Apollo 能夠集中化管理應用不同環(huán)境、不同集群的配置。配置修改后能夠實時推送到應用端，并且具備規(guī)范的權限、流程治理等特性，適用于微服務配置管理場景。

Apollo 服務端基于 Spring Boot 和 Spring Cloud 開發(fā)，打包后可以直接運行，不需要額外安裝 Tomcat 等應用容器。Apollo 支持多種語言的客戶端，包括 Java 和 .Net 客戶端，客戶端運行不需要依賴其他框架，對系統侵入較小。

相比 Diamond 和 Disconf，Apollo 一直保持著穩(wěn)定的版本更新，開源社區(qū)也比較活躍，管理界面友好，適合大型的業(yè)務系統，比較推薦使用?？梢栽?Apollo的代碼倉庫 ctripcorp-apollo 中了解更多的信息。

除了以上幾款組件，大家熟悉的 ZooKeeper 也經常被用作分布式配置管理，和 Disconf 的實現類似，是依賴 ZooKeeper 的發(fā)布訂閱功能，基于 watch 機制實現。

內容中介紹的配置管理選型都是單獨提供配置管理功能的，其實在大部分業(yè)務系統中，配置管理都不是一個單獨的功能，一般是和服務治理，或者網關集成在一起。比如 Spring Cloud Nacos，除了支持服務發(fā)現，還提供了配置管理的功能，Dubbo 的控制臺 Dubbo Admin 也內置了服務配置推送的功能。

總結

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論