摘要：于是，市面上出現(xiàn)了分布式的配置中心。為什么呢因?yàn)橐Y(jié)合分布式配置中心微服務(wù)，才能真正實(shí)現(xiàn)我們所理解的。所謂灰度發(fā)布，是說一個(gè)微服務(wù)集群里面，比如有個(gè)訂單系統(tǒng)，做了一些配置上的更新。數(shù)人云分布式統(tǒng)一配置中心數(shù)人云分布式統(tǒng)一配置中心，取名。

本文來自1月18日數(shù)人云資深工程師在IT大咖說平臺(tái)的線上直播分享。

今天主要探討這幾方面：

一、配置中心的定位
二、云化的微服務(wù)對(duì)于配置中心的要求
三、微服務(wù)配置原則
四、數(shù)人云分布式配置中心整體架構(gòu)

應(yīng)DevOps和微服務(wù)而生的配置中心
首先想跟大家分享一下，為什么會(huì)有配置中心的存在？在我早期從事軟件開發(fā)時(shí)，是沒有配置中心，也沒有微服務(wù)的。

以前每次系統(tǒng)發(fā)布，無論是大改動(dòng)，還是很小很小的改動(dòng)，都必須經(jīng)歷發(fā)布的過程。這個(gè)改動(dòng)有時(shí)候小到，只是修改了某個(gè)配置文件的某個(gè)字段，也必須要重新打包，重新部署。

而且，在企業(yè)里開發(fā)和運(yùn)維的人員，往往不是同一個(gè)群組。部署時(shí)，開發(fā)人員需要為運(yùn)維人員準(zhǔn)備部署文檔。這個(gè)過程中，經(jīng)常會(huì)由于溝通協(xié)調(diào)不到位，無法第一時(shí)間預(yù)測(cè)到所有問題，導(dǎo)致在正式上線時(shí)，被用戶第一時(shí)間察覺到上線出了問題，或者部署不正確等，導(dǎo)致一些非常嚴(yán)重的后果。

隨著時(shí)間的推移，軟件工程界出現(xiàn)了新的名詞--DevOps。開發(fā)和運(yùn)維人員共同協(xié)作進(jìn)行產(chǎn)品的部署上線。在DevOps時(shí)代，如何將概念通過一些IT的手段轉(zhuǎn)化為直接的生產(chǎn)力。因?yàn)槊看伟l(fā)布改動(dòng)越大，發(fā)布的頻率越高，系統(tǒng)的風(fēng)險(xiǎn)就越大。

所以業(yè)界急需一種技術(shù)手段，來協(xié)助開發(fā)、部署和運(yùn)維三方面的人員，在不斷的迭代過程中，減少這種風(fēng)險(xiǎn)。配置能不能是一種動(dòng)態(tài)的配置？而不再需要去做一些靜態(tài)配置?；谶@種業(yè)界的風(fēng)險(xiǎn)，就有了去做配置中心的沖動(dòng)。于是，市面上出現(xiàn)了分布式的配置中心。

無論是分布式的配置中心，還是普通配置中心，它到底在配置什么東西？如果把時(shí)間往前推一段，通過SSH登陸服務(wù)器修改配置的那個(gè)時(shí)代，配置中心的作用其實(shí)不大。

到了2010年之后，業(yè)界出現(xiàn)了微服務(wù)，分布式的配置中心才正式地光明正大的走向舞臺(tái)。為什么呢？因?yàn)橐Y(jié)合分布式配置中心+微服務(wù)，才能真正實(shí)現(xiàn)我們所理解的DevOps。

微服務(wù)配置原則
Heroku創(chuàng)始人AdamWiggins發(fā)布了一個(gè)“十二要素應(yīng)用宣言（TheTwelve-Factor App）”，為構(gòu)建使用標(biāo)準(zhǔn)化流程自動(dòng)配置，服務(wù)界限清晰，可移植性高，基于云計(jì)算平臺(tái)，可擴(kuò)展的服務(wù)配置提供了方法論：

1.配置是可分離的，可從微服務(wù)中抽離出來，任何的配置修改不需要?jiǎng)右恍写a。
2.配置應(yīng)該是中央的 通過統(tǒng)一的中央配置平臺(tái)去配置管理不同的微服務(wù)
3.配置中心必須必須可靠切穩(wěn)定地提供配置服務(wù)。
4.配置是可追溯的，任何的配置歷史都是可追溯，被管理且可用。

在云服務(wù)時(shí)代，對(duì)微服務(wù)做配置，對(duì)它有什么樣的要求呢？

首先必須基于鏡像管理部署，有自己相應(yīng)獨(dú)立的配置，而且程序包不可以因?yàn)榄h(huán)境的改變而更改。也就是說，它是獨(dú)立于環(huán)境的不可變的程序包。

其次所有的微服務(wù)通過環(huán)境變量或者配置存儲(chǔ)時(shí)，在啟動(dòng)的那一刻，就可以做配置，也可以通過動(dòng)態(tài)的修改實(shí)時(shí)生效。

微服務(wù)啟動(dòng)時(shí)配置

一個(gè)微服務(wù)從打包、上線、部署，打包以后，會(huì)在啟動(dòng)階段從配置Configuration Repository 里面拉取它的配置，通過注冊(cè)與發(fā)現(xiàn)，注冊(cè)在注冊(cè)中心里，在啟動(dòng)時(shí)，把服務(wù)中心的配置拉取到本地，成為應(yīng)用的一部分。

并且在服務(wù)運(yùn)行過程中，實(shí)時(shí)動(dòng)態(tài)監(jiān)聽配置的變更，達(dá)到有新的配置時(shí)馬上下發(fā)到微服務(wù)，使配置有實(shí)時(shí)生效的效果。

配置中心的定位

有了以上這種業(yè)務(wù)需求，到底要做一個(gè)怎樣的配置中心？數(shù)人云認(rèn)為，這個(gè)配置中心必須有一致性的K-V存儲(chǔ)中心，K-V存儲(chǔ)就是說，一個(gè)K對(duì)應(yīng)一個(gè)V，而且這種存儲(chǔ)必須持久化、可追溯。

它必須是可以集中統(tǒng)一配置，實(shí)時(shí)推送，以及馬上生效。

所有配置都必須實(shí)現(xiàn)灰度更新與回滾。所謂灰度發(fā)布，是說一個(gè)微服務(wù)集群里面，比如有個(gè)訂單系統(tǒng)，做了一些配置上的更新。想在小范圍探討一下，實(shí)驗(yàn)一下這個(gè)配置對(duì)業(yè)務(wù)有怎樣的影響，這時(shí)就用到灰度更新這個(gè)概念。

灰度更新是說，通過Data center或靜態(tài)IP，指定某個(gè)配置只對(duì)某幾個(gè)IP，或者Datacenter里面的某個(gè)服務(wù)生效，其他的不在這個(gè)范圍內(nèi)的服務(wù)，不會(huì)受到影響。觀察效果，如果OK，就把這個(gè)整體配置全面推送到所有的微服務(wù)。如果效果不滿意，就把配置回滾到原來的狀態(tài)。

全量更新，灰度更新，或者回滾，必須是可在任何時(shí)候查看，在某一個(gè)任意的時(shí)刻，回滾到某一個(gè)歷史點(diǎn)的配置。

最后一個(gè)是要有多集群的啟動(dòng)，所謂多集群的啟動(dòng)就是，我們把配置存儲(chǔ)的時(shí)候，必須存儲(chǔ)在一個(gè)多集群的環(huán)境里面，以達(dá)到物理隔離的目的。

另外還有一些原則，業(yè)務(wù)無關(guān)性、 Open API、配置生效監(jiān)控。就是說配置中心必須提供API給第三方的系統(tǒng)來使用。配置的生效監(jiān)控是，必須實(shí)時(shí)知道，有哪些服務(wù)拉取了配置，是否已經(jīng)生效，或者這個(gè)配置的效果如何？

配置中心的支撐體系

第一種運(yùn)維管理體系類似于偏靜態(tài)類的配置，在啟動(dòng)時(shí)通過配置文件直接拉取讀業(yè)務(wù)。

另外一種是開發(fā)管理體系，偏動(dòng)態(tài)管理，代表的是一種程序或者在運(yùn)行過程中，通過實(shí)時(shí)的變更配置內(nèi)容而實(shí)時(shí)生效，達(dá)到的一種效果。

一個(gè)健全的配置中心應(yīng)該支持這兩種運(yùn)維體系。

配置中心的微服務(wù)兼容

配置中心必須對(duì)現(xiàn)有主流的一些開發(fā)框架有API方面的兼容。數(shù)人云在做配置中心時(shí)，很難預(yù)估第三方來調(diào)用服務(wù)時(shí)，到底搭配在什么樣的開發(fā)框架上？通常來說，配置中心不可能兼容市面上所有的東西，數(shù)人云選擇重要的框架來做深度兼容。

首先，對(duì)Spring Cloud，阿里的Dubbo這些常規(guī)的第三方云服務(wù)框架做了API方面的兼容。目前來說，至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。

這種配置各有各的特性，所以我們就挑選了一些有經(jīng)典案例的，通用性的東西來做配置的集成，比如原生支持SpringBoot、Spring Cloud，集成支持k8s，就是k8s容器。

數(shù)人云hawk分布式統(tǒng)一配置中心

數(shù)人云分布式統(tǒng)一配置中心，取名Hawk。Hawk基于ETCD打造，主要解決把開發(fā)人員從復(fù)雜的業(yè)務(wù)流程和煩瑣的配置中解脫出來，讓開發(fā)人員只關(guān)注自己的業(yè)務(wù)代碼，把運(yùn)維、配置這些剝離出去。同時(shí)降低服務(wù)部署、發(fā)布過程中的風(fēng)險(xiǎn)。

基于微服務(wù)體系理念打造的分布式統(tǒng)一配置中心Hawk支持多種類型配置：如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment，具有完善的配置管理流程、配置實(shí)施推送、支持多集群多環(huán)境、多版本控制，更提供配置細(xì)粒度的管理如灰度管理、任意版本重置等豐富功能。

整個(gè)體系兼容開源社區(qū)的Spring Cloud Config以及Kubernetes的Configmap，極大降低使用者的學(xué)習(xí)門檻以及業(yè)務(wù)對(duì)平臺(tái)的耦合。相應(yīng)的管理流程也規(guī)范了配置的使用，降低配置帶來的發(fā)布錯(cuò)誤等。

功能特性
對(duì)比主流框架，數(shù)人云HAWK有如下一些重要的功能特性：

支持配置實(shí)時(shí)推送以及實(shí)時(shí)生效，在程序的運(yùn)行過程中，不能說把服務(wù)停下來才能更新，必須實(shí)時(shí)配置，實(shí)時(shí)生效。

支持多版本管理，配置不管哪個(gè)版本，都可以隨時(shí)查看、查閱以及激活歷史的版本，并做發(fā)布。

支持多集群環(huán)境，多環(huán)境配置。通過數(shù)據(jù)庫(kù)或者后端存儲(chǔ)，以達(dá)到支持SIT、UAT環(huán)境的體系。

優(yōu)美的監(jiān)控臺(tái),提供多維度Dashboard以及監(jiān)控視圖，支持配置灰度和回滾。

支持?jǐn)?shù)據(jù)全局備份和回復(fù)，進(jìn)一步提升配置數(shù)據(jù)的容災(zāi)能力。

提供OpenAPI,支持多系統(tǒng)集成的便利手段，支持配置應(yīng)急預(yù)案處理。

配置流程管理，完善的配置流程管理，確保配置下發(fā)前必須獲得確認(rèn)和授權(quán)。

認(rèn)證與授權(quán)，提供LDAP集成，以及多角色權(quán)限管理。

支持操作審計(jì)，確保配置操作有據(jù)可查。

支持多種配置文件，Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。

支持Spring Cloud服務(wù)治理配置和管控，支持Spring Cloud自有的Hystrix的微服務(wù)治理如熔斷、Fallback等等。

無縫集成Kubernetes的Configmap以及Secrets，并提供增強(qiáng)的企業(yè)管理流程。

Hawk整體架構(gòu)

首先接入第一層是網(wǎng)關(guān)，整體的存儲(chǔ)通過Hawk Server，下發(fā)到ETCD集群，ETCD集群再同步到K8S容器運(yùn)行的平臺(tái)。

剛才有同學(xué)說Hawk跟阿波羅有相似的地方。在研究對(duì)比時(shí)，我們覺得阿波羅出于業(yè)務(wù)需求，有一些比較復(fù)雜的地方，決定把流程簡(jiǎn)化。

先從數(shù)據(jù)遷移的狀態(tài)簡(jiǎn)化成簡(jiǎn)單的幾部分。比如新建一個(gè)配置，要么配置就被刪除了，直接一步到位。如果沒有這樣做，就面臨幾種情況，這個(gè)配置是否要小范圍的去做一些試探性的發(fā)布，這種情況可以走灰度發(fā)布，狀態(tài)變成灰度中，配置不允許更改。要么就是兩條路走，全量發(fā)布到所有服務(wù)上。要么就是放棄灰度回到之前的狀態(tài)，放棄灰度后會(huì)去到已修改的狀態(tài)。

另外一種情況，新建一個(gè)配置，直接全量發(fā)布，狀態(tài)變成已發(fā)布狀態(tài)，這時(shí)候是可更改的。但是每一次的更改，還是會(huì)回到原來那個(gè)狀態(tài)。這個(gè)更改要做灰度嗎？還是做發(fā)布？還是對(duì)發(fā)布有點(diǎn)后悔，不打算更改了？這時(shí)，從歷史版本里面找一個(gè)合適的版本，激活，然后再做一次發(fā)布，通過幾個(gè)簡(jiǎn)單的回路，涵蓋了大部分的業(yè)務(wù)場(chǎng)景。
配置數(shù)據(jù)狀態(tài)變遷

Hawk Portal是主體的配置界面，用戶在界面上對(duì)配置進(jìn)行輸入、增刪、改查的管理。這些資料會(huì)有兩份，一份做通過Mysql做本地存儲(chǔ)，另一份通過Hawk Server直接同步到ETCD。

由于HAWK Server是同步到ETCD里面，也就是說ETCD相當(dāng)于另外一個(gè)數(shù)據(jù)庫(kù)，這當(dāng)中不存在數(shù)據(jù)之間的互相抄送，從而減低丟失數(shù)據(jù)的風(fēng)險(xiǎn)。持久化，是說研發(fā)和運(yùn)維在后臺(tái)做數(shù)據(jù)遷移，或者數(shù)據(jù)監(jiān)控時(shí)更有把握，更方便。

數(shù)人云HAWK其實(shí)有兩個(gè)ETCD，一個(gè)ETCD是做注冊(cè)發(fā)現(xiàn)的，Hawk Server、Hawk Portal都會(huì)注冊(cè)在里面，作為相關(guān)的組件。類比Spring Cloud Eureka，Eureka是注冊(cè)在Eureka Server里面的一個(gè)內(nèi)存列表，集群里面所有Server共享這個(gè)內(nèi)存信息。這個(gè)過程數(shù)人云做了簡(jiǎn)化，所有信息全部注冊(cè)在ETCD里面。

ECTD集群由于是共享的，組件的狀態(tài)和一致性得到保障。Portal和Server之間不再通過Portal注冊(cè)在Server并通過心跳來維持關(guān)系而是通過共享持久化的ETCD，保證數(shù)據(jù)在任意時(shí)刻所看到的狀態(tài)都是一致的，從而保證了服務(wù)的注冊(cè)，以及服務(wù)發(fā)現(xiàn)的穩(wěn)定性。

Hawk和Eureka 選擇的路徑不一樣。Eureka是比較重量級(jí)的，HAWK則簡(jiǎn)化了這個(gè)配置，簡(jiǎn)化這種代碼的復(fù)雜性，重點(diǎn)提高系統(tǒng)的完整性，打造系統(tǒng)閉環(huán)，通過一些相對(duì)簡(jiǎn)單的方法，提高服務(wù)的穩(wěn)定性。

配置一旦通過Hawk Portal潛入本地?cái)?shù)據(jù)庫(kù)，微服務(wù)的注冊(cè)服務(wù)是怎么實(shí)現(xiàn)配置呢？當(dāng)Portal寫入配置到本地?cái)?shù)據(jù)庫(kù)時(shí)，同時(shí)也會(huì)通過服務(wù)Sever去同步到ETCD，ETCD里面存儲(chǔ)的信息，是一個(gè)持久化的數(shù)據(jù)。

通過Server實(shí)時(shí)從ETCD拉取配置，有時(shí)是運(yùn)行的時(shí)候拉取，有時(shí)是啟動(dòng)時(shí)拉取。啟動(dòng)時(shí)拉取有兩種策略，啟動(dòng)的時(shí)候拉取配置，存儲(chǔ)到本地作為靜態(tài)文件的配置，運(yùn)行時(shí)候拉取，動(dòng)態(tài)的變更實(shí)時(shí)生效。

在Web層其實(shí)也有一些問題需要解決，比如，因?yàn)槲覀儾皇且粋€(gè)開發(fā)框架，是奔著一個(gè)開源系統(tǒng)的方向去，所以要解決服務(wù)跟瀏覽器之間的授權(quán)。

數(shù)人云現(xiàn)在的做法是在本土數(shù)據(jù)庫(kù)存儲(chǔ)一些用戶的信息，但是并沒有采用傳統(tǒng)意義上的建Session來做驗(yàn)證和授權(quán)，而是通過動(dòng)態(tài)下發(fā)JWT的形式，每一個(gè)請(qǐng)求動(dòng)態(tài)下發(fā)，根據(jù)我個(gè)人用戶的一些信息生成，每次的請(qǐng)求一來一去都有交換新的Token，每個(gè)Token實(shí)時(shí)生效并有續(xù)約的功能，來代替?zhèn)鹘y(tǒng)意義上的Session。

配置中心集成第三方框架與類庫(kù)

Hawk有一個(gè)第三方類庫(kù)集成，操作流程是這樣的：操作者通過UI調(diào)用HAWK后端的portal，通過Hawk Server把配置寫入ETCD。另外一些運(yùn)營(yíng)者和開發(fā)人員所持有的第三方服務(wù)，通過集成Hawk Client來讀取配置。

Hawk也有新的迭代，跟Sharding-JDBC做了集成，JDBC 2.0的一些趨勢(shì)跟HAWK系統(tǒng)做了深度集成。服務(wù)通過實(shí)時(shí)讀取配置中心配置實(shí)現(xiàn)動(dòng)態(tài)更改分庫(kù)分表的策略。

Q&A
Q1：實(shí)時(shí)更改分布分表策略？
A1：可以，Sharding JDBC 2.0就是重點(diǎn)實(shí)現(xiàn)這個(gè)功能，這也是Hawk與Sharding JDBC深度合作的成果

Q2：歷史數(shù)據(jù)怎么辦？
A2：歷史的數(shù)據(jù)其實(shí)都是持久化存儲(chǔ)的。如果有一天要回到某個(gè)歷史版本，可以隨時(shí)通過調(diào)取已發(fā)布的歷史。Hawk有一個(gè)版面叫發(fā)布?xì)v史。這里，每一個(gè)配置都有配置歷史可追尋，可以隨時(shí)查看或激活某個(gè)版本。激活的時(shí)候，需要用戶去選擇要做一個(gè)全鏈發(fā)布還灰度發(fā)布，還是說什么都不做。

Q3：是否支持ServiceMesh？
A3：目前來說ServiceMesh還是一個(gè)比較新的東西。如果ServiceMesh是獨(dú)立配置的話，其實(shí)可以支持到。但是ServiceMesh有非常多的特性，還不敢說100%可以支持得到。其實(shí)數(shù)人云也在做ServiceMesh相關(guān)的項(xiàng)目，就是說它以后還是有非常大的可能，還是要集成ServiceMesh配置中心里面做一個(gè)閉環(huán)。目前這個(gè)版本支持一些比較輕量的配置。

ServiceMesh中文網(wǎng)微信公眾號(hào)（ID：servicemesh），大量Istio、Conduit官方文檔翻譯版和技術(shù)干貨文章，歡迎關(guān)注。

Q4：開發(fā)環(huán)境和生產(chǎn)環(huán)境用哪一步驟？
A4：SIT和UI其實(shí)可以部署在一起，通過存儲(chǔ)隔離來做到。但是，不建議生產(chǎn)也部署在一起，生產(chǎn)還是建議獨(dú)立部署。生產(chǎn)還是物理隔離是最好的方案。

Q5：配置中心和服務(wù)中心是不是兩個(gè)系統(tǒng)？
A5：目前來說是兩個(gè)系統(tǒng)，但是現(xiàn)在的想法是暫時(shí)的?，F(xiàn)在的想法是是不是把配置中心再擴(kuò)大一點(diǎn)，不叫配置中心了，而是叫比如微服務(wù)服務(wù)平臺(tái)。服務(wù)平臺(tái)里把配置中心跟注冊(cè)中心都作為一個(gè)組件融入進(jìn)去，把一些跟業(yè)務(wù)無關(guān)的東西抽離出來，搭載一些公共的平臺(tái)上，以組件的形式去融入到這個(gè)平臺(tái)里面去。

Q6：開源有本地緩存嗎？
A6：目前來說沒有本地緩存，是直接獲取ETCD的東西，所以它是實(shí)時(shí)的，但是注冊(cè)中心里面會(huì)加入緩存。

Q7：一般哪些信息通過配置中心配置？
A7：非業(yè)務(wù)的東西，比如平時(shí)開發(fā)一個(gè)系統(tǒng)，或者開發(fā)一個(gè)第三方系統(tǒng)，我們都有所有的配置文件，比如數(shù)據(jù)庫(kù)的連接，跟治理相關(guān)的東西，或者一些國(guó)外的引用，都可以通過配置中心來配置，并且這種配置不僅僅是在頁面上的配置，有一個(gè)插件給它，啟動(dòng)之后直接把這些配置導(dǎo)入到配置中心里面去，還可以通過啟動(dòng)的時(shí)候把這種配置下發(fā)到本地，形成一個(gè)本地的靜態(tài)配置。

Q8：server如果斷開怎么處理？
A8：因?yàn)镾erver是多Server集群的，如果斷開了并不是說通過指定IP地址去訪問這個(gè)Server，而是通過注冊(cè)與發(fā)現(xiàn)去訪問這個(gè)Server，如果Server斷開了，其實(shí)也就是說他們之間沒有心跳了，他們就會(huì)嘗試去ETCD里面請(qǐng)求一個(gè)新的連接，而這個(gè)連接也會(huì)通過注冊(cè)與發(fā)現(xiàn)，會(huì)發(fā)現(xiàn)其他的Server，這樣的話他們就會(huì)連接。