配置中心是網際網路架構體系中很重要的一塊，但為什麼會有配置中心，是不是一開始就要有配置中心，它究竟解決什麼問題，這是今天要讨論的問題。
随着網際網路業務的越來越複雜，使用者量與流量越來越大，“服務化分層”是架構演進的必由之路。
如上圖，使用者中心服務user-service有三個節點，ip1/ip2/ip3對上遊提供服務，任何一個節點當機，都不影響服務的可用性。 那麼問題來了：調用方如何維護下遊服務叢集配置？當服務叢集增減節點時，調用方是否有感覺？ 初期：“配置私藏”架構
“配置私藏”是配置的最初級階段，上遊調用下遊，每個上遊都有一個專屬的私有配置檔案，記錄被調用下遊的每個節點配置資訊。
- 群裡吼
- 發郵件詢問
- 通過連接配接找到ip，通過ip問運維，找到機器負責人，再通過機器負責人找到對應調用服務
畫外音：是不是似曾相識?
不管哪種方式，都很有可能遺漏，導緻ip1一直有流量難以下線，ip4/ip5的流量難以均勻遷移過來。該如何優化呢？ 中期：“全局配置”架構
架構的更新并不是一步到位的，先來用最低的成本來解決上述“修改配置重新開機”的問題一。
“全局配置”架構：對于通用的服務，建立全局配置檔案，消除配置私藏：
（1）運維層面制定規範，建立全局配置檔案，例如/opt/global.conf；畫外音：如果配置較多，注意做好配置的垂直拆分。（2）對于服務方，如果是通用的服務，叢集資訊配置在global.conf裡；（3）對于調用方，調用方禁止配置私藏，必須從global.conf裡讀取通用下遊配置； 全局配置有什麼好處呢？（1）如果下遊容量變化，隻需要修改一處配置global.conf，而不需要各個上遊修改；（2）調用方下一次重新開機的時候，自動遷移到擴容後的叢集上來了；（3）修改成本非常小，讀取配置檔案目錄變了而已； 全局配置有什麼不足呢？如果調用方一直不重新開機，就沒有辦法将流量遷移到新叢集上去了。
有沒有方面實作自動流量遷移呢？
答案是肯定的，隻需要引入兩個并不複雜的元件，就能實作調用方的流量自動遷移：
（1）檔案監控元件FileMonitor作用是監控檔案的變化，起一個timer，定期監控檔案的ModifyTime或者md5就能輕松實作，當檔案變化後，實施回調。
（2）動态連接配接池元件DynamicConnectionPool“連接配接池元件”是RPC-client中的一個子元件，用來維護與多個RPC-server節點之間的連接配接。所謂“動态連接配接池”，是指連接配接池中的連接配接可以動态增加和減少。畫外音：用鎖來互斥，很容易實作。 引入了這兩個元件之後：（1）一旦全局配置檔案變化，檔案監控元件實施回調；（2）如果動态連接配接池元件發現配置中減少了一些節點，就動态的将對應連接配接銷毀，如果增加了一些節點，就動态建立連接配接，自動完成下遊節點的增容與縮容； 終版：“配置中心”架構
“全局配置”架構是一個能夠快速落地的，解決“修改配置重新開機”問題的方案，但它仍然解決不了，服務提供方“不知道有多少個上遊調用了自己”這個問題。 如果不知道多少上遊調用了自己：“按照調用方限流”“繪制全局架構依賴圖”等這類需求便難以實作，怎麼辦？
“配置中心”架構能夠完美解決。
對比“全局配置”與“配置中心”的架構圖，會發現配置由靜态的檔案更新為動态的服務：
（1）整個配置中心子系統由zk、conf-center服務，DB配置存儲與，conf-web配置背景組成；（2）所有下遊服務的配置，通過背景設定在配置中心裡；（3）所有上遊需要拉取配置，需要去配置中心注冊，拉取下遊服務配置資訊（ip1/ip2/ip3）；
當下遊服務需要擴容縮容時：
（4）conf-web配置背景進行設定，新增ip4/ip5，減少ip1；（5）conf-center服務将變更的配置推送給已經注冊關注相關配置的調用方；（6）結合動态連接配接池元件，完成自動的擴容與縮容； “配置中心”架構有什麼好處呢？（1）調用方不需要再重新開機；（2）服務方從配置中心中很清楚的知道上遊依賴關系，進而實施按照調用方限流；（3）很容易從配置中心得到全局架構依賴關系；痛點一、痛點二同時解決。 “配置中心”架構有什麼不足呢？一來，系統複雜度相對較高；二來，對配置中心的可靠性要求較高，一處挂全局挂。
總結
究竟要解決什麼痛點？上遊痛：擴容的是下遊，改配置重新開機的是上遊；下遊痛：不知道誰依賴于自己；總之，難以實施服務治理。
究竟如何解決上述痛點？一、“配置私藏”架構；二、“全局配置檔案”架構；三、“配置中心”架構； 知其然，知其是以然。
本文轉自“架構師之路”公衆号，58沈劍提供。