今天公司的項目比較忙，遠程開會和辦公的溝通效率總是差那麼一點，爲了節約點時間，就不介紹SpringCloud了，我想只要是一名Java開發程序員，提到微服務，一定對SpringCloud的大名如雷貫耳，我們直接來看它的高頻面試題吧。
1、什麼是Spring Cloud？
Spring cloud 流應用程序啓動器是基於 Spring Boot 的 Spring 集成應用程序，提供與外部系統的集成，更專注於服務治理。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。
2、Spring Cloud和Dubbo的區別
-
Dubbo關注的領域是Spring Cloud的一個子集。Dubbo專注於服務治理，其在服務治理、灰度發佈、流量分發方面比Spring Cloud更全面。Spring Cloud覆蓋整個微服務架構領域。
-
Dubbo使用RPC調用效率高一些，Spring Cloud使用HTTP調用效率低，使用更簡單。
3、REST和RPC的區別
-
REST風格的系統交互更方便，RPC調用服務提供方和調用方式之間依賴太強。
-
REST調用系統性能較低，RPC調用效率比REST高。
-
REST的靈活性可以跨系統跨語言調用，RPC只能在同語言內調用。
-
REST可以和Swagger等工具整合，自動輸出接口API文檔。
4、SpringCloud如何實現服務的註冊和發現
-
服務在發佈時 指定對應的服務名（服務名包括了IP地址和端口） 將服務註冊到註冊中心（eureka或者zookeeper）。
-
這一過程是springcloud自動實現 只需要在main方法添加@EnableDisscoveryClient 同一個服務修改端口就可以啓動多個實例。
-
調用方法：傳遞服務名稱通過註冊中心獲取所有的可用實例 通過負載均衡策略調用（ribbon和feign）對應的服務。
5、什麼是服務熔斷和服務降級？
-
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。當某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制通過Hystrix實現，Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內調用20次，如果失敗，就會啓動熔斷機制。
-
服務降級，一般是從整體負荷考慮。就是當某個服務熔斷之後，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值。這樣做，雖然會出現局部的錯誤，但可以避免因爲一個服務掛機，而影響到整個架構的穩定性。
Hystrix相關注解：
-
@EnableHystrix：開啓熔斷
-
@HystrixCommand(fallbackMethod=”XXX”)：聲明一個失敗回滾處理函數XXX，當被註解的方法執行超時（默認是1000毫秒），就會執行fallback函數，返回錯誤提示。
6、什麼是Hystrix？它如何實現容錯？
Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障並在複雜的分佈式系統中實現彈性。
通常對於使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協作。
思考以下微服務
假設如果上圖中的微服務9失敗了，那麼使用傳統方法我們將傳播一個異常。但這仍然會導致整個系統崩潰。
隨着微服務數量的增加，這個問題變得更加複雜。微服務的數量可以高達1000.這是hystrix出現的地方 我們將使用Hystrix在這種情況下的Fallback方法功能。我們有兩個服務employee-consumer使用由employee-consumer公開的服務。
簡化圖如下所示
現在假設由於某種原因，employee-producer公開的服務會拋出異常。我們在這種情況下使用Hystrix定義了一個回退方法。這種後備方法應該具有與公開服務相同的返回類型。如果暴露服務中出現異常，則回退方法將返回一些值。
7、什麼是Hystrix斷路器？我們需要它嗎？
由於某些原因，employee-consumer公開服務會引發異常。在這種情況下使用Hystrix我們定義了一個回退方法。如果在公開服務中發生異常，則回退方法返回一些默認值。
如果firstPage method() 中的異常繼續發生，則Hystrix電路將中斷，並且員工使用者將一起跳過firtsPage方法，並直接調用回退方法。斷路器的目的是給第一頁方法或第一頁方法可能調用的其他方法留出時間，並導致異常恢復。可能發生的情況是，在負載較小的情況下，導致異常的問題有更好的恢復機會 。
8、項目中zuul常用的功能
-
提供動態路由
-
提供安全、鑑權處理
-
跨域處理
-
全局動態路由的hystrix(熔斷、降級、限流)處理
9、服務網關的作用
-
簡化客戶端調用複雜度，統一處理外部請求。
-
數據裁剪以及聚合，根據不同的接口需求，對數據加工後對外。
-
多渠道支持，針對不同的客戶端提供不同的網關支持。
-
遺留系統的微服務化改造，可以作爲新老系統的中轉組件。
-
統一處理調用過程中的安全、權限問題。
Spring Cloud中的網關有：Zuul和Spring Cloud Gateway，最新版本中推薦使用後者。
10、ribbon和feign區別
-
Ribbon添加maven依賴 spring-starter-ribbon 使用@RibbonClient(value="服務名稱") 使用RestTemplate調用遠程服務對應的方法。
-
feign添加maven依賴 spring-starter-feign 服務提供方提供對外接口 調用方使用 在接口上使用@FeignClient("指定服務名")
Ribbon和Feign的區別：
Ribbon和Feign都是用於調用其他服務的，不過方式不同。
-
啓動類使用的註解不同，Ribbon用的是@RibbonClient，Feign用的@EnableFeignClients。
-
服務的指定位置不同，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
-
調用方式不同，Ribbon需要自己構建http請求，模擬http請求然後使用RestTemplate發送給其他服務，步驟相當繁瑣。
Feign則是在Ribbon的基礎上進行了一次改進，採用接口的方式，將需要調用的其他服務的方法定義成抽象方法即可，
不需要自己構建http請求。不過要注意的是抽象方法的註解、方法簽名要和提供服務的方法完全一致。
11、ribbon的負載均衡策略
-
RoundRobinRule: 輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。所以示例中所啓動的兩個服務會被循環訪問;
-
RandomRule: 隨機策略，也就是說Ribbon會隨機從服務器列表中選擇一個進行訪問;
-
BestAvailableRule: 最大可用策略，即先過濾出故障服務器後，選擇一個當前併發請求數最小的;
-
WeightedResponseTimeRule: 帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，然後在採用輪詢的方式來獲取相應的服務器;
-
AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或併發請求大於閾值的一部分服務實例，然後再以線性輪詢的方式從過濾後的實例清單中選出一個;
-
ZoneAvoidanceRule: 區域感知策略，先使用主過濾條件（區域負載器，選擇最優區域）對所有實例過濾並返回過濾後的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認1）和最小過濾百分比（默認0），最後對滿足條件的服務器則使用RoundRobinRule(輪詢方式)選擇一個服務器實例。
12、簡述什麼是CAP,並說明Eureka包含CAP中的哪些?
CAP理論：一個分佈式系統不可能同時滿足C (一致性),A(可用性),P(分區容錯性).由於分區容錯性P在分佈式系統中是必須要保證的,因此我們只能從A和C中進行權衡.
Eureka 遵守 AP
-
Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,神域的節點依然可以提供註冊和查詢服務。
-
而Eureka的客戶端在向某個Eureka 註冊或查詢是如果發現連接失敗,則會自動切換至其他節點，只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查的信息可能不最新的不保證強一致性)。
13、Eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別？
-
Zookeeper保證了CP（C：一致性，P：分區容錯性）
-
Eureka保證了AP（A：高可用）
-
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說，服務註冊功能對高可用性要求比較高，但zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新選leader。問題在於，選取leader時間過長，30 ~ 120s，且選取期間zk集羣都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
-
Eureka保證了可用性，Eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而Eureka的客戶端向某個Eureka註冊或發現時發生連接失敗，則會自動切換到其他節點，只要有一臺Eureka還在，就能保證註冊服務可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心發生了網絡故障，此時會出現以下幾種情況：
-
Eureka不在從註冊列表中移除因爲長時間沒有收到心跳而應該過期的服務。
-
Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）。
-
當網絡穩定時，當前實例新的註冊信息會被同步到其他節點。
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個微服務癱瘓。
14、什麼是 Spring Cloud Bus?我們需要它嗎?
Spring Cloud Bus通過輕量消息代理連接各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的消息指令。Spring Cloud Bus的一個核心思想是通過分佈式的啓動器對Spring Boot應用進行擴展，也可以用來建立一個多個應用之間的通信頻道。
考慮以下情況:我們有多個應用程序使用 Spring Cloud Config 讀取屬性，而 Spring Cloud Config 從GIT 讀取這些屬性。
下面的例子中多個員工生產者模塊從 Employee Config Module 獲取 Eureka 註冊的財產。
如果假設 GIT 中的 Eureka 註冊屬性更改爲指向另一臺 Eureka 服務器，會發生什麼情況。在這種情況 下，我們將不得不重新啓動服務以獲取更新的屬性。
還有另一種使用執行器端點/刷新的方式。但是我們將不得不爲每個模塊單獨調用這個 url。例如，如果Employee Producer1 部署在端口 8080 上，則調用 http:// localhost:8080 / refresh。同樣對於Employee Producer2 http:// localhost:8081 / refresh 等等。這又很麻煩。這就是 Spring Cloud Bus 發揮作用的地方。
15、鏈路跟蹤Sleuth
當我們項目中引入Spring Cloud Sleuth後，每次鏈路請求都會添加一串追蹤信息，格式是[server-name, main-traceId,sub-spanId,boolean]：
-
server-name：服務結點名稱。
-
main-traceId：一條鏈路唯一的ID，爲TraceID。
-
sub-spanId：鏈路中每一環的ID，爲SpanID。
-
boolean：是否將信息輸出到Zipkin等服務收集和展示。
Sleuth的實現是基於HTTP的，爲了在數據的收集過程中不能影響到正常業務，Sleuth會在每個請求的Header上添加跟蹤需求的重要信息。這樣在數據收集時，只需要將Header上的相關信息發送給對應的圖像工具即可，圖像工具根據上傳的數據，按照Span對應的邏輯進行分析、展示。
參考文章：https://my.oschina.net/langwanghuangshifu/blog/3005195
參考文章：https://blog.csdn.net/weixin_30342639/article/details/99436321
好了，SpringCloud的面試題就到這兒結束，但是要精通SpringCloud，任重而道遠，需要鄉親們自己不斷的去學習和總結經驗。
更多面試題見我的個人公衆號【碼之初】，真心的希望能給你的面試之路助一臂之力。加油！