一、緣起

隨著業(yè)務(wù)越來越復(fù)雜，用戶量與流量越來越大，“服務(wù)化分層”是架構(gòu)演進(jìn)的必由之路，此時(shí)：

• 站點(diǎn)應(yīng)用會(huì)調(diào)用服務(wù)，上游服務(wù)調(diào)用底層服務(wù)，依賴關(guān)系會(huì)變得非常復(fù)雜；
• 對于同一個(gè)服務(wù)，為了保證高可用，服務(wù)會(huì)由若干個(gè)節(jié)點(diǎn)形成集群；

如上圖所示，用戶中心us有三個(gè)節(jié)點(diǎn)，ip1/ip2/ip3組成集群對上游提供服務(wù)，保證高可用。

那么問題來了，當(dāng)服務(wù)集群增減節(jié)點(diǎn)的時(shí)候，是否存在“反向依賴”，是否“耦合”，是否上游調(diào)用方需要修改配置重啟，是否能做到上游無感知，是今天需要討論的問題。

二、配置私藏

“配置私藏”是配置文件架構(gòu)的最初級(jí)階段，上游調(diào)用下游，每個(gè)上游都有一個(gè)專屬的私有配置文件，記錄被調(diào)用下游集群配置信息。

如上圖：

• 用戶中心us有ip1/ip2/ip3三個(gè)節(jié)點(diǎn)；
• service1調(diào)用us，它有一個(gè)專屬配置文件s1.conf，配置了us的集群信息ip1/ip2/ip3；
• service2也調(diào)用us，也有個(gè)配置文件s2.conf，也配置了us集群信息ip1/ip2/ip3；
• web2調(diào)用us，同理w2.conf，配置了us集群信息ip1/ip2/ip3；

是不是很熟悉？

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

1. 配置私藏架構(gòu)的缺點(diǎn)是什么呢？

此時(shí)，有兩大痛點(diǎn)：

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

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

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

2. 那要怎么優(yōu)化呢？

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

三、全局配置

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

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

1. 有什么好處？

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

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

2. 有沒有方面實(shí)現(xiàn)自動(dòng)流量遷移呢？

答案是肯定的，只需要實(shí)現(xiàn)兩個(gè)并不復(fù)雜的組件：

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

作用是監(jiān)控文件的變化，起一個(gè)timer，定期監(jiān)控文件的ModifyTime或者md5就能輕松實(shí)現(xiàn)，當(dāng)文件變化后，實(shí)施回調(diào)。

(2) 組件二，動(dòng)態(tài)連接池組件：DynamicConnectionPool

“連接池組件”是RPC-client中的一個(gè)子組件，用來維護(hù)與多個(gè)RPC-server節(jié)點(diǎn)之間的連接。所謂“動(dòng)態(tài)連接池”，是指連接池中的連接可以動(dòng)態(tài)增加和減少。

這兩個(gè)組件完成后：

• 一旦全局配置文件變化，文件監(jiān)控組件實(shí)施回調(diào)；
• 動(dòng)態(tài)連接池組件配置配置的變化，動(dòng)態(tài)增減連接，自動(dòng)完成下游節(jié)點(diǎn)的增容與縮容。

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

四、配置中心

對比“全局配置”與“配置中心”的架構(gòu)圖，配置由靜態(tài)文件升級(jí)為動(dòng)態(tài)服務(wù)：

• 整個(gè)配置中心子系統(tǒng)由zk、conf-center服務(wù)，DB配置存儲(chǔ)，conf-web配置后臺(tái)組成；
• 所有下游服務(wù)的配置，通過后臺(tái)設(shè)置在配置中心里；
• 所有上游需要拉取配置，需要去配置中心注冊，拉取下游服務(wù)配置信息（ip1/ip2/ip3）；

當(dāng)下游服務(wù)容量變化時(shí)，配置中心會(huì)將集群的變化信息推送給上游調(diào)用方，再結(jié)合動(dòng)態(tài)連接池組件，完成自動(dòng)的擴(kuò)容與縮容。同時(shí)，有了全局的調(diào)用拓?fù)鋱D，很容易實(shí)現(xiàn)按需限流，藍(lán)綠部署，算法分流等服務(wù)治理高級(jí)功能。

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

五、總結(jié)

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

配置導(dǎo)致系統(tǒng)耦合，架構(gòu)反向依賴。

2. 什么痛點(diǎn)？

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

3. 配置架構(gòu)如何演進(jìn)？

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

知其然，知其所以然。

思路比結(jié)論更重要。