互聯網架構中為什么需要配置中心

這篇文章主要介紹了互聯網架構中為什么需要配置中心，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

配置中心是互聯網架構體系中很重要的一塊，但為什么會有配置中心，是不是一開始就要有配置中心，它究竟解決什么問題，這是今天要討論的問題。

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

如上圖，站點應用會調用服務，上游服務調用底層服務，依賴關系會變得非常復雜。

對于同一個服務：

(1)它往往有多個上游調用;

(2)為了保證高可用，它往往是若干個節點組成的集群提供服務;

如上圖，用戶中心服務user-service有三個節點，ip1/ip2/ip3對上游提供服務，任何一個節點當機，都不影響服務的可用性。

那么問題來了：

• 調用方如何維護下游服務集群配置?

• 當服務集群增減節點時，調用方是否有感知?

初期：“配置私藏”架構

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

如上圖：

• 用戶中心user-service有ip1/ip2/ip3三個節點;

• service1調用了用戶中心，它有一個專屬配置文件s1.conf，里面配置了us的集群是ip1/ip2/ip3;

• service2也調用了用戶中心，同理有個配置文件s2.conf，記錄了us集群是ip1/ip2/ip3;

• web2也調用了用戶中心，同理w2.conf，配置了us集群是ip1/ip2/ip3;

畫外音：是不是很熟悉?絕大部分公司，初期都是這么玩的。

“配置私藏”架構的缺點是什么呢?

來看一個容量變化的需求：

• 運維檢測出ip1節點的硬盤性能下降，通知研發未來要將ip1節點下線;

• 由于5月8日要做大促運營活動，未來流量會激增，研發準備增加兩個節點ip4和ip5;

此時要怎么做呢?

需要用戶中心的負責人通知所有上游調用者，修改“私藏”的配置，并重啟上游，連接到新的集群上去。在ip1上沒有流量之后，通知運維將ip1節點下線，以完成整個縮容擴容過程。

這種方案存在什么問題呢?

當業務復雜度較高，研發人數較多，服務依賴關系較復雜的時候，就沒這么簡單了。

問題一：調用方很痛，容量變化的是你，憑啥修改配置重啟的是我?這是一個典型的“反向依賴”架構設計，上下游通過配置耦合，不合理。

問題二：服務方很痛，ta不知道有多少個上游調用了自己，往往只能通過以下方式來定位上游：

• 群里吼

• 發郵件詢問

• 通過連接找到ip，通過ip問運維，找到機器負責人，再通過機器負責人找到對應調用服務

畫外音：是不是似曾相識?

不管哪種方式，都很有可能遺漏，導致ip1一直有流量難以下線，ip4/ip5的流量難以均勻遷移過來。該如何優化呢?

中期：“全局配置”架構

架構的升級并不是一步到位的，先來用最低的成本來解決上述“修改配置重啟”的問題一。

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

• 運維層面制定規范，新建全局配置文件，例如/opt/global.conf;畫外音：如果配置較多，注意做好配置的垂直拆分。

• 對于服務方，如果是通用的服務，集群信息配置在global.conf里;

• 對于調用方，調用方禁止配置私藏，必須從global.conf里讀取通用下游配置;

全局配置有什么好處呢?

• 如果下游容量變化，只需要修改一處配置global.conf，而不需要各個上游修改;

• 調用方下一次重啟的時候，自動遷移到擴容后的集群上來了;

• 修改成本非常小，讀取配置文件目錄變了而已;

全局配置有什么不足呢?

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

有沒有方面實現自動流量遷移呢?

答案是肯定的，只需要引入兩個并不復雜的組件，就能實現調用方的流量自動遷移：

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

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

畫外音：用鎖來互斥，很容易實現。

引入了這兩個組件之后：

• 一旦全局配置文件變化，文件監控組件實施回調;

• 如果動態連接池組件發現配置中減少了一些節點，就動態的將對應連接銷毀，如果增加了一些節點，就動態建立連接，自動完成下游節點的增容與縮容;

終版：“配置中心”架構

“全局配置”架構是一個能夠快速落地的，解決“修改配置重啟”問題的方案，但它仍然解決不了，服務提供方“不知道有多少個上游調用了自己”這個問題。

如果不知道多少上游調用了自己：

• “按照調用方限流”

• “繪制全局架構依賴圖”

等這類需求便難以實現，怎么辦?

“配置中心”架構能夠完美解決

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

• 整個配置中心子系統由zk、conf-center服務，DB配置存儲與，conf-web配置后臺組成;

• 所有下游服務的配置，通過后臺設置在配置中心里;

• 所有上游需要拉取配置，需要去配置中心注冊，拉取下游服務配置信息(ip1/ip2/ip3);

當下游服務需要擴容縮容時：

• conf-web配置后臺進行設置，新增ip4/ip5，減少ip1;

• conf-center服務將變更的配置推送給已經注冊關注相關配置的調用方;

• 結合動態連接池組件，完成自動的擴容與縮容;

“配置中心”架構有什么好處呢?

• 調用方不需要再重啟;

• 服務方從配置中心中很清楚的知道上游依賴關系，從而實施按照調用方限流;

• 很容易從配置中心得到全局架構依賴關系;

痛點一、痛點二同時解決。

“配置中心”架構有什么不足呢?

• 一來，系統復雜度相對較高;

• 二來，對配置中心的可靠性要求較高，一處掛全局掛。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“互聯網架構中為什么需要配置中心”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!