SpringCloud 面試題 - 收藏版 （一網打淨，持續更新）

• 瘋狂創客圈 經典圖書 ： 《Netty Zookeeper Redis 高併發實戰》 面試必備 + 面試必備 + 面試必備 【博客園總入口 】
• 瘋狂創客圈 經典圖書 ： 《SpringCloud、Nginx高併發核心編程》 大廠必備 + 大廠必備 + 大廠必備 【博客園總入口 】
• 入大廠+漲工資必備： 高併發【 億級流量IM實戰】 實戰系列 【 SpringCloud Nginx秒殺】 實戰系列 【博客園總入口 】

---

Spring Cloud 入門級 試題

參考資料

瘋狂創客圈 《SpringCloud Nginx 高併發核心編程》高併發 架構師 必備【連接 】

爲何須要學習Spring Cloud

不管是商業應用仍是用戶應用，在業務初期都很簡單，咱們一般會把它實現爲單體結構的應用。可是，隨着業務逐漸發展，產品思想會變得愈來愈複雜，單體結構的應用也會愈來愈複雜。這就會給應用帶來以下的幾個問題：

代碼結構混亂：業務複雜，致使代碼量很大，管理會愈來愈困難。同時，這也會給業務的快速迭代帶來巨大挑戰；開發效率變低：開發人員同時開發一套代碼，很難避免代碼衝突。開發過程會伴隨着不斷解決衝突的過程，這會嚴重的影響開發效率；排查解決問題成本高：線上業務發現 bug，修復 bug 的過程可能很簡單。可是，因爲只有一套代碼，須要從新編譯、打包、上線，成本很高。因爲單體結構的應用隨着系統複雜度的增高，會暴露出各類各樣的問題。近些年來，微服務架構逐漸取代了單體架構，且這種趨勢將會愈來愈流行。Spring Cloud是目前最經常使用的微服務開發框架，已經在企業級開發中大量的應用。

什麼是Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、智能路由、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。Spring Cloud並無重複製造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

Spring Cloud設計目標與優缺點

設計目標

協調各個微服務，簡化分佈式系統開發。

優缺點

微服務的框架那麼多好比：dubbo、Kubernetes，爲何就要使用Spring Cloud的呢？

優勢：

產出於Spring你們族，Spring在企業級開發框架中無人能敵，來頭很大，能夠保證後續的更新、完善組件豐富，功能齊全。Spring Cloud 爲微服務架構提供了很是完整的支持。例如、配置管理、服務發現、斷路器、微服務網關等；Spring Cloud 社區活躍度很高，教程很豐富，遇到問題很容易找到解決方案服務拆分粒度更細，耦合度比較低，有利於資源重複利用，有利於提升開發效率能夠更精準的制定優化服務方案，提升系統的可維護性減輕團隊的成本，能夠並行開發，不用關注其餘人怎麼開發，先關注本身的開發微服務能夠是跨平臺的，能夠用任何一種語言開發適於互聯網時代，產品迭代週期更短缺點：

微服務過多，治理成本高，不利於維護系統分佈式系統開發的成本高（容錯，分佈式事務等）對團隊挑戰大總的來講優勢大過於缺點，目前看來Spring Cloud是一套很是完善的分佈式框架，目前不少企業開始用微服務、Spring Cloud的優點是顯而易見的。所以對於想研究微服務架構的同窗來講，學習Spring Cloud是一個不錯的選擇。

Spring Cloud發展前景

Spring Cloud對於中小型互聯網公司來講是一種福音，由於這類公司每每沒有實力或者沒有足夠的資金投入去開發本身的分佈式系統基礎設施，使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減小開發成本。同時，隨着近幾年微服務架構和Docker容器概念的火爆，也會讓Spring Cloud在將來愈來愈「雲」化的軟件開發風格中立有一席之地，尤爲是在五花八門的分佈式解決方案中提供了標準化的、全站式的技術方案，意義可能會堪比當年Servlet規範的誕生，有效推動服務端軟件系統技術水平的進步。

Spring Cloud總體架構

Spring Cloud主要的子項目有哪些

Spring Cloud的子項目，大體可分紅兩類，一類是對現有成熟框架"Spring Boot化"的封裝和抽象，也是數量最多的項目；第二類是開發了一部分分佈式系統的基礎設施的實現，如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色。

Spring Cloud Config

集中配置管理工具，分佈式系統中統一的外部配置管理，默認使用Git來存儲配置，能夠支持客戶端配置的刷新及加密、解密操做。

Spring Cloud Netflix

Netflix OSS 開源組件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心組件。

Eureka：服務治理組件，包括服務端的註冊中心和客戶端的服務發現機制；Ribbon：負載均衡的服務調用組件，具備多種負載均衡調用策略；Hystrix：服務容錯組件，實現了斷路器模式，爲依賴服務的出錯和延遲提供了容錯能力；Feign：基於Ribbon和Hystrix的聲明式服務調用組件；Zuul：API網關組件，對請求提供路由及過濾功能。

Spring Cloud Bus

用於傳播集羣狀態變化的消息總線，使用輕量級消息代理連接分佈式系統中的節點，能夠用來動態刷新集羣中的服務配置。

Spring Cloud Consul

基於Hashicorp Consul的服務治理組件。

Spring Cloud Security

安全工具包，對Zuul代理中的負載均衡OAuth2客戶端及登陸認證進行支持。

Spring Cloud Sleuth

Spring Cloud應用程序的分佈式請求鏈路跟蹤，支持使用Zipkin、HTrace和基於日誌（例如ELK）的跟蹤。

Spring Cloud Stream

輕量級事件驅動微服務框架，可使用簡單的聲明式模型來發送及接收消息，主要實現爲Apache Kafka及RabbitMQ。

Spring Cloud Task

用於快速構建短暫、有限數據處理任務的微服務框架，用於嚮應用中添加功能性和非功能性的特性。

Spring Cloud Zookeeper

基於Apache Zookeeper的服務治理組件。

Spring Cloud Gateway

API網關組件，對請求提供路由及過濾功能。

Spring Cloud OpenFeign

基於Ribbon和Hystrix的聲明式服務調用組件，能夠動態建立基於Spring MVC註解的接口實現用於服務調用，在Spring Cloud 2.0中已經取代Feign成爲了一等公民。

Spring Cloud的版本關係

Spring Cloud是一個由許多子項目組成的綜合項目，各子項目有不一樣的發佈節奏。爲了管理Spring Cloud與各子項目的版本依賴關係，發佈了一個清單，其中包括了某個Spring Cloud版本對應的子項目版本。爲了不Spring Cloud版本號與子項目版本號混淆，Spring Cloud版本採用了名稱而非版本號的命名，這些版本的名字採用了倫敦地鐵站的名字，根據字母表的順序來對應版本時間順序，例如Angel是第一個版本，Brixton是第二個版本。當Spring Cloud的發佈內容積累到臨界點或者一個重大BUG被解決後，會發佈一個"service releases"版本，簡稱SRX版本，好比Greenwich.SR2就是Spring Cloud發佈的Greenwich版本的第2個SRX版本。目前Spring Cloud的最新版本是Hoxton。

Spring Cloud和SpringBoot版本對應關係

Spring Cloud和各子項目版本對應關係

注意：Hoxton版本是基於SpringBoot 2.2.x版本構建的，不適用於1.5.x版本。隨着2019年8月SpringBoot 1.5.x版本中止維護，Edgware版本也將中止維護。

SpringBoot和SpringCloud的區別？

SpringBoot專一於快速方便的開發單個個體微服務。

SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，

爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

SpringBoot能夠離開SpringCloud獨立使用開發項目， 可是SpringCloud離不開SpringBoot ，屬於依賴的關係

SpringBoot專一於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。

使用 Spring Boot 開發分佈式微服務時，咱們面臨如下問題

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

（2）服務發現 - 服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，而後可以查找並鏈接到該目錄中的服務。

（3）冗餘 - 分佈式系統中的冗餘問題。

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

（5）性能問題 - 因爲各類運營開銷致使的性能問題。

（6）部署複雜性 - DevOps的要求。

服務註冊和發現是什麼意思？Spring Cloud 如何實現？

當咱們開始一個項目時，咱們一般在屬性文件中進行全部的配置。隨着愈來愈多的服務開發和部署，添加和修改這些屬性變得更加複雜。有些服務可能會降低，而某些位置可能會發生變化。手動更改屬性可能會產生問題。Eureka 服務註冊和發現能夠在這種狀況下提供幫助。因爲全部服務都在 Eureka 服務器上註冊並經過調用 Eureka 服務器完成查找，所以無需處理服務地點的任何更改和處理。

Spring Cloud 和dubbo區別?

（1）服務調用方式：dubbo是RPC，Spring Cloud是Rest Api。

（2）註冊中心：dubbo 是zookeeper，Spring Cloud能夠是zookeeper或其餘。

（3）服務網關：dubbo自己沒有實現，只能經過其餘第三方技術整合，springcloud有Zuul路由網關，做爲路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

（4）架構完整度：Spring Cloud包含諸多微服務組件要素，完整度上比Dubbo高。

Spring Cloud 提升 試題

負載平衡的意義什麼？

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

什麼是 Hystrix？它如何實現容錯？

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

一般對於使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協做。

思考如下微服務

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

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

簡化圖以下所示

如今假設因爲某種緣由，employee-producer 公開的服務會拋出異常。咱們在這種狀況下使用 Hystrix 定義了一個回退方法。這種後備方法應該具備與公開服務相同的返回類型。若是暴露服務中出現異常，則回退方法將返回一些值。

什麼是 Hystrix 斷路器？咱們須要它嗎？

因爲某些緣由，employee-consumer 公開服務會引起異常。在這種狀況下使用Hystrix 咱們定義了一個回退方法。若是在公開服務中發生異常，則回退方法返回一些默認值。

若是 firstPage method() 中的異常繼續發生，則 Hystrix 電路將中斷，而且employee使用者將一塊兒跳過 firtsPage 方法，並直接調用回退方法。斷路器的目的是給firstPage方法或firstPage方法可能調用的其餘方法留出時間，並致使異常恢復。可能發生的狀況是，在負載較小的情況下，致使異常的問題有更好的恢復機會 。

什麼是 Netflix Feign？它的優勢是什麼？

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 啓發的 java 客戶端聯編程序。

Feign 的第一個目標是將約束分母的複雜性統一到 http apis，而不考慮其穩定性。

在 employee-consumer 的例子中，咱們使用了 employee-producer 使用 REST模板公開的 REST 服務。

可是咱們必須編寫大量代碼才能執行如下步驟

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

（2）獲取服務實例，而後獲取基本 URL。

（3）利用 REST 模板來使用服務。前面的代碼以下

以前的代碼，有像 NullPointer的機率，並非最優的。咱們將看到如何使用 Netflix Feign 使調用變得更加簡潔。並且若是當 Netflix Ribbon 依賴關係也在類路徑中，那麼 Feign 默認也會負責負載平衡。

什麼是 Spring Cloud Bus？咱們須要它嗎？

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

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

若是假設 GIT 中的 Eureka 註冊屬性更改成指向另外一臺 Eureka 服務器，會發生什麼狀況。在這種狀況下，咱們將不得不從新啓動服務以獲取更新的屬性。

還有另外一種使用執行器端點/刷新的方式。可是咱們將不得不爲每一個模塊單獨調用這個 url。例如，若是 Employee Producer1 部署在端口 8080 上，則調用 localhost:8080/refresh。一樣對於 Employee Producer2 localhost8081/refresh 等等。這又很麻煩。這就是 Spring Cloud Bus 發揮做用的地方。

Spring Cloud Bus 提供了跨多個實例刷新配置的功能。所以，在上面的示例中，若是咱們刷新 Employee Producer1，則會自動刷新全部其餘必需的模塊。若是咱們有多個微服務啓動並運行，這特別有用。這是經過將全部微服務鏈接到單個消息代理來實現的。不管什麼時候刷新實例，此事件都會訂閱到偵聽此代理的全部微服務，而且它們也會刷新。能夠經過使用端點/總線/刷新來實現對任何單個實例的刷新。

Spring Cloud斷路器的做用

當一個服務調用另外一個服務因爲網絡緣由或自身緣由出現問題，調用者就會等待被調用者的響應 當更多的服務請求到這些資源致使更多的請求等待，發生連鎖效應（雪崩效應）

斷路器有徹底打開狀態:一段時間內 達到必定的次數沒法調用 而且屢次監測沒有恢復的跡象 斷路器徹底打開 那麼下次請求就不會請求到該服務

半開:短期內 有恢復跡象 斷路器會將部分請求發給該服務，正常調用時 斷路器關閉

關閉：當服務一直處於正常狀態 能正常調用

什麼是Spring Cloud Config?

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

使用通常也是三步：

（1）添加pom依賴

（2）配置文件添加相關配置

（3）啓動類添加註解@EnableConfigServer

什麼是Spring Cloud Gateway?

Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關做爲流量的控制，在微服務系統中有着很是做用，網關常見的功能有路由轉發、權限校驗、限流控制等做用。

它使用了一個RouteLocatorBuilder的bean去建立路由，除了建立路由，RouteLocatorBuilder也可讓你添加各類predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各類過濾器，用來對請求作各類判斷和修改。

Spring Cloud 高級 試題

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

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

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

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

​ 優勢：

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

​ 缺點：

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

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

2.消息：

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

​ 優勢:

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

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

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

​ 缺點:

​ 消息中間件有額外的複雜

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

優勢

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

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

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

缺點

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

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

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

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

5：什麼是Netflix Feign？它的優勢是什麼？

​ 答：** Feign是一個受到Retrofit，JAXRS-2.0和WebSocket啓發的java到http客戶端綁定器。Feign的第一個目標是下降將Denominator統一綁定到http apis的複雜性，不管其是否安寧。員工 - 消費者中的先前示例咱們使用REST模板 使用員工生產者公開的REST服務

可是咱們必須編寫大量代碼來執行如下操做 -

• 使用功能區進行負載均衡。

• 獲取服務實例，而後獲取基本URL。

• 使用REST模板來消費服務

---

回到◀瘋狂創客圈▶

瘋狂創客圈 - Java高併發研習社羣，爲你們開啓大廠之門