對於配置檔案，我們不陌生，它提供我們可以動態修改程式執行能力。引用別人的一句話就是：
系統執行時(runtime)飛行姿態的動態調整我可以把我們的工作稱之為在快速飛行的飛機上修理零件。我們人類總是無法掌控和預知一切。對於我們系統來說，我們總是需要預留一些控制線條，以便在我們需要的時候做出調整，控制系統方向（如灰度控制、限流調整），這對於擁抱變化的網際網路行業尤為重要。對於單機版，我們稱之為配置（檔案），對於分布式集群系統，我們稱之為配置中心（系統）;下面聊聊我們的配置中心。
當我們是乙個單機服務的是，我們的配置通常寫在乙個檔案中的，**發布的時候，把配置檔案和程式推送到機器上去。
當隨著業務的使用者量增加，通常我們會把我們的服務進行多機器（集群）部署。這時候，配置的發布就變成了如下：
行，這樣發配置也能接受 業務的急劇擴張，導致單機服務無法滿業務需求。這時候需要對單體大服務進行切開，服務走向soa(微服務化)。
這樣去部署配置簡直是一場噩夢，而且無法做到快速的動態的調整。失去了配置主要意義之一。這時候就需要今天說的統一配置中心。
配置中心的特點
我們可以設計出如下的簡版配置中心
設計說明點：
很多時候，這樣可以基本上滿足我們對配置系統的基本需求，對配置的增刪改查，能容忍一段時間的資料不一致性。
這種設計，由於所有的配置都存放在集中式快取中，這樣集中式的快取也會有他的效能瓶頸。而且，每次配置的訪問都需要發起rpc請求(網路請求)，因此考慮在客戶端引入本地快取（localcache，例如ehcache）。
本地快取可以參考我之前文章：本地快取的選擇及其原理
考慮到，減少網路請求的因素，在客戶端引入localcache，來解決系統的高可用，高效能、可伸縮性。
相對於第一版的改進點是，在客戶端引入localcache。開啟執行緒非同步呼叫配置服務，更新本地配置。 這樣可以減少rpc呼叫。
基於資料的cap原理，該方式只做到了ap，這裡會存在資料的一段時間的不一致性，但最終會保證是配置的最終一致性。如何解決這個資料不一致性問題？
還好，配置通常都只會有乙個入口修改，因此可以考慮在配置修改後，通知應用服務清理本地快取和分布式快取。這裡可以引入mq或zookeeper。
最後通過，推拉相結合的方式，完成資料的一致性。
歡迎關注我的技術部落格，我們一起成長一起進步。
林灣村龍貓：www.jianshu.com/u/5a327aab7…
統一配置中心
1.搭建統一配置專案 建立git倉庫配置檔案 檔案訪問路徑說明 2.spring cloud bus 配置檔案修改後自動重新整理 org.springframework.boot spring boot starter amqp 暴露全路徑介面 management endpoints web ex...
SpringCloud統一配置中心
服務端步驟 1 引用依賴 org.springframework.cloud spring cloud config server 2 啟動類新增註解 enableconfigserver3 修改配置檔案 server port 8091 spring name config server clou...
SpringCloud統一配置中心
目錄config client原專案配置檔案 環境要求 i.實現啟動專案，拉取配置 ii.實現手動post請求，重新整理配置 iii.實現webhooks自動重新整理 org.springframework.cloud spring cloud config server org.springfra...