Eureka集群的那些坑

今天遇到乙個eureka集群的乙個坑。

問題現場類似是這樣的：兩台eureka組成的服務註冊中心集群，兩台服務提供方server1、server2，兩個服務呼叫方client1、client2。

正常的情況下：

client1和client2通過服務中心獲取的服務提供方的註冊的元資料資訊，然後本地快取呼叫server2、server1的服務api是沒問題的。呼叫server的api服務時採用的feignclient通過eureka註冊中心獲取服務資訊呼叫。

以下簡寫成client服務、server服務、eureka服務：

但今天遇到的情況是client呼叫server時，返回結果不穩定，以下是排查過程。

1、習慣性的先檢視client方日誌，發現介面呼叫有一定的概率失敗，但是並沒有拋異常，而僅僅是response返回null。

2、檢視server方日誌，並沒有發現異常，也沒有發現response為null的情況，並且server方的本機上訪問介面都是響應正常。

3、通過分析兩方日誌，猜想client端的請求可能沒有打到server方。

4、分析整個呼叫流程，只差eureka服務這乙個環節沒有排查了，然後檢視eureka服務上的server方註冊資訊是否正常。

5、發現兩台eureka服務，有一台tomcat假死了，至此猜想是假死的eureka服務假死所致。

6、驗證猜想，重啟假死的eureka的tomcat服務，問題驗證解決。

那麼問題來了，

1、為什麼一台eureka假死了，沒有拋異常，只在response中返回個null?

2、eureka集群的一台例項假死，為什麼會導致服務間呼叫不穩定？

3、eureka服務跑了大半年，怎麼突然一台例項假死了？

接下來，我們來**這三個問題。

1、為什麼一台eureka假死了，沒有拋異常，只在response中返回個null?

這個問題經查，eureka假死，導致呼叫方呼叫服務方時，觸發了hystrix熔斷器,專案實現的熔斷降級介面直接在熔斷自動降級時返回null，這就回答了第乙個問題。

2、eureka集群的一台例項假死，為什麼會導致服務間呼叫不穩定？

這個得翻看一下eureka的機制原始碼了，猜想feign端在本地快取90s後去重新整理本地服務列表資訊時，卡在呼叫eureka服務上了（此時恰好通過假死的eureka服務重新整理），從而服務不可用。

3、eureka服務跑了大半年，怎麼突然一台例項假死了？

生產環境有多台虛擬機器eureka伺服器，配置都一樣，其它的伺服器沒有出過問題，只有一台eureka服務會有類似週期性假死的問題，由於筆者生產環境許可權所限，只能猜想可能是宿主機的原因，估計換台機器可能就沒問題了，待驗證。

還有幾個等思考的問題，之後待續。。。。。。。。。。。。。

1、服務提供方配置了多個eureka 位址，是服務註冊時，是呼叫註冊到哪個上？ ---> 猜想優化使用第乙個，那第二個是何時用到的（除了第乙個宕機的情況）

2、feign介面通過eureka呼叫服務時，是不需要自己專案也註冊到eureka上的，怎麼處理？

3、服務呼叫方配置了多個eureka 位址，是獲取服務列表呼叫時，是呼叫註冊到哪個上？ --> 猜想優化使用第乙個，那第二個是何時用到的（除了第乙個宕機的情況）

另外，昨天查eureka假死日誌時，日誌打的異常堆疊如下：

這個其實就是找不到報錯了找不到相應的url所致，可以設定com.ibm.ws.webcontainer.invokeflushafterservice為false，關閉此日誌。

網上也有說可以增加如下依賴解決關閉日誌，沒試過，此處只記錄一下。

org.springframework.boot

spring-boot-starter-thymeleaf

$net.sourceforge.nekohtml

nekohtml

1.9.22