2021最新版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方法，并直接調用回退方法。斷路器的目的是給第一頁方法或第一頁方法可能調用的其他方法留出時間，并導致異常恢復?？赡馨l生的情況是，在負載較小的情況下，導致異常的問題有更好的恢復機會 。

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對應的邏輯進行分析、展示。

Spring Spring Cloud

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。