問題的根源

  一個專案採用Eureka Client的方式跟服務方互動，之前執行好好的，直到運維停機維護，結果就是調不通服務，彷彿整個服務端掛了。服務端是三臺伺服器組成的叢集，客戶端通過Ribbon負載均衡呼叫，運維是逐個停機維護，不會一下子關閉所有的伺服器，不應該出現所有服務不可用。查詢問題半天，最後發現是Eureka叢集地址寫錯了，而且從進入生產環境的第一天地址就是錯的。

正確的地址是

eureka.client.serviceUrl.defaultZone=http://ip1:11111/eureka/,http://ip2:11111/eureka/,http://ip3:11111/eureka
 
/

呼叫方配置成了

eureka.client.serviceUrl.defaultZone=http://ip1:11111/eureka/,http://ip2:22222/eureka/,http://ip3:33333/eureka/

後面兩臺伺服器的埠都配置錯了，由於平常通過Ribbon負載均衡機制把請求路由到能夠調通的服務上，一時沒發現問題。直到前面那臺服務停機維護，對客戶端來說可用的服務沒了。 隨著配置的增多，更多相似的問題暴露出來，運維、開發人員錯得一塌糊塗比如把ActiveMq叢集地址配置成：

tcp://ip1::61616,tcp://ip2:61616,tcp://ip3:61616

地址裡面多了個冒號，也是平常負載均衡作用下沒問題，一旦後面兩臺服務掛了，服務就不通了。 這讓我想起一個笑話，把原文摘抄在此，形象地展現了資訊在傳遞過程中如何往奇怪的方向發展。

據說，一次部隊的命令傳遞是這樣的：
營長對值班軍官：明晚大約8點鐘左右，哈雷彗星將可能在這個地區看到，這種彗星每隔76年才能看見一次。命令所有士兵著野戰服在操場上集合，我將向他們解釋這一罕見的現象。如果下雨的話，就在禮堂集合，我為他們放一部有關彗星的影片。

值班軍官對連長：根據營長的命令，明晚８點哈雷彗星將在操場上空出現。如果下雨的話，就讓士兵穿著野戰服列隊前往禮堂，這一罕見的現象將在那裡出現。

連長對排長：根據營長的命令，明晚8點，非凡的哈雷彗星將身穿野戰服在禮堂中出現。如果操場上下雨，營長將下達另一個命令，這種命令每隔76年才會出現一次。

排長對班長：明晚8點，營長將帶著哈雷彗星在禮堂中出現，這是每隔76年才有的事。如果下雨的話，營長將命令彗星穿上野戰服到操場上去。

班長對士兵：在明晚8點下雨的時候，著名的76歲哈雷將軍將在營長的陪同下身著野戰服，開著他那彗星牌汽車，經過操場前往禮堂。
 

首先這種(ip1:port1,ip2:port1,ip3:port1)地址+埠+英文逗號分隔的形式並不符合人的閱讀習慣，其次運維跟開發之間貼上來貼上去，難免出錯。現在是三臺服務，試想後續是三十臺服務，只怕誰看了都頭大。

解決方法

  所有呼叫方不再維護叢集地址，統一由公司內部框架封裝，公司內部框架再從分散式配置中心獲取叢集地址，叢集地址由專人維護。Spring Cloud已經提供了分散式配置中心元件Spring Cloud Config，但我們使用了攜程開源的分散式配置中心 Apollo（阿波羅）。集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置管理場景。