前言

? 今天公司的項目比較忙餐茵，遠程開會和辦公的溝通效率總是差那么一點康栈，為了節(jié)約點時間笙瑟，就不介紹SpringCloud了楼镐，我想只要是一名Java開發(fā)程序員，提到微服務(wù)逮走，一定對SpringCloud的大名如雷貫耳鸠蚪，我們直接來看它的高頻面試題吧今阳。?

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)用方式之間依賴太強。

REST調(diào)用系統(tǒng)性能較低摆霉，RPC調(diào)用效率比REST高豪椿。

REST的靈活性可以跨系統(tǒng)跨語言調(diào)用，RPC只能在同語言內(nèi)調(diào)用斯入。

REST可以和Swagger等工具整合砂碉，自動輸出接口API文檔。

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

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

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

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

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

熔斷機制是應(yīng)對雪崩效應(yīng)的一種微服務(wù)鏈路保護機制户誓。當某個微服務(wù)不可用或者響應(yīng)時間太長時饼灿，會進行服務(wù)降級，進而熔斷該節(jié)點微服務(wù)的調(diào)用帝美，快速返回“錯誤”的響應(yīng)信息碍彭。當檢測到該節(jié)點微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)悼潭，Hystrix會監(jiān)控微服務(wù)間調(diào)用的狀況庇忌，當失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)調(diào)用20次舰褪，如果失敗皆疹，就會啟動熔斷機制。

服務(wù)降級占拍，一般是從整體負荷考慮略就。就是當某個服務(wù)熔斷之后捎迫，服務(wù)器將不再被調(diào)用，此時客戶端可以自己準備一個本地的fallback回調(diào)表牢，返回一個缺省值窄绒。這樣做，雖然會出現(xiàn)局部的錯誤崔兴，但可以避免因為一個服務(wù)掛機颗祝，而影響到整個架構(gòu)的穩(wěn)定性。

Hystrix相關(guān)注解：

@EnableHystrix：開啟熔斷

@HystrixCommand(fallbackMethod=”XXX”)：聲明一個失敗回滾處理函數(shù)XXX恼布，當被注解的方法執(zhí)行超時（默認是1000毫秒）螺戳，就會執(zhí)行fallback函數(shù)，返回錯誤提示折汞。

6倔幼、什么是Hystrix？它如何實現(xiàn)容錯爽待？

? ? ? ? Hystrix是一個延遲和容錯庫损同，旨在隔離遠程系統(tǒng)，服務(wù)和第三方庫的訪問點鸟款，當出現(xiàn)故障是不可避免的故障時膏燃，停止級聯(lián)故障并在復(fù)雜的分布式系統(tǒng)中實現(xiàn)彈性。

通常對于使用微服務(wù)架構(gòu)開發(fā)的系統(tǒng)何什，涉及到許多微服務(wù)组哩。這些微服務(wù)彼此協(xié)作。?

? 思考以下微服務(wù)?

假設(shè)如果上圖中的微服務(wù)9失敗了处渣，那么使用傳統(tǒng)方法我們將傳播一個異常伶贰。但這仍然會導(dǎo)致整個系統(tǒng)崩潰。?

隨著微服務(wù)數(shù)量的增加罐栈，這個問題變得更加復(fù)雜黍衙。微服務(wù)的數(shù)量可以高達1000.這是hystrix出現(xiàn)的地方 我們將使用Hystrix在這種情況下的Fallback方法功能。我們有兩個服務(wù)employee-consumer使用由employee-consumer公開的服務(wù)荠诬。?

簡化圖如下所示

現(xiàn)在假設(shè)由于某種原因琅翻，employee-producer公開的服務(wù)會拋出異常。我們在這種情況下使用Hystrix定義了一個回退方法柑贞。這種后備方法應(yīng)該具有與公開服務(wù)相同的返回類型方椎。如果暴露服務(wù)中出現(xiàn)異常，則回退方法將返回一些值凌外。

7辩尊、什么是Hystrix斷路器涛浙？我們需要它嗎康辑？

? 由于某些原因摄欲，employee-consumer公開服務(wù)會引發(fā)異常。在這種情況下使用Hystrix我們定義了一個回退方法疮薇。如果在公開服務(wù)中發(fā)生異常胸墙，則回退方法返回一些默認值。?

? ? 如果firstPage method() 中的異常繼續(xù)發(fā)生按咒，則Hystrix電路將中斷迟隅，并且員工使用者將一起跳過firtsPage方法，并直接調(diào)用回退方法励七。斷路器的目的是給第一頁方法或第一頁方法可能調(diào)用的其他方法留出時間智袭，并導(dǎo)致異常恢復(fù)掠抬『鹨埃可能發(fā)生的情況是，在負載較小的情況下两波，導(dǎo)致異常的問題有更好的恢復(fù)機會 瞳步。?

8、項目中zuul常用的功能

提供動態(tài)路由

提供安全腰奋、鑒權(quán)處理

跨域處理

全局動態(tài)路由的hystrix(熔斷单起、降級、限流)處理

9劣坊、服務(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藕帜，最新版本中推薦使用后者烫罩。

10、ribbon和feign區(qū)別

Ribbon添加maven依賴 spring-starter-ribbon 使用@RibbonClient(value="服務(wù)名稱") 使用RestTemplate調(diào)用遠程服務(wù)對應(yīng)的方法洽故。

feign添加maven依賴 spring-starter-feign 服務(wù)提供方提供對外接口 調(diào)用方使用 在接口上使用@FeignClient("指定服務(wù)名")

Ribbon和Feign的區(qū)別：

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

啟動類使用的注解不同时甚，Ribbon用的是@RibbonClient隘弊，F(xiàn)eign用的@EnableFeignClients哈踱。

服務(wù)的指定位置不同，Ribbon是在@RibbonClient注解上聲明梨熙，F(xiàn)eign則是在定義抽象方法的接口中使用@FeignClient聲明开镣。

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

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

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

11奋早、ribbon的負載均衡策略

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

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

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

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

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

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

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

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

Eureka 遵守 AP

Eureka各個節(jié)點都是平等的,幾個節(jié)點掛掉不會影響正常節(jié)點的工作,神域的節(jié)點依然可以提供注冊和查詢服務(wù)镀钓。

而Eureka的客戶端在向某個Eureka 注冊或查詢是如果發(fā)現(xiàn)連接失敗,則會自動切換至其他節(jié)點穗熬，只要有一臺Eureka還在,就能保證注冊服務(wù)可用(保證可用性),只不過查的信息可能不最新的不保證強一致性)。

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

Zookeeper保證了CP（C：一致性，P：分區(qū)容錯性）

Eureka保證了AP（A：高可用）?

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

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

Eureka不在從注冊列表中移除因為長時間沒有收到心跳而應(yīng)該過期的服務(wù)持舆。?

Eureka仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其他節(jié)點上（即保證當前節(jié)點仍然可用）伪窖。

當網(wǎng)絡(luò)穩(wěn)定時逸寓，當前實例新的注冊信息會被同步到其他節(jié)點。?

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

14、什么是 Spring Cloud Bus?我們需要它嗎?

Spring Cloud Bus通過輕量消息代理連接各個分布的節(jié)點勋篓。這會用在廣播狀態(tài)的變化（例如配置變化）或者其他的消息指令吧享。Spring Cloud Bus的一個核心思想是通過分布式的啟動器對Spring Boot應(yīng)用進行擴展，也可以用來建立一個多個應(yīng)用之間的通信頻道譬嚣。

考慮以下情況:我們有多個應(yīng)用程序使用 Spring Cloud Config 讀取屬性钢颂，而 Spring Cloud Config 從GIT 讀取這些屬性。

? 下面的例子中多個員工生產(chǎn)者模塊從 Employee Config Module 獲取 Eureka 注冊的財產(chǎn)拜银。?

如果假設(shè) GIT 中的 Eureka 注冊屬性更改為指向另一臺 Eureka 服務(wù)器殊鞭，會發(fā)生什么情況。在這種情況 下尼桶，我們將不得不重新啟動服務(wù)以獲取更新的屬性操灿。

還有另一種使用執(zhí)行器端點/刷新的方式。但是我們將不得不為每個模塊單獨調(diào)用這個 url泵督。例如趾盐，如果Employee Producer1 部署在端口 8080 上，則調(diào)用 http:// localhost:8080 / refresh小腊。同樣對于Employee Producer2 http:// localhost:8081 / refresh 等等救鲤。這又很麻煩。這就是 Spring Cloud Bus 發(fā)揮作用的地方秩冈。

15蜒简、鏈路跟蹤Sleuth

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

server-name：服務(wù)結(jié)點名稱搓茬。

main-traceId：一條鏈路唯一的ID，為TraceID队他。

sub-spanId：鏈路中每一環(huán)的ID卷仑，為SpanID。

boolean：是否將信息輸出到Zipkin等服務(wù)收集和展示麸折。

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

說明：本文限于篇幅馁启，故而只展示部分的文檔截圖驾孔，完整的Java面試學(xué)習(xí)文檔小編已經(jīng)幫你整理好了，有需要的朋友們關(guān)注私信“需要”，即可免費獲取大廠面試學(xué)習(xí)資料哦翠勉！

好了妖啥，SpringCloud的面試題就到這兒結(jié)束，但是要精通SpringCloud对碌，任重而道遠荆虱，需要自己不斷的去學(xué)習(xí)和總結(jié)經(jīng)驗。