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

概覽

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」即可無套路獲取！

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

概覽