1、什么是Spring Cloud？

Spring cloud 流應(yīng)用程序啟動器是基于 Spring Boot 的 Spring 集成應(yīng)用程序，提供與外部系統(tǒng)的集成，更專注于服務(wù)治理。Spring cloud Task，一個生命周期短暫的微服務(wù)框架，用于快速構(gòu)建執(zhí)行有限數(shù)據(jù)處理的應(yīng)用程序。

2、Spring Cloud和Dubbo的區(qū)別

• Dubbo關(guān)注的領(lǐng)域是Spring Cloud的一個子集。Dubbo專注于服務(wù)治理，其在服務(wù)治理、灰度發(fā)布、流量分發(fā)方面比Spring Cloud更全面。Spring Cloud覆蓋整個微服務(wù)架構(gòu)領(lǐng)域。
• Dubbo使用RPC調(diào)用效率高一些，Spring Cloud使用HTTP調(diào)用效率低，使用更簡單。

3、REST和RPC的區(qū)別

• REST風(fēng)格的系統(tǒng)交互更方便，RPC調(diào)用服務(wù)提供方和調(diào)用方式之間依賴太強(qiáng)。
• REST調(diào)用系統(tǒng)性能較低，RPC調(diào)用效率比REST高。
• REST的靈活性可以跨系統(tǒng)跨語言調(diào)用，RPC只能在同語言內(nèi)調(diào)用。
• REST可以和Swagger等工具整合，自動輸出接口API文檔。

4、SpringCloud如何實(shí)現(xiàn)服務(wù)的注冊和發(fā)現(xiàn)

服務(wù)在發(fā)布時 指定對應(yīng)的服務(wù)名（服務(wù)名包括了IP地址和端口） 將服務(wù)注冊到注冊中心（eureka或者zookeeper）。

這一過程是springcloud自動實(shí)現(xiàn) 只需要在main方法添加@EnableDisscoveryClient 同一個服務(wù)修改端口就可以啟動多個實(shí)例。

調(diào)用方法：傳遞服務(wù)名稱通過注冊中心獲取所有的可用實(shí)例 通過負(fù)載均衡策略調(diào)用（ribbon和feign）對應(yīng)的服務(wù)。

5、什么是服務(wù)熔斷和服務(wù)降級？

• 熔斷機(jī)制是應(yīng)對雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。當(dāng)某個微服務(wù)不可用或者響應(yīng)時間太長時，會進(jìn)行服務(wù)降級，進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用，快速返回“錯誤”的響應(yīng)信息。當(dāng)檢測到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在SpringCloud框架里熔斷機(jī)制通過Hystrix實(shí)現(xiàn)，Hystrix會監(jiān)控微服務(wù)間調(diào)用的狀況，當(dāng)失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)調(diào)用20次，如果失敗，就會啟動熔斷機(jī)制。
• 服務(wù)降級，一般是從整體負(fù)荷考慮。就是當(dāng)某個服務(wù)熔斷之后，服務(wù)器將不再被調(diào)用，此時客戶端可以自己準(zhǔn)備一個本地的fallback回調(diào)，返回一個缺省值。這樣做，雖然會出現(xiàn)局部的錯誤，但可以避免因?yàn)橐粋€服務(wù)掛機(jī)，而影響到整個架構(gòu)的穩(wěn)定性。

Hystrix相關(guān)注解：

• @EnableHystrix：開啟熔斷
• @HystrixCommand(fallbackMethod=”XXX”)：聲明一個失敗回滾處理函數(shù)XXX，當(dāng)被注解的方法執(zhí)行超時（默認(rèn)是1000毫秒），就會執(zhí)行fallback函數(shù)，返回錯誤提示。

6、項(xiàng)目中zuul常用的功能

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

7、服務(wù)網(wǎng)關(guān)的作用

• 簡化客戶端調(diào)用復(fù)雜度，統(tǒng)一處理外部請求。
• 數(shù)據(jù)裁剪以及聚合，根據(jù)不同的接口需求，對數(shù)據(jù)加工后對外。
• 多渠道支持，針對不同的客戶端提供不同的網(wǎng)關(guān)支持。
• 遺留系統(tǒng)的微服務(wù)化改造，可以作為新老系統(tǒng)的中轉(zhuǎn)組件。
• 統(tǒng)一處理調(diào)用過程中的安全、權(quán)限問題。

Spring Cloud中的網(wǎng)關(guān)有：Zuul和Spring Cloud Gateway，最新版本中推薦使用后者。

8、ribbon和feign區(qū)別

• Ribbon添加maven依賴 spring-starter-ribbon 使用@RibbonClient(value="服務(wù)名稱") 使用RestTemplate調(diào)用遠(yuǎn)程服務(wù)對應(yīng)的方法。
• feign添加maven依賴 spring-starter-feign 服務(wù)提供方提供對外接口 調(diào)用方使用 在接口上使用@FeignClient("指定服務(wù)名")

Ribbon和Feign的區(qū)別：

Ribbon和Feign都是用于調(diào)用其他服務(wù)的，不過方式不同。

啟動類使用的注解不同，Ribbon用的是@RibbonClient，Feign用的@EnableFeignClients。

服務(wù)的指定位置不同，Ribbon是在@RibbonClient注解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。

調(diào)用方式不同，Ribbon需要自己構(gòu)建http請求，模擬http請求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當(dāng)繁瑣。

Feign則是在Ribbon的基礎(chǔ)上進(jìn)行了一次改進(jìn)，采用接口的方式，將需要調(diào)用的其他服務(wù)的方法定義成抽象方法即可，

不需要自己構(gòu)建http請求。不過要注意的是抽象方法的注解、方法簽名要和提供服務(wù)的方法完全一致。

9、ribbon的負(fù)載均衡策略

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

RandomRule: 隨機(jī)策略，也就是說Ribbon會隨機(jī)從服務(wù)器列表中選擇一個進(jìn)行訪問;

BestAvailableRule: 最大可用策略，即先過濾出故障服務(wù)器后，選擇一個當(dāng)前并發(fā)請求數(shù)最小的;

WeightedResponseTimeRule: 帶有加權(quán)的輪詢策略，對各個服務(wù)器響應(yīng)時間進(jìn)行加權(quán)處理，然后在采用輪詢的方式來獲取相應(yīng)的服務(wù)器;

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

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

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

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

Eureka 遵守 AP

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

11、Eureka和zookeeper都可以提供服務(wù)注冊與發(fā)現(xiàn)的功能，請說說兩個的區(qū)別？

• Zookeeper保證了CP（C：一致性，P：分區(qū)容錯性）
• Eureka保證了AP（A：高可用）

當(dāng)向注冊中心查詢服務(wù)列表時，我們可以容忍注冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說，服務(wù)注冊功能對高可用性要求比較高，但zk會出現(xiàn)這樣一種情況，當(dāng)master節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時，剩余節(jié)點(diǎn)會重新選leader。問題在于，選取leader時間過長，30 ~ 120s，且選取期間zk集群都不可用，這樣就會導(dǎo)致選取期間注冊服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問題使得zk集群失去master節(jié)點(diǎn)是較大概率會發(fā)生的事，雖然服務(wù)能夠恢復(fù)，但是漫長的選取時間導(dǎo)致的注冊長期不可用是不能容忍的。

Eureka保證了可用性，Eureka各個節(jié)點(diǎn)是平等的，幾個節(jié)點(diǎn)掛掉不會影響正常節(jié)點(diǎn)的工作，剩余的節(jié)點(diǎn)仍然可以提供注冊和查詢服務(wù)。而Eureka的客戶端向某個Eureka注冊或發(fā)現(xiàn)時發(fā)生連接失敗，則會自動切換到其他節(jié)點(diǎn)，只要有一臺Eureka還在，就能保證注冊服務(wù)可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護(hù)機(jī)制，如果在15分鐘內(nèi)超過85%的節(jié)點(diǎn)沒有正常的心跳，那么Eureka就認(rèn)為客戶端與注冊中心發(fā)生了網(wǎng)絡(luò)故障，此時會出現(xiàn)以下幾種情況：

• Eureka不在從注冊列表中移除因?yàn)殚L時間沒有收到心跳而應(yīng)該過期的服務(wù)。
• Eureka仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其他節(jié)點(diǎn)上（即保證當(dāng)前節(jié)點(diǎn)仍然可用）。
• 當(dāng)網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實(shí)例新的注冊信息會被同步到其他節(jié)點(diǎn)。

因此，Eureka可以很好的應(yīng)對因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，而不會像Zookeeper那樣使整個微服務(wù)癱瘓。

12、鏈路跟蹤Sleuth

當(dāng)我們項(xiàng)目中引入Spring Cloud Sleuth后，每次鏈路請求都會添加一串追蹤信息，格式是[server-name, main-traceId,sub-spanId,boolean]：

• server-name：服務(wù)結(jié)點(diǎn)名稱。
• main-traceId：一條鏈路唯一的ID，為TraceID。
• sub-spanId：鏈路中每一環(huán)的ID，為SpanID。
• boolean：是否將信息輸出到Zipkin等服務(wù)收集和展示。

Sleuth的實(shí)現(xiàn)是基于HTTP的，為了在數(shù)據(jù)的收集過程中不能影響到正常業(yè)務(wù)，Sleuth會在每個請求的Header上添加跟蹤需求的重要信息。這樣在數(shù)據(jù)收集時，只需要將Header上的相關(guān)信息發(fā)送給對應(yīng)的圖像工具即可，圖像工具根據(jù)上傳的數(shù)據(jù)，按照Span對應(yīng)的邏輯進(jìn)行分析、展示。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。