SpringCloud必知的面試題有哪些

本篇內(nèi)容主要講解“SpringCloud必知的面試題有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“SpringCloud必知的面試題有哪些”吧!

1、什么是Spring Cloud？

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

2、使用Spring Cloud有什么優(yōu)勢(shì)？

使用Spring Boot開(kāi)發(fā)分布式微服務(wù)時(shí)，我們面臨以下問(wèn)題:

與分布式系統(tǒng)相關(guān)的復(fù)雜性-這種開(kāi)銷(xiāo)包括網(wǎng)絡(luò)問(wèn)題，延遲開(kāi)銷(xiāo)，帶寬問(wèn)題，安全問(wèn)題。

服務(wù)發(fā)現(xiàn)-服務(wù)發(fā)現(xiàn)工具管理群集中的流程和服務(wù)如何查找和互相交談。它涉及一個(gè)服務(wù)目錄，在該目錄中注冊(cè)服務(wù)，然后能夠查找并連接到該目錄中的服務(wù)。

冗余-分布式系統(tǒng)中的冗余問(wèn)題。

負(fù)載平衡 --負(fù)載平衡改善跨多個(gè)計(jì)算資源的工作負(fù)荷，諸如計(jì)算機(jī)，計(jì)算機(jī)集群，網(wǎng)絡(luò)鏈路，中央處理單元，或磁盤(pán)驅(qū)動(dòng)器的分布。

性能-問(wèn)題 由于各種運(yùn)營(yíng)開(kāi)銷(xiāo)導(dǎo)致的性能問(wèn)題。部署復(fù)雜性-Devops技能的要求。

3、服務(wù)注冊(cè)和發(fā)現(xiàn)是什么意思？Spring Cloud如何實(shí)現(xiàn)？

當(dāng)我們開(kāi)始一個(gè)項(xiàng)目時(shí)，我們通常在屬性文件中進(jìn)行所有的配置。隨著越來(lái)越多的服務(wù)開(kāi)發(fā)和部署，添加和修改這些屬性變得更加復(fù)雜。有些服務(wù)可能會(huì)下降，而某些位置可能會(huì)發(fā)生變化。手動(dòng)更改屬性可能會(huì)產(chǎn)生問(wèn)題。 Eureka服務(wù)注冊(cè)和發(fā)現(xiàn)可以在這種情況下提供幫助。由于所有服務(wù)都在Eureka服務(wù)器上注冊(cè)并通過(guò)調(diào)用Eureka服務(wù)器完成查找，因此無(wú)需處理服務(wù)地點(diǎn)的任何更改和處理。

4、負(fù)載平衡的意義什么？

在計(jì)算中，負(fù)載平衡可以改善跨計(jì)算機(jī)，計(jì)算機(jī)集群，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤(pán)驅(qū)動(dòng)器等多種計(jì)算資源的工作負(fù)載分布。負(fù)載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應(yīng)時(shí)間并避免任何單一資源的過(guò)載。使用多個(gè)組件進(jìn)行負(fù)載平衡而不是單個(gè)組件可能會(huì)通過(guò)冗余來(lái)提高可靠性和可用性。負(fù)載平衡通常涉及專(zhuān)用軟件或硬件，例如多層交換機(jī)或域名系統(tǒng)服務(wù)器進(jìn)程。

5、什么是Hystrix？它如何實(shí)現(xiàn)容錯(cuò)？ 

Hystrix是一個(gè)延遲和容錯(cuò)庫(kù)，旨在隔離遠(yuǎn)程系統(tǒng)，服務(wù)和第三方庫(kù)的訪(fǎng)問(wèn)點(diǎn)，當(dāng)出現(xiàn)故障是不可避免的故障時(shí)，停止級(jí)聯(lián)故障并在復(fù)雜的分布式系統(tǒng)中實(shí)現(xiàn)彈性。

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

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

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

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

簡(jiǎn)化圖如下所示：

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

6、什么是Hystrix斷路器？我們需要它嗎？ 

由于某些原因，employee-consumer公開(kāi)服務(wù)會(huì)引發(fā)異常。在這種情況下使用Hystrix我們定義了一個(gè)回退方法。如果在公開(kāi)服務(wù)中發(fā)生異常，則回退方法返回一些默認(rèn)值。

如果firstPage method() 中的異常繼續(xù)發(fā)生，則Hystrix電路將中斷，并且員工使用者將一起跳過(guò)firtsPage方法，并直接調(diào)用回退方法。斷路器的目的是給第一頁(yè)方法或第一頁(yè)方法可能調(diào)用的其他方法留出時(shí)間，并導(dǎo)致異?；謴?fù)?？赡馨l(fā)生的情況是，在負(fù)載較小的情況下，導(dǎo)致異常的問(wèn)題有更好的恢復(fù)機(jī)會(huì) 。

7、什么是Netflix Feign？它的優(yōu)點(diǎn)是什么？

Feign是受到Retrofit，JAXRS-2.0和WebSocket啟發(fā)的java客戶(hù)端聯(lián)編程序。Feign的第一個(gè)目標(biāo)是將約束分母的復(fù)雜性統(tǒng)一到http apis，而不考慮其穩(wěn)定性。在employee-consumer的例子中，我們使用了employee-producer使用REST模板公開(kāi)的REST服務(wù)。

但是我們必須編寫(xiě)大量代碼才能執(zhí)行以下步驟:

1、使用功能區(qū)進(jìn)行負(fù)載平衡。

2、獲取服務(wù)實(shí)例，然后獲取基本URL。

3、利用REST模板來(lái)使用服務(wù)。前面的代碼如下:

@Controller  public class ConsumerControllerClient {  @Autowired  private LoadBalancerClient loadBalancer;  public void getEmployee() throws RestClientException, IOException {      ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");      System.out.println(serviceInstance.getUri());      String baseUrl=serviceInstance.getUri().toString();      baseUrlbaseUrl=baseUrl+"/employee";      RestTemplate restTemplate = new RestTemplate();      ResponseEntity<String> response=null;      try{      response=restTemplate.exchange(baseUrl,              HttpMethod.GET, getHeaders(),String.class);      }catch (Exception ex)      {          System.out.println(ex);      }      System.out.println(response.getBody());  }

之前的代碼，有像NullPointer這樣的例外的機(jī)會(huì)，并不是最優(yōu)的。我們將看到如何使用Netflix Feign使呼叫變得更加輕松和清潔。如果Netflix Ribbon依賴(lài)關(guān)系也在類(lèi)路徑中，那么Feign默認(rèn)也會(huì)負(fù)責(zé)負(fù)載平衡。

8、什么是Spring Cloud Bus？我們需要它嗎？ 

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

下面的例子中多個(gè)員工生產(chǎn)者模塊從Employee Config Module獲取Eureka注冊(cè)的財(cái)產(chǎn)。

如果假設(shè)GIT中的Eureka注冊(cè)屬性更改為指向另一臺(tái)Eureka服務(wù)器，會(huì)發(fā)生什么情況。在這種情況下，我們將不得不重新啟動(dòng)服務(wù)以獲取更新的屬性。

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

Spring Cloud Bus提供了跨多個(gè)實(shí)例刷新配置的功能。因此，在上面的示例中，如果我們刷新Employee Producer1，則會(huì)自動(dòng)刷新所有其他必需的模塊。如果我們有多個(gè)微服務(wù)啟動(dòng)并運(yùn)行，這特別有用。這是通過(guò)將所有微服務(wù)連接到單個(gè)消息代理來(lái)實(shí)現(xiàn)的。無(wú)論何時(shí)刷新實(shí)例，此事件都會(huì)訂閱到偵聽(tīng)此代理的所有微服務(wù)，并且它們也會(huì)刷新。可以通過(guò)使用端點(diǎn)/總線(xiàn)/刷新來(lái)實(shí)現(xiàn)對(duì)任何單個(gè)實(shí)例的刷新。

9、SpringCloud和Dubbo

SpringCloud和Dubbo都是現(xiàn)在主流的微服務(wù)架構(gòu)；

SpringCloud是Apache旗下的Spring體系下的微服務(wù)解決方案；

Dubbo是阿里系的分布式服務(wù)治理框架。

從技術(shù)維度上,其實(shí)SpringCloud遠(yuǎn)遠(yuǎn)的超過(guò)Dubbo,Dubbo本身只是實(shí)現(xiàn)了服務(wù)治理,而SpringCloud現(xiàn)在以及有21個(gè)子項(xiàng)目以后還會(huì)更多。

所以其實(shí)很多人都會(huì)說(shuō)Dubbo和SpringCloud是不公平的

但是由于RPC以及注冊(cè)中心元數(shù)據(jù)等原因,在技術(shù)選型的時(shí)候我們只能二者選其一,所以我們常常為用他倆來(lái)對(duì)比。

服務(wù)的調(diào)用方式Dubbo使用的是RPC遠(yuǎn)程調(diào)用,而SpringCloud使用的是 Rest API,其實(shí)更符合微服務(wù)官方的定義。

服務(wù)的注冊(cè)中心來(lái)看,Dubbo使用了第三方的ZooKeeper作為其底層的注冊(cè)中心,實(shí)現(xiàn)服務(wù)的注冊(cè)和發(fā)現(xiàn),SpringCloud使用Spring Cloud Netflix Eureka實(shí)現(xiàn)注冊(cè)中心,當(dāng)然SpringCloud也可以使用ZooKeeper實(shí)現(xiàn),但一般我們不會(huì)這樣做。

服務(wù)網(wǎng)關(guān),Dubbo并沒(méi)有本身的實(shí)現(xiàn),只能通過(guò)其他第三方技術(shù)的整合,而SpringCloud有Zuul路由網(wǎng)關(guān),作為路由服務(wù)器,進(jìn)行消費(fèi)者的請(qǐng)求分發(fā),SpringCloud還支持?jǐn)嗦菲?與git完美集成分布式配置文件支持版本控制,事務(wù)總線(xiàn)實(shí)現(xiàn)配置文件的更新與服務(wù)自動(dòng)裝配等等一系列的微服務(wù)架構(gòu)要素。

10、技術(shù)選型

目前國(guó)內(nèi)的分布式系統(tǒng)選型主要還是Dubbo畢竟國(guó)產(chǎn),而且國(guó)內(nèi)工程師的技術(shù)熟練程度高,并且Dubbo在其他維度上的缺陷可以由其他第三方框架進(jìn)行集成進(jìn)行彌補(bǔ)

而SpringCloud目前是國(guó)外比較流行,當(dāng)然我覺(jué)得國(guó)內(nèi)的市場(chǎng)也會(huì)慢慢的偏向SpringCloud,就連劉軍作為Dubbo重啟的負(fù)責(zé)人也發(fā)表過(guò)觀(guān)點(diǎn),Dubbo的發(fā)展方向是積極適應(yīng)SpringCloud生態(tài),并不是起沖突

11、Rest和RPC對(duì)比

其實(shí)如果仔細(xì)閱讀過(guò)微服務(wù)提出者馬丁福勒的論文的話(huà)可以發(fā)現(xiàn)其定義的服務(wù)間通信機(jī)制就是Http Rest

RPC最主要的缺陷就是服務(wù)提供方和調(diào)用方式之間依賴(lài)太強(qiáng),我們需要為每一個(gè)微服務(wù)進(jìn)行接口的定義,并通過(guò)持續(xù)繼承發(fā)布,需要嚴(yán)格的版本控制才不會(huì)出現(xiàn)服務(wù)提供和調(diào)用之間因?yàn)榘姹静煌a(chǎn)生的沖突

而REST是輕量級(jí)的接口,服務(wù)的提供和調(diào)用不存在代碼之間的耦合,只是通過(guò)一個(gè)約定進(jìn)行規(guī)范,但也有可能出現(xiàn)文檔和接口不一致而導(dǎo)致的服務(wù)集成問(wèn)題,但可以通過(guò)swagger工具整合,是代碼和文檔一體化解決,所以REST在分布式環(huán)境下比RPC更加靈活

這也是為什么當(dāng)當(dāng)網(wǎng)的DubboX在對(duì)Dubbo的增強(qiáng)中增加了對(duì)REST的支持的原因

12、文檔質(zhì)量和社區(qū)活躍度

SpringCloud社區(qū)活躍度遠(yuǎn)高于Dubbo,畢竟由于梁飛團(tuán)隊(duì)的原因?qū)е翫ubbo停止更新迭代五年,而中小型公司無(wú)法承擔(dān)技術(shù)開(kāi)發(fā)的成本導(dǎo)致Dubbo社區(qū)嚴(yán)重低落,而SpringCloud異軍突起,迅速占領(lǐng)了微服務(wù)的市場(chǎng),背靠Spring混的風(fēng)生水起

Dubbo經(jīng)過(guò)多年的積累文檔相當(dāng)成熟,對(duì)于微服務(wù)的架構(gòu)體系各個(gè)公司也有穩(wěn)定的現(xiàn)狀

13、SpringBoot和SpringCloud

SpringBoot是Spring推出用于解決傳統(tǒng)框架配置文件冗余,裝配組件繁雜的基于Maven的解決方案,旨在快速搭建單個(gè)微服務(wù)

而SpringCloud專(zhuān)注于解決各個(gè)微服務(wù)之間的協(xié)調(diào)與配置,服務(wù)之間的通信,熔斷,負(fù)載均衡等,技術(shù)維度并相同,并且SpringCloud是依賴(lài)于SpringBoot的,而SpringBoot并不是依賴(lài)與SpringCloud,甚至還可以和Dubbo進(jìn)行優(yōu)秀的整合開(kāi)發(fā)

總結(jié):

1、SpringBoot專(zhuān)注于快速方便的開(kāi)發(fā)單個(gè)個(gè)體的微服務(wù) 

2、SpringCloud是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架,整合并管理各個(gè)微服務(wù),為各個(gè)微服務(wù)之間提供,配置管理,服務(wù)發(fā)現(xiàn),斷路器,路由,事件總線(xiàn)等集成服務(wù)

3、SpringBoot不依賴(lài)于SpringCloud,SpringCloud依賴(lài)于SpringBoot,屬于依賴(lài)關(guān)系

4、SpringBoot專(zhuān)注于快速,方便的開(kāi)發(fā)單個(gè)的微服務(wù)個(gè)體,SpringCloud關(guān)注全局的服務(wù)治理框架

14、Eureka和ZooKeeper都可以提供服務(wù)注冊(cè)與發(fā)現(xiàn)的功能,請(qǐng)說(shuō)說(shuō)兩個(gè)的區(qū)別

1.ZooKeeper保證的是CP,Eureka保證的是AP

ZooKeeper在選舉期間注冊(cè)服務(wù)癱瘓,雖然服務(wù)最終會(huì)恢復(fù),但是選舉期間不可用的

Eureka各個(gè)節(jié)點(diǎn)是平等關(guān)系,只要有一臺(tái)Eureka就可以保證服務(wù)可用,而查詢(xún)到的數(shù)據(jù)并不是最新的

自我保護(hù)機(jī)制會(huì)導(dǎo)致：

Eureka不再?gòu)淖?cè)列表移除因長(zhǎng)時(shí)間沒(méi)收到心跳而應(yīng)該過(guò)期的服務(wù)

Eureka仍然能夠接受新服務(wù)的注冊(cè)和查詢(xún)請(qǐng)求,但是不會(huì)被同步到其他節(jié)點(diǎn)(高可用)

當(dāng)網(wǎng)絡(luò)穩(wěn)定時(shí),當(dāng)前實(shí)例新的注冊(cè)信息會(huì)被同步到其他節(jié)點(diǎn)中(最終一致性)

Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況,而不會(huì)像ZooKeeper一樣使得整個(gè)注冊(cè)系統(tǒng)癱瘓

2.ZooKeeper有Leader和Follower角色,Eureka各個(gè)節(jié)點(diǎn)平等

3.ZooKeeper采用過(guò)半數(shù)存活原則,Eureka采用自我保護(hù)機(jī)制解決分區(qū)問(wèn)題

4.Eureka本質(zhì)上是一個(gè)工程,而ZooKeeper只是一個(gè)進(jìn)程

15、微服務(wù)之間是如何獨(dú)立通訊的

微服務(wù)通信機(jī)制：

系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。

圍繞業(yè)務(wù)能力組織服務(wù)、自動(dòng)化部署、智能端點(diǎn)、對(duì)語(yǔ)言及數(shù)據(jù)的去集中化控制。

將組件定義為可被獨(dú)立替換和升級(jí)的軟件單元。

以業(yè)務(wù)能力為出發(fā)點(diǎn)組織服務(wù)的策略。

倡導(dǎo)誰(shuí)開(kāi)發(fā)，誰(shuí)運(yùn)營(yíng)的開(kāi)發(fā)運(yùn)維一體化方法。

RESTful HTTP協(xié)議是微服務(wù)架構(gòu)中最常用的通訊機(jī)制。

每個(gè)微服務(wù)可以考慮選用最佳工具完成(如不同的編程語(yǔ)言)。

允許不同微服務(wù)采用不同的數(shù)據(jù)持久化技術(shù)。

微服務(wù)非常重視建立架構(gòu)及業(yè)務(wù)相關(guān)指標(biāo)的實(shí)時(shí)監(jiān)控和日志機(jī)制，必須考慮每個(gè)服務(wù)的失敗容錯(cuò)機(jī)制。

注重快速更新，因此系統(tǒng)會(huì)隨時(shí)間不斷變化及演進(jìn)?？商娲阅K化設(shè)計(jì)。

微服務(wù)通信方式：   

同步：RPC，REST等   

異步：消息隊(duì)列。要考慮消息可靠傳輸、高性能，以及編程模型的變化等。

消息隊(duì)列中間件如何選型：

1.協(xié)議：AMQP、STOMP、MQTT、私有協(xié)議等。

2.消息是否需要持久化。

3.吞吐量。

4.高可用支持，是否單點(diǎn)。

5.分布式擴(kuò)展能力。

6.消息堆積能力和重放能力。

7.開(kāi)發(fā)便捷，易于維護(hù)。

8.社區(qū)成熟度。

RabbitMQ是一個(gè)實(shí)現(xiàn)了AMQP(高級(jí)消息隊(duì)列協(xié)議)協(xié)議的消息隊(duì)列中間件。RabbitMQ支持其中的最多一次和最少一次兩種。網(wǎng)易蜂巢平臺(tái)的服務(wù)架構(gòu)，服務(wù)間通過(guò)RabbitMQ實(shí)現(xiàn)通信。

16、什么是服務(wù)熔斷?什么是服務(wù)降級(jí)

在復(fù)雜的分布式系統(tǒng)中,微服務(wù)之間的相互調(diào)用,有可能出現(xiàn)各種各樣的原因?qū)е路?wù)的阻塞,在高并發(fā)場(chǎng)景下,服務(wù)的阻塞意味著線(xiàn)程的阻塞,導(dǎo)致當(dāng)前線(xiàn)程不可用,服務(wù)器的線(xiàn)程全部阻塞,導(dǎo)致服務(wù)器崩潰,由于服務(wù)之間的調(diào)用關(guān)系是同步的,會(huì)對(duì)整個(gè)微服務(wù)系統(tǒng)造成服務(wù)雪崩，為了解決某個(gè)微服務(wù)的調(diào)用響應(yīng)時(shí)間過(guò)長(zhǎng)或者不可用進(jìn)而占用越來(lái)越多的系統(tǒng)資源引起雪崩效應(yīng)就需要進(jìn)行服務(wù)熔斷和服務(wù)降級(jí)處理。

所謂的服務(wù)熔斷指的是某個(gè)服務(wù)故障或異常一起類(lèi)似顯示世界中的“保險(xiǎn)絲"當(dāng)某個(gè)異常條件被觸發(fā)就直接熔斷整個(gè)服務(wù)，而不是一直等到此服務(wù)超時(shí)。

服務(wù)熔斷就是相當(dāng)于我們電閘的保險(xiǎn)絲,一旦發(fā)生服務(wù)雪崩的,就會(huì)熔斷整個(gè)服務(wù),通過(guò)維護(hù)一個(gè)自己的線(xiàn)程池,當(dāng)線(xiàn)程達(dá)到閾值的時(shí)候就啟動(dòng)服務(wù)降級(jí),如果其他請(qǐng)求繼續(xù)訪(fǎng)問(wèn)就直接返回fallback的默認(rèn)值。

17、微服務(wù)的優(yōu)缺點(diǎn)分別是什么?說(shuō)下你在項(xiàng)目開(kāi)發(fā)中碰到的坑

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

每一個(gè)服務(wù)足夠內(nèi)聚,代碼容易理解

開(kāi)發(fā)效率提高,一個(gè)服務(wù)只做一件事

微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā)       

微服務(wù)是松耦合的,是有功能意義的服務(wù)       

可以用不同的語(yǔ)言開(kāi)發(fā),面向接口編程

易于與第三方集成       

微服務(wù)只是業(yè)務(wù)邏輯的代碼,不會(huì)和HTML,CSS或者其他界面組合         

開(kāi)發(fā)中,兩種開(kāi)發(fā)模式               

前后端分離               

全棧工程師       

可以靈活搭配,連接公共庫(kù)/連接獨(dú)立庫(kù)   

缺點(diǎn):     

分布式系統(tǒng)的負(fù)責(zé)性;多服務(wù)運(yùn)維難度,隨著服務(wù)的增加,運(yùn)維的壓力也在增大;系統(tǒng)部署依賴(lài);服務(wù)間通信成本;數(shù)據(jù)一致性;系統(tǒng)集成測(cè)試;性能監(jiān)控.

18、你所知道的微服務(wù)技術(shù)棧有哪些?請(qǐng)列舉一二

多種技術(shù)的集合體

我們?cè)谟懻撘粋€(gè)分布式的微服務(wù)架構(gòu)的話(huà),需要哪些維度

維度(SpringCloud)       

服務(wù)開(kāi)發(fā)            SpringBoot            Spring            SpringMVC        服務(wù)配置與管理            Netfilx公司的Archaiusm,阿里的Diamond        服務(wù)注冊(cè)與發(fā)現(xiàn)            Eureka,ZooKeeper        服務(wù)調(diào)用            Rest,RPC,gRPC        服務(wù)熔斷器            Hystrix        服務(wù)負(fù)載均衡            Ribbon,Nginx        服務(wù)接口調(diào)用            Feign        消息隊(duì)列            Kafka,RabbitMq,ActiveMq        服務(wù)配置中心管理            SpringCloudConfing        服務(wù)路由(API網(wǎng)關(guān))            Zuul        事件消息總線(xiàn)            SpringCloud Bus

到此，相信大家對(duì)“SpringCloud必知的面試題有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢(xún)，關(guān)注我們，繼續(xù)學(xué)習(xí)！