面試專區|【54道Spring Cloud高頻題整理(附答案背誦版)】

什么是Spring Cloud？

Spring Cloud是一個基于Spring Boot的開源框架，它提供了在分布式系統中集成各種服務治理功能的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和集群狀態等。其主要目標是通過簡單的方式，快速地為開發人員構建與部署分布式系統中的通用模式。

簡單來說，Spring Cloud就像是一個“工具箱”，里面裝了很多已經封裝好的工具，這些工具可以幫助我們更輕松地構建和維護微服務架構。比如，當你有多個微服務需要互相通信時，你可以使用Spring Cloud提供的服務發現功能，讓每個服務都能夠自動找到其他服務的位置。

舉個例子，假設你正在開發一個電商平臺，這個平臺由多個微服務組成，比如訂單服務、商品服務、用戶服務等。你可以使用Spring Cloud來管理這些微服務，讓它們能夠更好地協同工作。比如，當用戶下單時，訂單服務可以通過Spring Cloud找到商品服務和用戶服務的位置，然后調用它們的接口完成訂單處理。這樣，你就可以更專注于業務邏輯的開發，而不用過多地關心服務之間的通信和管理問題。

SpringBoot和SpringCloud的區別？

SpringBoot和SpringCloud都是Spring生態圈中非常重要的組件，但它們各自的角色和功能是有所區別的。

作用與目標：SpringBoot的設計目標是為了簡化新Spring應用的初始搭建以及開發過程，它致力于快速地創建獨立的、生產級別的Spring基礎應用程序。而SpringCloud的目標則是為了構建分布式系統，它提供了一套完整的解決方案，用于在微服務架構中集成各種服務治理功能，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線等。
使用方式：SpringBoot可以獨立使用，它是一個快速開發框架，用于簡化Spring的開發過程。而SpringCloud則必須基于SpringBoot才能使用，它是構建在SpringBoot之上的，用于在微服務之間提供協調和管理功能的工具集。
組成：SpringBoot通過簡化配置、內嵌的服務器、快速創建獨立可運行的應用等方式來提高開發效率。而SpringCloud則是一個包含了多個子項目的集合，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Bus等，這些子項目提供了各種服務治理功能。

總的來說，SpringBoot和SpringCloud都是為了讓開發者能夠更輕松地構建和維護應用程序，但它們各自關注的領域和提供的功能是不同的。SpringBoot主要關注于快速開發單個應用程序，而SpringCloud則更關注于在微服務架構中管理和協調多個服務。

使用 Spring Boot 開發分布式微服務時，我們面臨以下問題
服務發現與注冊：
- 問題：在分布式系統中，服務實例可能動態地上線或下線，客戶端如何知道服務的位置？

解答：Spring Cloud提供了服務發現與注冊的解決方案，如Eureka。Eureka是一個服務注冊中心，服務提供者啟動時，會將自己的信息注冊到Eureka Server，同時服務消費者會從Eureka Server獲取服務提供者的信息，實現服務的動態發現。

負載均衡：
- 問題：當有多個服務實例時，如何均勻地分配客戶端的請求？

解答：Spring Cloud集成了Ribbon，一個客戶端負載均衡器。Ribbon能夠自動地從服務注冊中心獲取服務列表，并基于某種策略（如輪詢、隨機等）將請求分發到不同的服務實例上。

容錯與斷路器：
- 問題：當某個服務出現故障時，如何避免整個系統的崩潰？
- 解答：Spring Cloud引入了Hystrix，一個斷路器庫。Hystrix能夠監控服務的調用情況，當服務調用失敗率達到一定閾值時，會自動觸發斷路器，阻止后續的請求繼續調用該服務，從而保護整個系統的穩定性。
配置管理：
- 問題：在分布式系統中，如何統一管理各個服務的配置？
- 解答：Spring Cloud Config是一個配置管理工具。它支持將配置信息存儲在中心化的位置（如Git倉庫），服務啟動時，會從配置中心拉取配置信息，實現配置的集中管理和動態刷新。
API網關：
- 問題：如何統一管理和路由外部的API請求？
- 解答：Spring Cloud Zuul是一個API網關，它能夠作為系統的統一入口，處理所有的外部請求。Zuul支持請求路由、過濾、限流等功能，可以有效地保護后端服務。
鏈路追蹤：
- 問題：在一個復雜的微服務架構中，如何追蹤一個請求從發起到完成的整個調用鏈？
- 解答：Spring Cloud Sleuth提供了鏈路追蹤的解決方案。它能夠在每個請求中注入一個唯一的追蹤ID，并記錄請求在各個服務間的調用路徑，從而幫助我們分析和監控系統的性能瓶頸。

應用場景與例子：

服務發現與注冊：假設我們有一個電商系統，其中包括商品服務、訂單服務等。我們可以使用Eureka作為服務注冊中心，各個服務啟動時自動注冊到Eureka，同時前端應用可以從Eureka獲取服務列表，實現服務的動態發現。
負載均衡：在電商系統中，當有多個訂單服務實例時，Ribbon可以幫助我們均勻地分配用戶的下單請求，保證系統的處理能力。
容錯與斷路器：如果商品服務突然出現故障，Hystrix可以在檢測到故障后迅速切斷對商品服務的調用，避免用戶的請求長時間等待或失敗，從而提升用戶體驗。
配置管理：當我們需要修改訂單服務的某些配置時，只需在Spring Cloud Config的配置中心更新配置信息，然后通知訂單服務刷新配置即可，無需重啟服務。
API網關：我們可以使用Zuul作為電商系統的API網關，處理所有的外部請求，如用戶的登錄、商品查詢、下單等操作。Zuul可以根據請求的路徑將其路由到相應的服務，同時還可以對請求進行權限驗證、限流等處理。
鏈路追蹤：當用戶反映下單速度慢時，我們可以利用Spring Cloud Sleuth生成的鏈路追蹤信息，分析請求在整個系統中的調用路徑和耗時，從而定位性能瓶頸并進行優化。

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

服務注冊和發現是微服務架構中的關鍵概念，主要涉及到服務的動態管理和網絡位置的自動檢測。

服務注冊指的是當服務實例啟動后，它會將自己的網絡地址等信息注冊到服務注冊中心，這樣其他服務或客戶端就可以通過網絡找到它。而服務發現則是客戶端通過查詢服務注冊中心，找到需要的服務實例的網絡地址，進而實現服務的調用。

在Spring Cloud中，服務注冊和發現主要通過Eureka、Zookeeper、Consul等組件來實現。這些組件都提供了服務注冊和發現的功能，可以動態地管理服務實例的網絡位置，并且支持服務的健康檢查和負載均衡等特性。

以Eureka為例，當服務實例啟動時，它會向Eureka Server注冊自己的信息，包括網絡地址、端口號、服務名稱等。Eureka Server會維護一個服務注冊表，記錄所有注冊的服務實例信息。當客戶端需要調用某個服務時，它會向Eureka Server發起查詢請求，獲取可用的服務實例列表，并從中選擇一個進行調用。

除了Eureka之外，Spring Cloud還支持其他的服務注冊和發現組件，如Zookeeper和Consul。這些組件的使用方法略有不同，但基本原理是相似的。

總的來說，服務注冊和發現是微服務架構中非常重要的概念，它可以幫助我們更好地管理和調用服務，提高系統的可用性和可擴展性。而Spring Cloud提供了多種組件來實現服務注冊和發現的功能，可以根據實際需求進行選擇和配置。

Spring Cloud 和dubbo區別?

Spring Cloud和Dubbo都是用于構建微服務架構的工具，但它們在多個方面存在顯著的差異。

初始定位：Spring Cloud定位為微服務架構下的一站式解決方案，提供了一套完整的微服務治理工具集；而Dubbo是SOA時代的產物，它的關注點主要在于服務的調用和治理。
生態環境：Spring Cloud依托于Spring平臺，具備更加完善的生態體系，包括配置管理、服務發現、熔斷器、智能路由等功能的支持；而Dubbo一開始只是做RPC遠程調用，生態相對匱乏，但現在已經逐漸豐富起來，提供了包括服務注冊與發現、負載均衡、容錯處理等功能。
調用方式：Spring Cloud是采用Http協議做遠程調用，接口一般是Rest風格，比較靈活；而Dubbo是采用Dubbo協議，接口一般是Java的Service接口，格式固定。但調用時采用Netty的NIO方式，性能較好。
組件差異：Spring Cloud和Dubbo在組件方面也存在差異，例如Spring Cloud注冊中心一般用Eureka，而Dubbo用的是Zookeeper。此外，Spring Cloud生態豐富，功能完善，更像是品牌機，Dubbo則相對靈活，可定制性強，更像是組裝機。

總的來說，Spring Cloud和Dubbo各有優勢，選擇哪個取決于具體需求和場景。如果需要更完善的生態體系和一站式解決方案，可以選擇Spring Cloud；如果對性能有較高要求且需要更靈活的服務治理，可以考慮使用Dubbo。

負載平衡的意義什么？

負載平衡（Load Balancing）在分布式系統中扮演著非常重要的角色。簡單來說，負載平衡就是將工作任務或者網絡請求等負載，均勻地分攤到多個操作單元或服務器上進行處理，從而達到避免單點故障、提高系統性能、增強系統可擴展性等目的。

舉個例子，如果我們有一個非常受歡迎的在線購物網站，在沒有負載平衡的情況下，所有的用戶請求可能都會集中到某一臺服務器上，這樣很容易導致這臺服務器過載，而其他服務器卻處于空閑狀態。一旦這臺過載的服務器崩潰，整個網站就會面臨癱瘓的風險。

而通過負載平衡技術，我們可以將這些用戶請求分散到多臺服務器上，確保每臺服務器都能夠承擔適量的負載。這樣不僅能夠提高整個系統的處理能力和穩定性，還能夠實現水平擴展，即通過增加服務器數量來進一步提升系統性能。

在Spring Cloud中，負載平衡通常是通過服務注冊與發現組件（如Eureka）和負載均衡器（如Ribbon或Spring Cloud LoadBalancer）來實現的。這些組件可以幫助我們自動地管理和分配負載，從而簡化分布式系統的開發和運維工作。

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

Hystrix是Netflix開源的一款容錯框架，被廣泛用于處理分布式系統中的延遲和容錯問題。在分布式環境中，許多服務不可避免地會依賴一些可能失敗的服務。Hystrix通過添加延遲容忍和容錯邏輯，幫助我們控制這些分布式服務之間的交互。

Hystrix實現容錯的方式主要有以下幾種：

包裹請求：使用HystrixCommand或HystrixObservableCommand包裹對依賴的調用邏輯，每個命令在獨立線程中執行。
跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或手動跳閘，停止請求該服務一段時間。這類似于電路中的保險絲，一旦后端服務不可用，斷路器會直接切斷請求鏈，避免發送大量無效請求影響系統吞吐量，并且斷路器有自我檢測并恢復的能力。
資源隔離：Hystrix為每一個服務調用都維護一個小型線程池（或信號量），使得資源之間彼此隔離，防止故障在整個系統中蔓延。如果線程池已滿，請求會立即被拒絕，從而加速失敗。
回退機制：當請求出錯或斷路器打開時，會執行回退邏輯，返回我們設定的默認值，保證系統的整體彈性。
實時監控：Hystrix還提供了實時的運行指標和配置變化監控，幫助我們更好地了解系統的運行狀態。

總的來說，Hystrix通過隔離、跳閘、回退等機制，實現了對分布式系統中故障的容錯處理，提高了系統的穩定性和可靠性。

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

Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫。在分布式系統里，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分布式系統的彈性。

“斷路器”本身是一種開關裝置。當某個服務單元發生故障之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要的占用，從而避免了故障在分布式系統中的蔓延，乃至雪崩。

至于是否需要Hystrix斷路器，這取決于你的系統的具體情況。如果你的系統是一個分布式系統，并且有許多依賴關系，那么使用Hystrix斷路器可能會很有幫助。然而，在某些情況下，可能還有其他方法（如預防性維護、故障預測和恢復等）更為合適。

因此，需要根據實際情況來決定是否使用Hystrix斷路器。如果你的系統需要處理大量的依賴調用，并且需要有一定的容錯和彈性，那么使用Hystrix斷路器可能是一個很好的選擇。

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

Netflix Feign是一個聲明式的Web服務客戶端，它使得編寫Web服務客戶端變得更加簡單。使用Feign，只需要創建一個接口并注解。它具有可插拔的注解特性，包括Feign注解和JAX-RS注解。Feign也支持可插拔的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支持了Spring MVC標準注解和HttpMessageConverters。Feign可以與Eureka和Ribbon結合使用以支持負載均衡。

Netflix Feign的主要優點包括：

聲明式API：Feign通過聲明式API簡化了HTTP客戶端的編寫，讓開發者能夠像調用本地方法一樣調用遠程服務，而無需關注底層的HTTP通信細節。
集成與Spring Cloud：Feign能夠很好地與Spring Cloud集成，這使得它成為了在Spring生態系統中進行微服務間通信的理想選擇。
負載均衡：Feign可以與Eureka和Ribbon等組件結合使用，實現客戶端負載均衡，從而提高了系統的可用性和可擴展性。
可插拔性：Feign的注解、編碼器和解碼器都是可插拔的，這使得它可以根據項目需求進行定制化配置。
減少代碼量：通過使用Feign，開發者可以減少大量的HTTP客戶端編寫代碼，從而提高開發效率。

總之，Netflix Feign是一個功能強大且易于使用的Web服務客戶端，它在Spring Cloud生態系統中發揮著重要作用，為微服務間的通信提供了便捷、高效和可靠的解決方案。

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

Spring Cloud Bus是Spring Cloud體系內的消息總線，用于連接分布式系統的所有節點。它利用輕量級的消息代理（如RabbitMQ、Kafka等）將各個分布的節點連接起來，并允許廣播狀態變化（如配置變更）或其他管理指令。

Spring Cloud Bus提供了跨多個實例刷新配置的功能。例如，當我們在Git中更改了Eureka的注冊屬性，并且想要在不重新啟動服務的情況下獲取這些更新時，Spring Cloud Bus就可以發揮作用。它能夠將更改廣播到所有連接到消息總線的微服務，并觸發它們的自動刷新。

至于是否需要Spring Cloud Bus，這取決于你的具體需求。如果你的系統是一個分布式系統，并且你需要動態地刷新配置或服務間的通信，那么Spring Cloud Bus將是一個非常有價值的工具。然而，如果你的系統并不復雜，或者你不需要這種動態刷新的功能，那么你可能就不需要Spring Cloud Bus。

總的來說，Spring Cloud Bus為分布式系統提供了一種有效的通信和管理機制，但是否使用它還需要根據具體情況來決定。

Spring Cloud斷路器的作用

Spring Cloud斷路器是微服務架構中一種重要的容錯機制，具有以下幾個主要作用：

異常容忍能力：當某個微服務出現故障或異常時，斷路器可以快速失敗，避免長時間等待和資源浪費。它還可以自動切換到備用服務，防止故障微服務對整個系統的影響。
熔斷保護：斷路器通過監控微服務之間的調用，當某個微服務的調用延遲超過閾值或失敗次數超過閾值時，會自動將該微服務置為不可用狀態，從而避免連鎖故障。這種機制可以提高系統的容錯能力。
降級處理：當某個微服務不可用時，斷路器可以提供一種降級處理策略，例如返回默認的響應或使用緩存的數據來代替真實的響應。這可以確保系統的可用性和穩定性。
實時監控和統計：斷路器可以實時監控微服務的狀態和性能指標，如請求的成功和失敗次數、響應時間等。這些統計數據可以幫助找出故障和性能問題的根本原因，從而進行針對性的優化和改進。
自動恢復：斷路器可以根據微服務的狀態和性能指標，自動決定是否恢復對斷開的微服務的訪問。當故障微服務恢復正常時，斷路器可以自動重新建立對該微服務的訪問。
隔離機制：斷路器可以提供一種隔離機制，防止微服務之間由于故障引起的相互影響。當一個微服務發生故障時，斷路器可以確保其他微服務正常運行。

在Spring Cloud中，Hystrix是實現斷路器功能的一種常用庫。通過使用Hystrix，我們可以更容易地實現上述功能，提高微服務架構的容錯能力和穩定性。

總的來說，Spring Cloud斷路器在微服務架構中發揮著至關重要的作用，它可以幫助我們更好地應對和處理各種故障和異常情況，確保系統的穩定運行。

什么是Spring Cloud Config?

Spring Cloud Config是Spring Cloud項目中的一個子項目，旨在為分布式系統中的基礎設施和微服務應用提供集中化的外部配置支持。它分為客戶端和服務端兩部分。服務端也稱為分布式配置中心，是一個獨立的微服務應用，用來連接配置倉庫并為客戶端提供獲取配置信息、加密/解密信息等訪問接口。客戶端則是微服務架構中的各微服務應用或基礎設施，通過指定的配置中心來管理應用資源與業務相關的配置內容，并在啟動的時候從配置中心獲取和加載配置信息。

Spring Cloud Config服務端默認使用Git來存儲配置信息，因此它可以輕松地支持標簽版本的配置環境。此外，Spring Cloud Config服務端也可以用其他的方式來實現配置的存儲，比如SVN倉庫、本地文件、數據庫等。

當配置中心發生變化時，Spring Cloud Config可以利用Spring Cloud Bus來通知微服務架構中的各微服務應用，從而實現動態刷新配置。此外，Spring Cloud Config還具有配置加密與解密的功能，可以更好地保護配置信息的安全性。

總的來說，Spring Cloud Config是一個非常重要的組件，它可以幫助開發人員更好地管理和維護分布式系統中的配置信息，從而提高系統的可維護性和可擴展性。

什么是Spring Cloud Gateway?

Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技術開發的網關，它旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式。Spring Cloud Gateway作為Spring Cloud生態系統中的網關，目標是替代Netflix Zuul，其不僅提供統一的路由方式，并且基于Filter鏈的方式提供了網關基本的功能，例如：安全、監控/埋點、限流等。

它是基于WebFlux框架實現的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。Spring Cloud Gateway的性能比Zuul更加優秀，從測試結果來看，Spring Cloud Gateway的RPS是Zuul的1.6倍。

此外，Spring Cloud Gateway還提供了豐富的API管理功能，可以輔助企業管理大規模的API，降低管理成本和安全風險。這些功能包括協議適配、協議轉發、安全策略、防刷、流量、監控日志等。

總的來說，Spring Cloud Gateway是一個功能強大、性能優秀的API網關，適用于微服務架構中的API管理和路由。

什么是微服務？

微服務（或微服務架構）是一種云原生架構方法，它將一個單一的應用拆分成多個小型的服務，每個服務都在自己的進程中運行，并采用輕量級通信機制進行通信。這些服務圍繞業務能力構建，并能夠全自動獨立部署。每個服務可以使用不同的編程語言、數據庫和數據管理模型，具有高度的自治性。微服務架構可以促進更好的擴展性、靈活性和可維護性。

微服務架構的特點包括：

易于開發和維護：每個微服務關注特定的業務功能，業務清晰、代碼量較少，開發和維護單個微服務相對簡單，而對整個應用進行維護時，也能保持在一個可控狀態。
局部修改容易部署：在微服務架構中，只需對修改的服務進行重新部署，而不需要重新部署整個應用，這可以大大節省部署時間，降低部署成本。
技術棧不受限：微服務架構允許結合不同服務開發團隊的技術強項和特點，合理地選擇技術棧。這意味著開發團隊可以根據需要選擇最適合特定服務的技術，而不必在整個應用中統一技術棧。
容錯和隔離：微服務架構可以更好地實現容錯和隔離。由于每個服務都運行在獨立的進程中，某個服務的故障不會影響到其他服務。此外，通過合理地設計微服務之間的交互和依賴關系，可以進一步降低故障傳播的風險。

然而，微服務架構也面臨一些挑戰，如分布式系統的復雜性、網絡延遲、數據一致性問題等。因此，在實施微服務架構時，需要充分考慮這些因素，并采取相應的措施來應對這些挑戰。

微服務之間如何獨立通訊的?

微服務之間獨立通訊的方式主要有兩種：同步通信和異步通信。

同步通信方式中，常見的有RPC（Remote Procedure Call，遠程過程調用）和REST（Representational State Transfer，表述性狀態轉移）。RPC是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。在微服務架構中，各個微服務可以使用RPC框架（如gRPC、Apache Thrift等）進行通信，實現服務的調用和返回結果。REST則是一種基于HTTP協議的通信方式，它通過將資源用URL進行標識，并使用不同的HTTP方法（GET、POST、PUT、DELETE等）對資源進行操作，從而實現微服務之間的通信。

異步通信方式中，常用的有消息隊列。消息隊列是一種跨進程通信或同一進程內線程之間的通信方式，它可以用來處理并發操作，實現異步處理。在微服務架構中，各個微服務可以將需要通信的消息發送到消息隊列中，由其他微服務異步地接收和處理這些消息。常見的消息隊列有RabbitMQ、Kafka等。

無論是同步通信還是異步通信，微服務之間的通信都需要遵循一定的協議和規范，以確保通信的正確性和可靠性。同時，為了提高系統的可用性和可擴展性，微服務之間的通信也需要考慮負載均衡、容錯處理等問題。在實際應用中，可以根據具體的需求和場景選擇合適的通信方式，并結合Spring Cloud等微服務框架提供的組件和工具來實現微服務之間的通信和管理。

由于內容太多，更多內容以鏈接形勢給大家，點擊進去就是答案了

16. 微服務的優缺點是什么？說下你在項目中碰到的坑。

17. eureka和zookeeper都可以提供服務注冊與發現的功能，請說說兩個的區別？

18. 你所知道微服務的技術棧有哪些？列舉一二。

19. 什么是微服務架構？

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

21. 使用Spring Cloud有什么優勢？

22. Ribbon負載均衡策略有哪些？

23. 使用Zuul的優點?

24. Zuul有幾種過濾器類型？分別是？

25. Eureka的自我保護模式是什么？

26. 簡述什么是CAP,并說明Eureka包含CAP中的哪些?