吐槽

以前都是手?jǐn)]RPC，最近接觸SpringCloud，深感痛心。主要有以下幾點(diǎn)：

1）代碼量巨大，找BUG時間長，超級復(fù)雜的設(shè)計

2）版本管理混亂，經(jīng)常出現(xiàn)莫名其妙的配置錯誤（所以2.0是打死不敢上生產(chǎn)?。?/p>

3）Netflix公司的有些代碼，實(shí)在是讓人費(fèi)解，根本就不考慮擴(kuò)展性

4）生態(tài)鏈龐大，學(xué)習(xí)成本大

建議準(zhǔn)備上微服務(wù)的同學(xué)，固定下一個版本，不要隨意更新或降級。拿tomcat的basedir來說，1.5.8到1.5.13到1.5.16版本是換來換去，不小心點(diǎn)會出事故的。

server:
 port: 21004
 context-path: /
 tomcat:
  basedir: file:.

如上，basedir先是從.換到file:.，又從file:.換成.，連兼容代碼都木有。有木有想打死工程師？

前言

今天主要談的話題，是平滑的上下線功能。所謂平滑，指的是發(fā)版無感知，不至于等到夜深人靜的時候偷偷去搞。某些請求時間可以長點(diǎn)，但不能失敗，尤其是對支付來說，想花錢花不出去是很讓人苦惱的；花了錢買不到東西是很讓人惱火的。整體來說，SpringCloud功能齊全，經(jīng)過一段時間的踩坑后使用起來還是非常舒服的。

我們的微服務(wù)，大體集成了以下內(nèi)容。

嗯，一個龐大的生態(tài)

問題

那么問題來了，SpringCloud到注冊中心的注冊是通過Rest接口調(diào)用的。它不能像ZooKeeper那樣，有問題節(jié)點(diǎn)反饋及時生效。也不能像Redis那么快的去輪訓(xùn)，太嬌貴怕輪壞了。如下圖：

有三個要求：

1）ServiceA下線一臺實(shí)例后，Zuul網(wǎng)關(guān)的調(diào)用不能失敗 2）ServiceB下線一臺實(shí)例后，ServiceA的Feign調(diào)用不能失敗 3）服務(wù)上線下線，Eureka服務(wù)能夠快速感知

說白了就一件事，怎樣盡量縮短服務(wù)下線后Zuul和其他被依賴服務(wù)的發(fā)現(xiàn)時間，并在這段時間內(nèi)保證請求不失敗。

解決時間問題

影響因子

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

EurekaServer默認(rèn)有兩個緩存，一個是ReadWriteMap，另一個是ReadOnlyMap。有服務(wù)提供者注冊服務(wù)或者維持心跳時時，會修改ReadWriteMap。當(dāng)有服務(wù)調(diào)用者查詢服務(wù)實(shí)例列表時，默認(rèn)會從ReadOnlyMap讀?。ㄟ@個在原生Eureka可以配置，SpringCloud Eureka中不能配置，一定會啟用ReadOnlyMap讀?。@樣可以減少ReadWriteMap讀寫鎖的爭用，增大吞吐量。EurekaServer定時把數(shù)據(jù)從ReadWriteMap更新到ReadOnlyMap中

2) 心跳時間

服務(wù)提供者注冊服務(wù)后，會定時心跳。這個根據(jù)服務(wù)提供者的Eureka配置中的服務(wù)刷新時間決定。還有個配置是服務(wù)過期時間，這個配置在服務(wù)提供者配置但是在EurekaServer使用了，但是默認(rèn)配置EurekaServer不會啟用這個字段。需要配置好EurekaServer的掃描失效時間，才會啟用EurekaServer的主動失效機(jī)制。在這個機(jī)制啟用下：每個服務(wù)提供者會發(fā)送自己服務(wù)過期時間上去，EurekaServer會定時檢查每個服務(wù)過期時間和上次心跳時間，如果在過期時間內(nèi)沒有收到過任何一次心跳，同時沒有處于保護(hù)模式下，則會將這個實(shí)例從ReadWriteMap中去掉

3）調(diào)用者服務(wù)從Eureka拉列表的輪訓(xùn)間隔

4) Ribbon緩存

解決方式

1) 禁用Eureka的ReadOnlyMap緩存 (Eureka端)

eureka.server.use-read-only-response-cache: false

2) 啟用主動失效，并且每次主動失效檢測間隔為3s (Eureka端)

eureka.server.eviction-interval-timer-in-ms: 3000

像eureka.server.responseCacheUpdateInvervalMs和eureka.server.responseCacheAutoExpirationInSeconds在啟用了主動失效后其實(shí)沒什么用了。默認(rèn)的180s真夠把人給急瘋的。

3) 服務(wù)過期時間 （服務(wù)提供方）

eureka.instance.lease-expiration-duration-in-seconds: 15

超過這個時間沒有接收到心跳EurekaServer就會將這個實(shí)例剔除。EurekaServer一定要設(shè)置eureka.server.eviction-interval-timer-in-ms否則這個配置無效，這個配置一般為服務(wù)刷新時間配置的三倍。默認(rèn)90s！

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

eureka.instance.lease-renewal-interval-in-seconds: 5

默認(rèn)30s

5) 拉服務(wù)列表時間間隔 （客戶端）

eureka.client.registryFetchIntervalSeconds: 5

默認(rèn)30s

6) ribbon刷新時間 （客戶端）

ribbon.ServerListRefreshInterval: 5000

ribbon竟然也有緩存，默認(rèn)30s

這些超時時間相互影響，竟然三個地方都需要配置，一不小心就會出現(xiàn)服務(wù)不下線，服務(wù)不上線的囧境。不得不說SpringCloud的這套默認(rèn)參數(shù)簡直就是在搞笑。

重試

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

如果你只有兩個實(shí)例，極端情況下服務(wù)上線的發(fā)現(xiàn)時間也需要11秒，那就是22秒的時間。

理想情況下，在這11秒之間，請求是失敗的。加入你的QPS是1000，部署了四個節(jié)點(diǎn)，那么在11秒中失敗的請求數(shù)量會是 1000 / 4 * 11 = 2750，這是不可接受的。所以我們要引入重試機(jī)制。

SpringCloud引入重試還是比較簡單的。但不是配置一下就可以的，既然用了重試，那么就還需要控制超時?？梢园凑找韵碌牟襟E：

引入pom （千萬別忘了哦)

<dependency>
  <groupId>org.springframework.retry</groupId>
  <artifactId>spring-retry</artifactId>
</dependency>

加入配置

ribbon.OkToRetryOnAllOperations:true 
#(是否所有操作都重試，若false則僅get請求重試)
ribbon.MaxAutoRetriesNextServer:3 
#(重試負(fù)載均衡其他實(shí)例最大重試次數(shù),不含首次實(shí)例)
ribbon.MaxAutoRetries:1
#(同一實(shí)例最大重試次數(shù),不含首次調(diào)用)
ribbon.ReadTimeout:30000
ribbon.ConnectTimeout:3000
ribbon.retryableStatusCodes:404,500,503
#（那些狀態(tài)進(jìn)行重試）
spring.cloud.loadbalancer.retry.enable:true
# (重試開關(guān))

發(fā)布系統(tǒng)

OK,機(jī)制已經(jīng)解釋清楚，但是實(shí)踐起來還是很繁雜的，讓人焦躁。比如有一個服務(wù)有兩個實(shí)例，我要一臺一臺的去發(fā)布，在發(fā)布第二臺之前，起碼要等上11秒。如果手速太快，那就是災(zāi)難。所以一個配套的發(fā)布系統(tǒng)是必要的。

首先可以通過rest請求去請求Eureka，主動去隔離一臺實(shí)例，多了這一步，可以減少至少3秒服務(wù)不可用的時間（還是比較劃算的）。

然后通過打包工具打包，推包。依次上線替換。

市面上沒有這樣的持續(xù)集成哦你工具，那么發(fā)布系統(tǒng)就需要定制，這也是一部分工作量。

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

不過大體不用擔(dān)心，你的公司能不能活下去，還是一個未知數(shù)。Netflix都忍了，在做的各位能比它強(qiáng)大么？

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論