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、項目中zuul常用的功能

• 提供動態路由
• 提供安全、鑒權處理
• 跨域處理
• 全局動態路由的hystrix(熔斷、降級、限流)處理

7、服務網關的作用

• 簡化客戶端調用復雜度，統一處理外部請求。
• 數據裁剪以及聚合，根據不同的接口需求，對數據加工后對外。
• 多渠道支持，針對不同的客戶端提供不同的網關支持。
• 遺留系統的微服務化改造，可以作為新老系統的中轉組件。
• 統一處理調用過程中的安全、權限問題。

Spring Cloud中的網關有：Zuul和Spring Cloud Gateway，最新版本中推薦使用后者。

8、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請求。不過要注意的是抽象方法的注解、方法簽名要和提供服務的方法完全一致。

9、ribbon的負載均衡策略

RoundRobinRule: 輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。所以示例中所啟動的兩個服務會被循環訪問;

RandomRule: 隨機策略，也就是說Ribbon會隨機從服務器列表中選擇一個進行訪問;

BestAvailableRule: 最大可用策略，即先過濾出故障服務器后，選擇一個當前并發請求數最小的;

WeightedResponseTimeRule: 帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，然后在采用輪詢的方式來獲取相應的服務器;

AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或并發請求大于閾值的一部分服務實例，然后再以線性輪詢的方式從過濾后的實例清單中選出一個;

ZoneAvoidanceRule: 區域感知策略，先使用主過濾條件（區域負載器，選擇最優區域）對所有實例過濾并返回過濾后的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認1）和最小過濾百分比（默認0），最后對滿足條件的服務器則使用RoundRobinRule(輪詢方式)選擇一個服務器實例。

10、簡述什么是CAP,并說明Eureka包含CAP中的哪些?

CAP理論：一個分布式系統不可能同時滿足C (一致性),A(可用性),P(分區容錯性).由于分區容錯性P在分布式系統中是必須要保證的,因此我們只能從A和C中進行權衡.

Eureka 遵守 AP

• Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,神域的節點依然可以提供注冊和查詢服務。
• 而Eureka的客戶端在向某個Eureka 注冊或查詢是如果發現連接失敗,則會自動切換至其他節點，只要有一臺Eureka還在,就能保證注冊服務可用(保證可用性),只不過查的信息可能不最新的不保證強一致性)。

11、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那樣使整個微服務癱瘓。

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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SpringCloud面试题分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。