今天跟大家分享下SpringCloud常見面試題的知識。

1、什么是Spring Cloud？

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

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

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

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

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

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

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

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

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

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

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

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

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

Hystrix是一個延遲和容錯庫，旨在隔離遠(yuǎn)程系統(tǒng)，服務(wù)和第三方庫的訪問點(diǎn)，當(dāng)出現(xiàn)故障是不可避免的故障時，停止級聯(lián)故障并在復(fù)雜的分布式系統(tǒng)中實(shí)現(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ù)量可以高達(dá)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)異常，則回退方法將返回一些值。

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

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

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

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

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

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

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

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

3、利用REST模板來使用服務(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ī)會，并不是最優(yōu)的。我們將看到如何使用Netflix Feign使呼叫變得更加輕松和清潔。如果Netflix Ribbon依賴關(guān)系也在類路徑中，那么Feign默認(rèn)也會負(fù)責(zé)負(fù)載平衡。

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

考慮以下情況：我們有多個應(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ǎn)/刷新的方式。但是我們將不得不為每個模塊單獨(dú)調(diào)用這個url。例如，如果Employee Producer1部署在端口8080上，則調(diào)用 http：// localhost：8080 / refresh。同樣對于Employee Producer2 http：// localhost：8081 / refresh等等。這又很麻煩。這就是Spring Cloud Bus發(fā)揮作用的地方。 

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

9、SpringCloud和Dubbo

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

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

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

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

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

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

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

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

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

10、技術(shù)選型

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

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

11、Rest和RPC對比

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

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

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

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

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

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

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

13、SpringBoot和SpringCloud

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

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

總結(jié):

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

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

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

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

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

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

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

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

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

Eureka不再從注冊列表移除因長時間沒收到心跳而應(yīng)該過期的服務(wù)

Eureka仍然能夠接受新服務(wù)的注冊和查詢請求,但是不會被同步到其他節(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一樣使得整個注冊系統(tǒng)癱瘓

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注重快速更新，因此系統(tǒng)會隨時間不斷變化及演進(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.開發(fā)便捷，易于維護(hù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

易于與第三方集成        

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

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

前后端分離                

全棧工程師        

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

缺點(diǎn):       

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

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

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

我們在討論一個分布式的微服務(wù)架構(gòu)的話,需要哪些維度

維度(SpringCloud)        

服務(wù)開發(fā)            SpringBoot            Spring            SpringMVC        服務(wù)配置與管理            Netfilx公司的Archaiusm,阿里的Diamond        服務(wù)注冊與發(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        事件消息總線            SpringCloud Bus 

 

參考文獻(xiàn)：https://blog.csdn.net/moakun/article/details/82817757 

今天就分享這么多，如果覺得文章對你有一丟丟幫助，請點(diǎn)右下角【在看】，讓更多人看到該文章。