建站
咨詢
售后
建站咨詢
新聞中心
配置中心是互聯(lián)網(wǎng)架構(gòu)體系中很重要的一塊，但為什么會有配置中心，是不是一開始就要有配置中心，它究竟解決什么問題，這是今天要討論的問題。
在柳河等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都做網(wǎng)站、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需求定制設(shè)計,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),營銷型網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站制作,柳河網(wǎng)站建設(shè)費用合理。
隨著互聯(lián)網(wǎng)業(yè)務(wù)的越來越復(fù)雜，用戶量與流量越來越大，“服務(wù)化分層”是架構(gòu)演進的必由之路。
如上圖，站點應(yīng)用會調(diào)用服務(wù)，上游服務(wù)調(diào)用底層服務(wù)，依賴關(guān)系會變得非常復(fù)雜。
對于同一個服務(wù)：
(1)它往往有多個上游調(diào)用;
(2)為了保證高可用，它往往是若干個節(jié)點組成的集群提供服務(wù);
如上圖，用戶中心服務(wù)user-service有三個節(jié)點，ip1/ip2/ip3對上游提供服務(wù)，任何一個節(jié)點當機，都不影響服務(wù)的可用性。
那么問題來了：
- 調(diào)用方如何維護下游服務(wù)集群配置?
- 當服務(wù)集群增減節(jié)點時，調(diào)用方是否有感知?
初期：“配置私藏”架構(gòu)
“配置私藏”是配置的最初級階段，上游調(diào)用下游，每個上游都有一個專屬的私有配置文件，記錄被調(diào)用下游的每個節(jié)點配置信息。
如上圖：
- 用戶中心user-service有ip1/ip2/ip3三個節(jié)點;
- service1調(diào)用了用戶中心，它有一個專屬配置文件s1.conf，里面配置了us的集群是ip1/ip2/ip3;
- service2也調(diào)用了用戶中心，同理有個配置文件s2.conf，記錄了us集群是ip1/ip2/ip3;
- web2也調(diào)用了用戶中心，同理w2.conf，配置了us集群是ip1/ip2/ip3;
畫外音：是不是很熟悉?絕大部分公司，初期都是這么玩的。
“配置私藏”架構(gòu)的缺點是什么呢?
來看一個容量變化的需求：
- 運維檢測出ip1節(jié)點的硬盤性能下降，通知研發(fā)未來要將ip1節(jié)點下線;
- 由于5月8日要做大促運營活動，未來流量會激增，研發(fā)準備增加兩個節(jié)點ip4和ip5;
此時要怎么做呢?
需要用戶中心的負責人通知所有上游調(diào)用者，修改“私藏”的配置，并重啟上游，連接到新的集群上去。在ip1上沒有流量之后，通知運維將ip1節(jié)點下線，以完成整個縮容擴容過程。
這種方案存在什么問題呢?
當業(yè)務(wù)復(fù)雜度較高，研發(fā)人數(shù)較多，服務(wù)依賴關(guān)系較復(fù)雜的時候，就沒這么簡單了。
問題一：調(diào)用方很痛，容量變化的是你，憑啥修改配置重啟的是我?這是一個典型的“反向依賴”架構(gòu)設(shè)計，上下游通過配置耦合，不合理。
問題二：服務(wù)方很痛，ta不知道有多少個上游調(diào)用了自己，往往只能通過以下方式來定位上游：
- 群里吼
- 發(fā)郵件詢問
- 通過連接找到ip，通過ip問運維，找到機器負責人，再通過機器負責人找到對應(yīng)調(diào)用服務(wù)
畫外音：是不是似曾相識?
不管哪種方式，都很有可能遺漏，導(dǎo)致ip1一直有流量難以下線，ip4/ip5的流量難以均勻遷移過來。該如何優(yōu)化呢?
中期：“全局配置”架構(gòu)
架構(gòu)的升級并不是一步到位的，先來用最低的成本來解決上述“修改配置重啟”的問題一。
“全局配置”架構(gòu)：對于通用的服務(wù)，建立全局配置文件，消除配置私藏：
- 運維層面制定規(guī)范，新建全局配置文件，例如/opt/global.conf;畫外音：如果配置較多，注意做好配置的垂直拆分。
- 對于服務(wù)方，如果是通用的服務(wù)，集群信息配置在global.conf里;
- 對于調(diào)用方，調(diào)用方禁止配置私藏，必須從global.conf里讀取通用下游配置;
全局配置有什么好處呢?
- 如果下游容量變化，只需要修改一處配置global.conf，而不需要各個上游修改;
- 調(diào)用方下一次重啟的時候，自動遷移到擴容后的集群上來了;
- 修改成本非常小，讀取配置文件目錄變了而已;
全局配置有什么不足呢?
如果調(diào)用方一直不重啟，就沒有辦法將流量遷移到新集群上去了。
有沒有方面實現(xiàn)自動流量遷移呢?
答案是肯定的，只需要引入兩個并不復(fù)雜的組件，就能實現(xiàn)調(diào)用方的流量自動遷移：
- 文件監(jiān)控組件FileMonitor：作用是監(jiān)控文件的變化，起一個timer，定期監(jiān)控文件的ModifyTime或者md5就能輕松實現(xiàn)，當文件變化后，實施回調(diào)。
- 動態(tài)連接池組件DynamicConnectionPool：“連接池組件”是RPC-client中的一個子組件，用來維護與多個RPC-server節(jié)點之間的連接。所謂“動態(tài)連接池”，是指連接池中的連接可以動態(tài)增加和減少。
畫外音：用鎖來互斥，很容易實現(xiàn)。
引入了這兩個組件之后：
- 一旦全局配置文件變化，文件監(jiān)控組件實施回調(diào);
- 如果動態(tài)連接池組件發(fā)現(xiàn)配置中減少了一些節(jié)點，就動態(tài)的將對應(yīng)連接銷毀，如果增加了一些節(jié)點，就動態(tài)建立連接，自動完成下游節(jié)點的增容與縮容;
終版：“配置中心”架構(gòu)
“全局配置”架構(gòu)是一個能夠快速落地的，解決“修改配置重啟”問題的方案，但它仍然解決不了，服務(wù)提供方“不知道有多少個上游調(diào)用了自己”這個問題。
如果不知道多少上游調(diào)用了自己：
- “按照調(diào)用方限流”
- “繪制全局架構(gòu)依賴圖”
等這類需求便難以實現(xiàn)，怎么辦?
“配置中心”架構(gòu)能夠完美解決
對比“全局配置”與“配置中心”的架構(gòu)圖，會發(fā)現(xiàn)配置由靜態(tài)的文件升級為動態(tài)的服務(wù)：
- 整個配置中心子系統(tǒng)由zk、conf-center服務(wù)，DB配置存儲與，conf-web配置后臺組成;
- 所有下游服務(wù)的配置，通過后臺設(shè)置在配置中心里;
- 所有上游需要拉取配置，需要去配置中心注冊，拉取下游服務(wù)配置信息(ip1/ip2/ip3);
當下游服務(wù)需要擴容縮容時：
- conf-web配置后臺進行設(shè)置，新增ip4/ip5，減少ip1;
- conf-center服務(wù)將變更的配置推送給已經(jīng)注冊關(guān)注相關(guān)配置的調(diào)用方;
- 結(jié)合動態(tài)連接池組件，完成自動的擴容與縮容;
“配置中心”架構(gòu)有什么好處呢?
- 調(diào)用方不需要再重啟;
- 服務(wù)方從配置中心中很清楚的知道上游依賴關(guān)系，從而實施按照調(diào)用方限流;
- 很容易從配置中心得到全局架構(gòu)依賴關(guān)系;
痛點一、痛點二同時解決。
“配置中心”架構(gòu)有什么不足呢?
- 一來，系統(tǒng)復(fù)雜度相對較高;
- 二來，對配置中心的可靠性要求較高，一處掛全局掛。
總結(jié)
究竟要解決什么痛點?
- 上游痛：擴容的是下游，改配置重啟的是上游;
- 下游痛：不知道誰依賴于自己;總之，難以實施服務(wù)治理。
究竟如何解決上述痛點?
- “配置私藏”架構(gòu);
- “全局配置文件”架構(gòu);
- “配置中心”架構(gòu);
知其然，知其所以然。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
當前標題：互聯(lián)網(wǎng)架構(gòu)，究竟為什么需要配置中心？
文章網(wǎng)址：http://m.fisionsoft.com.cn/article/dhjhcje.html
