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

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

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

配置管理的應用場景

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

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

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

配置管理如何實現(xiàn)

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

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

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

• 提取配置信息，放到一個公共的地方存儲，比如文件系統(tǒng)、數(shù)據(jù)庫、Redis；

• 使用發(fā)布/訂閱模式，讓子系統(tǒng)訂閱這些配置信息；

• 對外開放可視化的配置管理中心，對配置信息進行操作維護。

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

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

• 高可用性，服務器集群應該無單點故障，只要集群中還有存活的節(jié)點，就能提供服務；

• 容錯性，保證在配置平臺不可用時，也不影響客戶端的正常運行；

• 高性能，對于配置平臺，應該是盡可能低的性能開銷，不能因為獲取配置給應用帶來不可接受的性能損耗；

• 可靠存儲，包括數(shù)據(jù)的備份容災，一致性等，盡可能保證不丟失配置數(shù)據(jù)；

• 實時生效，對于配置的變更，客戶端應用能夠及時感知。

可以看到，一個好的配置管理系統(tǒng)，不只是提供配置發(fā)布和推送就可以，還有許多高級特性的要求。

分布式配置中心選型

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

Diamond

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

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

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

Disconf

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

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

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

Apollo

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

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

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

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

總結

這一課時分享了分布式配置管理的應用，實現(xiàn)分布式配置管理應該考慮的一些問題，以及常用分布式配置管理的選型。

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