SpringCloud服務的平滑上下線

吐槽

之前都是手擼RPC，最近接觸SpringCloud，深感痛心。主要有如下幾點：

1）代碼量巨大，找BUG時間長，超級複雜的設計

2）版本管理混亂，常常出現莫名其妙的配置錯誤（因此2.0是打死不敢上生產啊）

3）Netflix公司的有些代碼，實在是讓人費解，根本就不考慮擴展性

4）生態鏈龐大，學習成本大

建議準備上微服務的同窗，固定下一個版本，不要隨意更新或降級。拿tomcat的basedir來講，1.5.8到1.5.13到1.5.16版本是換來換去，不當心點會出事故的

SpringCloud服務的平滑上下線 如上，basedir先是從.換到file:.，又從file:.換成.，連兼容代碼都木有。有木有想打死工程師？

前言

今天主要談的話題，是平滑的上下線功能。所謂平滑，指的是發版無感知，不至於等到夜深人靜的時候偷偷去搞。某些請求時間能夠長點，但不能失敗，尤爲是對支付來講，想花錢花不出去是很讓人苦惱的；花了錢買不到東西是很讓人惱火的。總體來講，SpringCloud功能齊全，通過一段時間的踩坑後使用起來仍是很是舒服的。

咱們的微服務，大致集成了如下內容。

嗯，一個龐大的生態

問題

那麼問題來了，SpringCloud到註冊中心的註冊是經過Rest接口調用的。它不能像ZooKeeper那樣，有問題節點反饋及時生效。也不能像Redis那麼快的去輪訓，太嬌貴怕輪壞了。以下圖：

有三個要求：1）ServiceA下線一臺實例後，Zuul網關的調用不能失敗 2）ServiceB下線一臺實例後，ServiceA的Feign調用不能失敗 3）服務上線下線，Eureka服務可以快速感知

說白了就一件事，怎樣儘可能縮短服務下線後Zuul和其餘被依賴服務的發現時間，並在這段時間內保證請求不失敗。

解決時間問題

影響因子

1 Eureka的兩層緩存問題 (這是什麼鬼）

調用者服務從Eureka拉列表的輪訓間隔

Ribbon緩存

解決方式

禁用Eureka的ReadOnlyMap緩存 (Eureka端)

啓用主動失效，而且每次主動失效檢測間隔爲3s (Eureka端)

像eureka.server.responseCacheUpdateInvervalMs和eureka.server.responseCacheAutoExpirationInSeconds在啓用了主動失效後其實沒什麼用了。默認的180s真夠把人給急瘋的。

服務過時時間 （服務提供方）

服務刷新時間配置，每隔這個時間會主動心跳一次 (服務提供方）

默認30s

拉服務列表時間間隔 （客戶端）

ribbon居然也有緩存，默認30s

這些超時時間相互影響，居然三個地方都須要配置，一不當心就會出現服務不下線，服務不上線的囧境。不得不說SpringCloud的這套默認參數簡直就是在搞笑。

重試

那麼一臺服務器下線，最長的不可用時間是多少呢？（即請求會落到下線的服務器上，請求失敗）。趕的巧的話，這個基本時間就是eureka.client.registryFetchIntervalSeconds+ribbon.ServerListRefreshInterval,大約是8秒的時間。若是算上服務端主動失效的時間，這個時間會增長到11秒。

若是你只有兩個實例，極端狀況下服務上線的發現時間也須要11秒，那就是22秒的時間。

理想狀況下，在這11秒之間，請求是失敗的。加入你的QPS是1000，部署了四個節點，那麼在11秒中失敗的請求數量會是 1000 / 4 * 11 = 2750，這是不可接受的。因此咱們要引入重試機制。

SpringCloud引入重試仍是比較簡單的。但不是配置一下就能夠的，既然用了重試，那麼就還須要控制超時。能夠按照如下的步驟：

引入pom （千萬別忘了哦)

加入配置

發佈系統

OK,機制已經解釋清楚，可是實踐起來仍是很繁雜的，讓人焦躁。好比有一個服務有兩個實例，我要一臺一臺的去發佈，在發佈第二臺以前，起碼要等上11秒。若是手速太快，那就是災難。因此一個配套的發佈系統是必要的。

首先能夠經過rest請求去請求Eureka，主動去隔離一臺實例，多了這一步，能夠減小至少3秒服務不可用的時間（仍是比較划算的）。

而後經過打包工具打包，推包。依次上線替換。

市面上沒有這樣的持續集成哦你工具，那麼發佈系統就須要定製，這也是一部分工做量。

到此，僅僅是解決了SpringCloud微服務平滑上下線的功能，至於灰度，又是另一個話題了。有條件的公司選擇自研仍是很明智的，不至於將功能拉低到如此的水平。

不過大致不用擔憂，你的公司能不能活下去，仍是一個未知數。Netflix都忍了，在作的各位能比它強大麼？