技術(shù)背景

在一個分布式環(huán)境中，同類型的服務(wù)往往會部署很多實例。這些實例使用了一些配置，為了更好地維護(hù)這些配置就產(chǎn)生了配置管理服務(wù)。通過這個服務(wù)可以輕松地管理成千上百個服務(wù)實例的配置問題。

王阿晶提出了基于zooKeeper的配置信息存儲方案的設(shè)計與實現(xiàn)[1], 它將所有配置存儲在zookeeper上，這會導(dǎo)致配置的管理不那么方便，而且他們沒有相關(guān)的源碼實現(xiàn)。淘寶的diamond[2]是淘寶內(nèi)部使用的一個管理持久配置的系統(tǒng)，它具有完整的開源源碼實現(xiàn)，它的特點是簡單、可靠、易用，淘寶內(nèi)部絕大多數(shù)系統(tǒng)的配置都采用diamond來進(jìn)行統(tǒng)一管理。他將所有配置文件里的配置打散化進(jìn)行存儲，只支持KV結(jié)構(gòu)，并且配置更新的推送是非實時的。百度內(nèi)部的BJF配置中心服務(wù)[3]采用了類似淘寶diamond的實現(xiàn)，也是配置打散化、只支持KV和非實時推送。

同構(gòu)系統(tǒng)是市場的主流，特別地，在業(yè)界大量使用部署虛擬化（如JPAAS系統(tǒng)，SAE，BAE）的情況下，同一個系統(tǒng)使用同一個部署包的情景會越來越多。但是，異構(gòu)系統(tǒng)也有一定的存在意義，譬如，對于“拉模式”的多個下游實例，同一時間點只能只有一個下游實例在運(yùn)行。在這種情景下，就存在多臺實例機(jī)器有“主備機(jī)”模式的問題。目前國內(nèi)并沒有很明顯的解決方案來統(tǒng)一解決此問題。

功能特點與設(shè)計理念

disconf是一套完整的基于zookeeper的分布式配置統(tǒng)一解決方案。

功能特點

支持配置（配置項+配置文件）的分布式化管理

• 配置發(fā)布統(tǒng)一化
• 配置發(fā)布、更新統(tǒng)一化（云端存儲、發(fā)布）:配置存儲在云端系統(tǒng)，用戶統(tǒng)一在平臺上進(jìn)行發(fā)布、更新配置。
• 配置更新自動化：用戶在平臺更新配置，使用該配置的系統(tǒng)會自動發(fā)現(xiàn)該情況，并應(yīng)用新配置。特殊地，如果用戶為此配置定義了回調(diào)函數(shù)類，則此函數(shù)類會被自動調(diào)用。

配置異構(gòu)系統(tǒng)管理

• 異構(gòu)包部署統(tǒng)一化：這里的異構(gòu)系統(tǒng)是指一個系統(tǒng)部署多個實例時，由于配置不同，從而需要多個部署包（jar或war）的情況（下同）。使用Disconf后，異構(gòu)系統(tǒng)的部署只需要一個部署包，不同實例的配置會自動分配。特別地，在業(yè)界大量使用部署虛擬化（如JPAAS系統(tǒng)，SAE，BAE）的情況下，同一個系統(tǒng)使用同一個部署包的情景會越來越多，Disconf可以很自然地與他天然契合。 異構(gòu)主備自動切換：如果一個異構(gòu)系統(tǒng)存在主備機(jī)，主機(jī)發(fā)生掛機(jī)時，備機(jī)可以自動獲取主機(jī)配置從而變成主機(jī)。
• 異構(gòu)主備機(jī)Context共享工具：異構(gòu)系統(tǒng)下，主備機(jī)切換時可能需要共享Context?？梢允褂肅ontext共享工具來共享主備的Context。

注解式編程，極簡的使用方式：我們追求的是極簡的、用戶編程體驗良好的編程方式。通過簡單的標(biāo)注+極簡單的代碼撰寫，即可完成復(fù)雜的配置分布式化。

需要Spring編程環(huán)境

設(shè)計理念

簡單，用戶體驗良好：

• 摒棄了打散化配置的管理方式[2,3]，仍舊采用基于配置文件的編程方式，這和程序員以前的編程習(xí)慣（配置都是放在配置文件里）一致。特別的，為了支持較為小眾的打散化配置功能，還特別支持了配置項。
• 采用了基于XML無代碼侵入編程方式：只需要幾行XML配置，即可實現(xiàn)配置文件發(fā)布更新統(tǒng)一化、自動化。
• 采用了基于注解式的弱代碼侵入編程方式：通過編程規(guī)范，一個配置文件一個配置類，代碼結(jié)構(gòu)簡單易懂。XML幾乎沒有任何更改，與原springXML配置一樣。真正編程時，幾乎感覺不到配置已經(jīng)分布式化

可以托管任何類型的配置文件，這與[2,3]只能支持KV結(jié)構(gòu)的功能有較大的改進(jìn)。

配置更新實時推送

提供界面良好Web管理功能，可以非常方便的查看配置被哪些實例使用了。

詳細(xì)設(shè)計

架構(gòu)設(shè)計

disconf服務(wù)集群模式：

disconf的模塊架構(gòu)圖：

每個模塊的簡單介紹如下：

• Disconf-core
  • 分布式通知模塊：支持配置更新的實時化通知
  • 路徑管理模塊：統(tǒng)一管理內(nèi)部配置路徑URL
• Disconf-client
  • 配置倉庫容器模塊：統(tǒng)一管理用戶實例中本地配置文件和配置項的內(nèi)存數(shù)據(jù)存儲
  • 配置reload模塊：監(jiān)控本地配置文件的變動，并自動reload到指定bean
  • 掃描模塊：支持掃描所有disconf注解的類和域
  • 下載模塊：restful風(fēng)格的下載配置文件和配置項
  • watch模塊：監(jiān)控遠(yuǎn)程配置文件和配置項的變化
  • 主備分配模塊：主備競爭結(jié)束后，統(tǒng)一管理主備分配與主備監(jiān)控控制
  • 主備競爭模塊：支持分布式環(huán)境下的主備競爭
• Disconf-web
  • 配置存儲模塊：管理所有配置的存儲和讀取
  • 配置管理模塊：支持配置的上傳、下載、更新
  • 通知模塊：當(dāng)配置更新后，實時通知使用這些配置的所有實例
  • 配置自檢監(jiān)控模塊：自動定時校驗實例本地配置與中心配置是否一致
  • 權(quán)限控制：web的簡單權(quán)限控制
• Disconf-tools
  • context共享模塊：提供多實例間context的共享。

流程設(shè)計

運(yùn)行流程詳細(xì)介紹：

與2.0版本的主要區(qū)別是支持了：主備分配功能/主備切換事件。

• 啟動事件A：以下按順序發(fā)生。
  • A3：掃描靜態(tài)注解類數(shù)據(jù)，并注入到配置倉庫里。
  • A4+A2：根據(jù)倉庫里的配置文件、配置項，去 disconf-web 平臺里下載配置數(shù)據(jù)。這里會有主備競爭
  • A5：將下載得到的配置數(shù)據(jù)值注入到倉庫里。
  • A6：根據(jù)倉庫里的配置文件、配置項，去ZK上監(jiān)控結(jié)點。
  • A7+A2：根據(jù)XML配置定義，到 disconf-web 平臺里下載配置文件，放在倉庫里，并監(jiān)控ZK結(jié)點。這里會有主備競爭。
  • A8：A1-A6均是處理靜態(tài)類數(shù)據(jù)。A7是處理動態(tài)類數(shù)據(jù)，包括：實例化配置的回調(diào)函數(shù)類；將配置的值注入到配置實體里。
• 更新配置事件B：以下按順序發(fā)生。
  • B1：管理員在 Disconf-web 平臺上更新配置。
  • B2：Disconf-web 平臺發(fā)送配置更新消息給ZK指定的結(jié)點。
  • B3：ZK通知 Disconf-cient 模塊。
  • B4：與A4一樣。
  • B5：與A5一樣。
  • B6：基本與A4一樣，唯一的區(qū)別是，這里還會將配置的新值注入到配置實體里。
• 主備機(jī)切換事件C：以下按順序發(fā)生。
  • C1：發(fā)生主機(jī)掛機(jī)事件。
  • C2：ZK通知所有被影響到的備機(jī)。
  • C4：與A2一樣。
  • C5：與A4一樣。
  • C6：與A5一樣。
  • C7：與A6一樣。

模塊實現(xiàn)

disconf-web提供了前后端分離的web架構(gòu)，具體可見：https://github.com/knightliao/disconf/tree/master/disconf-web

本部分會重點介紹disconf-client的實現(xiàn)方式。

注解式disconf實現(xiàn)

本實現(xiàn)會涉及到 配置倉庫容器模塊、掃描模塊、下載模塊、watch模塊，

使用AOP攔截的一個好處是可以比較輕松的實現(xiàn)配置控制，比如并發(fā)環(huán)境下的配置統(tǒng)一生效。

特別地，本方式提供的編程模式非常簡單，例如使用以下配置類的程序在使用它時，可以直接@Autowired進(jìn)來進(jìn)行調(diào)用，使用它時就和平常使用普通的JavaBean一樣，但其實它已經(jīng)分布式化了。配置更新時，配置類亦會自動更新。

@Service
@DisconfFile(filename = "redis.properties")
public class JedisConfig {
    // 代表連接地址
    private String host;
    // 代表連接port
    private int port;
    /**
     * 地址, 分布式文件配置
     * 
     * @return
     */
    @DisconfFileItem(name = "redis.host", associateField = "host")
    public String getHost() {
        return host;
    }
    public void setHost(String host) {
        this.host = host;
    }
    /**
     * 端口, 分布式文件配置
     * 
     * @return
     */
    @DisconfFileItem(name = "redis.port", associateField = "port")
    public int getPort() {
        return port;
    }
    public void setPort(int port) {
        this.port = port;
    }
}

基于XML配置disconf實現(xiàn)

本實現(xiàn)提供了無任何代碼侵入方式的分布式配置。

ReloadablePropertiesFactoryBean繼承了Spring Properties文件的PropertiesFactoryBean類，管理所有當(dāng)配置更新時要進(jìn)行reload的配置文件。對于被管理的每一個配置文件，都會通過 配置倉庫容器模塊、掃描模塊、下載模塊、watch模塊 進(jìn)行配置獲取至配置倉庫里。

ReloadingPropertyPlaceholderConfigurer繼承了Spring Bean配置值控制類PropertyPlaceholderConfigurer。在第一次掃描spring bean 時，disconf會記錄配置文件的配置與哪些bean有關(guān)聯(lián)。

ReloadConfigurationMonitor是一個定時任務(wù)，定時check本地配置文件是否有更新。

當(dāng)配置中心的配置被更新時，配置文件會被下載至實例本地，ReloadConfigurationMonitor即會監(jiān)控到此行為，并且通知 ReloadingPropertyPlaceholderConfigurer 對相關(guān)的bean類進(jìn)行值更新。

特別的，此種方式無法解決并發(fā)情況下配置統(tǒng)一生效的問題。

主備分配實現(xiàn)

在實現(xiàn)中，為每個配置提供主備選擇的概念。用戶實例在獲取配置前需要先進(jìn)行全局唯一性競爭才能得到配置值。在這里，我們采用基于zookeeper的全局唯一性鎖來實現(xiàn)。

COMPARISONS

以上就是Disconf實現(xiàn)分布式配置管理的原理與設(shè)計的詳細(xì)內(nèi)容，更多關(guān)于Disconf分布式配置管理的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論