一、緣起

隨著業務越來越復雜，用戶量與流量越來越大，“服務化分層”是架構演進的必由之路，此時：

• 站點應用會調用服務，上游服務調用底層服務，依賴關系會變得非常復雜；
• 對于同一個服務，為了保證高可用，服務會由若干個節點形成集群；

如上圖所示，用戶中心us有三個節點，ip1/ip2/ip3組成集群對上游提供服務，保證高可用。

那么問題來了，當服務集群增減節點的時候，是否存在“反向依賴”，是否“耦合”，是否上游調用方需要修改配置重啟，是否能做到上游無感知，是今天需要討論的問題。

二、配置私藏

“配置私藏”是配置文件架構的最初級階段，上游調用下游，每個上游都有一個專屬的私有配置文件，記錄被調用下游集群配置信息。

如上圖：

• 用戶中心us有ip1/ip2/ip3三個節點；
• service1調用us，它有一個專屬配置文件s1.conf，配置了us的集群信息ip1/ip2/ip3；
• service2也調用us，也有個配置文件s2.conf，也配置了us集群信息ip1/ip2/ip3；
• web2調用us，同理w2.conf，配置了us集群信息ip1/ip2/ip3；

是不是很熟悉？

這是典型的“配置私藏”架構，很多公司初期都是這么玩的。

1. 配置私藏架構的缺點是什么呢？

此時，有兩大痛點：

問題一，調用方很痛：us集群發生變化的時候，s1s2web2需要修改自己的專屬配置文件，并重啟。

畫外音：這是一個典型的“反向依賴”耦合，集群變化的是你，憑啥修改配置重啟的是我，需要優化。

問題二，服務方很痛：us不知道有多少個上游調用了自己，無法進行服務治理。例如：它無法按照調用方限流，容易出現一個邊緣上游業務把調用量打滿，從而耦合影響上游核心業務。

2. 那要怎么優化呢？

架構的升級并不是一步到位的，可以先采用最低成本的“全局配置法”，來解決問題一。

三、全局配置

“全局配置”法：對于通用的服務，建立全局配置文件，消除配置私藏：

• 運維層面制定規范，新建全局配置文件，global.conf；
• 對于服務方，如果是通用的服務，集群信息配置在global.conf里
• 對于調用方，調用方禁止配置私藏，必須從global.conf里讀取通用下游配置

1. 有什么好處？

• 如果下游容量變化，只需要修改一處配置global.conf，而不需要各個上游修改；
• 調用方下一次重啟的時候，自動遷移到擴容后的集群上來了；
• 修改成本非常小，讀取配置文件目錄變了；

不足：如果調用方一直不重啟，就沒有辦法將流量遷移到新集群上去了。

2. 有沒有方面實現自動流量遷移呢？

答案是肯定的，只需要實現兩個并不復雜的組件：

(1) 組件一，文件監控組件：FileMonitor

作用是監控文件的變化，起一個timer，定期監控文件的ModifyTime或者md5就能輕松實現，當文件變化后，實施回調。

(2) 組件二，動態連接池組件：DynamicConnectionPool

“連接池組件”是RPC-client中的一個子組件，用來維護與多個RPC-server節點之間的連接。所謂“動態連接池”，是指連接池中的連接可以動態增加和減少。

這兩個組件完成后：

• 一旦全局配置文件變化，文件監控組件實施回調；
• 動態連接池組件配置配置的變化，動態增減連接，自動完成下游節點的增容與縮容。

全局配置文件是一個能夠快速落地的，解決“修改配置重啟”問題的方案，但它仍然解決不了，服務提供方“服務治理”的問題，此時可以采用“配置中心”來解決。

四、配置中心

對比“全局配置”與“配置中心”的架構圖，配置由靜態文件升級為動態服務：

• 整個配置中心子系統由zk、conf-center服務，DB配置存儲，conf-web配置后臺組成；
• 所有下游服務的配置，通過后臺設置在配置中心里；
• 所有上游需要拉取配置，需要去配置中心注冊，拉取下游服務配置信息（ip1/ip2/ip3）；

當下游服務容量變化時，配置中心會將集群的變化信息推送給上游調用方，再結合動態連接池組件，完成自動的擴容與縮容。同時，有了全局的調用拓撲圖，很容易實現按需限流，藍綠部署，算法分流等服務治理高級功能。

不足：系統復雜度相對較高，對配置中心的可靠性要求較高，一處掛全局掛。

五、總結

1. 系列方案解決什么問題？

配置導致系統耦合，架構反向依賴。

2. 什么痛點？

• 上游痛：擴容的是下游，改配置重啟的是上游
• 下游痛：不知道誰依賴于自己

3. 配置架構如何演進？

• 配置私藏
• 全局配置文件
• 配置中心

知其然，知其所以然。

思路比結論更重要。