配置中心，互聯網架構解耦利器
《小小的ip，大大的耦合》提到，因為"變更ip，導致上游重啟一大片"的不合理架構，可以使用“內網域名代替內網ip”的方式解耦。
這一次，隨著流量的越來越大，一個服務集群由3個節點增加到5個節點，擴容增加了兩個ip，居然也要調用方修改配置，重啟一大片?
因為調用服務集群配置關聯在一起，導致下游服務擴容時上游需要配合重啟，是一個耦合的典型案例。
一、場景還原
user-service是一個下游底層通用服務，原集群有3個節點：ip1, ip2, ip3。
上游service1、service2、web1等三個上游要調用user-service。
隨著業務、數據量、并發的增長，user-service慢慢扛不住了，擴容新增ip4和ip5兩個節點。
此時user-service的維護者，要通知所有的上游s1/s2/web1，讓其協助增加兩個ip節點(通過《小小的ip，大大的耦合》的描述，其實是增加兩個內網域名)，然后重啟，以便于將流量導入到新的節點上去。
歷史總是驚人的相似，明明是下游擴容，為何需要上游修改配置，重啟呢?
二、耦合如何產生的?
上游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
三、“配置私藏”為何導致耦合?
配置私藏，它的本質是“配置數據的擴散”。
本來下游user-service配置數據只應該存在一份，但這個配置數據擴散到不同的上游，所私藏的配置文件里，人手一份。
這就導致，當這個配置數據發生變化時，所以私藏這份配置的上游，都需要修改配置，以保證數據一致性。
四、如何解除“配置私藏”，因為上下游調用而產生的耦合?
答：配置中心。
如上圖，配置中心一般由若干個組件組成，其細節不是本文的重點，故不在此展開。
配置中心是一個典型的邏輯上解耦、物理上不解耦的一個架構優化工具(如果大家還有印象《MQ，互聯網架構解耦神器》提到，MQ是一個邏輯上解耦，物理上也解耦的一個架構優化工具)。
物理依賴，指物理上要建立連接，產生依賴：
- MQ解耦，上游和下游不會建立物理連接
- 配置中心解耦，上游和下游依然會建立物理連接
但很多時候，當關注下游處理結果的時候，上下游不能使用MQ通訊，而必須使用RPC(詳見《MQ，互聯網架構解耦神器》)。
配置中心的一些要點：
- 所有通用配置，基礎配置將由配置中心統一維護，數據只存儲一份，不再有“配置私藏”
- 所有上游通過配置中心來訂閱下游配置
- 所有下游的配置變更，例如擴容時，通過配置中心統一修改
- 配置中心將變更后的配置通知所有上游訂閱方
- 訂閱方得知下游服務擴容或者縮容后，通過動態連接池，自動新增或者銷毀連接，實現自動擴容與縮容，大部分服務發現都是這么做的
五、總結
A、“配置私藏”導致的耦合，本質是由一份配置數據的冗余引起的。
B、配置中心對于“配置私藏”的上下游解耦非常有效。
C、MQ和ConfCenter是常見的互聯網架構解耦利器：
- 前者，邏輯解耦，物理解耦
- 后者，邏輯解耦，物理不解耦
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
