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

1、什么是Spring Cloud？

Spring cloud流應用程序啟動器是基于Spring Boot的Spring集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命周期短暫的微服務框架，用于快速構建執行有限數據處理的應用程序。

2、使用Spring Cloud有什么優勢？

使用Spring Boot開發分布式微服務時，我們面臨以下問題:

與分布式系統相關的復雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。

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

冗余-分布式系統中的冗余問題。

負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計算機，計算機集群，網絡鏈路，中央處理單元，或磁盤驅動器的分布。

性能-問題 由于各種運營開銷導致的性能問題。部署復雜性-Devops技能的要求。

3、服務注冊和發現是什么意思？Spring Cloud如何實現？

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

4、負載平衡的意義什么？

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

5、什么是Hystrix？它如何實現容錯？ 

Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，停止級聯故障并在復雜的分布式系統中實現彈性。

通常對于使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協作。 

思考以下微服務：

假設如果上圖中的微服務9失敗了，那么使用傳統方法我們將傳播一個異常。但這仍然會導致整個系統崩潰。 

隨著微服務數量的增加，這個問題變得更加復雜。微服務的數量可以高達1000.這是hystrix出現的地方 我們將使用Hystrix在這種情況下的Fallback方法功能。我們有兩個服務employee-consumer使用由employee-consumer公開的服務。 

簡化圖如下所示：

現在假設由于某種原因，employee-producer公開的服務會拋出異常。我們在這種情況下使用Hystrix定義了一個回退方法。這種后備方法應該具有與公開服務相同的返回類型。如果暴露服務中出現異常，則回退方法將返回一些值。

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

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

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

7、什么是Netflix Feign？它的優點是什么？

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

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

1、使用功能區進行負載平衡。

2、獲取服務實例，然后獲取基本URL。

3、利用REST模板來使用服務。前面的代碼如下: 

@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這樣的例外的機會，并不是最優的。我們將看到如何使用Netflix Feign使呼叫變得更加輕松和清潔。如果Netflix Ribbon依賴關系也在類路徑中，那么Feign默認也會負責負載平衡。

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

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

下面的例子中多個員工生產者模塊從Employee Config Module獲取Eureka注冊的財產。

如果假設GIT中的Eureka注冊屬性更改為指向另一臺Eureka服務器，會發生什么情況。在這種情況下，我們將不得不重新啟動服務以獲取更新的屬性。

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

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

9、SpringCloud和Dubbo

SpringCloud和Dubbo都是現在主流的微服務架構；

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

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

從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及有21個子項目以后還會更多。

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

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

服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義。

服務的注冊中心來看,Dubbo使用了第三方的ZooKeeper作為其底層的注冊中心,實現服務的注冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現注冊中心,當然SpringCloud也可以使用ZooKeeper實現,但一般我們不會這樣做。

服務網關,Dubbo并沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作為路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分布式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

10、技術選型

目前國內的分布式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,并且Dubbo在其他維度上的缺陷可以由其他第三方框架進行集成進行彌補

而SpringCloud目前是國外比較流行,當然我覺得國內的市場也會慢慢的偏向SpringCloud,就連劉軍作為Dubbo重啟的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,并不是起沖突

11、Rest和RPC對比

其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest

RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要為每一個微服務進行接口的定義,并通過持續繼承發布,需要嚴格的版本控制才不會出現服務提供和調用之間因為版本不同而產生的沖突

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

這也是為什么當當網的DubboX在對Dubbo的增強中增加了對REST的支持的原因

12、文檔質量和社區活躍度

SpringCloud社區活躍度遠高于Dubbo,畢竟由于梁飛團隊的原因導致Dubbo停止更新迭代五年,而中小型公司無法承擔技術開發的成本導致Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速占領了微服務的市場,背靠Spring混的風生水起

Dubbo經過多年的積累文檔相當成熟,對于微服務的架構體系各個公司也有穩定的現狀

13、SpringBoot和SpringCloud

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

而SpringCloud專注于解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等,技術維度并相同,并且SpringCloud是依賴于SpringBoot的,而SpringBoot并不是依賴與SpringCloud,甚至還可以和Dubbo進行優秀的整合開發

總結:

1、SpringBoot專注于快速方便的開發單個個體的微服務   

2、SpringCloud是關注全局的微服務協調整理治理框架,整合并管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務

3、SpringBoot不依賴于SpringCloud,SpringCloud依賴于SpringBoot,屬于依賴關系

4、SpringBoot專注于快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架

14、Eureka和ZooKeeper都可以提供服務注冊與發現的功能,請說說兩個的區別

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

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

Eureka各個節點是平等關系,只要有一臺Eureka就可以保證服務可用,而查詢到的數據并不是最新的

自我保護機制會導致：

Eureka不再從注冊列表移除因長時間沒收到心跳而應該過期的服務

Eureka仍然能夠接受新服務的注冊和查詢請求,但是不會被同步到其他節點(高可用)

當網絡穩定時,當前實例新的注冊信息會被同步到其他節點中(最終一致性)

Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統癱瘓

2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等

3.ZooKeeper采用過半數存活原則,Eureka采用自我保護機制解決分區問題

4.Eureka本質上是一個工程,而ZooKeeper只是一個進程

15、微服務之間是如何獨立通訊的

微服務通信機制：

系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。

圍繞業務能力組織服務、自動化部署、智能端點、對語言及數據的去集中化控制。

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

以業務能力為出發點組織服務的策略。

倡導誰開發，誰運營的開發運維一體化方法。

RESTful HTTP協議是微服務架構中最常用的通訊機制。

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

允許不同微服務采用不同的數據持久化技術。

微服務非常重視建立架構及業務相關指標的實時監控和日志機制，必須考慮每個服務的失敗容錯機制。

注重快速更新，因此系統會隨時間不斷變化及演進。可替代性模塊化設計。

微服務通信方式：    

同步：RPC，REST等    

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

消息隊列中間件如何選型：

1.協議：AMQP、STOMP、MQTT、私有協議等。

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

3.吞吐量。

4.高可用支持，是否單點。

5.分布式擴展能力。

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

7.開發便捷，易于維護。

8.社區成熟度。

RabbitMQ是一個實現了AMQP(高級消息隊列協議)協議的消息隊列中間件。RabbitMQ支持其中的最多一次和最少一次兩種。網易蜂巢平臺的服務架構，服務間通過RabbitMQ實現通信。

16、什么是服務熔斷?什么是服務降級

在復雜的分布式系統中,微服務之間的相互調用,有可能出現各種各樣的原因導致服務的阻塞,在高并發場景下,服務的阻塞意味著線程的阻塞,導致當前線程不可用,服務器的線程全部阻塞,導致服務器崩潰,由于服務之間的調用關系是同步的,會對整個微服務系統造成服務雪崩，為了解決某個微服務的調用響應時間過長或者不可用進而占用越來越多的系統資源引起雪崩效應就需要進行服務熔斷和服務降級處理。

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

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

17、微服務的優缺點分別是什么?說下你在項目開發中碰到的坑

優點:        

每一個服務足夠內聚,代碼容易理解

開發效率提高,一個服務只做一件事 

微服務能夠被小團隊單獨開發        

微服務是松耦合的,是有功能意義的服務        

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

易于與第三方集成        

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

開發中,兩種開發模式                

前后端分離                

全棧工程師        

可以靈活搭配,連接公共庫/連接獨立庫    

缺點:       

分布式系統的負責性;多服務運維難度,隨著服務的增加,運維的壓力也在增大;系統部署依賴;服務間通信成本;數據一致性;系統集成測試;性能監控.

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

多種技術的集合體

我們在討論一個分布式的微服務架構的話,需要哪些維度

維度(SpringCloud)        

服務開發            SpringBoot            Spring            SpringMVC        服務配置與管理            Netfilx公司的Archaiusm,阿里的Diamond        服務注冊與發現            Eureka,ZooKeeper        服務調用            Rest,RPC,gRPC        服務熔斷器            Hystrix        服務負載均衡            Ribbon,Nginx        服務接口調用            Feign        消息隊列            Kafka,RabbitMq,ActiveMq        服務配置中心管理            SpringCloudConfing        服務路由(API網關)            Zuul        事件消息總線            SpringCloud Bus 

 

參考文獻：https://blog.csdn.net/moakun/article/details/82817757 

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