一、解決的問題
- 如上圖，站點應用會調用服務，上游服務調用底層服務，依賴關系會變得非常復雜。 調用方如何維護下游服務集群配置？ 當服務集群增減節點時，調用方是否有感知？
二、初期 “配置私藏”架構
- 每個上下游都有一份配置文件，記錄被調用下游的每個節點配置信息 該方案的缺陷 問題一：調用方很痛，容量變化的是你，憑啥修改配置重啟的是我？這是一個典型的“反向依賴”架構設計，上下游通過配置耦合，不合理。 問題二：服務方很痛，ta不知道有多少個上游調用了自己，往往只能通過以下方式來定位上游：
- 群里吼
- 發郵件詢問
- 通過連接找到ip，通過ip問運維，找到機器負責人，再通過機器負責人找到對應調用服務
三、中期：“全局配置”架構
（1）運維層面制定規范，新建全局配置文件，例如/opt/global.conf； （2）對於服務方，如果是通用的服務，集群信息配置在global.conf里； （3）對於調用方，調用方禁止配置私藏，必須從global.conf里讀取通用下游配置；
好處：
（1）如果下游容量變化，只需要修改一處配置global.conf，而不需要各個上游修改；
（2）調用方下一次重啟的時候，自動遷移到擴容后的集群上來了；
（3）修改成本非常小，讀取配置文件目錄變了而已；
全局配置有什么不足呢？
如果調用方一直不重啟，就沒有辦法將流量遷移到新集群上去了。
四、終版：“配置中心”架構
- 對比“全局配置”與“配置中心”的架構圖，會發現配置由靜態的文件升級為動態的服務：
（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）很容易從配置中心得到全局架構依賴關系；
“配置中心”架構有什么不足呢？
一來，系統復雜度相對較高；
二來，對配置中心的可靠性要求較高，一處掛全局掛。
究竟要解決什么痛點？
上游痛：擴容的是下游，改配置重啟的是上游；
下游痛：不知道誰依賴於自己；
總之，難以實施服務治理。
究竟如何解決上述痛點？
一、“配置私藏”架構；
二、“全局配置文件”架構；
三、“配置中心”架構；