SpringCloud面試題及答案，面試官被摩擦系列

1. 什麼是 spring cloud？

spring cloud 是一系列框架的有序集合。它利用 spring boot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用 spring boot 的開發風格作到一鍵啓動和部署。

2. spring cloud 斷路器的做用是什麼？

在分佈式架構中，斷路器模式的做用也是相似的，當某個服務單元發生故障（相似用電器發生短路）以後，經過斷路器的故障監控（相似熔斷保險絲），向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間佔用不釋放，避免了故障在分佈式系統中的蔓延。

3. spring cloud 的核心組件有哪些？

• Eureka：服務註冊於發現。
• Feign：基於動態代理機制，根據註解和選擇的機器，拼接請求 url 地址，發起請求。
• Ribbon：實現負載均衡，從一個服務的多臺機器中選擇一臺。
• Hystrix：提供線程池，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題。
• Zuul：網關管理，由 Zuul 網關轉發請求給對應的服務。

4. 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完美集成分佈式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素

從技術選型上講~

目前國內的分佈式系統選型主要仍是Dubbo畢竟國產,並且國內工程師的技術熟練程度高,而且Dubbo在其餘維度上的缺陷能夠由其餘第三方框架進行集成進行彌補
而SpringCloud目前是國外比較流行,固然我以爲國內的市場也會慢慢的偏向SpringCloud,就連劉軍做爲Dubbo重啓的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並非起衝突

Rest和RPC對比

其實若是仔細閱讀過微服務提出者馬丁福勒的論文的話能夠發現其定義的服務間通訊機制就是Http Rest
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,咱們須要爲每個微服務進行接口的定義,並經過持續繼承發佈,須要嚴格的版本控制纔不會出現服務提供和調用之間由於版本不一樣而產生的衝突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是經過一個約定進行規範,但也有可能出現文檔和接口不一致而致使的服務集成問題,但能夠經過swagger工具整合,是代碼和文檔一體化解決,因此REST在分佈式環境下比RPC更加靈活
這也是爲何當當網的DubboX在對Dubbo的加強中增長了對REST的支持的緣由

文檔質量和社區活躍度

SpringCloud社區活躍度遠高於Dubbo,畢竟因爲梁飛團隊的緣由致使Dubbo中止更新迭代五年,而中小型公司沒法承擔技術開發的成本致使Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速佔領了微服務的市場,背靠Spring混的風生水起
Dubbo通過多年的積累文檔至關成熟,對於微服務的架構體系各個公司也有穩定的現狀

5. SpringBoot和SpringCloud

SpringBoot是Spring推出用於解決傳統框架配置文件冗餘,裝配組件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務
而SpringCloud專一於解決各個微服務之間的協調與配置,服務之間的通訊,熔斷,負載均衡等
技術維度並相同,而且SpringCloud是依賴於SpringBoot的,而SpringBoot並非依賴與SpringCloud,甚至還能夠和Dubbo進行優秀的整合開發

總結:

• SpringBoot專一於快速方便的開發單個個體的微服務
• SpringCloud是關注全局的微服務協調整理治理框架,整合並管理各個微服務,爲各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務
• SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關係
• SpringBoot專一於快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架

6. 微服務之間是如何獨立通信的

1.遠程過程調用（Remote Procedure Invocation）：

也就是咱們常說的服務的註冊與發現

直接經過遠程過程調用來訪問別的service。

優勢：

簡單，常見,由於沒有中間件代理，系統更簡單

缺點：

只支持請求/響應的模式，不支持別的，好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應

下降了可用性，由於客戶端和服務端在請求過程當中必須都是可用的

2.消息：

使用異步消息來作服務間通訊。服務間經過消息管道來交換消息，從而通訊。

優勢:

把客戶端和服務端解耦，更鬆耦合

提升可用性，由於消息中間件緩存了消息，直到消費者能夠消費

支持不少通訊機制好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應

缺點:

消息中間件有額外的複雜

7. 負載均衡的意義是什麼?

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

8. springcloud如何實現服務的註冊?

1.服務發佈時，指定對應的服務名,將服務註冊到 註冊中心(eureka zookeeper)
2.註冊中心加@EnableEurekaServer,服務用@EnableDiscoveryClient，而後用ribbon或feign進行服務直接的調用發現。

9. 什麼是服務熔斷?什麼是服務降級

在複雜的分佈式系統中,微服務之間的相互調用,有可能出現各類各樣的緣由致使服務的阻塞,在高併發場景下,服務的阻塞意味着線程的阻塞,致使當前線程不可用,服務器的線程所有阻塞,致使服務器崩潰,因爲服務之間的調用關係是同步的,會對整個微服務系統形成服務雪崩

爲了解決某個微服務的調用響應時間過長或者不可用進而佔用愈來愈多的系統資源引發雪崩效應就須要進行服務熔斷和服務降級處理。

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

服務熔斷就是至關於咱們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,經過維護一個本身的線程池,當線程達到閾值的時候就啓動服務降級,若是其餘請求繼續訪問就直接返回fallback的默認值

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

優勢

• 每個服務足夠內聚,代碼容易理解
• 開發效率提升,一個服務只作一件事
• 微服務可以被小團隊單獨開發
• 微服務是鬆耦合的,是有功能意義的服務
• 能夠用不一樣的語言開發,面向接口編程
• 易於與第三方集成
• 微服務只是業務邏輯的代碼,不會和HTML,CSS或者其餘界面組合

開發中,兩種開發模式
先後端分離
全棧工程師

• 能夠靈活搭配,鏈接公共庫/鏈接獨立庫

缺點

• 分佈式系統的負責性
• 多服務運維難度,隨着服務的增長,運維的壓力也在增大
• 系統部署依賴
• 服務間通訊成本
• 數據一致性
• 系統集成測試
• 性能監控

11. 你所知道的微服務技術棧？

• 維度(springcloud)
• 服務開發：springboot spring springmvc
• 服務配置與管理:Netfix公司的Archaiusm ,阿里的Diamond
• 服務註冊與發現:Eureka,Zookeeper
• 服務調用:Rest RPC gRpc
• 服務熔斷器:Hystrix
• 服務負載均衡:Ribbon Nginx
• 服務接口調用:Fegin
• 消息隊列:Kafka Rabbitmq activemq
• 服務配置中心管理:SpringCloudConfig
• 服務路由（API網關）Zuul
• 事件消息總線:SpringCloud Bus

12. 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只是一個進程

13. eureka自我保護機制是什麼?

當Eureka Server 節點在短期內丟失了過多實例的鏈接時（好比網絡故障或頻繁啓動關閉客戶端）節點會進入自我保護模式，保護註冊信息，再也不刪除註冊數據，故障恢復時，自動退出自我保護模式。

14. 什麼是Ribbon？

ribbon是一個負載均衡客戶端，能夠很好的控制htt和tcp的一些行爲。feign默認集成了ribbon。

15. 什麼是feigin？它的優勢是什麼？

1.feign採用的是基於接口的註解
2.feign整合了ribbon，具備負載均衡的能力
3.整合了Hystrix，具備熔斷的能力

使用:
1.添加pom依賴。
2.啓動類添加@EnableFeignClients
3.定義一個接口@FeignClient(name=「xxx」)指定調用哪一個服務

16. Ribbon和Feign的區別？

1.Ribbon都是調用其餘服務的，但方式不一樣。
2.啓動類註解不一樣，Ribbon是@RibbonClient feign的是@EnableFeignClients
3.服務指定的位置不一樣，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
4.調用方式不一樣，Ribbon須要本身構建http請求，模擬http請求而後使用RestTemplate發送給其餘服務，步驟至關繁瑣。Feign須要將調用的方法定義成抽象方法便可。

17. 什麼是Spring Cloud Bus?

spring cloud bus 將分佈式的節點用輕量的消息代理鏈接起來，它能夠用於廣播配置文件的更改或者服務直接的通信，也可用於監控。
若是修改了配置文件，發送一次請求，全部的客戶端便會從新讀取配置文件。
使用:
1.添加依賴
2.配置rabbimq

18. 什麼是Hystrix?

防雪崩利器，具有服務降級，服務熔斷，依賴隔離，監控（Hystrix Dashboard）
服務降級:
雙十一 提示 哎喲喂，被擠爆了。 app秒殺 網絡開小差了，請稍後再試。
優先核心服務，非核心服務不可用或弱可用。經過HystrixCommand註解指定。
fallbackMethod(回退函數)中具體實現降級邏輯。

19. springcloud斷路器做用?

當一個服務調用另外一個服務因爲網絡緣由或自身緣由出現問題，調用者就會等待被調用者的響應 當更多的服務請求到這些資源致使更多的請求等待，發生連鎖效應（雪崩效應）
斷路器有徹底打開狀態:一段時間內 達到必定的次數沒法調用 而且屢次監測沒有恢復的跡象 斷路器徹底打開 那麼下次請求就不會請求到該服務
半開:短期內 有恢復跡象 斷路器會將部分請求發給該服務，正常調用時 斷路器關閉
關閉：當服務一直處於正常狀態 能正常調用

20. 什麼是SpringCloudConfig?

在分佈式系統中，因爲服務數量巨多，爲了方便服務配置文件統一管理，實時更新，因此須要分佈式配置中心組件。在Spring Cloud中，有分佈式配置中心組件spring cloud config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在spring cloud config 組件中，分兩個角色，一是config server，二是config client。

使用：
一、添加pom依賴
二、配置文件添加相關配置
三、啓動類添加註解@EnableConfigServer

21. 架構？

在微服務架構中，須要幾個基礎的服務治理組件，包括服務註冊與發現、服務消費、負載均衡、斷路器、智能路由、配置管理等，由這幾個基礎組件相互協做，共同組建了一個簡單的微服務系統

在Spring Cloud微服務系統中，一種常見的負載均衡方式是，客戶端的請求首先通過負載均衡（zuul、Ngnix），再到達服務網關（zuul集羣），而後再到具體的服。，服務統一註冊到高可用的服務註冊中心集羣，服務的全部的配置文件由配置服務管理，配置服務的配置文件放在git倉庫，方便開發人員隨時改配置。

以上就是二十一到SpringCloud面試題及答案，當你被面試官問到SpringCloud問題時但願這篇文章能對你有幫助，須要SpringCloud學習文檔資料的朋友們能夠點此瞭解：微服務：這是迄今爲止寫的最全的一篇，不用想的太難