配置中心，互聯網架構解耦利器

《小小的ip，大大的耦合》提到，由於"變動ip，致使上游重啓一大片"的不合理架構，可使用「內網域名代替內網ip」的方式解耦。

這一次，隨着流量的愈來愈大，一個服務集羣由3個節點增長到5個節點，擴容增長了兩個ip，竟然也要調用方修改配置，重啓一大片？

由於調用服務集羣配置關聯在一塊兒，致使下游服務擴容時上游須要配合重啓，是一個耦合的典型案例。

1、場景還原

user-service是一個下游底層通用服務，原集羣有3個節點：ip1, ip2, ip3。
上游service一、service二、web1等三個上游要調用user-service。

隨着業務、數據量、併發的增加，user-service慢慢扛不住了，擴容新增ip4和ip5兩個節點。

此時user-service的維護者，要通知全部的上游s1/s2/web1，讓其協助增長兩個ip節點(經過《小小的ip，大大的耦合》的描述，實際上是增長兩個內網域名)，而後重啓，以便於將流量導入到新的節點上去。

歷史老是驚人的類似，明明是下游擴容，爲什麼須要上游修改配置，重啓呢？

2、耦合如何產生的？

上游web1站點，通常有個獨有的配置文件，假設叫web1.conf，它裏面會記錄web1站點相關的配置，例如：

web1.log.path : /opt/logs/web1/
web1.connection.timeout : 2000ms
web1.thread.num : 200
…

web1調用了user-service，因此web1.conf裏確定也記錄了user-service的相關配置：

web1.user-service.ip : ip1/ip2/ip3
web1.user-service.port : 5858

在創業初期，此類配置比比皆是，無可厚非，人稱「配置私藏」。

service1和service2也都調用了這個底層的公共服務，service1.conf 和service2.conf 裏也有相似的配置：

serviceX.user-service.ip : ip1/ip2/ip3
serviceX.user-service.port : 5858

3、「配置私藏」爲什麼致使耦合？

配置私藏，它的本質是「配置數據的擴散」。

原本下游user-service配置數據只應該存在一份，但這個配置數據擴散到不一樣的上游，所私藏的配置文件裏，人手一份。

這就致使，當這個配置數據發生變化時，因此私藏這份配置的上游，都須要修改配置，以保證數據一致性。

4、如何解除「配置私藏」，由於上下游調用而產生的耦合？

答：配置中心。

如上圖，配置中心通常由若干個組件組成，其細節不是本文的重點，故不在此展開。

配置中心是一個典型的邏輯上解耦、物理上不解耦的一個架構優化工具（若是你們還有印象《MQ，互聯網架構解耦神器》提到，MQ是一個邏輯上解耦，物理上也解耦的一個架構優化工具）。

物理依賴，指物理上要創建鏈接，產生依賴：

• MQ解耦，上游和下游不會創建物理鏈接
• 配置中心解耦，上游和下游依然會創建物理鏈接
  但不少時候，當關注下游處理結果的時候，上下游不能使用MQ通信，而必須使用RPC（詳見《MQ，互聯網架構解耦神器》）。

配置中心的一些要點：

• 全部通用配置，基礎配置將由配置中心統一維護，數據只存儲一份，再也不有「配置私藏」
• 全部上游經過配置中心來訂閱下游配置
• 全部下游的配置變動，例如擴容時，經過配置中心統一修改
• • 配置中心將變動後的配置通知全部上游訂閱方
    訂閱方得知下游服務擴容或者縮容後，經過動態鏈接池，自動新增或者銷燬鏈接，實現自動擴容與縮容，大部分服務發現都是這麼作的

5、總結

A、「配置私藏」致使的耦合，本質是由一份配置數據的冗餘引發的。
B、配置中心對於「配置私藏」的上下游解耦很是有效。
C、MQ和ConfCenter是常見的互聯網架構解耦利器：

• 前者，邏輯解耦，物理解耦
• 後者，邏輯解耦，物理不解耦

你們天天收穫一點點，架構就能美好一點點。
你痛過嗎，下游擴容你被迫重啓過嗎？那幫轉下。

相關文章：MQ，互聯網架構解耦神器一分鐘實現鏈接池小小的IP，大大的耦合