原創文章，轉載請標注。http://www.rzrgm.cn/boycelee/p/17967590

聲明

原創文章，轉載請標注。http://www.rzrgm.cn/boycelee/p/17967590
《碼頭工人的一千零一夜》是一位專注于技術干貨分享的博主，追隨博主的文章，你將深入了解業界最新的技術趨勢，以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者，都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。

配置中心系列文章

《【架構師視角系列】風控場景下的配置中心設計思考》 http://www.rzrgm.cn/boycelee/p/18355942
《【架構師視角系列】Apollo配置中心之架構設計（一）》http://www.rzrgm.cn/boycelee/p/17967590
《【架構師視角系列】Apollo配置中心之Client端（二）》http://www.rzrgm.cn/boycelee/p/17978027
《【架構師視角系列】Apollo配置中心之Server端（ConfigSevice）（三）》http://www.rzrgm.cn/boycelee/p/18005318
《【架構師視角系列】QConfig配置中心系列之架構設計（一）》http://www.rzrgm.cn/boycelee/p/18013653
《【架構師視角系列】QConfig配置中心系列之Client端（二）》http://www.rzrgm.cn/boycelee/p/18033286

一、什么是配置中心？

配置中心是集中管理和動態更新應用配置信息的服務，服務能夠在不停機的情況下新增或修改配置信息，具有以下關鍵特點：

（1）集中管理。配置中心集中存儲服務所需要的各類配置信息；

（2）動態變更。應用服務不需要重啟就可以從配置中心動態獲取到最新數據；

（3）通知機制。當服務配置發生變化時，配置中心可以提供通知機制，通知應用程序關心的配置發生變化。

能夠提高系統的可維護性、靈活性和實時性。

二、傳統配置有什么問題？

傳統配置會使用本地靜態文件作為存儲介質。就存在這幾個問題：

（1）動態修改。本地靜態文件修改時必須重啟應用，無法做到動態修改；

（2）統一管理。存儲格式、存儲地點都雜亂無章，無法對配置進行統一規范和約束；

（3）即時生效。配置完成后，需要多機器部署完成，修改配置才能夠生效。無法做到及時通知、及時生效。

三、配置中心的場景

大體場景有如下這幾種：

（1）系統相關。如線程池配置信息、緩存大小、連接池大小、熔斷/限流閾值等；

（2）業務相關。如活動文案、推廣活動、積分規則、價格策略等；

（3）開關相關。A/B Test、特性開關、推送開關等；

（4）安全相關。數據庫連接信息、加密秘鑰、賬號密碼等。

四、架構設計

（1）基礎模型

（2）詳細架構

架構圖分為三層，分別是客戶端層、網絡層以及服務層。其中客戶端層包括client模塊、portal模塊，網絡層包括Load Balancer（Nginx）和Mata Server以及Eureka，服務層包括Config Service模塊和Admin Service模塊。

六、模塊介紹

客戶端層

Client

• 客戶端負責從Config Service獲取應用的配置信息；
• 監聽配置變化。當配置發生更新時，Config Service會通知Client，并出發其進行配置刷新；
• 通過ip + port的方式遠程調用Config Service，以獲取配置數據。

Portal

• 管理平臺，提供配置中心的管理功能，包括應用創建、查看、修改、發布以及回滾等功能

網絡層

NginxLB

• Client、Portal通過域名的方式訪問MetaServer，Nginx作為負載均衡器；
• Nginx將請求分發到每個Meta Server服務實例，結合Eureka可以動態地獲取到注冊中心注冊的服務實例（Config Service、Admin Service）列表。

Meta Server

• Meta Server封裝Eureka Client，通過Eureka Client獲取Config Service和Admin Service的服務信息，Client與Portal不需要關心注冊中心的服務發現問題；
• Client和Portal通過ip+port的方式訪問Client Service 與 Admin Service
• Meta Server是邏輯概念與Config Service模塊一起部署在同一實例中；
• Meta Service還提供其他注冊中心的封裝類，其中包括Consul、Nacos、Kubernetes等；

Eureka

• Eureka是用于服務注冊與服務發現的注冊中心，Config Sevice與Admin Service會定期向注冊中心上報心跳；
• Eureka與Config Service部署在一起，簡化部署和管理。
• 相對于Zookeeper其部署方式更便捷。

服務端層

Config Service

• 服務于Client模塊；
• 提供獲取配置的接口；
• 基于長輪詢，提供配置更新接口；

Admin Service

• 服務于Admin模塊；
• 提供配置管理接口；
• 提供修改、發布配置等接口。

七、思考

1、為什么NginxLB與Eureka一起使用？不使用Eureka是否可行？

（1）負載均衡（Nginx LB）。具有高可用和容錯的特性，當Apollo配置中心節點出現故障時，負載均衡器可以將流量重新路由到其他可用的節點上，從而實現系統的穩定性。

（2）服務注冊與發現（Eureka）。Eureka可以幫助配置中心實現動態的服務注冊和發現。Config Service動態注冊到Eureka中，而Client通過Eureka獲取可用節點列表。從而實現動態獲取配置中心節點變化。

（3）綜合使用Nginx負載均衡和Eureka注冊中心，可以提高配置中心的可用性和容錯性。這種架構允許系統在動態環境中靈活地處理配置中心（Config Service）節點的變化，并且確?？蛻舳耍–lient）始終能夠訪問到可用的的配置中心（Config Service）節點。

（4）不使用Eureka，只使用Nginx負載均衡是可行的。這種情況下配置中心節點（Config Service）由Nginx進行負載均衡和請求分發，不需要Eureka進行服務注冊與服務發現。優點是架構簡單，缺點是Nginx雖然可以感知到節點不可用，但其并不具備動態節點管理的能力，當新的節點加入時，Eureka能夠及時發現且自動地處理，而Nginx則需要人工干預。

2、Confg Service 、Admin Service以及Portal為什么作為獨立應用單獨部署？

（1）Confg Service和Admin Service獨立部署，是從功能解耦上考慮，Confg Service服務于Client端負責處理配置相關邏輯，而Admin Service服務于Portal管理平臺，提供接口給Portal進行使用。從產品迭代角度來分析Admin Service因為服務于Protal管理平臺其迭代頻率會高于Confg Service，分開獨立部署能夠提升開發靈活性以及降低發布風險。

（2）Admin Service和Portal獨立部署，是為了環境隔離時，Protal能夠調用不同Service提供的API接口，進行不同環境配置的統一管理。

最后

《碼頭工人的一千零一夜》是一位專注于技術干貨分享的博主，追隨博主的文章，你將深入了解業界最新的技術趨勢，以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者，都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。
懂得不多，做得太少。歡迎批評、指正。