大家好，我是老三，面渣逆襲系列繼續，這期給大家帶來微服務相關的面試題。

概覽

1.什麼是微服務？

微服務（Microservices）是一種軟件架構風格，將一個大型應用程序劃分爲一組小型、自治且松耦合的服務。每個微服務負責執行特定的業務功能，並通過輕量級通信機制（如HTTP）相互協作。每個微服務可以獨立開發、部署和擴展，使得應用程序更加靈活、可伸縮和可維護。

在微服務的架構演進中，一般可能會存在這樣的演進方向：單體式-->服務化-->微服務。

單體服務一般是所有項目最開始的樣子：

單體服務（Monolithic Service）是一種傳統的軟件架構方式，將整個應用程序作爲一個單一的、緊耦合的單元進行開發和部署。單體服務通常由多個模塊組成，這些模塊共享同一個數據庫和代碼庫。然而，隨着應用程序規模的增長，單體服務可能變得龐大且難以維護，且部署和擴展困難。

後來，單體服務過大，維護困難，漸漸演變到了分佈式的SOA：

SOA（Service-Oriented Architecture，面向服務的架構）是一種軟件架構設計原則，強調將應用程序拆分爲相互獨立的服務，通過標準化的接口進行通信。SOA關注於服務的重用性和組合性，但並沒有具體規定服務的大小。
微服務是在SOA的基礎上進一步發展而來，是一種特定規模下的服務拆分和部署方式。微服務架構強調將應用程序拆分爲小型、自治且松耦合的服務，每個服務都專注於特定的業務功能。這種架構使得應用程序更加靈活、可伸縮和可維護。

需要注意的是，微服務是一種特定的架構風格，而SOA是一種設計原則。微服務可以看作是對SOA思想的一種具體實踐方式，但並不等同於SOA。

微服務與單體服務的區別在於規模和部署方式。微服務將應用程序拆分爲更小的、自治的服務單元，每個服務都有自己的數據庫和代碼庫，可以獨立開發、測試、部署和擴展，帶來了更大的靈活性、可維護性、可擴展性和容錯性。

2.微服務帶來了哪些挑戰？

微服務架構不是萬金油，盡它有很多優點，但是對於是否採用微服務架構，是否將原來的單體服務進行拆分，還是要考慮到服務拆分後可能帶來的一些挑戰和問題：

系統複雜性增加：一個服務拆成了多個服務，整體系統的複雜性增加，需要處理服務之間的通信、部署、監控和維護等方面的複雜性。
服務間通信開銷：微服務之間通過網絡進行通信，傳遞數據需要額外的網絡開銷和序列化開銷，可能導致性能瓶頸和增加系統延遲。
數據一致性和事務管理：每個微服務都有自己的數據存儲，數據一致性和跨服務的事務管理變得更加複雜，需要額外解決分佈式事務和數據同步的問題。
部署和運維複雜性：微服務架構涉及多個獨立部署的服務，對於部署、監控和容錯機制的要求更高，需要建立適當的部署管道和自動化工具，以簡化部署和運維過程。
團隊溝通和協作成本：每個微服務都由專門的團隊負責，可能增加團隊之間的溝通和協作成本。需要有效的溝通渠道和協作機制，確保服務之間的協調和一致性。
服務治理和版本管理：隨着微服務數量的增加，服務的治理和版本管理變得更加複雜。需要考慮服務的註冊發現、負載均衡、監控和故障處理等方面，以確保整個系統的可靠性和穩定性。
分佈式系統的複雜性：微服務架構涉及構建和管理分佈式系統，而分佈式系統本身具有一些固有的挑戰，如網絡延遲、分佈式一致性和容錯性。

簡單說，採用微服務需要權衡這些問題和挑戰，根據實際的需求來選擇對應的技術方案，很多時候單體能搞定的也可以用單體，不能爲了微服務而微服務。

3.現在有哪些流行的微服務解決方案？

目前最主流的微服務開源解決方案有三種：

Dubbo：
- Dubbo 是一個高性能、輕量級的 Java 微服務框架，最初由阿里巴巴（Alibaba）開發並於2011年開源。它提供了服務註冊與發現、負載均衡、容錯、分佈式調用等功能，後來一度停止維護，在近兩年，又重新開始迭代，並推出了Dubbo3。
- Dubbo 使用基於 RPC（Remote Procedure Call）的通信模型，具有較高的性能和可擴展性。它支持多種傳輸協議（如TCP、HTTP、Redis）和序列化方式（如JSON、Hessian、Protobuf），可根據需求進行配置。
- Dubbo更多地被認爲是一個高性能的RPC（遠程過程調用）框架，一些服務治理功能依賴於第三方組件實現，比如使用ZooKeeper、Apollo等等。
Spring Cloud Netflix：
- Spring Cloud Netflix 是 Spring Cloud 的一個子項目，結合了 Netflix 開源的多個組件，但是Netflix自2018年停止維護和更新Netflix OSS項目，包括Eureka、Hystrix等組件，所以Spring Cloud Netflix也逐漸進入了維護模式。
- 該項目包含了許多流行的 Netflix 組件，如Eureka（服務註冊與發現）、Ribbon（客戶端負載均衡）、Hystrix（斷路器）、Zuul（API 網關）等。它們都是高度可擴展的、經過大規模實踐驗證的微服務組件。

Spring Cloud Alibaba：

Spring Cloud Alibaba 是 Spring Cloud 的另一個子項目，與阿里巴巴的分佈式應用開發框架相關。它提供了一整套與 Alibaba 生態系統集成的解決方案。
該項目包括 Nacos（服務註冊與發現、配置管理）、Sentinel（流量控制、熔斷降級）、RocketMQ（消息隊列）等組件，以及與 Alibaba Cloud（阿里雲）的集成。它爲構建基於 Spring Cloud 的微服務架構提供了豐富的選項。
據說SpringCloud Alibaba項目的發起人已經跑路去了騰訊，併發起了SpringCloud Tecent項目，社區發展存在隱憂。

這三種方案有什麼區別嗎？

三種方案的區別：

特點	Dubbo	Spring Cloud Netflix	Spring Cloud Alibaba
開發語言	Java	Java	Java
服務治理	提供完整的服務治理功能	提供部分服務治理功能	提供完整的服務治理功能
服務註冊與發現	ZooKeeper/Nacos	Eureka/Consul	Nacos
負載均衡	自帶負載均衡策略	Ribbon	Ribbon\Dubbo負載均衡策略
服務調用	RPC方式	RestTemplate/Feign	Feign/RestTemplate/Dubbo
熔斷器	Sentinel	Hystrix	Sentinel/Resilience4j
配置中心	Apollo	Spring Cloud Config	Nacos Config
API網關	Higress/APISIX	Zuul/Gateway	Spring Cloud Gateway
分佈式事務	Seata	不支持分佈式事務	Seata
限流和降級	Sentinel	Hystrix	Sentinel
分佈式追蹤和監控	Skywalking	Spring Cloud Sleuth + Zipkin	SkyWalking或Sentinel Dashboard
微服務網格	Dubbo Mesh	不支持微服務網格	Service Mesh（Nacos+Dubbo Mesh）
社區活躍度	相對較高	目前較低	相對較高
孵化和成熟度	孵化較早，成熟度較高	成熟度較高	孵化較新，但迅速發展

在面試中，微服務一般主要討論的是Spring Cloud Netflix，其次是Spring Cloud Alibaba，Dubbo更多的是作爲一個RPC框架來問。

4.說下微服務有哪些組件？

微服務給系統開發帶來了一些問題和挑戰，如服務調用的複雜性、分佈式事務的處理、服務的動態管理等。爲了更好地解決這些問題和挑戰，各種微服務治理的組件應運而生，充當微服務架構的基石和支撐。

微服務的各個組件和常見實現：

註冊中心：用於服務的註冊與發現，管理微服務的地址信息。常見的實現包括：
- Spring Cloud Netflix：Eureka、Consul
- Spring Cloud Alibaba：Nacos
配置中心：用於集中管理微服務的配置信息，可以動態修改配置而不需要重啓服務。常見的實現包括：
- Spring Cloud Netflix：Spring Cloud Config
- Spring Cloud Alibaba：Nacos Config
遠程調用：用於在不同的微服務之間進行通信和協作。常見的實現保包括：
- RESTful API：如RestTemplate、Feign
- RPC（遠程過程調用）：如Dubbo、gRPC
API網關：作爲微服務架構的入口，統一暴露服務，並提供路由、負載均衡、安全認證等功能。常見的實現包括：
- Spring Cloud Netflix：Zuul、Gateway
- Spring Cloud Alibaba：Gateway、Apisix等
分佈式事務：保證跨多個微服務的一致性和原子性操作。常見的實現包括：
- Spring Cloud Alibaba：Seata
熔斷器：用於防止微服務之間的故障擴散，提高系統的容錯能力。常見的實現包括：
- Spring Cloud Netflix：Hystrix
- Spring Cloud Alibaba：Sentinel、Resilience4j
限流和降級：用於防止微服務過載，對請求進行限制和降級處理。常見的實現包括：
- Spring Cloud Netflix：Hystrix
- Spring Cloud Alibaba：Sentinel
分佈式追蹤和監控：用於跟蹤和監控微服務的請求流程和性能指標。常見的實現包括：
- Spring Cloud Netflix：Spring Cloud Sleuth + Zipkin
- Spring Cloud Alibaba：SkyWalking、Sentinel Dashboard

註冊中心

5.註冊中心是用來幹什麼的？

註冊中心是用來管理和維護分佈式系統中各個服務的地址和元數據的組件。它主要用於實現服務發現和服務註冊功能。

總結一下注冊中心的作用：

服務註冊：各個服務在啓動時向註冊中心註冊自己的網絡地址、服務實例信息和其他相關元數據。這樣，其他服務就可以通過註冊中心獲取到當前可用的服務列表。
服務發現：客戶端通過向註冊中心查詢特定服務的註冊信息，獲得可用的服務實例列表。這樣客戶端就可以根據需要選擇合適的服務進行調用，實現了服務間的解耦。
負載均衡：註冊中心可以對同一服務的多個實例進行負載均衡，將請求分發到不同的實例上，提高整體的系統性能和可用性。
故障恢復：註冊中心能夠監測和檢測服務的狀態，當服務實例發生故障或下線時，可以及時更新註冊信息，從而保證服務能夠正常工作。
服務治理：通過註冊中心可以進行服務的配置管理、動態擴縮容、服務路由、灰度發佈等操作，實現對服務的動態管理和控制。

6.SpringCloud可以選擇哪些註冊中心？

SpringCloud可以與多種註冊中心進行集成，常見的註冊中心包括：

Eureka：Eureka 是 Netflix 開源的服務發現框架，具有高可用、彈性、可擴展等特點，並與 Spring Cloud 集成良好。
Consul：Consul 是一種分佈式服務發現和配置管理系統，由 HashiCorp 開發。它提供了服務註冊、服務發現、健康檢查、鍵值存儲等功能，並支持多數據中心部署。
ZooKeeper：ZooKeeper 是 Apache 基金會開源的分佈式協調服務，可以用作服務註冊中心。它具有高可用、一致性、可靠性等特點。
Nacos：Nacos 是阿里巴巴開源的一個動態服務發現、配置管理和服務管理平臺。它提供了服務註冊和發現、配置管理、動態 DNS 服務等功能。
etcd：etcd 是 CoreOS 開源的一種分佈式鍵值存儲系統，可以被用作服務註冊中心。它具有高可用、強一致性、分佈式複製等特性。

7.說下Eureka、ZooKeeper、Nacos的區別？

特性	Eureka	ZooKeeper	Nacos
開發公司	Netflix	Apache 基金會	阿里巴巴
CAP	AP（可用性和分區容忍性）	CP（一致性和分區容忍性）	既支持AP，也支持CP
功能	服務註冊與發現	分佈式協調、配置管理、分佈式鎖	服務註冊與發現、配置管理、服務管理
定位	適用於構建基於 HTTP 的微服務架構	通用的分佈式協調服務框架	適用於微服務和雲原生應用
訪問協議	HTTP	TCP	HTTP/DNS
自我保護	支持	-	支持
數據存儲	內嵌數據庫、多個實例形成集羣	ACID 特性的分佈式文件系統 ZAB 協議	內嵌數據庫、MySQL 等
健康檢查	Client Beat	Keep Alive	TCP/HTTP/MYSQL/Client Beat
特點	簡單易用、自我保護機制	高性能、強一致性	動態配置管理、流量管理、灰度發佈等

可以看到Eureka和ZooKeeper的最大區別是一個支持AP，一個支持CP，Nacos既支持既支持AP，也支持CP。

8.Eureka實現原理了解嗎？

Eureka的實現原理，大概可以從這幾個方面來看：

服務註冊與發現: 當一個服務實例啓動時，它會向Eureka Server發送註冊請求，將自己的信息註冊到註冊中心。Eureka Server會將這些信息保存在內存中，並提供REST接口供其他服務查詢。服務消費者可以通過查詢服務實例列表來獲取可用的服務提供者實例，從而實現服務的發現。
服務健康檢查: Eureka通過心跳機制來檢測服務實例的健康狀態。服務實例會定期向Eureka Server發送心跳，也就是續約，以表明自己的存活狀態。如果Eureka Server在一定時間內沒有收到某個服務實例的心跳，則會將其標記爲不可用，並從服務列表中移除，下線實例。
服務負載均衡: Eureka客戶端在調用其他服務時，會從本地緩存中獲取服務的註冊信息。如果緩存中沒有對應的信息，則會向Eureka Server發送查詢請求。Eureka Server會返回一個可用的服務實例列表給客戶端，客戶端可以使用負載均衡算法選擇其中一個進行調用。

其它的註冊中心，如Nacos、Consul等等，在服務註冊和發現上，實現原理都是大同小異。

9.Eureka Server怎麼保證高可用？

Eureka Server保證高可用，主要通過這三個方面來實現：

多實例部署: 通過將多個Eureka Server實例部署在不同的節點上，可以實現高可用性。當其中一個實例發生故障時，其他實例仍然可以提供服務，並保持註冊信息的一致性。
服務註冊信息的複製: 當一個服務實例向Eureka Server註冊時，每個Eureka Server實例都會複製其他實例的註冊信息，以保持數據的一致性。當某個Eureka Server實例發生故障時，其他實例可以接管其工作，保證整個系統的正常運行。
自我保護機制: Eureka還具有自我保護機制。當Eureka Server節點在一定時間內沒有接收到心跳時，它會進入自我保護模式。在自我保護模式下，Eureka Server不再剔除註冊表中的服務實例，以保護現有的註冊信息。這樣可以防止由於網絡抖動或其他原因導致的誤剔除，進一步提高系統的穩定性。

配置中心

10.爲什麼微服務需要配置中心？

微服務架構中的每個服務通常都需要一些配置信息，例如數據庫連接地址、服務端口、日誌級別等。這些配置可能因爲不同環境、不同部署實例或者動態運行時需要進行調整和管理。

微服務的實例一般非常多，如果每個實例都需要一個個地去做這些配置，那麼運維成本將會非常大，這時候就需要一個集中化的配置中心，去管理這些配置。

11.SpringCloud可以選擇哪些配置中心？

和註冊中心一樣，SpringCloud也支持對多種配置中心的集成。常見的配置中心選型包括：

Spring Cloud Config：官方推薦的配置中心，支持將配置文件存儲在Git、SVN等版本控制系統中，並提供RESTful API進行訪問和管理。
ZooKeeper：一個開源的分佈式協調服務，可以用作配置中心。它具有高可用性、一致性和通知機制等特性。
Consul：另一個開源的分佈式服務發現和配置管理工具，也可用作配置中心。支持多種配置文件格式，提供健康檢查、故障轉移和動態變更等功能。
Etcd：一個分佈式鍵值存儲系統，可用作配置中心。它使用基於Raft算法的一致性機制，提供分佈式數據一致性保證。
Apollo：攜程開源的配置中心，支持多種語言和框架。提供細粒度的配置權限管理、配置變更通知和灰度發佈等高級特性，還有可視化的配置管理界面。
Nacos：阿里巴巴開源的服務發現、配置管理和服務管理平臺，也可以作爲配置中心使用。支持服務註冊與發現、動態配置管理、服務健康監測和動態DNS服務等功能。

12.Nacos配置中心的原理了解嗎？

配置中心，說白了就是一句話：配置信息的CRUD。

具體的實現大概可以分成這麼幾個部分：

配置信息存儲：Nacos默認使用內嵌數據庫Derby來存儲配置信息，還可以採用MySQL等關係型數據庫。
註冊配置信息：服務啓動時，Nacos Client會向Nacos Server註冊自己的配置信息，這個註冊過程就是把配置信息寫入存儲，並生成版本號。
獲取配置信息：服務運行期間，Nacos Client通過API從Nacos Server獲取配置信息。Server根據鍵查找對應的配置信息，並返回給Client。
監聽配置變化：Nacos Client可以通過註冊監聽器的方式，實現對配置信息的監聽。當配置信息發生變化時，Nacos Server會通知已註冊的監聽器，並觸發相應的回調方法。

13.Nacos配置中心長輪詢機制？

一般來說客戶端和服務端的交互分爲兩種：推（Push）和拉（Pull），Nacos在Pull的基礎上，採用了長輪詢來進行配置的動態刷新。

在長輪詢模式下，客戶端定時向服務端發起請求，檢查配置信息是否發生變更。如果沒有變更，服務端會"hold"住這個請求，即暫時不返回結果，直到配置發生變化或達到一定的超時時間。

具體的實現過程如下：

客戶端發起Pull請求，服務端檢查配置是否有變更。如果沒有變更，則設置一個定時任務，在一段時間後執行，並將當前的客戶端連接加入到等待隊列中。
在等待期間，如果配置發生變更，服務端會立即返回結果給客戶端，完成一次"推送"操作。
如果在等待期間沒有配置變更，等待時間達到預設的超時時間後，服務端會自動返回結果給客戶端，即使配置沒有變更。
如果在等待期間，通過Nacos Dashboard或API對配置進行了修改，會觸發一個事件機制，服務端會遍歷等待隊列，找到發生變更的配置項對應的客戶端連接，並將變更的數據通過連接返回，完成一次"推送"操作。

通過長輪詢的方式，Nacos客戶端能夠實時感知配置的變化，並及時獲取最新的配置信息。同時，這種方式也降低了服務端的壓力，避免了大量的長連接佔用內存資源。

遠程調用

14.能說下HTTP和RPC的區別嗎？

嚴格來講，HTTP和不是一個層面的東西：

HTTP（Hypertext Transfer Protocol）是一種應用層協議，主要強調的是網絡通信；
RPC（Remote Procedure Call，遠程過程調用）是一種用於分佈式系統之間通信的協議，強調的是服務之間的遠程調用。

一些RPC框架比如gRPC，底層傳輸協議其實也是用的HTTP2，包括Dubbo3，也兼容了gRPC，使用了HTTP2作爲傳輸層的一層協議。

如果硬要說區別的話，如下：

HTTP	RPC
定義	HTTP（超文本傳輸協議）是一種用於傳輸超文本的協議。	RPC（遠程過程調用）是一種用於實現分佈式系統中不同節點之間通信的協議。
通信方式	基於請求-響應模型，客戶端發送請求，服務器返回響應。	基於方法調用模型，客戶端調用遠程方法並等待結果。
傳輸協議	基於TCP協議，可使用其他傳輸層協議如TLS/SSL進行安全加密。	可以使用多種傳輸協議，如TCP、UDP等。
數據格式	基於文本，常用的數據格式有JSON、XML等。	可以使用各種數據格式，如二進制、JSON、Protocol Buffers等。
接口定義	使用RESTful風格的接口進行定義，常用的方法有GET、POST、PUT、DELETE等。	使用IDL（接口定義語言）進行接口定義，如Protocol Buffers、Thrift等。
跨語言性	支持跨語言通信，可以使用HTTP作爲通信協議實現不同語言之間的通信。	支持跨語言通信，可以使用IDL生成不同語言的客戶端和服務端代碼。
靈活性	更加靈活，適用於不同類型的應用場景，如Web開發、API調用等。	更加高效，適用於需要高性能和低延遲的分佈式系統。

在微服務體系裏，基於HTTP風格的遠程調用通常使用框架如Feign來實現，基於RPC的遠程調用通常使用框架如Dubbo來實現。

15.那Feign和Dubbo的區別呢？

這兩個纔是適合拿來比較的東西：

	Feign	Dubbo
定義	Feign是一個聲明式的Web服務客戶端，用於簡化HTTP API的調用。	Dubbo是一個分佈式服務框架，用於構建面向服務的微服務架構。
通信方式	基於HTTP協議，使用RESTful風格的接口進行定義和調用。	基於RPC協議，支持多種序列化協議如gRPC、Hessian等。
服務發現	通常結合服務註冊中心（如Eureka、Consul）進行服務發現和負載均衡。	通過ZooKeeper、Nacos等進行服務註冊和發現，並提供負載均衡功能。
服務治理	不直接提供服務治理功能，需要結合其他組件或框架進行服務治理。	提供服務註冊與發現、負載均衡、容錯機制、服務降級等服務治理功能。
跨語言性	支持跨語言通信，可以使用HTTP作爲通信協議實現不同語言之間的通信。	支持跨語言通信，通過Dubbo的IDL生成不同語言的客戶端和服務端代碼。
生態系統	集成了Spring Cloud生態系統，與Spring Boot無縫集成。	擁有完整的生態系統，包括註冊中心、配置中心、監控中心等組件。
適用場景	適用於構建RESTful風格的微服務架構，特別適合基於HTTP的微服務調用。	適用於構建面向服務的微服務架構，提供更全面的服務治理和容錯機制。

需要注意的是，Feign和Dubbo並不是互斥的關係。實際上，Dubbo可以使用HTTP協議作爲通信方式，而Feign也可以集成RPC協議進行遠程調用。選擇使用哪種遠程調用方式取決於具體的業務需求和技術棧的選擇。

16.說一下Fegin?

Feign是一個聲明式的Web服務客戶端，它簡化了使用基於HTTP的遠程服務的開發。

Feign是在RestTemplate 和 Ribbon的基礎上進一步封裝，使用RestTemplate實現Http調用，使用Ribbon實現負載均衡。

Feign的主要特點和功能包括：

聲明式API：Feign允許開發者使用簡單的註解來定義和描述對遠程服務的訪問。通過使用註解，開發者可以輕鬆地指定URL、HTTP方法、請求參數、請求頭等信息，使得遠程調用變得非常直觀和易於理解。

@FeignClient(name = "example", url = "https://api.example.com")
public interface ExampleService {
    @GetMapping("/endpoint")
    String getEndpointData();
}

集成負載均衡：Feign集成了Ribbon負載均衡器，可以自動實現客戶端的負載均衡。它可以根據服務名和可用實例進行動態路由，並分發請求到不同的服務實例上，提高系統的可用性和可伸縮性。
容錯機制：Feign支持集成Hystrix容錯框架，可以在調用遠程服務時提供容錯和斷路器功能。當遠程服務不可用或響應時間過長時，Feign可以快速失敗並返回預設的響應結果，避免對整個系統造成級聯故障。

17.爲什麼Feign第一次調用耗時很長？

主要原因是由於Ribbon的懶加載機制，當第一次調用發生時，Feign會觸發Ribbon的加載過程，包括從服務註冊中心獲取服務列表、建立連接池等操作，這個加載過程會增加首次調用的耗時。

ribbon:
  eager-load:
    enabled: true
      clients: service-1

那怎麼解決這個問題呢？

可以在應用啓動時預熱Feign客戶端，自動觸發一次無關緊要的調用，來提前加載Ribbon和其他相關組件。這樣，就相當於提前進行了第一次調用。

18.Feign怎麼實現認證傳遞？

比較常見的一個做法是，使用攔截器傳遞認證信息。可以通過實現RequestInterceptor接口來定義攔截器，在攔截器裏，把認證信息添加到請求頭中，然後將其註冊到Feign的配置中。

@Configuration
public class FeignClientConfig {

    @Bean
    public RequestInterceptor requestInterceptor() {
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // 添加認證信息到請求頭中
                template.header("Authorization", "Bearer " + getToken());
            }
        };
    }

    private String getToken() {
        // 獲取認證信息的邏輯，可以從SecurityContext或其他地方獲取
        // 返回認證信息的字符串形式
        return "your_token";
    }
}

19.Fegin怎麼做負載均衡？Ribbon?

在Feign中，負載均衡是通過集成Ribbon來實現的。

Ribbon是Netflix開源的一個客戶端負載均衡器，可以與Feign無縫集成，爲Feign提供負載均衡的能力。

Ribbon通過從服務註冊中心獲取可用服務列表，並通過負載均衡算法選擇合適的服務實例進行請求轉發，實現客戶端的負載均衡。

20.說說有哪些負載均衡算法？

常見的負載均衡算法包含以下幾種：

輪詢算法（Round Robin）：輪詢算法是最簡單的負載均衡算法之一。它按照順序將請求依次分配給每個後端服務器，循環往復。當請求到達時，負載均衡器按照事先定義的順序選擇下一個服務器。輪詢算法適用於後端服務器具有相同的處理能力和性能的場景。
加權輪詢算法（Weighted Round Robin）：加權輪詢算法在輪詢算法的基礎上增加了權重的概念。每個後端服務器都被賦予一個權重值，權重值越高，被選中的概率就越大。這樣可以根據服務器的處理能力和性能調整請求的分配比例，使得性能較高的服務器能夠處理更多的請求。
隨機算法（Random）：隨機算法將請求隨機分配給後端服務器。每個後端服務器有相等的被選中概率，沒有考慮服務器的實際負載情況。這種算法簡單快速，適用於後端服務器性能相近且無需考慮請求處理能力的場景。
加權隨機算法（Weighted Random）：加權隨機算法在隨機算法的基礎上引入了權重的概念。每個後端服務器被賦予一個權重值，權重值越高，被選中的概率就越大。這樣可以根據服務器的處理能力和性能調整請求的分配比例。
最少連接算法（Least Connection）：最少連接算法會根據後端服務器當前的連接數來決定請求的分配。負載均衡器會選擇當前連接數最少的服務器進行請求分配，以保證後端服務器的負載均衡。這種算法適用於後端服務器的處理能力不同或者請求的處理時間不同的場景。
哈希算法（Hash）：哈希算法會根據請求的某個特定屬性（如客戶端IP地址、請求URL等）計算哈希值，然後根據哈希值選擇相應的後端服務器。

常見的負載均衡器，比如Ribbion、Gateway等等，基本都支持這些負載均衡算法。

關於Dubbo，後面會單獨出一期。

服務容災

21.什麼是服務雪崩？

在微服務中，假如一個或者多個服務出現故障，如果這時候，依賴的服務還在不斷髮起請求，或者重試，那麼這些請求的壓力會不斷在下游堆積，導致下游服務的負載急劇增加。不斷累計之下，可能會導致故障的進一步加劇，可能會導致級聯式的失敗，甚至導致整個系統崩潰，這就叫服務雪崩。

一般，爲了防止服務雪崩，可以採用這些措施：

服務高可用部署：確保各個服務都具備高可用性，通過冗餘部署、故障轉移等方式來減少單點故障的影響。
限流和熔斷：對服務之間的請求進行限流和熔斷，以防止過多的請求湧入導致後端服務不可用。
緩存和降級：合理使用緩存來減輕後端服務的負載壓力，並在必要時進行服務降級，保證核心功能的可用性。

22.什麼是服務熔斷？什麼是服務降級？

什麼是服務熔斷？

服務熔斷是微服務架構中的容錯機制，用於保護系統免受服務故障或異常的影響。當某個服務出現故障或異常時，服務熔斷可以快速隔離該服務，確保系統穩定可用。

它通過監控服務的調用情況，當錯誤率或響應時間超過閾值時，觸發熔斷機制，後續請求將返回默認值或錯誤信息，避免資源浪費和系統崩潰。

服務熔斷還支持自動恢復，重新嘗試對故障服務的請求，確保服務恢復正常後繼續使用。

什麼是服務降級？

服務降級是也是一種微服務架構中的容錯機制，用於在系統資源緊張或服務故障時保證核心功能的可用性。

當系統出現異常情況時，服務降級會主動屏蔽一些非核心或可選的功能，而只提供最基本的功能，以確保系統的穩定運行。通過減少對資源的依賴，服務降級可以保證系統的可用性和性能。

它可以根據業務需求和系統狀況來制定策略，例如替換耗時操作、返回默認響應、返回靜態錯誤頁面等。

有哪些熔斷降級方案實現？

目前常見的服務熔斷降級實現方案有這麼幾種：

框架	實現方案	特點
Spring Cloud	Netflix Hystrix	- 提供線程隔離、服務降級、請求緩存、請求合併等功能 - 可與Spring Cloud其他組件無縫集成 - 官方已宣佈停止維護，推薦使用Resilience4j代替
Spring Cloud	Resilience4j	- 輕量級服務熔斷庫 - 提供類似於Hystrix的功能 - 具有更好的性能和更簡潔的API - 可與Spring Cloud其他組件無縫集成
Spring Cloud Alibaba	Sentinel	- 阿里巴巴開源的流量控制和熔斷降級組件 - 提供實時監控、流量控制、熔斷降級等功能 - 與Spring Cloud Alibaba生態系統緊密集成
Dubbo	Dubbo自帶熔斷降級機制	- Dubbo框架本身提供的熔斷降級機制 - 可通過配置實現服務熔斷和降級 - 與Dubbo的RPC框架緊密集成

23.Hystrix怎麼實現服務容錯？

儘管已經不再更新，但是Hystrix是非常經典的服務容錯開源庫，它提供了多種機制來保護系統：

服務熔斷（Circuit Breaker）：Hystrix通過設置閾值來監控服務的錯誤率或響應時間。當錯誤率或響應時間超過預設的閾值時，熔斷器將會打開，後續的請求將不再發送到實際的服務提供方，而是返回預設的默認值或錯誤信息。這樣可以快速隔離故障服務，防止故障擴散，提高系統的穩定性和可用性。
服務降級（Fallback）：當服務熔斷打開時，Hystrix可以提供一個備用的降級方法或返回默認值，以保證系統繼續正常運行。開發者可以定義降級邏輯，例如返回緩存數據、執行簡化的邏輯或調用其他可靠的服務，以提供有限但可用的功能。

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;

/**
* 服務降級示例
**/
@Service
public class MyService {

    @HystrixCommand(fallbackMethod = "fallbackMethod")
    public String myServiceMethod() {
        // 實際的服務調用邏輯
        // ...
    }

    public String fallbackMethod() {
        // 降級方法的邏輯，當服務調用失敗時會執行此方法
        // 可以返回默認值或執行其他備用邏輯
        // ...
    }
}

請求緩存（Request Caching）：Hystrix可以緩存對同一請求的響應結果，當下次請求相同的數據時，直接從緩存中獲取，避免重複的網絡請求，提高系統的性能和響應速度。
請求合併（Request Collapsing）：Hystrix可以將多個併發的請求合併爲一個批量請求，減少網絡開銷和資源佔用。這對於一些高併發的場景可以有效地減少請求次數，提高系統的性能。
實時監控和度量（Real-time Monitoring and Metrics）：Hystrix提供了實時監控和度量功能，可以對服務的執行情況進行監控和統計，包括錯誤率、響應時間、併發量等指標。通過監控數據，可以及時發現和解決服務故障或性能問題。
線程池隔離（Thread Pool Isolation）：Hystrix將每個依賴服務的請求都放在獨立的線程池中執行，避免因某個服務的故障導致整個系統的線程資源耗盡。通過線程池隔離，可以提高系統的穩定性和可用性。

24.Sentinel怎麼實現限流的？

Sentinel通過動態管理限流規則，根據定義的規則對請求進行限流控制。具體實現步驟如下：

定義資源：在Sentinel中，資源可以是URL、方法等，用於標識需要進行限流的請求。

// 原本的業務方法.
@SentinelResource(blockHandler = "blockHandlerForGetUser")
public User getUserById(String id) {
    throw new RuntimeException("getUserById command failed");
}

// blockHandler 函數，原方法調用被限流/降級/系統保護的時候調用
public User blockHandlerForGetUser(String id, BlockException ex) {
    return new User("admin");
}

配置限流規則：在Sentinel的配置文件中定義資源的限流規則。規則可以包括資源名稱、限流閾值、限流模式（令牌桶或漏桶）等。

private static void initFlowQpsRule() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule1 = new FlowRule();
    rule1.setResource(resource);
    // Set max qps to 20
    rule1.setCount(20);
    rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule1.setLimitApp("default");
    rules.add(rule1);
    FlowRuleManager.loadRules(rules);
}

監控流量：Sentinel會監控每個資源的流量情況，包括請求的QPS（每秒請求數）、線程數、響應時間等。

限流控制：當請求到達時，Sentinel會根據資源的限流規則判斷是否需要進行限流控制。如果請求超過了限流閾值，則可以進行限制、拒絕或進行其他降級處理。

Sentinel採用的什麼限流算法？

Sentinel使用滑動窗口限流算法來實現限流。

滑動窗口限流算法是一種基於時間窗口的限流算法。它將一段時間劃分爲多個時間窗口，並在每個時間窗口內統計請求的數量。通過動態地調整時間窗口的大小和滑動步長，可以更精確地控制請求的通過速率。

滑動窗口限流可以查看前面的分佈式篇。

Sentinel怎麼實現集羣限流？

Sentinel利用了Token Server和Token Client的機制來實現集羣限流。

開啓集羣限流後，Client向Token Server發送請求，Token Server根據配置的規則決定是否限流。T

服務網關

25.什麼是API網關？

API網關（API Gateway）是一種中間層服務器，用於集中管理、保護和路由對後端服務的訪問。它充當了客戶端與後端服務之間的入口點，提供了一組統一的接口來管理和控制API的訪問。

API網關的主要功能包括：

路由轉發：API網關根據請求的URL路徑或其他標識，將請求路由到相應的後端服務。通過配置路由規則，可以靈活地將請求分發給不同的後端服務。
負載均衡：API網關可以在後端服務之間實現負載均衡，將請求平均分發到多個實例上，提高系統的吞吐量和可擴展性。
安全認證與授權：API網關可以集中處理身份驗證和授權，確保只有經過身份驗證的客戶端才能訪問後端服務。它可以與身份提供者（如OAuth、OpenID Connect）集成，進行用戶認證和授權操作。
緩存：API網關可以緩存後端服務的響應，減少對後端服務的請求次數，提高系統性能和響應速度。
監控與日誌：API網關可以收集和記錄請求的指標和日誌，提供實時監控和分析，幫助開發人員和運維人員進行故障排查和性能優化。
數據轉換與協議轉換：API網關可以在客戶端和後端服務之間進行數據格式轉換和協議轉換，如將請求從HTTP轉換爲WebSocket，或將請求的參數進行格式轉換，以滿足後端服務的需求。
API版本管理：API網關可以管理不同版本的API，允許同時存在多個API版本，並通過路由規則將請求正確地路由到相應的API版本上。

……

通過使用API網關，可以簡化前端與後端服務的交互，提供統一的接口和安全性保障，同時也方便了服務治理和監控。它是構建微服務架構和實現API管理的重要組件之一。

26.SpringCloud可以選擇哪些API網關？

使用SpringCloud開發，可以採用以下的API網關選型：

Netflix Zuul（已停止更新）：Netflix Zuul是Spring Cloud早期版本中提供的默認API網關。它基於Servlet技術棧，可以進行路由、過濾、負載均衡等功能。然而，自2020年12月起，Netflix宣佈停止對Zuul 1的維護，轉而支持新的API網關項目。
Spring Cloud Gateway：Spring Cloud Gateway是Spring Cloud官方推薦的API網關，取代了Netflix Zuul。它基於非阻塞的WebFlux框架，充分利用了響應式編程的優勢，並提供了路由、過濾、斷路器、限流等特性。Spring Cloud Gateway還支持與Spring Cloud的其他組件集成，如服務發現、負載均衡等。
Kong：Kong是一個獨立的、雲原生的API網關和服務管理平臺，可以與Spring Cloud集成。Kong基於Nginx，提供了強大的路由、認證、授權、監控和擴展能力。它支持多種插件和擴展，可滿足不同的API管理需求。
APISIX：APISIX基於Nginx和Lua開發，它具有強大的路由、流量控制、插件擴展等功能。APISIX支持靈活的配置方式，可以根據需求進行動態路由、負載均衡和限流等操作。

……

27.Spring Cloud Gateway核心概念？

在Spring Cloud Gateway裏，有三個關鍵組件：

Route（路由）：路由是Spring Cloud Gateway的基本構建塊，它定義了請求的匹配規則和轉發目標。通過配置路由，可以將請求映射到後端的服務實例或URL上。路由規則可以根據請求的路徑、方法、請求頭等條件進行匹配，並指定轉發的目標URI。
Predicate（斷言）：斷言用於匹配請求的條件，如果請求滿足斷言的條件，則會應用所配置的過濾器。Spring Cloud Gateway提供了多種內置的斷言，如Path（路徑匹配）、Method（請求方法匹配）、Header（請求頭匹配）等，同時也支持自定義斷言。
Filter（過濾器）：過濾器用於對請求進行處理和轉換，可以修改請求、響應以及執行其他自定義邏輯。Spring Cloud Gateway提供了多個內置的過濾器，如請求轉發、請求重試、請求限流等。同時也支持自定義過濾器，可以根據需求編寫自己的過濾器邏輯。

我們再來看下Spring Cloud Gateway的具體工作流程：

又有兩個比較重要的概念：

Gateway Handler（網關處理器）：網關處理器是Spring Cloud Gateway的核心組件，負責將請求轉發到匹配的路由上。它根據路由配置和斷言條件進行路由匹配，選擇合適的路由進行請求轉發。網關處理器還會依次應用配置的過濾器鏈，對請求進行處理和轉換。
Gateway Filter Chain（網關過濾器鏈）：網關過濾器鏈由一系列過濾器組成，按照配置的順序依次執行。每個過濾器可以在請求前、請求後或請求發生錯誤時進行處理。過濾器鏈的執行過程可以修改請求、響應以及執行其他自定義邏輯。

鏈路追蹤

28.爲什麼要用微服務鏈路追蹤？

在微服務中，有的山下游可能有十幾個服務，如果某一環出了問題，排查起來非常困難，所以，就需要進行鏈路追蹤，來幫助排查問題。

通過鏈路追蹤，可以可視化地追蹤請求從一個微服務到另一個微服務的調用情況。除了排查問題，鏈路追蹤黑還可以幫助優化性能，可視化依賴關係、服務監控和告警。

29.SpringCloud可以選擇哪些微服務鏈路追蹤方案？

Spring Cloud提供了多種選擇的微服務鏈路追蹤方案。以下是一些常用的方案：

Zipkin：Zipkin 是一個開源的分佈式實時追蹤系統，由 Twitter 開發並貢獻給開源社區。Spring Cloud Sleuth 提供了與 Zipkin 的集成，可以通過在微服務中添加相應的依賴和配置，將追蹤信息發送到 Zipkin 服務器，並通過 Zipkin UI 進行可視化展示和查詢。

Jaeger：Jaeger 是 Uber 開源的分佈式追蹤系統，也被納入了 CNCF（雲原生計算基金會）的維護。通過使用 Spring Cloud Sleuth 和 Jaeger 客戶端庫，可以將追蹤信息發送到 Jaeger 並進行可視化展示和查詢。
SkyWalking：Apache SkyWalking 是一款開源的應用性能監控與分析系統，提供了對 Java、.NET 和 Node.js 等語言的支持。它可以與 Spring Cloud Sleuth 集成，將追蹤數據發送到 SkyWalking 服務器進行可視化展示和分析。

Pinpoint：Pinpoint 是 Naver 開源的分佈式應用性能監控系統，支持 Java 和 .NET。它提供了與 Spring Cloud Sleuth 的集成，可以將追蹤數據發送到 Pinpoint 服務器，並通過其 UI 進行分析和監控。

這些方案都可以與 Spring Cloud Sleuth 進行集成，Spring Cloud Sleuth 是 Spring Cloud 中的一個組件，提供了在微服務調用時生成追蹤信息的能力。

分佈式事務

分佈式事務可以查看前面的分佈式基礎篇。

30.Seata支持哪些模式的分佈式事務？

Seata以下幾種模式的分佈式事務：

AT（Atomikos）模式：AT模式是Seata默認支持的模式，也是最常用的模式之一。在AT模式下，Seata通過在業務代碼中嵌入事務上下文，實現對分佈式事務的管理。Seata會攔截並解析業務代碼中的SQL語句，通過對數據庫連接進行攔截和代理，實現事務的管理和協調。

TCC（Try-Confirm-Cancel）模式：TCC模式是一種基於補償機制的分佈式事務模式。在TCC模式中，業務邏輯需要實現Try、Confirm和Cancel三個階段的操作。Seata通過調用業務代碼中的Try、Confirm和Cancel方法，並在每個階段記錄相關的操作日誌，來實現分佈式事務的一致性。

SAGA模式：SAGA模式是一種基於事件驅動的分佈式事務模式。在SAGA模式中，每個服務都可以發佈和訂閱事件，通過事件的傳遞和處理來實現分佈式事務的一致性。Seata提供了與SAGA模式兼容的Saga框架，用於管理和協調分佈式事務的各個階段。

XA模式：XA模式是一種基於兩階段提交（Two-Phase Commit）協議的分佈式事務模式。在XA模式中，Seata通過與數據庫的XA事務協議進行交互，實現對分佈式事務的管理和協調。XA模式需要數據庫本身支持XA事務，並且需要在應用程序中配置相應的XA數據源。

31.瞭解Seata的實現原理嗎？

Seata的實現原理主要包括三個核心組件：事務協調器（Transaction Coordinator）、事務管理器（Transaction Manager）和資源管理器（Resource Manager）。

事務協調器（Transaction Coordinator）：事務協調器負責協調和管理分佈式事務的整個過程。它接收事務的開始和結束請求，並根據事務的狀態進行協調和處理。事務協調器還負責記錄和管理事務的全局事務 ID（Global Transaction ID）和分支事務 ID（Branch Transaction ID）。
事務管理器（Transaction Manager）：事務管理器負責全局事務的管理和控制。它協調各個分支事務的提交或回滾，並保證分佈式事務的一致性和隔離性。事務管理器還負責與事務協調器進行通信，並將事務的狀態變更進行持久化。
資源管理器（Resource Manager）：資源管理器負責管理和控制各個參與者（Participant）的事務操作。它與事務管理器進行通信，並根據事務管理器的指令執行相應的事務操作，包括提交和回滾。

Seata的實現原理基於兩階段提交（Two-Phase Commit）協議，具體的機制如下：

一階段：在事務提交的過程中，首先進行預提交階段。事務協調器向各個資源管理器發送預提交請求，資源管理器執行相應的事務操作並返回執行結果。在此階段，業務數據和回滾日誌記錄在同一個本地事務中提交，並釋放本地鎖和連接資源。
二階段：在預提交階段成功後，進入真正的提交階段。此階段主要包括提交異步化和回滾反向補償兩個步驟：
- 提交異步化：事務協調器發出真正的提交請求，各個資源管理器執行最終的提交操作。這個階段的操作是非常快速的，以確保事務的提交效率。
- 回滾反向補償：如果在預提交階段中有任何一個資源管理器返回失敗結果，事務協調器發出回滾請求，各個資源管理器執行回滾操作，利用一階段的回滾日誌進行反向補償。

Seata的事務執行流程是什麼樣的？

Seata事務的執行流程可以簡要概括爲以下幾個步驟：

事務發起方（Transaction Starter）發起全局事務：事務發起方是指發起分佈式事務的應用程序或服務。它向Seata的事務協調器發送全局事務的開始請求，生成全局事務ID（Global Transaction ID）。
事務協調器創建全局事務記錄：事務協調器接收到全局事務的開始請求後，會爲該事務創建相應的全局事務記錄，並生成分支事務ID（Branch Transaction ID）。
分支事務註冊：事務發起方將全局事務ID和分支事務ID發送給各個參與者（Participant），即資源管理器。參與者將分支事務ID註冊到本地事務管理器，並將事務的執行結果反饋給事務協調器。
執行業務邏輯：在分佈式事務的上下文中，各個參與者執行各自的本地事務，即執行業務邏輯和數據庫操作。
預提交階段：事務發起方向事務協調器發送預提交請求，事務協調器將預提交請求發送給各個參與者。
執行本地事務確認：參與者接收到預提交請求後，執行本地事務的確認操作，並將本地事務的執行結果反饋給事務協調器。
全局事務提交或回滾：事務協調器根據參與者反饋的結果進行判斷，如果所有參與者的本地事務都執行成功，事務協調器發送真正的提交請求給參與者，參與者執行最終的提交操作；如果有任何一個參與者的本地事務執行失敗，事務協調器發送回滾請求給參與者，參與者執行回滾操作。
完成全局事務：事務協調器接收到參與者的提交或回滾結果後，根據結果更新全局事務的狀態，並通知事務發起方全局事務的最終結果。

全局事務ID和分支事務ID是怎麼傳遞的？

全局事務ID和分支事務ID在分佈式事務中通過上下文傳遞的方式進行傳遞。常見的傳遞方式包括參數傳遞、線程上下文傳遞和消息中間件傳遞。具體的傳遞方式可以根據業務場景和技術選型進行選擇和調整。

Seata的事務回滾是怎麼實現的？

Seata的事務回滾是通過回滾日誌實現的。每個參與者在執行本地事務期間生成回滾日誌，記錄了對數據的修改操作。

當需要回滾事務時，事務協調器向參與者發送回滾請求，參與者根據回滾日誌中的信息執行撤銷操作，將數據恢復到事務開始前的狀態。

回滾日誌的管理和存儲是Seata的核心機制，可以選擇將日誌存儲在不同的介質中。通過回滾日誌的持久化和恢復，Seata確保了事務的一致性和恢復性。

服務監控

32.你們的服務怎麼做監控和告警？

我們使用Prometheus和Grafana來實現整個微服務集羣的監控和告警：

Prometheus：Prometheus 是一個開源的監控系統，具有靈活的數據模型和強大的查詢語言，能夠收集和存儲時間序列數據。它可以通過HTTP協議定期拉取微服務的指標數據，並提供可擴展的存儲和查詢功能。
Grafana：Grafana 是一個開源的可視化儀表板工具，可以與 Prometheus 結合使用，創建實時和歷史數據的儀表板。Grafana 提供了豐富的圖表和可視化選項，可以幫助用戶更好地理解和分析微服務的性能和狀態。

33.你們的服務怎麼做日誌收集？

日誌收集有很多種方案，我們用的是ELK：

Elasticsearch：Elasticsearch是一個分佈式搜索和分析引擎，用於存儲和索引大量的日誌數據。它提供了快速的搜索和聚合功能，可以高效地處理大規模的日誌數據。
Logstash：Logstash是一個用於收集、過濾和轉發日誌數據的工具。它可以從各種來源（如文件、網絡、消息隊列等）收集日誌數據，並對數據進行處理和轉換，然後將其發送到Elasticsearch進行存儲和索引。
Kibana：Kibana是一個用於日誌數據可視化和分析的工具。它提供了豐富的圖表、儀表盤和搜索功能，可以幫助用戶實時監控和分析日誌數據，發現潛在的問題和趨勢。

簡單說，這三者裏Elasticsearch提供數據存儲和檢索能力，Logstash負責將日誌收集到ES，Kibana負責日誌數據的可視化分析。

使用ELK進行微服務日誌收集的一般流程如下：

在每個微服務中配置日誌輸出：將微服務的日誌輸出到標準輸出（stdout）或日誌文件。
使用Logstash收集日誌：配置Logstash收集器，通過配置輸入插件（如文件輸入、網絡輸入等）監聽微服務的日誌輸出，並進行過濾和處理。
將日誌數據發送到Elasticsearch：配置Logstash的輸出插件，將經過處理的日誌數據發送到Elasticsearch進行存儲和索引。
使用Kibana進行可視化和分析：通過Kibana連接到Elasticsearch，創建儀表盤、圖表和搜索查詢，實時監控和分析微服務的日誌數據。

除了應用最廣泛的ELK，還有一些其它的方案比如Fluentd、Graylog、Loki、Filebeat，一些雲廠商也提供了付費方案，比如阿里雲的sls。

參考：

[1]. 《重新定義SpringCloud實戰》

[2]. 《SpringCloud Alibaba微服務實戰與原理》

[4].《SpringCloud微服務和分佈式系統實踐》

[5].https://cn.dubbo.apache.org/

[6].https://cloud.spring.io/spring-cloud-netflix/reference/html/

[7].https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu

[8].https://grafana.com/

[9].https://www.bmabk.com/index.php/post/142012.html

[10].https://sentinelguard.io/zh-cn/

[11].https://www.elastic.co/elastic-stack

[12].https://seata.io/

**⭐️面渣逆襲系列：**

面渣逆襲系列已經結集成冊，持續更新維護中，關注公衆號「三分惡」，回覆「666」即可無套路獲取！

面渣逆襲：微服務三十三問，兩萬字圖文詳解！速收藏！

概覽