目錄

一、簡(jiǎn)單說(shuō)一說(shuō)什么是微服務(wù)？

二、微服務(wù)有哪些優(yōu)缺點(diǎn)？

三、微服務(wù)、分布式、集群的區(qū)別？

四、什么是Eureka？

五、Eureka有那兩大組件？

六、actuator是什么？

七、Discovery是什么？

八、什么是Eureka的自我保護(hù)機(jī)制？

九、微服務(wù)有很多注冊(cè)中心組件，說(shuō)說(shuō)你知道的有哪些？并說(shuō)出他們的區(qū)別？

十、什么是Ribbon？

十一、剛才你提到了RestTemplate，那么RestTemplate有什么常用的方法嗎？

十二、Ribbon有哪些負(fù)載規(guī)則？

十三、Ribbon默認(rèn)的輪詢規(guī)則的原理是什么？

十四、什么是OpenFeign？它能干什么？

十五、Feign和OpenFeign兩者區(qū)別？

十六、Ribbon與Feign的區(qū)別？

十七、簡(jiǎn)單講一講OpenFeign的超時(shí)控制？

十八、什么是OpenFeign日志增強(qiáng)？

十九、講一講Hystrix是什么？有什么作用？

二十、請(qǐng)你分別說(shuō)一說(shuō)服務(wù)降級(jí)和服務(wù)熔斷的概念

二十一、服務(wù)熔斷重要的三個(gè)參數(shù)是什么？

二十二、Hystrix有哪些常用注解？

二十三、Hystrix組件有個(gè)Dashboard，你了解過(guò)嗎？

二十四、GateWay是什么？

二十五、SpringCloud Gateway與Zuul的區(qū)別？

二十六、能簡(jiǎn)單講一講GateWay的非阻塞異步模型嗎？

二十七、GateWay有三個(gè)核心概念，你知道是什么嗎？

二十八、GateWay常用的Predicate斷言有哪些？

二十九、GateWay中自定義全局過(guò)濾器如何實(shí)現(xiàn)？

三十、SpringCloud Config是什么？有什么用處？

三十一、SpringCloud中，使用過(guò)全局事件總線bus嗎？如果使用過(guò)請(qǐng)簡(jiǎn)單的談一談

三十二、SpringCloud中，使用過(guò)Stream消息驅(qū)動(dòng)嗎？如果使用過(guò)請(qǐng)簡(jiǎn)單的談一談

三十三、假如說(shuō)我們的分布式項(xiàng)目鏈路很多，有很多節(jié)點(diǎn)，那么如何跟蹤這些鏈路呢？

三十四、除了Eureka、Zookeeper、Consul，你還知道什么服務(wù)注冊(cè)中心的組件嗎？

三十五、你剛剛提到Nacos，那與其它幾種注冊(cè)中心組件有什么區(qū)別嗎？

三十六、Hystrix與Sentinel有什么區(qū)別嗎？

三十七、簡(jiǎn)單說(shuō)一說(shuō)Sentinel都有哪些流控規(guī)則？

一、簡(jiǎn)單說(shuō)一說(shuō)什么是微服務(wù)？

微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，每個(gè)服務(wù)運(yùn)行在其獨(dú)立的自己的進(jìn)程中，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。服務(wù)之間采用輕量級(jí)的通信機(jī)制互相溝通(通常是基于HTTP的RESTful API)。

舉個(gè)簡(jiǎn)單例子來(lái)說(shuō)，我們以前都是單一的Web項(xiàng)目，包含著比如訂單功能、支付功能、物流功能、日志功能等。但微服務(wù)是要你將這些功能按業(yè)務(wù)進(jìn)行拆分，每個(gè)功能是一個(gè)SpringBoot項(xiàng)目，每個(gè)項(xiàng)目互相通信。

二、微服務(wù)有哪些優(yōu)缺點(diǎn)？

優(yōu)點(diǎn)：

1. 每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求。
2. 開(kāi)發(fā)簡(jiǎn)單、開(kāi)發(fā)效率提高，一個(gè)服務(wù)可能就是專一的只干一件事。
3. 微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā)，這個(gè)小團(tuán)隊(duì)是2到5人的開(kāi)發(fā)人員組成。
4. 微服務(wù)是松稠合的，是有功能意義的服務(wù)，無(wú)論是在開(kāi)發(fā)階段或部署階段都是獨(dú)立的。
5. 微服務(wù)能使用不同的語(yǔ)言開(kāi)發(fā)。
6. 易于和第三方集成，微服務(wù)允許容易且靈活的方式集成自動(dòng)部署，通過(guò)持續(xù)集成工具，如Jenkins,Hudson,bamboo。
7. 微服務(wù)易于被一個(gè)開(kāi)發(fā)人員理解，修改和維護(hù)，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果。無(wú)需通過(guò)合作才能體現(xiàn)價(jià)值。
8. 微服務(wù)允許你利用融合最新技術(shù)。
9. 微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會(huì)和HTML、CSS或其他界面組件混合。
10. 每個(gè)微服務(wù)都有自己的存儲(chǔ)能力，可以有自己的數(shù)據(jù)庫(kù)，也可以有統(tǒng)一數(shù)據(jù)庫(kù)。

缺點(diǎn)：

1. 開(kāi)發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性。
2. 多服務(wù)運(yùn)維難度，隨著服務(wù)的增加，運(yùn)維的壓力也在增大。
3. 系統(tǒng)部署依賴。
4. 服務(wù)間通信成本。
5. 數(shù)據(jù)一致性。
6. 系統(tǒng)集成測(cè)試。
7. 性能監(jiān)控......

三、微服務(wù)、分布式、集群的區(qū)別？

分布式：一個(gè)業(yè)務(wù)分拆多個(gè)子業(yè)務(wù)，部署在不同的服務(wù)器上。

集群：同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上。

去飯店吃飯就是一個(gè)完整的業(yè)務(wù)，飯店的廚師、配菜師、傳菜員、服務(wù)員就是分布式；廚師、配菜師、傳菜員和服務(wù)員都不止一個(gè)人，這就是集群；分布式就是微服務(wù)的一種表現(xiàn)形式，分布式是部署層面，微服務(wù)是設(shè)計(jì)層面。

四、什么是Eureka？

在服務(wù)注冊(cè)與發(fā)現(xiàn)中，有一個(gè)注冊(cè)中心。當(dāng)服務(wù)器啟動(dòng)的時(shí)候，會(huì)把當(dāng)前自己服務(wù)器的信息比如服務(wù)地址通訊地址等以別名方式注冊(cè)到注冊(cè)中心上。另一方(消費(fèi)者服務(wù)提供者)，以該別名的方式去注冊(cè)中心上獲取到實(shí)際的服務(wù)通訊地址，然后再實(shí)現(xiàn)本地RPC調(diào)用RPC遠(yuǎn)程調(diào)用框架核心設(shè)計(jì)思想：在于注冊(cè)中心，因?yàn)槭褂米?cè)中心管理每個(gè)服務(wù)與服務(wù)之間的一個(gè)依賴關(guān)系(服務(wù)治理概念)。在任何RPC遠(yuǎn)程框架中，都會(huì)有一個(gè)注冊(cè)中心存放服務(wù)地址相關(guān)信息(接口地址)。

Eureka說(shuō)白了就是服務(wù)注冊(cè)中心，我們都知道微服務(wù)架構(gòu)會(huì)有很多Module項(xiàng)目，眾多的項(xiàng)目需要一個(gè)管家去管理，每個(gè)項(xiàng)目都要去Eureka中注冊(cè)，由Eureka去統(tǒng)籌管理眾多的項(xiàng)目。

我們發(fā)現(xiàn)哪怕不加服務(wù)注冊(cè)中心，我們的消費(fèi)端也能調(diào)用數(shù)據(jù)提供端完成功能，但怕就怕在量變引起質(zhì)變。比如一個(gè)病人去私人醫(yī)院一對(duì)一的找大夫咨詢，這時(shí)倒不用中間隔這一個(gè)門診，直接去就行了。但如果病人多了，我想知道今天還有沒(méi)有剩號(hào)和余號(hào)，我們需要監(jiān)控流量的管控，那么這些東西我們是不是需要一個(gè)門診來(lái)咨詢。我們得知道今天有什么專家坐診，這個(gè)專家現(xiàn)在有沒(méi)有余號(hào)了，這都需要門診來(lái)咨詢。

五、Eureka有那兩大組件？

Eureka Server和EurekaClient。

六、actuator是什么？

如圖，在Eureka中暴露了IP地址。

actuator的作用就是把Eureka頁(yè)面中暴露的IP地址換成你指定的名字，具有信息保護(hù)的作用。

七、Discovery是什么？

消費(fèi)端可以通過(guò)Discovery來(lái)獲取生產(chǎn)者端的一些信息，比如IP、端口、服務(wù)ID等。

八、什么是Eureka的自我保護(hù)機(jī)制？

一句話總結(jié)：某時(shí)刻某一個(gè)微服務(wù)不可用 ，Eureka不會(huì)立刻清理，依舊會(huì)對(duì)該微服務(wù)的信息進(jìn)行保存。

默認(rèn)情況下，如果EurekaServer在一定時(shí)間內(nèi)沒(méi)有接收到某個(gè)微服務(wù)實(shí)例的心跳，EurekaServer將會(huì)注銷該實(shí)例(默認(rèn)90秒)。但是當(dāng)網(wǎng)絡(luò)分區(qū)故障發(fā)生(延時(shí)、卡頓、擁擠)時(shí)，微服務(wù)與EurekaServer之間無(wú)法正常通信，以上行為可能變得非常危險(xiǎn)了——因?yàn)槲⒎?wù)本身其實(shí)是健康的，此時(shí)本不應(yīng)該注銷這個(gè)微服務(wù)。Eureka通過(guò)“自我保護(hù)模式”來(lái)解決這個(gè)問(wèn)題——當(dāng)EurekaServer節(jié)點(diǎn)在短時(shí)間內(nèi)丟失過(guò)多客戶端時(shí)(可能發(fā)生了網(wǎng)絡(luò)分區(qū)故障)，那么這個(gè)節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式。

自我保護(hù)機(jī)制：默認(rèn)情況下EurekaClient定時(shí)向EurekaServer端發(fā)送心跳包

如果Eureka在server端在一定時(shí)間內(nèi)(默認(rèn)90秒)沒(méi)有收到EurekaClient發(fā)送心跳包，便會(huì)直接從服務(wù)注冊(cè)列表中剔除該服務(wù)，但是在短時(shí)間( 90秒中)內(nèi)丟失了大量的服務(wù)實(shí)例心跳，這時(shí)候Eurekaserver會(huì)開(kāi)啟自我保護(hù)機(jī)制，不會(huì)剔除該服務(wù)（該現(xiàn)象可能出現(xiàn)在如果網(wǎng)絡(luò)不通但是EurekaClient為出現(xiàn)宕機(jī)，此時(shí)如果換做別的注冊(cè)中心如果一定時(shí)間內(nèi)沒(méi)有收到心跳會(huì)將剔除該服務(wù)，這樣就出現(xiàn)了嚴(yán)重失誤，因?yàn)榭蛻舳诉€能正常發(fā)送心跳，只是網(wǎng)絡(luò)延遲問(wèn)題，而保護(hù)機(jī)制是為了解決此問(wèn)題而產(chǎn)生的)。

它的設(shè)計(jì)哲學(xué)就是寧可保留錯(cuò)誤的服務(wù)注冊(cè)信息，也不盲目注銷任何可能健康的服務(wù)實(shí)例。一句話講解：好死不如賴活著。

九、微服務(wù)有很多注冊(cè)中心組件，說(shuō)說(shuō)你知道的有哪些？并說(shuō)出他們的區(qū)別？

注冊(cè)中心組件有Eureka、Zookeeper、Consul等。

區(qū)別是：

Eureka具有自我保護(hù)機(jī)制，當(dāng)你某個(gè)服務(wù)宕機(jī)時(shí)，我不會(huì)立即把你干掉，會(huì)保留一段時(shí)間，保證了高可用性AP。

而Zk和Consul都是只要服務(wù)一宕機(jī)，立馬把你干掉，頭也不回，所以保證了CP。

十、什么是Ribbon？

Ribbon是基于Netflix Ribbon實(shí)現(xiàn)的一套客戶端負(fù)載均衡的工具。

簡(jiǎn)單的說(shuō)，Ribbon是Netflix發(fā)布的開(kāi)源項(xiàng)目，主要功能是提供客戶端的軟件負(fù)載均衡算法和服務(wù)調(diào)用。

一句話解釋Ribbon，就是?負(fù)載均衡 + RestTemplate調(diào)用。

十一、剛才你提到了RestTemplate，那么RestTemplate有什么常用的方法嗎？

（1）getForObject方法/getForEntity方法（GET請(qǐng)求方法）。

getForObject()：返回對(duì)象為響應(yīng)體中數(shù)據(jù)轉(zhuǎn)化成的對(duì)象，基本上可以理解為Json。

getForEntity()：返回對(duì)象為ResponseEntity對(duì)象，包含了響應(yīng)中的一些重要信息，比如響應(yīng)頭、響應(yīng)狀態(tài)碼、響應(yīng)體等。

（2）postForObject方法/postForEntity方法（POST請(qǐng)求方法）。

十二、Ribbon有哪些負(fù)載規(guī)則？

1、RoundRobinRule 輪詢。

2、RandomRule 隨機(jī)。

3、RetryRule 先按照RoundRobinRule的策略獲取服務(wù)，如果獲取服務(wù)失敗則在指定時(shí)間內(nèi)會(huì)進(jìn)行重試，獲取可用的服務(wù)。

4、WeightedResponseTimeRule 對(duì)RoundRobinRule的擴(kuò)展，響應(yīng)速度越快的實(shí)例選擇權(quán)重越大，越容易被選擇。

5、BestAvailableRule 會(huì)先過(guò)濾掉由于多次訪問(wèn)故障而處于斷路器跳閘狀態(tài)的服務(wù)，然后選擇一個(gè)并發(fā)量最小的服務(wù)。

6、AvailabilityFilteringRule 先過(guò)濾掉故障實(shí)例，再選擇并發(fā)較小的實(shí)例。

7、ZoneAvoidanceRule 默認(rèn)規(guī)則，復(fù)合判斷server所在區(qū)域的性能和server的可用性選擇服務(wù)器。

十三、Ribbon默認(rèn)的輪詢規(guī)則的原理是什么？

默認(rèn)負(fù)載輪訓(xùn)算法：rest接口第幾次請(qǐng)求數(shù) % 服務(wù)器集群總數(shù)量 = 實(shí)際調(diào)用服務(wù)器位置下標(biāo)，每次服務(wù)重啟動(dòng)后rest接口計(jì)數(shù)從1開(kāi)始。

我們的客戶端現(xiàn)有2臺(tái)機(jī)器，我們是第一次請(qǐng)求，那么按公式算就是1%2=1。

十四、什么是OpenFeign？它能干什么？

Feign是一個(gè)聲明式WebService客戶端。使用Feign能讓編寫(xiě)Web Service客戶端更加簡(jiǎn)單。它的使用方法是定義一個(gè)服務(wù)接口然后在上面添加注解。Feign也支持可拔插式的編碼器和解碼器。Spring Cloud對(duì)Feign進(jìn)行了封裝，使其支持了SpringMVC標(biāo)準(zhǔn)注解和HttpMessageConverters。Feign可以與Eureka和Ribbon組合使用以支持負(fù)載均衡。

前面在使用Ribbon+RestTemplate時(shí)，利用RestTemplate對(duì)http請(qǐng)求的封裝處理，形成了一套模版化的調(diào)用方法。但是在實(shí)際開(kāi)發(fā)中，由于對(duì)服務(wù)依賴的調(diào)用可能不止一處，往往一個(gè)接口會(huì)被多處調(diào)用，所以通常都會(huì)針對(duì)每個(gè)微服務(wù)自行封裝一些客戶端類來(lái)包裝這些依賴服務(wù)的調(diào)用。所以，F(xiàn)eign在此基礎(chǔ)上做了進(jìn)一步封裝，由他來(lái)幫助我們定義和實(shí)現(xiàn)依賴服務(wù)接口的定義。在Feign的實(shí)現(xiàn)下，我們只需創(chuàng)建一個(gè)接口并使用注解的方式來(lái)配置它(以前是Dao接口上面標(biāo)注Mapper注解,現(xiàn)在是一個(gè)微服務(wù)接口上面標(biāo)注一個(gè)Feign注解即可)，即可完成對(duì)服務(wù)提供方的接口綁定，簡(jiǎn)化了使用Spring cloud Ribbon時(shí)，自動(dòng)封裝服務(wù)調(diào)用客戶端的開(kāi)發(fā)量。而OpenFeign在Feign的基礎(chǔ)上又增加了對(duì)springmvc注解的支持。

十五、Feign和OpenFeign兩者區(qū)別？

十六、Ribbon與Feign的區(qū)別？

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

2、啟動(dòng)類注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients。

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

4、調(diào)用方式不同，Ribbon需要自己構(gòu)建http請(qǐng)求，模擬http請(qǐng)求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當(dāng)繁瑣。Feign需要將調(diào)用的方法定義成抽象方法即可。

十七、簡(jiǎn)單講一講OpenFeign的超時(shí)控制？

我們?cè)谑褂肙penFeign進(jìn)行調(diào)用接口時(shí)，如果因?yàn)槟承┰?，調(diào)用時(shí)間過(guò)長(zhǎng)，會(huì)導(dǎo)致報(bào)錯(cuò)。

OpenFeign默認(rèn)等待1秒鐘，超過(guò)后報(bào)錯(cuò)。也就是說(shuō)如果你調(diào)用接口總共花了3秒時(shí)間，超過(guò)1秒不返回直接就報(bào)錯(cuò)了。為了避免這樣的情況，有時(shí)候我們需要設(shè)置Feign客戶端的超時(shí)控制。

十八、什么是OpenFeign日志增強(qiáng)？

說(shuō)白了就是對(duì)Feign接口的調(diào)用情況進(jìn)行監(jiān)控和輸出。

有以下四種日志級(jí)別：

NONE：默認(rèn)的，不顯示任何日志。

BASIC：僅記錄請(qǐng)求方法、URL、響應(yīng)狀態(tài)碼及執(zhí)行時(shí)間。

HEADERS：除了BASIC中定義的信息之外，還有請(qǐng)求和響應(yīng)的頭信息。

FULL：除了HEADERS中定義的信息之外，還有請(qǐng)求和響應(yīng)的正文及元數(shù)據(jù)。

十九、講一講Hystrix是什么？有什么作用？

在復(fù)雜分布式體系結(jié)構(gòu)中的應(yīng)用程序有數(shù)十個(gè)依賴關(guān)系，每個(gè)依賴關(guān)系在某些時(shí)候?qū)⒉豢杀苊獾厥　?/p>

多個(gè)微服務(wù)之間調(diào)用的時(shí)候，假設(shè)微服務(wù)A調(diào)用微服務(wù)B和微服務(wù)C，微服務(wù)B和微服務(wù)C又調(diào)用其它的微服務(wù)，這就是所謂的“扇出”。如果扇出的鏈路上某個(gè)微服務(wù)的調(diào)用響應(yīng)時(shí)間過(guò)長(zhǎng)或者不可用，對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來(lái)越多的系統(tǒng)資源，進(jìn)而引起系統(tǒng)崩潰，所謂的“雪崩效應(yīng)”。

而Hystrix是一個(gè)用于處理分布式系統(tǒng)的延遲和容錯(cuò)的開(kāi)源庫(kù)，在分布式系統(tǒng)里，許多依賴不可避免的會(huì)調(diào)用失敗，比如超時(shí)、異常等，Hystrix能夠保證在一個(gè)依賴出問(wèn)題的情況下，不會(huì)導(dǎo)致整體服務(wù)失敗，避免級(jí)聯(lián)故障，以提高分布式系統(tǒng)的彈性。

"斷路器”本身是一種開(kāi)關(guān)裝置，當(dāng)某個(gè)服務(wù)單元發(fā)生故障之后，通過(guò)斷路器的故障監(jiān)控（類似熔斷保險(xiǎn)絲)，向調(diào)用方返回一個(gè)符合預(yù)期的、可處理的備選響應(yīng)（FallBack)，而不是長(zhǎng)時(shí)間的等待或者拋出調(diào)用方無(wú)法處理的異常，這樣就保證了服務(wù)調(diào)用方的線程不會(huì)被長(zhǎng)時(shí)間、不必要地占用，從而避免了故障在分布式系統(tǒng)中的蔓延，乃至雪崩。

二十、請(qǐng)你分別說(shuō)一說(shuō)服務(wù)降級(jí)和服務(wù)熔斷的概念

服務(wù)降級(jí)：服務(wù)器忙，請(qǐng)稍后再試，不讓客戶端等待并立刻返回一個(gè)友好提示，調(diào)用備選fallback方法。比如程序運(yùn)行導(dǎo)常（數(shù)組下標(biāo)越界、除數(shù)分母為0）、超時(shí)等會(huì)觸發(fā)降級(jí)。

服務(wù)熔斷：類比保險(xiǎn)絲達(dá)到最大服務(wù)訪問(wèn)后，直接拒絕訪問(wèn)，拉閘限電，然后調(diào)用服務(wù)降級(jí)的方法并返回友好提示。服務(wù)熔斷也是一種服務(wù)降級(jí)方式。

1、調(diào)用失敗會(huì)觸發(fā)降級(jí)，而降級(jí)會(huì)調(diào)用fallback方法。

2、但無(wú)論如何降級(jí)的流程一定會(huì)先調(diào)用正常方法再調(diào)用fallback方法。

3、假如單位時(shí)間內(nèi)調(diào)用失敗次數(shù)過(guò)多，也就是降級(jí)次數(shù)過(guò)多，則觸發(fā)熔斷。

4、熔斷以后就會(huì)跳過(guò)正常方法直接調(diào)用fallback方法。

5、所謂“熔斷后服務(wù)不可用”就是因?yàn)樘^(guò)了正常方法直接執(zhí)行fallback。

二十一、服務(wù)熔斷重要的三個(gè)參數(shù)是什么？

1、快照時(shí)間窗：斷路器確定是否打開(kāi)需要統(tǒng)計(jì)一些請(qǐng)求和錯(cuò)誤數(shù)據(jù)，而統(tǒng)計(jì)的時(shí)間范圍就是快照時(shí)間窗，默認(rèn)為最近的10秒。

2、請(qǐng)求總數(shù)閥值：在快照時(shí)間窗內(nèi)，必須滿足請(qǐng)求總數(shù)閥值才有資格熔斷。默認(rèn)為20，意味著在10秒內(nèi)，如果該hystrix命令的調(diào)用次數(shù)不足20次，即使所有的請(qǐng)求都超時(shí)或其他原因失敗，斷路器都不會(huì)打開(kāi)。

3、錯(cuò)誤百分比閥值：當(dāng)請(qǐng)求總數(shù)在快照時(shí)間窗內(nèi)超過(guò)了閥值，比如發(fā)生了30次調(diào)用，如果在這30次調(diào)用中，有15次發(fā)生了超時(shí)異常，也就是超過(guò)50%的錯(cuò)誤百分比，在默認(rèn)設(shè)定50%閥值情況下，這時(shí)候就會(huì)將斷路器打開(kāi)。

二十二、Hystrix有哪些常用注解？

@HystrixCommand、@EnableHystrix、@DefaultProperties

二十三、Hystrix組件有個(gè)Dashboard，你了解過(guò)嗎？

Dashboard是Dashboard組件的圖形化頁(yè)面，Hystrix會(huì)持續(xù)地記錄所有通過(guò)Hystrix發(fā)起的請(qǐng)求的執(zhí)行信息，并以統(tǒng)計(jì)報(bào)表和圖形的形式展示給用戶，包括每秒執(zhí)行多少請(qǐng)求多少成功，多少失敗等。

二十四、GateWay是什么？

Gateway是在Spring生態(tài)系統(tǒng)之上構(gòu)建的API網(wǎng)關(guān)服務(wù)，基于Spring 5，Spring Boot 2和Project Reactor等技術(shù)。

Gateway旨在提供一種簡(jiǎn)單而有效的方式來(lái)對(duì)API進(jìn)行路由，以及提供一些強(qiáng)大的過(guò)濾器功能，例如:熔斷、限流、重試等。

SpringCloud Gateway是基于WebFlux框架實(shí)現(xiàn)的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。

二十五、SpringCloud Gateway與Zuul的區(qū)別？

（1）Zuul 1.x使用的是傳統(tǒng)的Serviet IO處理模型。而Gateway使用的是異步非阻塞模型，效率很高。在性能方面，根據(jù)官方提供的基準(zhǔn)測(cè)試，Spring Cloud Gateway的RPS(每秒請(qǐng)求數(shù))是Zuul的1.6倍。

（2）Gateway還支持WebSocket，并且與Spring緊密集成擁有更好的開(kāi)發(fā)體驗(yàn)。

二十六、能簡(jiǎn)單講一講GateWay的非阻塞異步模型嗎？

Zuul1.x模型

Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是傳統(tǒng)的Serviet IO處理模型。

該模型的缺點(diǎn)是：

Servlet是一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)IO模型，當(dāng)請(qǐng)求進(jìn)入Servlet container時(shí)，Servlet container就會(huì)為其綁定一個(gè)線程，在并發(fā)不高的場(chǎng)景下這種模型是適用的。但是一旦高并發(fā)(如抽風(fēng)用Jmeter壓)，線程數(shù)量就會(huì)上漲，而線程資源代價(jià)是昂貴的（上線文切換，內(nèi)存消耗大）嚴(yán)重影響請(qǐng)求的處理時(shí)間。在一些簡(jiǎn)單業(yè)務(wù)場(chǎng)景下，不希望為每個(gè)request分配一個(gè)線程，只需要1個(gè)或幾個(gè)線程就能應(yīng)對(duì)極大并發(fā)的請(qǐng)求，這種業(yè)務(wù)場(chǎng)景下servlet模型沒(méi)有優(yōu)勢(shì)。

所以Zuul 1.X是基于servlet之上的一個(gè)阻塞式處理模型，即Spring實(shí)現(xiàn)了處理所有request請(qǐng)求的一個(gè)servlet (DispatcherServlet)并由該servlet阻塞式處理處理。所以SpringCloud Zuul無(wú)法擺脫servlet模型的弊端。

Gateway模型

傳統(tǒng)的Web框架，比如說(shuō): Struts2，SpringMVC等都是基于Servlet APl與Servlet容器基礎(chǔ)之上運(yùn)行的。

但是在Servlet3.1之后有了異步非阻塞的支持。而WebFlux是一個(gè)典型非阻塞異步的框架，它的核心是基于Reactor的相關(guān)API實(shí)現(xiàn)的。相對(duì)于傳統(tǒng)的web框架來(lái)說(shuō)，它可以運(yùn)行在諸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞式+函數(shù)式編程(Spring 5必須讓你使用Java 8)。

Spring WebFlux是Spring 5.0 引入的新的響應(yīng)式框架，區(qū)別于Spring MVC，它不需要依賴Servlet APl，它是完全異步非阻塞的，并且基于Reactor來(lái)實(shí)現(xiàn)響應(yīng)式流規(guī)范。

二十七、GateWay有三個(gè)核心概念，你知道是什么嗎？

1、Route(路由) - 路由是構(gòu)建網(wǎng)關(guān)的基本模塊，它由ID，目標(biāo)URI，一系列的斷言和過(guò)濾器組成，如斷言為true則匹配該路由。

2、Predicate(斷言) - 參考的是Java8的java.util.function.Predicate，開(kāi)發(fā)人員可以匹配HTTP請(qǐng)求中的所有內(nèi)容(例如請(qǐng)求頭或請(qǐng)求參數(shù))，如果請(qǐng)求與斷言相匹配則進(jìn)行路由。

3、Filter(過(guò)濾) - 指的是Spring框架中GatewayFilter的實(shí)例，使用過(guò)濾器，可以在請(qǐng)求被路由前或者之后對(duì)請(qǐng)求進(jìn)行修改。

舉例：我去醫(yī)院看牙科（請(qǐng)求），門衛(wèi)大爺（Filter過(guò)濾）說(shuō)不管你要看什么，必須先做核酸。當(dāng)我做完核酸后門衛(wèi)大爺讓我進(jìn)去了。這時(shí)我拿著手機(jī)上的掛號(hào)信息與醫(yī)院的掛號(hào)信息相匹配（Predicate斷言），匹配上了我可以找大夫看病了（路由）。

二十八、GateWay常用的Predicate斷言有哪些？

After：比如在某段時(shí)間后才可以執(zhí)行路由。這個(gè)After大多用在維護(hù)開(kāi)服時(shí)間，比如游戲準(zhǔn)備22年10月1日開(kāi)服，那用After可以設(shè)置此時(shí)間之后的路由才好使。

Before：與After異曲同工。

Between：在兩個(gè)時(shí)間段內(nèi)才可執(zhí)行路由。

Cookie：通過(guò)Cookie值去匹配。

Header：根據(jù)請(qǐng)求頭信息來(lái)進(jìn)行匹配。

二十九、GateWay中自定義全局過(guò)濾器如何實(shí)現(xiàn)？

主要實(shí)現(xiàn)兩個(gè)接口：

• GlobalFilter
• Ordered

三十、SpringCloud Config是什么？有什么用處？

config是分布式配置中心，分布式系統(tǒng)面臨的問(wèn)題是，微服務(wù)意味著要將單體應(yīng)用中的業(yè)務(wù)拆分成一個(gè)個(gè)子服務(wù)，每個(gè)服務(wù)的粒度相對(duì)較小，因此系統(tǒng)中會(huì)出現(xiàn)大量的服務(wù)。由于每個(gè)服務(wù)都需要必要的配置信息才能運(yùn)行，所以一套集中式的、動(dòng)態(tài)的配置管理設(shè)施是必不可少的。

比如你現(xiàn)在有40個(gè)微服務(wù)都用的一個(gè)叫test的數(shù)據(jù)庫(kù)，如果我們修改了數(shù)據(jù)庫(kù)的名字，那還要每個(gè)微服務(wù)的配置文件都改一遍嗎，所以我們需要Config進(jìn)行集中式管理。

三十一、SpringCloud中，使用過(guò)全局事件總線bus嗎？如果使用過(guò)請(qǐng)簡(jiǎn)單的談一談

bus一般配合config進(jìn)行使用，config配置中心具有一個(gè)痛點(diǎn)，就是當(dāng)你改了配置文件，你需要一個(gè)個(gè)的手動(dòng)去通知到下面的服務(wù)，這樣很麻煩。而bus就輕松的解決了這點(diǎn)，Spring Cloud Bus目前支持RabbitMQ和Kafka。

ConfigClient實(shí)例都會(huì)監(jiān)聽(tīng)MQ中同一個(gè)topic(默認(rèn)是Spring Cloud Bus)。當(dāng)一個(gè)服務(wù)刷新數(shù)據(jù)的時(shí)候，它會(huì)把這個(gè)信息放入到Topic中，這樣其它監(jiān)聽(tīng)同一Topic的服務(wù)就能得到通知，然后去更新自身的配置。

三十二、SpringCloud中，使用過(guò)Stream消息驅(qū)動(dòng)嗎？如果使用過(guò)請(qǐng)簡(jiǎn)單的談一談

常見(jiàn)MQ(消息中間件)：

• ActiveMQ
• RabbitMQ
• RocketMQ
• Kafka

有沒(méi)有一種新的技術(shù)誕生，讓我們不再關(guān)注具體MQ的細(xì)節(jié)，我們只需要用一種適配綁定的方式，自動(dòng)的給我們?cè)诟鞣NMQ內(nèi)切換。（類似于Hibernate）

Cloud Stream是什么？屏蔽底層消息中間件的差異，降低切換成本，統(tǒng)一消息的編程模型。

其實(shí)Hibernate就是這個(gè)意思，我們不用關(guān)心它用的是oracle還是mysql，它給我們提供了session.create()，我們用就好了，不用關(guān)心具體的語(yǔ)法，我們也不可能所有數(shù)據(jù)庫(kù)都精通。

比方說(shuō)我們用到了RabbitMQ和Kafka，由于這兩個(gè)消息中間件的架構(gòu)上的不同，像RabbitMQ有exchange，kafka有Topic和Partitions分區(qū)。

這些中間件的差異性導(dǎo)致我們實(shí)際項(xiàng)目開(kāi)發(fā)給我們?cè)斐闪艘欢ǖ睦_，我們?nèi)绻昧藘蓚€(gè)消息隊(duì)列的其中一種，后面的業(yè)務(wù)需求，我想往另外一種消息隊(duì)列進(jìn)行遷移，這時(shí)候無(wú)疑就是一個(gè)災(zāi)難性的，一大堆東西都要重新推倒重新做，因?yàn)樗覀兊南到y(tǒng)耦合了，這時(shí)候Spring Cloud Stream給我們提供了—種解耦合的方式。

三十三、假如說(shuō)我們的分布式項(xiàng)目鏈路很多，有很多節(jié)點(diǎn)，那么如何跟蹤這些鏈路呢？

使用SpringCloud Sleuth技術(shù)。在微服務(wù)框架中，一個(gè)由客戶端發(fā)起的請(qǐng)求在后端系統(tǒng)中會(huì)經(jīng)過(guò)多個(gè)不同的的服務(wù)節(jié)點(diǎn)調(diào)用來(lái)協(xié)同產(chǎn)生最后的請(qǐng)求結(jié)果，每一個(gè)前段請(qǐng)求都會(huì)形成一條復(fù)雜的分布式服務(wù)調(diào)用鏈路，鏈路中的任何一環(huán)出現(xiàn)高延時(shí)或錯(cuò)誤都會(huì)引起整個(gè)請(qǐng)求最后的失敗。通過(guò)Sleuth技術(shù)可以通過(guò)頁(yè)面來(lái)對(duì)各個(gè)節(jié)點(diǎn)鏈路進(jìn)行跟蹤，哪個(gè)節(jié)點(diǎn)出了問(wèn)題，都會(huì)有所展現(xiàn)。

三十四、除了Eureka、Zookeeper、Consul，你還知道什么服務(wù)注冊(cè)中心的組件嗎？

知道，還有阿里出的Nacos。Nacos就是注冊(cè)中心＋配置中心的組合 -> Nacos = Eureka+Config+Bus?？梢蕴娲鶨ureka做服務(wù)注冊(cè)中心，還可以替代Config做服務(wù)配置中心。

三十五、你剛剛提到Nacos，那與其它幾種注冊(cè)中心組件有什么區(qū)別嗎？

?Nacos支持AP和CP模式的切換。

三十六、Hystrix與Sentinel有什么區(qū)別嗎？

首先它們倆都相當(dāng)于斷路器的作用，用來(lái)服務(wù)降級(jí)、服務(wù)熔斷、流量控制等功能。

區(qū)別在于：

????????Hystrix

????????????????需要我們程序員自己手工搭建監(jiān)控平臺(tái)。

????????????????沒(méi)有一套web界面可以給我們進(jìn)行更加細(xì)粒度化得配置流控、速率控制、服務(wù)熔斷、服務(wù)降級(jí)。

????????Sentinel

????????????????單獨(dú)一個(gè)組件，可以獨(dú)立出來(lái)。

????????????????直接界面化的細(xì)粒度統(tǒng)一配置。

三十七、簡(jiǎn)單說(shuō)一說(shuō)Sentinel都有哪些流控規(guī)則？

（1）QPS：當(dāng)每秒超過(guò)設(shè)定的QPS就會(huì)失敗。

（2）線程數(shù)：表示一個(gè)時(shí)間段只能有1個(gè)（自己隨便設(shè)定）線程數(shù)訪問(wèn)。

（3）關(guān)聯(lián)：當(dāng)關(guān)聯(lián)的資源達(dá)到閾值時(shí)，就限流自己。當(dāng)與A關(guān)聯(lián)的資源B達(dá)到閾值時(shí)，就限流A自己。B惹事，A掛了。

（4）預(yù)熱：一個(gè)系統(tǒng)最怕平常訪問(wèn)量是0，然后突然一秒鐘那一瞬間訪問(wèn)量是10萬(wàn)，這時(shí)候就不太好了，應(yīng)該先預(yù)熱一下。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-653410.html

到了這里，關(guān)于SpringCloud最新最全面試題的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！