微服务架构 为什么需要配置中心
https://kuaibao.qq.com/s/20180530G1O8RC00?refer=spider
一、介紹
?
在系統(tǒng)架構(gòu)中，和安全、日志、監(jiān)控等非功能需求一樣，配置管理也是一種非功能需求。配置中心是整個微服務(wù)基礎(chǔ)架構(gòu)體系中的一個組件，如下圖，它的功能看上去并不起眼，無非就是簡單配置的管理和存取，但它是整個微服務(wù)架構(gòu)中不可或缺的一環(huán)。另外，配置中心如果真得用好了，它還能推動技術(shù)組織持續(xù)交付和DevOps文化轉(zhuǎn)型。
?
?
本文介紹在分布式微服務(wù)環(huán)境下，應(yīng)用配置管理背后的業(yè)務(wù)需求，配置的各種分類和一些高級應(yīng)用場景。
?
二、配置定義和形態(tài)
?
配置其實是獨立于程序的可配變量，同一份程序在不同配置下會有不同的行為，常見的配置有連接字符串，應(yīng)用配置和業(yè)務(wù)配置等。
配置有多種形態(tài)，下面是一些常見的：
程序內(nèi)部hardcode，這種做法是反模式，一般我們不建議！
配置文件，比如Spring應(yīng)用程序的配置一般放在文件中。
環(huán)境變量，配置可以預(yù)置在操作系統(tǒng)的環(huán)境變量里頭，程序運行時讀取，這是很多PaaS平臺，比如Heroku推薦的做法，參考12 factor app[附錄9.1]。
啟動參數(shù)，可以在程序啟動時一次性提供參數(shù)，例如java程序啟動時可以通過方式配啟動參數(shù)。
基于數(shù)據(jù)庫，有經(jīng)驗的開發(fā)人員會把易變配置放在數(shù)據(jù)庫中，這樣可以在運行期靈活調(diào)整配置，這個做法和配置中心的思路已經(jīng)有點接近了。
?
?
?
三、傳統(tǒng)應(yīng)用配置的痛點
?
在沒有引入配置中心之前，一般企業(yè)研發(fā)都會面臨如下痛點：
1. 配置散亂格式不標(biāo)準(zhǔn)
有的用properties格式，有的用xml格式，還有的存DB，團隊傾向自造輪子，做法五花八門。
2. 主要采用本地靜態(tài)配置，配置修改麻煩
配置修改一般需要經(jīng)過一個較長的測試發(fā)布周期。在分布式微服務(wù)環(huán)境下，當(dāng)服務(wù)實例很多時，修改配置費時費力。
3. 易引發(fā)生產(chǎn)事故
這個是我親身經(jīng)歷，之前在一家互聯(lián)網(wǎng)公司，有團隊在發(fā)布的時候?qū)y試環(huán)境的配置帶到生產(chǎn)上，引發(fā)百萬級資損事故。
4. 配置缺乏安全審計和版本控制功能
誰改的配置？改了什么？什么時候改的？無從追溯，出了問題也無法及時回滾。
?
四、現(xiàn)代應(yīng)用配置核心需求
?
近年，持續(xù)交付和DevOps理念開始逐步被一線企業(yè)接受，微服務(wù)架構(gòu)和容器云也逐漸在一線企業(yè)落地，這些都對應(yīng)用配置管理提出了更高的要求：
?
?
1. 交付件和配置分離
傳統(tǒng)做法應(yīng)用在打包部署時，會為不同環(huán)境打出不同配置的包，例如為開發(fā)/測試/UAT/生產(chǎn)環(huán)境分別制作發(fā)布包，每個包里頭包含環(huán)境特定配置。
現(xiàn)代微服務(wù)提倡云原生(Cloud Native)和不可變基礎(chǔ)設(shè)施（Immutable Infrastructure）的理念，推薦采用如容器鏡像這種方式打包和交付微服務(wù)，應(yīng)用鏡像一般只打一份，可以部署到不同環(huán)境。這就要求交付件（比如容器鏡像）和配置進行分離，交付件只制作一份，并且是不可變的，可以部署到任意環(huán)境，而配置由配置中心集中管理，所有環(huán)境的配置都可以在配置中心集中配，運行期應(yīng)用根據(jù)自身環(huán)境到配置中心動態(tài)拉取相應(yīng)的配置。
2. 抽象標(biāo)準(zhǔn)化
企業(yè)應(yīng)該由框架或者中間件團隊提供標(biāo)準(zhǔn)化的配置中心服務(wù)(Configuration as a Service)，封裝屏蔽配置管理的細(xì)節(jié)和配置的不同格式，方便用戶進行自助式的配置管理。一般用戶只需要關(guān)注兩個抽象和標(biāo)準(zhǔn)化的接口：
?
配置管理界面UI，方便應(yīng)用開發(fā)人員管理和發(fā)布配置，
封裝好的客戶端API，方便應(yīng)用集成和獲取配置。
3. 多環(huán)境多集群
?
現(xiàn)代微服務(wù)應(yīng)用大都采用多環(huán)境部署，一般標(biāo)準(zhǔn)化的環(huán)境有開發(fā)/測試/UAT/生產(chǎn)等，有些應(yīng)用還需要多集群部署，例如支持跨機房或者多版本部署。配置中心需要支持對多環(huán)境和多集群應(yīng)用配置的集中式管理。
4. 高可用
配置中心必須保證高可用，不能隨便掛，否則可能大面積影響微服務(wù)。在極端的情況下，如果配置中心不可用，客戶端也需要有降級策略，保證應(yīng)用可以不受影響。
5. 實時性
配置更新需要盡快通知到客戶端，這個周期不能太長，理想應(yīng)該是實時的。有些配置的實時性要求很高，比方說主備切換配置或者藍(lán)綠部署配置，需要秒級切換配置的能力。
6. 治理
配置需要治理，具體包括：
配置審計，誰、在什么時間、修改了什么配置，需要詳細(xì)的審計，方便出現(xiàn)問題時能夠追溯。
配置版本控制，每次變更需要版本化，出現(xiàn)問題時候能夠及時回滾到上一版本。
配置權(quán)限控制，配置變更發(fā)布需要認(rèn)證授權(quán)，不是所有人都能修改和發(fā)布配置。
灰度發(fā)布，高級的配置治理支持灰度發(fā)布，配置發(fā)布時可以先讓少數(shù)實例生效，確保沒有問題再逐步放量。
?
五、配置分類
?
配置目前還沒有特別標(biāo)準(zhǔn)的分類方法，我簡單把配置分為靜態(tài)和動態(tài)兩大類，每一類再分為若干子類，如下圖：
?
?
1. 靜態(tài)配置
所謂靜態(tài)配置，就是在程序啟動前一次性配好，啟動時一次性生效，在程序運行期一般不會變化的配置。具體包括：
1.1 環(huán)境相關(guān)配置
有些配置是和環(huán)境相關(guān)的，每個環(huán)境的配置不一樣，例如數(shù)據(jù)庫、中間件和其它服務(wù)的連接字符串配置。這些配置一次性配好，運行期一般不變。
1.2 安全配置
有些配置和安全相關(guān)，例如用戶名，密碼，訪問令牌，許可證書等，這些配置也是一次性配好，運行期一般不變。因為涉及安全，相關(guān)信息一般需要加密存儲，對配置訪問需要權(quán)限控制。
2. 動態(tài)配置
所謂動態(tài)配置，就是在程序的運行期可以根據(jù)需要動態(tài)調(diào)整的配置。動態(tài)配置讓應(yīng)用行為和功能的調(diào)整變得更加靈活，是持續(xù)交付和DevOps的最佳實踐。具體包括：
2.1 應(yīng)用配置
和應(yīng)用相關(guān)的配置，例如服務(wù)請求超時，線程池和隊列的大小，緩存過期時間，數(shù)據(jù)庫連接池的容量，日志輸出級別，限流熔斷閥值，服務(wù)安全黑白名單等。一般開發(fā)或者運維會根據(jù)應(yīng)用的實際運行情況調(diào)整這些配置。
2.2 業(yè)務(wù)配置
和業(yè)務(wù)相關(guān)的一些配置，例如促銷規(guī)則，貸款額度，利率等業(yè)務(wù)參數(shù)，A/B測試參數(shù)等。一般產(chǎn)品運營或開發(fā)人員會根據(jù)實際的業(yè)務(wù)需求，動態(tài)調(diào)整這些參數(shù)。
2.3 功能開關(guān)
在英文中也稱Feature Flag/Toggle/Switch，簡單的只有真假兩個值，復(fù)雜的可以是多值參數(shù)。功能開關(guān)是DevOps的一種最佳實踐，在運維中有很多應(yīng)用場景，比如藍(lán)綠部署，灰度開關(guān)，降級開關(guān)，主備切換開關(guān)，數(shù)據(jù)庫遷移開關(guān)等。功能開關(guān)在國外互聯(lián)網(wǎng)公司用得比較多，國內(nèi)還沒有普及開，所以我在下一節(jié)會給出一些功能開關(guān)的高級應(yīng)用場景。
?
六、配置中心高級應(yīng)用場景
?
場景一、藍(lán)綠部署
藍(lán)綠部署的傳統(tǒng)做法是通過負(fù)載均衡器切流量來實現(xiàn)，如下圖左邊所示。這種做法一般研發(fā)人員無法自助操作，需要提交工單由運維介入操作，操作和反饋周期比較長，出了問題回退還需運維人員介入，所以回退也比較慢，總體風(fēng)險比較高。
?
?
藍(lán)綠部署也可以通過配置中心+功能開關(guān)的方式來實現(xiàn)，如上圖右邊所示。開發(fā)人員在上線新功能時先將新功能隱藏在動態(tài)開關(guān)后面，開關(guān)的值在配置中心里頭配。剛上線時新功能暫不啟用，走老功能邏輯，然后開發(fā)人員通過配置中心打開開關(guān)，這個時候新功能就啟用了。一旦發(fā)現(xiàn)新功能有問題，可以隨時把開關(guān)關(guān)掉切回老功能。這種做法開發(fā)人員可以全程自助實現(xiàn)藍(lán)綠部署，不需要運維人員介入，反饋周期短效率高。
場景二、限流降級
當(dāng)業(yè)務(wù)團隊在搞促銷，或者是系統(tǒng)受DDOS攻擊的時候，如果沒有好的限流降級機制，則系統(tǒng)很容易被洪峰流量沖垮，這個時候所有用戶無法訪問，體驗糟糕，如下圖左邊所示。
?
?
所以我們需要限流降級機制來應(yīng)對流量洪峰。常見做法，我們一般會在應(yīng)用的過濾器層或者是網(wǎng)關(guān)代理層添加限流降級邏輯，并且和配置中心配合，實現(xiàn)限流降級開關(guān)和參數(shù)的動態(tài)調(diào)整。如果促銷出現(xiàn)流量洪峰，我們可以通過配置中心啟動限流降級策略，比如對于普通用戶，我們可以先給出“網(wǎng)絡(luò)不給力，請稍后再試”的友好提示，對于高級VIP用戶，我們?nèi)匀槐ＷC他們的正常訪問。
國內(nèi)電商巨頭阿里，它內(nèi)部的系統(tǒng)大量采用限流降級機制，實現(xiàn)方式基于其內(nèi)部的diamond+sentinel配置管理系統(tǒng)。如果沒有限流降級機制的保護，則阿里的系統(tǒng)也無法抵御雙十一帶來的洪峰流量沖擊。
場景三、數(shù)據(jù)庫遷移
LaunchDarkly是一家提供配置既服務(wù)(Configuration as a Service)的SAAS服務(wù)公司，它在其博客上給出了一片關(guān)于使用功能開關(guān)實現(xiàn)數(shù)據(jù)庫遷移的案例文章，該案例基于其內(nèi)部一次成功的數(shù)據(jù)庫遷移實踐，從MongdoDB遷移到DynamoDB[參考附錄9.2]，下圖是展示了一個簡化的遷移流程：
?
?
簡化遷移騰挪流程如下：
?
開發(fā)人員先在應(yīng)用端的DAO層埋好數(shù)據(jù)雙寫雙讀、以及數(shù)據(jù)比對邏輯。雙寫雙讀邏輯由開關(guān)控制，開關(guān)的值可在配置中心配。
先保證應(yīng)用100%讀寫mongoDB，然后先放開10%的DynamoDB雙寫，也稱金絲雀寫(Canary Write)，確保金絲雀寫沒有功能和性能問題。
逐步放量DyanamoDB寫到100%，確保全量雙寫沒有功能和性能問題。
放開10%的DynamoDB雙讀，也稱金絲雀讀(Canary Read)，通過比對邏輯確保金絲雀讀沒有邏輯和性能問題。
逐步放量DynamoDB讀到100%，通過比對邏輯確保全量雙讀沒有邏輯和性能問題。
關(guān)閉對mongoDB的讀寫，遷移完成。
?
整個遷移流程受配置中心的開關(guān)控制，可以靈活調(diào)整開關(guān)和參數(shù)，有問題可以隨時回滾，大大降低遷移風(fēng)險。
場景四、A/B測試
如果我們需要對電商平臺的結(jié)賬(checkout)功能進行改版，考慮到結(jié)賬功能業(yè)務(wù)影響面大，一下子上線風(fēng)險大，為了減低風(fēng)險，我們可以在配置中心配合下，對結(jié)賬功能進行A/B測試，簡化邏輯如下圖：
?
?
我們在配置中心中增加一個開關(guān)，控制A/B測試邏輯：
?
如果A/B測試開關(guān)是關(guān)閉的()，那么就走老的結(jié)賬邏輯。
如果A/B測試開關(guān)是打開的(，并且是普通用戶(，可以檢查數(shù)據(jù)庫中用戶類型)，那么就走老的結(jié)賬邏輯。
如果A/B測試開關(guān)是打開的()，并且是beta用戶（），那么就走改版后的新結(jié)賬邏輯。
?
通過配置中心，我們可以靈活調(diào)整開關(guān)，先對新功能進行充分的beta試驗，再考慮全量上線，大大降低關(guān)鍵業(yè)務(wù)新功能的上線風(fēng)險。
?
七、公司案例和產(chǎn)品
?
在一線前沿的互聯(lián)網(wǎng)公司，配置中心都是其技術(shù)體系中的關(guān)鍵基礎(chǔ)服務(wù)，下圖給出一些公司案例產(chǎn)品:
?
?
?
阿里巴巴中間件部門很早就自研了配置中心Diamond，并且是開源的。Diamond對阿里系統(tǒng)的靈活穩(wěn)定性發(fā)揮了至關(guān)重要的作用。開源版本的Diamond由于研發(fā)時間比較早，使用的技術(shù)比較老，功能也不夠完善，目前社區(qū)不熱已經(jīng)不維護了。
Facebook內(nèi)部也有一整套完善的配置管理體系[可參考其論文，附錄9.3]，其中一個產(chǎn)品叫Gatekeeper，目前沒有開源。
Netflix內(nèi)部有大量的微服務(wù)，它的服務(wù)的穩(wěn)定靈活性也重度依賴于配置中心。Netflix開源了它的配置中心的客戶端，叫變色龍Archaius[參考附錄9.4]，比較可惜的是，Netflix沒有開源它的配置中心的服務(wù)器端。
Apollo[參考附錄9.5]是攜程框架部研發(fā)并開源的一款配置中心產(chǎn)品，企業(yè)級治理功能完善，目前社區(qū)比較火，在github上有超過5k星，在國內(nèi)眾多互聯(lián)網(wǎng)公司有落地案例。如果企業(yè)打算引入開源的配置中心，那么Apollo是我推薦的首選。
百度之前也開源過一個叫Disconf[參考附錄9.6]的配置中心產(chǎn)品，作者是前百度資深工程師廖綺綺。在Apollo沒有出來之前，Disconf在社區(qū)是比較火的，但是自從廖琦琦離開百度之后，他好像沒有足夠精力投入維護這個項目，目前社區(qū)活躍度已經(jīng)大不如前。
?
?
八、結(jié)論
?
?
配置中心是微服務(wù)基礎(chǔ)架構(gòu)中不可或缺的核心組件，現(xiàn)代微服務(wù)架構(gòu)和云原生環(huán)境，對應(yīng)用配置管理提出了更高的要求。
配置中心有眾多的應(yīng)用場景，配置中心+功能開關(guān)是DevOps最佳實踐。用好配置中心，它能幫助技術(shù)組織實現(xiàn)持續(xù)交付和DevOps文化轉(zhuǎn)型。
攜程開源的Apollo配置中心，企業(yè)級功能完善，經(jīng)過大規(guī)模生產(chǎn)驗證，社區(qū)活躍度高，是開源配置中心產(chǎn)品的首選。
?
九、附錄
?12 Factor App
https://12factor.net/config
使用功能開關(guān)實現(xiàn)數(shù)據(jù)庫遷移
https://blog.launchdarkly.com/feature-flagging-to-mitigate-risk-in-database-migration/
Facebook的配置管理體系論文
http://sigops.org/sosp/sosp15/current/2015-Monterey/printable/008-tang.pdf
Netflix開源的Archaius配置庫
https://github.com/Netflix/archaius
攜程開源的Apollo配置中心
https://github.com/ctripcorp/apollo
Disconf配置中心
https://github.com/knightliao/disconf
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9238281.html
總結(jié)
以上是生活随笔為你收集整理的微服务架构 为什么需要配置中心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： curl请求模拟post发送json
- 下一篇： 从 Spring Cloud 看一个微服