SpringCloud常見問題

1.關於自我保護機制                                                                                                                     什麼是自我保護機制：  這篇介紹的很好，簡單說就是每一個服務實例啓動後都會註冊到註冊中心Eureka中，而且以心跳的方式告訴註冊中心實例還活着，若是註冊中心在較短期內丟失了大量心跳，Eureka會認爲多是因爲通訊故障形成的，這種狀況Eureka認爲不該該刪除實例，因而就開啓自我保護機制                                                                                                       判斷是否開啓自我保護機制，主要在於計算每分鐘續約數的，getNumOfRenewInLastMin()這個獲取的是每分鐘的續約數量（每一個客戶端來續約的時候，都是會更新這個值的，每分鐘重置一次，有線程去跑的）， 若是每分鐘的續約數量>最小續約數（常量），則不須要開啓自我保護機制， 若是是小於，那麼就是須要開啓， 因此當返回false的時候，就須要開啓自我保護機制了。

    PS： 其實說白了，自我保護機制，就是在定時任務執行以前，判斷每分鐘的續約數量，而後決定是否繼續執行下去。所以Eureka Server的過時時間（默認60s） ,客戶端的續約時間（默認30s） , 這個配置最好不要更改，若是更改的話就會打破自我保護機制的規則。

解除

    當服務的網絡分區解除以後，客戶端可以和服務進行交互時，在續約的時候，更新每分鐘的續約數，當每分鐘的續約數大於最大續約數85%時，則自動解除自我保護機制

2.推測：Eureka server定時去清理無效節點，首先判斷自我保護機制有沒有設置爲false,若是是直接去判斷哪些是無效節點，而後剔除。判斷的依據是距離上一次收到心跳的時間間隔是否大於某個值（在客戶端配置），是就剔除。若是自我保護機制沒有設置，則系統在定時任務觸發時會判斷每分鐘續約數量是否大於最大續約數的85%,若是大於就不開啓，若是小於就開啓（至關於短期內丟失了大量續約，自我保護機制開啓）

3.客戶端配置的心跳頻率要比過時時間高

4.獲取服務                                                                                                                                消費者服務啓動時，會發送一個Rest請求給服務註冊中心，來獲取上面註冊的服務清單。同時該緩存清單默認會每隔30秒更新一次。

5.用Http Status Code傳遞Server的狀態信息。好比最經常使用的 200 表示成功，500 表示Server內部錯誤，403表示Bad Request等。（反例：傳統web開發返回的狀態碼一概都是200，其實不可取。

6.ribbon.ReadTimeout， ribbon.SocketTimeout這兩個就是ribbon超時時間設置，還有zuul.host.connect-timeout-millis， zuul.host.socket-timeout-millis這兩個配置，這兩個和上面的ribbon都是配超時的。區別在於，若是路由方式是serviceId的方式，那麼ribbon的生效，若是是url的方式，則zuul.host開頭的生效。（此處重要！使用serviceId路由和url路由是不同的超時策略）

7.熔斷超時是這樣的：

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 60000

default表明默認，若是你想爲某個特定的service配熔斷超時策略，可將default換爲服務名

8.ribbon.connectTimeot是請求鏈接的時間，基本上都是很短的，因此這個請求的時間能夠忽略不記，ribbon.readTimeout=5000，所耗費的時間基本上都是在請求的處理時間上。因此計算的公式是（1+maxAutoRetries+maxAutoRetriesNestServer)*5000,該計算公式會得出一個值，hystrix的超時時間最好要大於這個值，若是小於這個值的話，那麼配置重試就沒有意義了，由於當系統還在進行重試的時候，就把這一次的請求熔斷了

9.假設服務提供者響應很是緩慢，那麼消費者對提供者的請求線程就會被等待，直到服務返回，在高併發高負載的場景下，若是不作任何處理，這種問題頗有可能形成全部處理用戶請求的線程的資源耗竭，而不能響應用戶進一步請求。

    若是服務消費者又是另外服務的提供者，那麼有可能產生級聯反應，致使其它的下一級服務消費者不可用，最終產生雪崩效應。

    當依賴的服務不可用的時候，或者由於網絡問題，響應時間會變得很長（幾十秒）。而一般狀況下，一次遠程調用對應了一個線程或者進程，若是響應太慢，那這個線程、進程就會得不到釋放。而線程和進程是系統資源，若是大量線程、進程都不被釋放，越積越多，服務資源就會被耗盡。因此咱們必須設置超時請求

10.註冊中心須要集羣，1臺主，其他副，只有主註冊中心有服務註冊，主掛掉後有同步機制同步到其它註冊中心，中心只是拿地址，本地調用zuul網關服務既可做爲提供者也可做爲消費者

11.服務隔離就是對不一樣方法使用不一樣的線程池，這樣對A方法的高併發不會影響到B方法 nginx：c語言開發 zuul: java語言 

12.Eureka還提供了客戶端緩存的機制，即便全部的Eureka Server都掛掉，客戶端仍能夠利用緩存中的信息調用服務節點的服務 

13.get和post的表單請求是能夠獲取到參數的，可是post 的原生字符串請求，也就是application/json類型的請求是獲取不到的，你須要從流中讀取，就是request中getInputStream獲取，可是流只能獲取一次，若是你在過濾器中讀取了流，spring控制器裏就接受不到參數了，固然你能夠從新包裝下request，把參數從新寫回包裝後的request中

14.zuul中的path不能和serviceId中的requestmapping路徑一致

15.相似SpringCloud微服務適合敏捷開發，restful風格，適合大公司，人多的狀況