微服務(wù)
因?yàn)橹皩懙腟pringboot學(xué)習(xí)指南過長，這次就邊寫邊發(fā)了，
本章節(jié)首先介紹微服務(wù)的一些內(nèi)容，大概會分五到六篇的樣子，寫完就發(fā)不拖拉，
雖然很多人寫過但是沒關(guān)系萬一你沒看過呢，恰好你又看到了我寫的內(nèi)容.
這節(jié)可能有點(diǎn)干，但是還是請大家多喝水!內(nèi)容稍微枯燥，我自己寫的時(shí)候都是狂喝水，??????
1.微服務(wù)理論（個(gè)人理解）
微服務(wù)架構(gòu)是一種軟件架構(gòu)設(shè)計(jì)方法，其中應(yīng)用程序被拆分成一組小型、自治的服務(wù)單元，每個(gè)服務(wù)單元都專注于執(zhí)行特定的業(yè)務(wù)功能，并且可以獨(dú)立部署、擴(kuò)展和管理。這些服務(wù)單元通過輕量級的通信機(jī)制（通常是HTTP/REST或消息隊(duì)列）相互通信，以實(shí)現(xiàn)應(yīng)用程序的整體功能。
以下是微服務(wù)架構(gòu)的一些關(guān)鍵特點(diǎn)和優(yōu)勢：
- 模塊化： 微服務(wù)將應(yīng)用程序拆分成小的、松耦合的服務(wù)單元，每個(gè)單元都有明確定義的邊界和功能。這使得開發(fā)、測試、部署和維護(hù)變得更加簡單和靈活。
- 獨(dú)立部署： 每個(gè)微服務(wù)都可以獨(dú)立部署，這意味著你可以對系統(tǒng)的特定部分進(jìn)行更新或修改，而不會影響到整個(gè)系統(tǒng)的運(yùn)行。這降低了部署的風(fēng)險(xiǎn)，并且使得系統(tǒng)更容易擴(kuò)展和維護(hù)。
- 技術(shù)多樣性： 由于每個(gè)微服務(wù)都是獨(dú)立的，因此可以使用不同的技術(shù)棧和編程語言來開發(fā)不同的服務(wù)單元，以滿足特定的需求。這使得團(tuán)隊(duì)可以選擇最適合他們需求的技術(shù)，并且可以靈活地進(jìn)行技術(shù)升級或切換。
- 彈性和可伸縮性： 微服務(wù)架構(gòu)可以根據(jù)需求對每個(gè)服務(wù)單元進(jìn)行水平擴(kuò)展，從而實(shí)現(xiàn)系統(tǒng)的彈性和可伸縮性。你可以根據(jù)流量的增減動態(tài)地增加或減少服務(wù)的實(shí)例數(shù)量，以確保系統(tǒng)始終具有所需的性能和可用性。
- 獨(dú)立團(tuán)隊(duì)和快速交付： 每個(gè)微服務(wù)都由獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)開發(fā)和維護(hù)，這使得團(tuán)隊(duì)可以專注于特定的業(yè)務(wù)功能，并且可以快速地交付新功能或更新。此外，微服務(wù)架構(gòu)還鼓勵(lì)采用持續(xù)集成和持續(xù)交付（CI/CD）的實(shí)踐，以實(shí)現(xiàn)快速迭代和反饋循環(huán)。
- 容錯(cuò)性和故障隔離： 微服務(wù)架構(gòu)通過使用獨(dú)立的服務(wù)單元來實(shí)現(xiàn)容錯(cuò)性和故障隔離。如果一個(gè)服務(wù)單元發(fā)生故障，只會影響到該服務(wù)單元的功能，而不會影響到整個(gè)系統(tǒng)的穩(wěn)定性。
當(dāng)談到微服務(wù)時(shí)，我們可以將其比喻為一種建筑設(shè)計(jì)方法，其中軟件應(yīng)用程序被拆分成小的、獨(dú)立的服務(wù)單元，每個(gè)服務(wù)單元都專注于執(zhí)行特定的任務(wù)或功能。讓我們用一個(gè)通俗易懂的比喻來解釋微服務(wù)的理論：
想象你正在建造一座大型城市，而這個(gè)城市是你的軟件應(yīng)用程序。傳統(tǒng)的單體應(yīng)用程序就像是整個(gè)城市都建在一個(gè)大型建筑物里，所有的功能和服務(wù)都集中在一個(gè)地方。這可能會導(dǎo)致一些問題，比如如果需要對城市進(jìn)行維護(hù)或擴(kuò)展，會非常困難，而且一旦發(fā)生故障，整個(gè)城市就會癱瘓。
現(xiàn)在，想象你決定用微服務(wù)的方式來建造你的城市。相比于一個(gè)巨大的建筑物，你把城市拆分成了許多小區(qū)域，每個(gè)小區(qū)域都有自己的功能和服務(wù)，比如一棟建筑是一個(gè)服務(wù)單元，專門負(fù)責(zé)提供住宅服務(wù)，另一棟建筑是另一個(gè)服務(wù)單元，負(fù)責(zé)提供商業(yè)服務(wù)，而交通、娛樂等功能也都有各自的建筑。每個(gè)小區(qū)域（或服務(wù) 單元）都可以獨(dú)立運(yùn)行，而且可以根據(jù)需要靈活地?cái)U(kuò)展或更新，而不會影響到其他區(qū)域。這就是微服務(wù)的概念：將復(fù)雜的應(yīng)用程序拆分成小的、可獨(dú)立部署的服務(wù)單元，以提高靈活性、可維護(hù)性和可擴(kuò)展性。
通過這種方式，當(dāng)你需要修改或更新城市的某個(gè)部分時(shí)，你只需要關(guān)注到這個(gè)特定的區(qū)域，而不需要影響到整個(gè)城市的運(yùn)行。這使得開發(fā)、測試和部署變得更加簡單和高效，同時(shí)也減少了單點(diǎn)故障的風(fēng)險(xiǎn)。
總的來說，微服務(wù)就像是把一個(gè)大城市拆分成許多小社區(qū)，每個(gè)社區(qū)都有自己的功能和服務(wù)，使得整個(gè)系統(tǒng)更加靈活、可維護(hù)和可擴(kuò)展。
2.分布式概念及基本思想
[圖片上傳失敗...(image-7d97f0-1709663256835)]
分布式是指將一個(gè)系統(tǒng)或應(yīng)用程序的各個(gè)部分分散在多臺計(jì)算機(jī)上，這些計(jì)算機(jī)通過網(wǎng)絡(luò)進(jìn)行通信和協(xié)作，以完成共同的目標(biāo)。
集群是指將多臺計(jì)算機(jī)組合在一起，作為一個(gè)整體對外提供服務(wù)。集群中的計(jì)算機(jī)通常具有相同的硬件和軟件配置，并通過網(wǎng)絡(luò)進(jìn)行連接。
分布式和集群的區(qū)別在于：
- 分布式強(qiáng)調(diào)的是系統(tǒng)的各個(gè)部分之間的分工和協(xié)作，而集群強(qiáng)調(diào)的是多臺計(jì)算機(jī)的組合和統(tǒng)一管理。
- 分布式中的每個(gè)節(jié)點(diǎn)都可以做集群，而集群不一定就是分布式的。例如，一個(gè) Web 服務(wù)器集群可以看作是分布式系統(tǒng)中的一個(gè)節(jié)點(diǎn)。
分布式中的每個(gè)節(jié)點(diǎn)都可以做集群，因?yàn)槊總€(gè)節(jié)點(diǎn)都可以提供特定的功能或服務(wù)。例如，一個(gè)分布式文件系統(tǒng)中的每個(gè)節(jié)點(diǎn)都可以存儲一部分文件數(shù)據(jù)。
集群不一定就是分布式的，因?yàn)榧褐械乃泄?jié)點(diǎn)可以提供相同的功能或服務(wù)。例如，一個(gè) Web 服務(wù)器集群中的所有節(jié)點(diǎn)都提供 Web 服務(wù)器服務(wù)。
在實(shí)際應(yīng)用中，分布式和集群經(jīng)常被混淆使用。例如，我們可以將其比喻為一群工人，他們分散在不同的地方，但通過協(xié)作和通信完成共同的任務(wù)。每個(gè)工人都有自己的特長和職責(zé)，他們需要相互協(xié)作，以完成整個(gè)任務(wù)。
而集群則像是一家工廠，里面有許多相同的機(jī)器和設(shè)備，它們一起協(xié)作來生產(chǎn)產(chǎn)品。這些機(jī)器可能會被集中放置在一起，也可能分布在不同的地方，但它們都是為了共同的目標(biāo)而服務(wù)。
在這個(gè)比喻中，分布式系統(tǒng)強(qiáng)調(diào)的是分散在不同地方的工人之間的分工和協(xié)作，而集群則強(qiáng)調(diào)的是機(jī)器之間的組合和統(tǒng)一管理。每個(gè)分布式系統(tǒng)中的節(jié)點(diǎn)都可以看作是一個(gè)工人，而集群中的每臺機(jī)器則相當(dāng)于一個(gè)工廠中的一臺設(shè)備。
總結(jié)
分布式和集群是兩種不同的技術(shù)，它們可以相互結(jié)合使用。分布式強(qiáng)調(diào)的是系統(tǒng)的各個(gè)部分之間的分工和協(xié)作，而集群強(qiáng)調(diào)的是多臺計(jì)算機(jī)的組合和統(tǒng)一管理。分布式中的每個(gè)節(jié)點(diǎn)都可以做集群，而集群不一定就是分布式的。
2.1分布式系統(tǒng)架構(gòu)的演變
分布式系統(tǒng)的架構(gòu)演變是一個(gè)歷史悠久的過程，經(jīng)歷了多個(gè)階段和發(fā)展趨勢。以下是分布式系統(tǒng)架構(gòu)演變的主要階段和特點(diǎn)：
-
早期階段：基于RPC和消息傳遞的分布式系統(tǒng)
- 在分布式系統(tǒng)的早期階段，通信主要是通過遠(yuǎn)程過程調(diào)用（RPC）和消息傳遞來實(shí)現(xiàn)的。這些系統(tǒng)通常由多個(gè)節(jié)點(diǎn)組成，節(jié)點(diǎn)之間通過網(wǎng)絡(luò)進(jìn)行通信。
- 這種架構(gòu)簡單直接，但也存在一些問題，比如容錯(cuò)性差、擴(kuò)展性有限等。
-
中期階段：基于消息隊(duì)列和中間件的分布式系統(tǒng)
- 隨著業(yè)務(wù)需求的增加和技術(shù)的發(fā)展，分布式系統(tǒng)逐漸采用消息隊(duì)列和中間件來實(shí)現(xiàn)異步通信和解耦。
- 消息隊(duì)列提供了可靠的消息傳遞機(jī)制，可以解決網(wǎng)絡(luò)延遲和節(jié)點(diǎn)故障等問題，同時(shí)中間件（如消息代理）可以提供一些額外的功能，比如負(fù)載均衡、消息路由等。
-
近期階段：基于微服務(wù)和容器的分布式系統(tǒng)
- 隨著云計(jì)算和容器技術(shù)的興起，微服務(wù)架構(gòu)逐漸成為主流。微服務(wù)將應(yīng)用程序拆分成小的、自治的服務(wù)單元，每個(gè)服務(wù)單元都可以獨(dú)立部署和擴(kuò)展。
- 容器技術(shù)（如Docker、Kubernetes等）為微服務(wù)的部署和管理提供了更加靈活和高效的解決方案，使得分布式系統(tǒng)更加容易構(gòu)建、部署和維護(hù)。
-
未來趨勢：基于Serverless和邊緣計(jì)算的分布式系統(tǒng)
- 未來，隨著邊緣計(jì)算和Serverless架構(gòu)的發(fā)展，分布式系統(tǒng)可能會進(jìn)一步演變。
- Serverless架構(gòu)將應(yīng)用程序的部署和管理交給云服務(wù)提供商，開發(fā)人員只需關(guān)注業(yè)務(wù)邏輯，而邊緣計(jì)算則將計(jì)算資源推向網(wǎng)絡(luò)邊緣，使得數(shù)據(jù)處理更加快速和實(shí)時(shí)。（個(gè)人不建議大家現(xiàn)階段去研究）
總的來說，分布式系統(tǒng)的架構(gòu)演變是一個(gè)不斷發(fā)展的過程，始終圍繞著提高系統(tǒng)的可靠性、可擴(kuò)展性和靈活性這一核心目標(biāo)。隨著技術(shù)的不斷進(jìn)步和業(yè)務(wù)需求的變化，我們可以預(yù)見分布式系統(tǒng)架構(gòu)會繼續(xù)朝著更加簡單、高效和智能的方向發(fā)展。
2.2RPC的設(shè)計(jì)原理
RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用） 是一種分布式系統(tǒng)中的通信模式，它允許一個(gè)進(jìn)程調(diào)用另一個(gè)進(jìn)程（通常是在不同的機(jī)器上）上的函數(shù)或方法，就像調(diào)用本地函數(shù)一樣。以下是RPC的設(shè)計(jì)原理：
[圖片上傳失敗...(image-585a15-1709663256835)]
客戶端-服務(wù)器模型： RPC基于客戶端-服務(wù)器模型，其中客戶端向服務(wù)器發(fā)送請求，服務(wù)器執(zhí)行請求并返回結(jié)果?？蛻舳撕头?wù)器可以位于不同的機(jī)器上，并通過網(wǎng)絡(luò)進(jìn)行通信。
通信協(xié)議： RPC系統(tǒng)通常使用一種網(wǎng)絡(luò)協(xié)議來進(jìn)行通信，比如TCP/IP或HTTP。通信協(xié)議負(fù)責(zé)在客戶端和服務(wù)器之間傳輸請求和響應(yīng)數(shù)據(jù)，并提供可靠性和安全性保障。
Stub和Skeleton： 在RPC系統(tǒng)中，客戶端和服務(wù)器都有一些本地代理，分別稱為Stub和Skeleton。Stub負(fù)責(zé)將本地調(diào)用轉(zhuǎn)換為網(wǎng)絡(luò)消息，并將響應(yīng)消息轉(zhuǎn)換為本地調(diào)用；而Skeleton負(fù)責(zé)接收網(wǎng)絡(luò)消息，解析請求并調(diào)用本地的服務(wù)實(shí)現(xiàn)。
序列化和反序列化： 在RPC系統(tǒng)中，客戶端和服務(wù)器之間需要傳輸?shù)臄?shù)據(jù)通常以對象或結(jié)構(gòu)體的形式存在。因此，需要進(jìn)行序列化（將對象轉(zhuǎn)換為字節(jié)流）和反序列化（將字節(jié)流轉(zhuǎn)換為對象）操作，以在網(wǎng)絡(luò)上傳輸數(shù)據(jù)。
服務(wù)注冊與發(fā)現(xiàn)： 在RPC系統(tǒng)中，客戶端需要知道服務(wù)器的位置和服務(wù)接口信息，而這些信息通常是通過服務(wù)注冊中心或服務(wù)發(fā)現(xiàn)機(jī)制來獲取的。服務(wù)注冊中心負(fù)責(zé)維護(hù)服務(wù)的元數(shù)據(jù)信息，包括服務(wù)名稱、地址、端口號等，并將這些信息提供給客戶端。
遠(yuǎn)程調(diào)用： 當(dāng)客戶端調(diào)用遠(yuǎn)程方法時(shí)，客戶端的Stub將調(diào)用轉(zhuǎn)換為網(wǎng)絡(luò)消息，并將消息發(fā)送到服務(wù)器。服務(wù)器的Skeleton接收到消息后，解析請求并調(diào)用本地的服務(wù)實(shí)現(xiàn)。服務(wù)執(zhí)行完成后，服務(wù)器將結(jié)果返回給客戶端，客戶端的Stub將結(jié)果解析為本地調(diào)用的返回值。
總的來說，RPC的設(shè)計(jì)原理是通過遠(yuǎn)程調(diào)用的方式實(shí)現(xiàn)客戶端和服務(wù)器之間的通信和協(xié)作，使得分布式系統(tǒng)中的不同部分可以像調(diào)用本地函數(shù)一樣進(jìn)行交互，從而簡化了分布式系統(tǒng)的開發(fā)和維護(hù)。
2.3分布式常規(guī)知識點(diǎn)（面試題???????）
2.3.1 高并發(fā)
1）通過設(shè)計(jì)保證系統(tǒng)可以并行處理很多請求，應(yīng)對大量流量與請求。
- Tomcat最多支持并發(fā)多少用戶？
Tomcat 默認(rèn)配置的最大請求數(shù)是 150，也就是說同時(shí)支持 150 個(gè)并發(fā)，當(dāng)然了也可以將其重新配置，當(dāng)某個(gè)應(yīng)用擁有250個(gè)以上的并發(fā)的時(shí)候，應(yīng)考慮用服務(wù)器集群。具體能承載多少并發(fā)需要看硬件配置cpu越多性能越高，分配給jvm的內(nèi)存越多，性能也就越高。但是也會增加GC的負(fù)擔(dān)。
- 操作系統(tǒng)對于進(jìn)程中的線程數(shù)有一定的限制。
Windows每個(gè)進(jìn)程中的線程數(shù)不允許超過2000。（基本不用作生產(chǎn)）
Linux每個(gè)進(jìn)程中的線程數(shù)不允許超過1000。
另外，在 Java 中，每開啟一個(gè)線程需要耗用 1MB 的 JVM 內(nèi)存空間用作于線程棧之用。
Tomcat 默認(rèn)的 HTTP 實(shí)現(xiàn)是采用阻塞式的 Socket 通訊，每個(gè)請求都需要?jiǎng)?chuàng)建一個(gè)線程處理。這種模式下的并發(fā)量受到線程數(shù)的限制，但對于Tomcat來說幾乎沒有bug存在。
Tomcat 還可以配置 NIO 方式的 Socket 通訊，在性能上高于阻塞式的。 每個(gè)請求也不需要?jiǎng)?chuàng)建一個(gè)線程進(jìn)行處理，并發(fā)能力比前者高，但是沒有阻塞式的成熟。
這個(gè)并發(fā)能力還與應(yīng)用的邏輯密切相關(guān)：
如果邏輯很復(fù)雜，需要大量的計(jì)算，那么并發(fā)能力勢必會下降，如果每個(gè)請求都含有很多的數(shù)據(jù)庫操作，那么對于數(shù)據(jù)庫的性能也非常高。對于單臺數(shù)據(jù)庫服務(wù)器來說，允許客戶端的連接數(shù)量是有限的，并發(fā)能力涉及整個(gè)架構(gòu)系統(tǒng)。和業(yè)務(wù)邏輯。
并發(fā)能力涉及整個(gè)架構(gòu)系統(tǒng)和業(yè)務(wù)邏輯。
系統(tǒng)環(huán)境不同，Tomcat 版本不同，JDK 版本不同以及修改的設(shè)定參數(shù)不同，并發(fā)量的差異還是很大的
maxThreads="1000" 最大并發(fā)數(shù)設(shè)置，默認(rèn)值為200
minSpareThreads=“100” 初始化時(shí)創(chuàng)建的線程數(shù)，默認(rèn)值為10
acceptCount=“700” 指定當(dāng)所以可以使用的處理請求和線程數(shù)都被使用時(shí)，可以放到處理隊(duì)列中的請求數(shù)，超過這個(gè)數(shù)的請求將不予處理，默認(rèn)值為100
配置參考地址：https://tomcat.apache.org/tomcat-8.0-doc/config/http.html
2 )高并發(fā)衡量指標(biāo)。
高并發(fā)衡量指標(biāo)是指用來衡量系統(tǒng)在高并發(fā)情況下的性能指標(biāo)。這些指標(biāo)可以幫助我們了解系統(tǒng)的負(fù)載能力、響應(yīng)速度和穩(wěn)定性。
常見的高并發(fā)衡量指標(biāo)包括：
- QPS (Queries Per Second) ：每秒查詢數(shù)，指的是系統(tǒng)每秒能夠處理的請求數(shù)量。
- TPS (Transactions Per Second) ：每秒事務(wù)數(shù)，指的是系統(tǒng)每秒能夠處理的事務(wù)數(shù)量。
- RT (Response Time) ：響應(yīng)時(shí)間，指的是系統(tǒng)處理請求的平均時(shí)間。
- 并發(fā)數(shù)：同時(shí)處理的請求數(shù)量，指的是系統(tǒng)能夠同時(shí)處理的請求數(shù)量。
- 吞吐量：單位時(shí)間內(nèi)處理的請求數(shù)量，指的是系統(tǒng)單位時(shí)間內(nèi)能夠處理的請求數(shù)量。
QPS 和 TPS 是衡量系統(tǒng)處理能力的重要指標(biāo)。QPS 和 TPS 越大，說明系統(tǒng)處理請求的能力越強(qiáng)。
RT 是衡量系統(tǒng)響應(yīng)速度的重要指標(biāo)。RT 越小，說明系統(tǒng)響應(yīng)速度越快。
并發(fā)數(shù) 是衡量系統(tǒng)負(fù)載能力的重要指標(biāo)。并發(fā)數(shù)越高，說明系統(tǒng)能夠同時(shí)處理的請求越多。
吞吐量 是衡量系統(tǒng)整體性能的重要指標(biāo)。吞吐量越高，說明系統(tǒng)的整體性能越好。
除了以上指標(biāo)之外，還可以根據(jù)具體的應(yīng)用場景來定義其他指標(biāo)。例如：
- 錯(cuò)誤率：請求失敗的比例，指的是請求失敗的比例。
- 資源利用率：CPU、內(nèi)存、網(wǎng)絡(luò)等資源的使用情況，指的是 CPU、內(nèi)存、網(wǎng)絡(luò)等資源的使用情況。
在實(shí)際應(yīng)用中，需要根據(jù)系統(tǒng)的具體情況來選擇合適的衡量指標(biāo)。
以下是一些使用高并發(fā)衡量指標(biāo)的建議：
設(shè)定合理的閾值：對于每個(gè)指標(biāo)，都需要設(shè)定合理的閾值。當(dāng)指標(biāo)超過閾值時(shí)，需要采取措施來解決問題。
定期監(jiān)控指標(biāo)：需要定期監(jiān)控指標(biāo)，以了解系統(tǒng)的運(yùn)行狀況。
分析指標(biāo)趨勢：需要分析指標(biāo)趨勢，以發(fā)現(xiàn)潛在的問題。
-
常見的高并發(fā)測試工具包括：
- JMeter：一款開源的 Java 應(yīng)用性能測試工具，可以用于模擬各種類型的負(fù)載，包括 HTTP、HTTPS、FTP、JDBC、SOAP 等。
- LoadRunner：一款商業(yè)的負(fù)載測試工具，可以用于測試各種類型的應(yīng)用程序，包括 Web 應(yīng)用程序、移動應(yīng)用程序、API 等。
- ApacheBench：一款開源的 HTTP 負(fù)載測試工具，可以用于測試 Web 服務(wù)器的性能。
- Gatling：一款開源的 Scala 負(fù)載測試工具，可以用于模擬大量用戶的并發(fā)請求。
- WebLOAD：一款商業(yè)的負(fù)載測試工具，可以用于測試 Web 應(yīng)用程序和 API。
通過使用高并發(fā)衡量指標(biāo)，可以幫助我們了解系統(tǒng)的性能，并找到改進(jìn)的方向。
2.3.2 高可用
高可用（High Availability，HA） 是指系統(tǒng)能夠在面對硬件、軟件或者其他異常情況時(shí)，仍然能夠保持穩(wěn)定運(yùn)行并提供服務(wù)的能力。在Java應(yīng)用程序中實(shí)現(xiàn)高可用性需要綜合考慮多個(gè)方面，包括架構(gòu)設(shè)計(jì)、技術(shù)選型、容錯(cuò)機(jī)制等。以下是高可用性的一些常見技術(shù)解決方案：
- 主備模式（Active-Passive）： 在主備模式中，系統(tǒng)中的主節(jié)點(diǎn)負(fù)責(zé)處理所有的請求，而備節(jié)點(diǎn)則處于待命狀態(tài)。當(dāng)主節(jié)點(diǎn)發(fā)生故障時(shí)，備節(jié)點(diǎn)會自動接管服務(wù)，成為新的主節(jié)點(diǎn)，從而實(shí)現(xiàn)故障切換和持續(xù)的服務(wù)可用性。
- 多活模式（Active-Active）： 在多活模式中，系統(tǒng)中的多個(gè)節(jié)點(diǎn)都處于活動狀態(tài)，并且都在處理請求。每個(gè)節(jié)點(diǎn)都具有相同的功能和數(shù)據(jù)，可以獨(dú)立地處理請求。當(dāng)一個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，流量會自動轉(zhuǎn)移到其他健康的節(jié)點(diǎn)上，從而實(shí)現(xiàn)故障切換和服務(wù)的持續(xù)性。
- 冗余備份模式（Redundancy）： 冗余備份模式通過在系統(tǒng)中添加冗余的組件或節(jié)點(diǎn)來實(shí)現(xiàn)高可用。當(dāng)一個(gè)組件或節(jié)點(diǎn)發(fā)生故障時(shí)，系統(tǒng)可以自動切換到備用組件或節(jié)點(diǎn)上，從而保障服務(wù)的持續(xù)性。
更多的考慮如下：
- 容器化和編排： 使用容器化技術(shù)（如Docker）將應(yīng)用程序打包成容器，并使用容器編排工具（如Kubernetes）來管理和調(diào)度容器實(shí)例，實(shí)現(xiàn)快速部署、自動伸縮和故障恢復(fù)。
- 數(shù)據(jù)庫主從復(fù)制： 使用數(shù)據(jù)庫主從復(fù)制技術(shù)來實(shí)現(xiàn)數(shù)據(jù)的備份和容災(zāi)，確保系統(tǒng)在主數(shù)據(jù)庫故障時(shí)能夠自動切換到備用數(shù)據(jù)庫，保證數(shù)據(jù)的可用性和一致性。
- 分布式存儲： 使用分布式存儲系統(tǒng)（如HDFS、GlusterFS等）來存儲數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)的備份和容災(zāi)，避免單點(diǎn)故障和數(shù)據(jù)丟失。
- 消息隊(duì)列： 使用消息隊(duì)列（如RabbitMQ、Kafka等）來實(shí)現(xiàn)異步消息傳遞和解耦，減少系統(tǒng)間的直接依賴關(guān)系，提高系統(tǒng)的穩(wěn)定性和可用性。
- 健康檢查和自動恢復(fù)： 實(shí)現(xiàn)健康檢查和自動恢復(fù)機(jī)制，定期檢測系統(tǒng)的健康狀態(tài)，當(dāng)發(fā)現(xiàn)異常時(shí)自動進(jìn)行故障轉(zhuǎn)移或恢復(fù)，減少人工干預(yù)和減輕系統(tǒng)負(fù)擔(dān)。
- 災(zāi)備和容災(zāi)： 配置災(zāi)備和容災(zāi)方案，將系統(tǒng)部署在不同的地理位置或數(shù)據(jù)中心，確保在災(zāi)難發(fā)生時(shí)能夠快速切換到備用系統(tǒng)，保障業(yè)務(wù)的持續(xù)運(yùn)行。
- 持續(xù)監(jiān)控和報(bào)警： 配置監(jiān)控系統(tǒng)來實(shí)時(shí)監(jiān)測系統(tǒng)的運(yùn)行狀態(tài)和性能指標(biāo)，當(dāng)發(fā)現(xiàn)異常時(shí)及時(shí)發(fā)出報(bào)警并采取相應(yīng)的應(yīng)對措施，避免問題擴(kuò)大化。
2.3.3 注冊中心
注冊中心概述
注冊中心 是微服務(wù)架構(gòu)中的一個(gè)核心組件，用于管理和維護(hù)微服務(wù)實(shí)例的信息，包括服務(wù)的名稱、地址、端口等信息。注冊中心充當(dāng)著服務(wù)發(fā)現(xiàn)和服務(wù)注冊的中心化管理者，使得微服務(wù)之間可以動態(tài)地發(fā)現(xiàn)和調(diào)用彼此，從而實(shí)現(xiàn)了微服務(wù)架構(gòu)的核心特性之一：服務(wù)治理。
注冊中心的主要功能包括：
- 服務(wù)注冊：服務(wù)提供者將自己的信息注冊到注冊中心
- 服務(wù)發(fā)現(xiàn)：服務(wù)消費(fèi)者從注冊中心獲取服務(wù)提供者的信息
- 健康檢查：注冊中心定期檢查服務(wù)提供者的健康狀況
- 負(fù)載均衡：注冊中心可以根據(jù)一定的策略為服務(wù)消費(fèi)者選擇服務(wù)提供者
那么帶著你的思考我們來看看以下的問答內(nèi)容：
什么是注冊中心？（easy）
注冊中心是微服務(wù)架構(gòu)中的一個(gè)核心組件，用于管理和維護(hù)微服務(wù)實(shí)例的信息，包括服務(wù)的名稱、地址、端口等信息。它充當(dāng)著服務(wù)發(fā)現(xiàn)和服務(wù)注冊的中心化管理者，使得微服務(wù)之間可以動態(tài)地發(fā)現(xiàn)和調(diào)用彼此。
注冊中心的作用是什么？（easy）
注冊中心的作用主要包括兩個(gè)方面：
- 服務(wù)注冊：微服務(wù)啟動時(shí)向注冊中心注冊自己的信息，包括服務(wù)名稱、地址、端口等。
- 服務(wù)發(fā)現(xiàn)：微服務(wù)在需要調(diào)用其他服務(wù)時(shí)，向注冊中心查詢目標(biāo)服務(wù)的信息，獲取到服務(wù)地址后再進(jìn)行調(diào)用。
常見的注冊中心有哪些？（easy）
常見的注冊中心包括：
- Netflix Eureka
- Apache ZooKeeper
- Consul
- etcd 等
注冊中心和負(fù)載均衡有什么關(guān)系？
注冊中心通常和負(fù)載均衡配合使用。注冊中心負(fù)責(zé)管理和維護(hù)微服務(wù)實(shí)例的信息，而負(fù)載均衡器則負(fù)責(zé)將請求分發(fā)到多個(gè)微服務(wù)實(shí)例上，以實(shí)現(xiàn)負(fù)載均衡和高可用性。
注冊中心的實(shí)現(xiàn)原理是什么？
注冊中心的實(shí)現(xiàn)原理通常涉及到網(wǎng)絡(luò)通信、數(shù)據(jù)存儲和服務(wù)發(fā)現(xiàn)等方面。具體來說，注冊中心通過接收微服務(wù)實(shí)例的注冊請求，并將注冊信息存儲在自身的存儲介質(zhì)中（如內(nèi)存、數(shù)據(jù)庫等）。當(dāng)其他微服務(wù)需要調(diào)用某個(gè)服務(wù)時(shí)，它們向注冊中心發(fā)送查詢請求，注冊中心根據(jù)查詢條件返回相應(yīng)的服務(wù)實(shí)例信息。
如何保證注冊中心的高可用性？
為了保證注冊中心的高可用性，可以采用以下策略：
- 集群部署：使用多個(gè)注冊中心實(shí)例組成集群，避免單點(diǎn)故障。
- 數(shù)據(jù)備份：定期對注冊中心的數(shù)據(jù)進(jìn)行備份，以防止數(shù)據(jù)丟失。
- 心跳檢測：注冊中心定期向微服務(wù)發(fā)送心跳檢測請求，以確保服務(wù)實(shí)例的可用性。
- 自動故障轉(zhuǎn)移：當(dāng)注冊中心的某個(gè)實(shí)例發(fā)生故障時(shí)，自動切換到其他可用的實(shí)例上。
2.3.4 負(fù)載均衡
[圖片上傳失敗...(image-b8c289-1709663256835)]
負(fù)載均衡（Load Balancing） 是一種將網(wǎng)絡(luò)請求分發(fā)到多個(gè)服務(wù)器或者服務(wù)器集群上的技術(shù)，以實(shí)現(xiàn)資源的合理利用、提高系統(tǒng)的性能和可用性。常見的負(fù)載均衡策略包括：
- 輪詢（Round Robin）： 輪詢是一種最簡單的負(fù)載均衡策略，將請求依次分配給每個(gè)服務(wù)器，按照順序循環(huán)進(jìn)行。當(dāng)有新的請求到達(dá)時(shí)，負(fù)載均衡器會將其分配給下一個(gè)服務(wù)器，直到所有的服務(wù)器都被輪詢過一遍，然后重新開始。輪詢策略適用于所有服務(wù)器的性能相近且負(fù)載相對均衡的情況。
- 加權(quán)輪詢（Weighted Round Robin）： 加權(quán)輪詢是對輪詢策略的一種擴(kuò)展，通過為每個(gè)服務(wù)器分配一個(gè)權(quán)重值來調(diào)節(jié)服務(wù)器的負(fù)載比例。權(quán)重值越高的服務(wù)器，被分配到請求的概率越大。加權(quán)輪詢策略可以根據(jù)服務(wù)器的性能和配置情況，靈活地調(diào)整負(fù)載均衡的效果。
- 最少連接（Least Connections）： 最少連接策略會將新的請求分配給當(dāng)前連接數(shù)最少的服務(wù)器，以實(shí)現(xiàn)請求的均衡分配。這種策略適用于服務(wù)器的性能差異較大或者每個(gè)連接的處理時(shí)間不同的情況下，可以有效地減少響應(yīng)時(shí)間和提高系統(tǒng)的吞吐量。
- IP哈希（IP Hash）： IP哈希策略根據(jù)客戶端的IP地址計(jì)算哈希值，并將哈希值映射到固定范圍內(nèi)的服務(wù)器上。這樣相同IP的請求會被分配到同一臺服務(wù)器上，可以確保同一用戶的請求都被發(fā)送到同一個(gè)服務(wù)器上，有利于保持會話的一致性。
- 最少響應(yīng)時(shí)間（Least Response Time）： 最少響應(yīng)時(shí)間策略會將新的請求分配給響應(yīng)時(shí)間最短的服務(wù)器，以減少用戶等待時(shí)間和提高用戶體驗(yàn)。這種策略通常需要負(fù)載均衡器實(shí)時(shí)監(jiān)測服務(wù)器的響應(yīng)時(shí)間，并動態(tài)調(diào)整請求的分發(fā)策略。
- 隨機(jī)（Random）負(fù)載均衡。在隨機(jī)策略中，負(fù)載均衡器會隨機(jī)選擇一個(gè)服務(wù)器來處理每個(gè)請求，而不考慮服務(wù)器的負(fù)載情況或其他因素。隨機(jī)策略簡單直接，適用于服務(wù)器之間的負(fù)載相對均衡或者請求的到達(dá)頻率較低的情況。然而，由于隨機(jī)分配無法保證每個(gè)服務(wù)器的負(fù)載均衡，因此在一些場景下可能會導(dǎo)致某些服務(wù)器負(fù)載過高，而其他服務(wù)器負(fù)載過低的情況。
以下是一些負(fù)載均衡策略的優(yōu)缺點(diǎn)：
輪詢
- 優(yōu)點(diǎn)：簡單易行，實(shí)現(xiàn)成本低。
- 缺點(diǎn)：不能根據(jù)服務(wù)器的負(fù)載情況進(jìn)行調(diào)整。
加權(quán)輪詢
- 優(yōu)點(diǎn)：可以根據(jù)服務(wù)器的性能和負(fù)載情況進(jìn)行調(diào)整，提高系統(tǒng)的負(fù)載均衡。
- 缺點(diǎn)：實(shí)現(xiàn)成本較高。
最少連接
- 優(yōu)點(diǎn)：可以將請求分發(fā)到負(fù)載最小的服務(wù)器上，提高系統(tǒng)的負(fù)載均衡。
- 缺點(diǎn)：可能會導(dǎo)致服務(wù)器連接數(shù)過多，影響服務(wù)器性能。
哈希
- 優(yōu)點(diǎn)：可以將請求分發(fā)到指定的服務(wù)器上，提高緩存命中率。
- 缺點(diǎn)：如果服務(wù)器發(fā)生故障，可能會導(dǎo)致請求集中到其他服務(wù)器上，影響系統(tǒng)性能。
最少響應(yīng)時(shí)間
- 優(yōu)點(diǎn)：可以提高系統(tǒng)的響應(yīng)速度，提升用戶體驗(yàn)?？梢詫⒄埱蠓职l(fā)到負(fù)載最小的服務(wù)器上，提高系統(tǒng)的負(fù)載均衡。
- 缺點(diǎn)： 可能會導(dǎo)致服務(wù)器負(fù)載不均衡，影響系統(tǒng)的穩(wěn)定性。對服務(wù)器的性能要求較高。
隨機(jī)
- 優(yōu)點(diǎn)：簡單易行，實(shí)現(xiàn)成本低。
- 缺點(diǎn)：不能保證每個(gè)服務(wù)器的負(fù)載均衡。
總結(jié)
負(fù)載均衡 是提高系統(tǒng)性能和可用性的重要技術(shù)。選擇合適的負(fù)載均衡策略可以根據(jù)系統(tǒng)的具體情況進(jìn)行。
2.3.5 服務(wù)雪崩
服務(wù)雪崩是指在分布式系統(tǒng)中，由于某個(gè)服務(wù)節(jié)點(diǎn)的故障或異常引發(fā)了連鎖反應(yīng)，導(dǎo)致系統(tǒng)中大量的服務(wù)節(jié)點(diǎn)都出現(xiàn)故障或異常，最終導(dǎo)致整個(gè)系統(tǒng)崩潰的現(xiàn)象。服務(wù)雪崩通常是由于系統(tǒng)中的多個(gè)服務(wù)之間存在依賴關(guān)系，當(dāng)某個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)故障時(shí)，會導(dǎo)致其依賴的其他服務(wù)節(jié)點(diǎn)也無法正常工作，進(jìn)而引發(fā)更多的故障，最終形成雪崩效應(yīng)。
以下是服務(wù)雪崩的一些常見原因和預(yù)防措施：
單點(diǎn)故障： 如果系統(tǒng)中存在單點(diǎn)故障，當(dāng)這個(gè)單點(diǎn)故障發(fā)生時(shí)，會導(dǎo)致該節(jié)點(diǎn)的所有依賴服務(wù)都不可用，進(jìn)而引發(fā)整個(gè)系統(tǒng)的雪崩效應(yīng)。預(yù)防措施包括通過集群和負(fù)載均衡來消除單點(diǎn)故障。
依賴服務(wù)的超時(shí)或阻塞： 如果某個(gè)服務(wù)依賴的其他服務(wù)出現(xiàn)了超時(shí)或者阻塞，會導(dǎo)致該服務(wù)的請求得不到及時(shí)響應(yīng)，從而引發(fā)整個(gè)系統(tǒng)的雪崩效應(yīng)。預(yù)防措施包括設(shè)置適當(dāng)?shù)某瑫r(shí)時(shí)間、實(shí)現(xiàn)服務(wù)的異步調(diào)用以及采用熔斷機(jī)制。
擴(kuò)容不及時(shí)： 如果系統(tǒng)在高負(fù)載時(shí)沒有及時(shí)擴(kuò)容，會導(dǎo)致服務(wù)節(jié)點(diǎn)過載，進(jìn)而引發(fā)雪崩效應(yīng)。預(yù)防措施包括實(shí)時(shí)監(jiān)控系統(tǒng)負(fù)載，并根據(jù)負(fù)載情況進(jìn)行動態(tài)擴(kuò)容。
數(shù)據(jù)庫連接池耗盡： 如果系統(tǒng)中的數(shù)據(jù)庫連接池被耗盡，會導(dǎo)致所有的數(shù)據(jù)庫請求都無法得到響應(yīng)，從而引發(fā)雪崩效應(yīng)。預(yù)防措施包括優(yōu)化數(shù)據(jù)庫查詢、合理配置連接池參數(shù)以及實(shí)現(xiàn)數(shù)據(jù)庫的讀寫分離。
緩存擊穿： 如果系統(tǒng)中的緩存服務(wù)發(fā)生擊穿，會導(dǎo)致大量的請求直接擊中數(shù)據(jù)庫，從而引發(fā)雪崩效應(yīng)。預(yù)防措施包括設(shè)置合理的緩存過期時(shí)間、使用互斥鎖避免同時(shí)加載數(shù)據(jù)以及實(shí)現(xiàn)熔斷機(jī)制。
6.服務(wù)雪崩是指在分布式系統(tǒng)中，由于某個(gè)服務(wù)節(jié)點(diǎn)的故障或異常引發(fā)了連鎖反應(yīng)，導(dǎo)致系統(tǒng)中大量的服務(wù)節(jié)點(diǎn)都出現(xiàn)故障或異常，最終導(dǎo)致整個(gè)系統(tǒng)崩潰的現(xiàn)象。服務(wù)雪崩通常是由于系統(tǒng)中的多個(gè)服務(wù)之間存在依賴關(guān)系，當(dāng)某個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)故障時(shí)，會導(dǎo)致其依賴的其他服務(wù)節(jié)點(diǎn)也無法正常工作，進(jìn)而引發(fā)更多的故障，最終形成雪崩效應(yīng)。
以下是服務(wù)雪崩的一些常見原因和預(yù)防措施：
單點(diǎn)故障： 如果系統(tǒng)中存在單點(diǎn)故障，當(dāng)這個(gè)單點(diǎn)故障發(fā)生時(shí)，會導(dǎo)致該節(jié)點(diǎn)的所有依賴服務(wù)都不可用，進(jìn)而引發(fā)整個(gè)系統(tǒng)的雪崩效應(yīng)。預(yù)防措施包括通過集群和負(fù)載均衡來消除單點(diǎn)故障。
依賴服務(wù)的超時(shí)或阻塞： 如果某個(gè)服務(wù)依賴的其他服務(wù)出現(xiàn)了超時(shí)或者阻塞，會導(dǎo)致該服務(wù)的請求得不到及時(shí)響應(yīng)，從而引發(fā)整個(gè)系統(tǒng)的雪崩效應(yīng)。預(yù)防措施包括設(shè)置適當(dāng)?shù)某瑫r(shí)時(shí)間、實(shí)現(xiàn)服務(wù)的異步調(diào)用以及采用熔斷機(jī)制。
擴(kuò)容不及時(shí)： 如果系統(tǒng)在高負(fù)載時(shí)沒有及時(shí)擴(kuò)容，會導(dǎo)致服務(wù)節(jié)點(diǎn)過載，進(jìn)而引發(fā)雪崩效應(yīng)。預(yù)防措施包括實(shí)時(shí)監(jiān)控系統(tǒng)負(fù)載，并根據(jù)負(fù)載情況進(jìn)行動態(tài)擴(kuò)容。
數(shù)據(jù)庫連接池耗盡： 如果系統(tǒng)中的數(shù)據(jù)庫連接池被耗盡，會導(dǎo)致所有的數(shù)據(jù)庫請求都無法得到響應(yīng)，從而引發(fā)雪崩效應(yīng)。預(yù)防措施包括優(yōu)化數(shù)據(jù)庫查詢、合理配置連接池參數(shù)以及實(shí)現(xiàn)數(shù)據(jù)庫的讀寫分離。
緩存擊穿： 如果系統(tǒng)中的緩存服務(wù)發(fā)生擊穿，會導(dǎo)致大量的請求直接擊中數(shù)據(jù)庫，從而引發(fā)雪崩效應(yīng)。預(yù)防措施包括設(shè)置合理的緩存過期時(shí)間、使用互斥鎖避免同時(shí)加載數(shù)據(jù)以及實(shí)現(xiàn)熔斷機(jī)制。
-
示例如圖 首先，由于
Service A的流量突然增加，可能由于某些原因如突然的用戶訪問量增加或者系統(tǒng)內(nèi)部其他因素引發(fā)了流量波動。Service A
雖然可以扛住請求，但是它的突發(fā)流量可能導(dǎo)致其他服務(wù)如Service B和Service C`無法承受，導(dǎo)致它們發(fā)生了阻塞或者線程資源耗盡的情況。當(dāng)
Service C不可用時(shí)，它可能會導(dǎo)致Service B的請求被阻塞，而Service B的線程資源被耗盡。最終，整個(gè)服務(wù)鏈路都因?yàn)榉?wù)雪崩而變得不可用，導(dǎo)致整個(gè)系統(tǒng)癱瘓。
措施
這種情況下，服務(wù)雪崩的發(fā)生是由于系統(tǒng)中的一個(gè)服務(wù)的故障或者異常引發(fā)了連鎖反應(yīng)，導(dǎo)致整個(gè)服務(wù)鏈路都崩潰。因此，對于構(gòu)建分布式系統(tǒng)來說，需要采取一系列的預(yù)防措施，包括優(yōu)化系統(tǒng)架構(gòu)、合理設(shè)計(jì)服務(wù)之間的依賴關(guān)系、實(shí)現(xiàn)服務(wù)的熔斷和降級機(jī)制等，以減少服務(wù)雪崩的風(fēng)險(xiǎn)。
[圖片上傳失敗...(image-321701-1709663256835)]
2.3.6 熔斷
熔斷（Circuit Breaker） 是一種用于構(gòu)建可靠的分布式系統(tǒng)的設(shè)計(jì)模式，主要用于防止因服務(wù)故障或延遲而導(dǎo)致整個(gè)系統(tǒng)的雪崩效應(yīng)。熔斷器類似于電路中的保險(xiǎn)絲，在系統(tǒng)中監(jiān)控對特定服務(wù)的請求，當(dāng)請求失敗率達(dá)到設(shè)定的閾值時(shí)，熔斷器會打開，停止對該服務(wù)的請求，而不是一直等待服務(wù)恢復(fù)正常。
以下是熔斷器的一些重要特性和工作原理：
- 狀態(tài)管理： 熔斷器有三種狀態(tài)：關(guān)閉（Closed）、半開（Half-Open）和打開（Open）。在正常情況下，熔斷器處于關(guān)閉狀態(tài)，允許請求通過。當(dāng)請求失敗率超過設(shè)定閾值時(shí)，熔斷器會轉(zhuǎn)換為打開狀態(tài)，拒絕所有請求。在打開狀態(tài)下，熔斷器會定期嘗試將一部分請求發(fā)送給目標(biāo)服務(wù)，以檢查服務(wù)是否已經(jīng)恢復(fù)正常，如果檢測到服務(wù)恢復(fù)，則將熔斷器轉(zhuǎn)換為半開狀態(tài)，允許部分請求通過，否則繼續(xù)保持打開狀態(tài)。
- 故障檢測： 熔斷器會監(jiān)控對目標(biāo)服務(wù)的請求，并根據(jù)請求的成功或失敗來計(jì)算失敗率。當(dāng)失敗率超過設(shè)定的閾值時(shí)，熔斷器會打開，停止向目標(biāo)服務(wù)發(fā)送請求。
- 熔斷器打開時(shí)的處理： 當(dāng)熔斷器打開時(shí)，系統(tǒng)可以執(zhí)行一些預(yù)設(shè)的操作，如返回默認(rèn)值、執(zhí)行降級邏輯或者返回錯(cuò)誤信息等。這樣可以避免系統(tǒng)因?yàn)榈却〉恼埱蠖鴮?dǎo)致的資源浪費(fèi)和響應(yīng)延遲。
- 熔斷器的自我恢復(fù)： 一旦熔斷器打開，它會定期嘗試將一部分請求發(fā)送給目標(biāo)服務(wù)，以檢查服務(wù)是否已經(jīng)恢復(fù)。如果檢測到服務(wù)恢復(fù)，熔斷器會轉(zhuǎn)換為半開狀態(tài)，允許一部分請求通過，否則繼續(xù)保持打開狀態(tài)。
- 示例：當(dāng)熔斷器打開時(shí)，系統(tǒng)可以返回一些預(yù)先定義的兜底數(shù)據(jù)，以確保用戶獲得某種反饋，而不是完全失去響應(yīng)。這些兜底數(shù)據(jù)通常是一些默認(rèn)值、靜態(tài)內(nèi)容或者先前緩存的數(shù)據(jù)，能夠幫助用戶繼續(xù)執(zhí)行某些操作，而不受服務(wù)不可用的影響。
[圖片上傳失敗...(image-8a4580-1709663256835)]
-
常用的熔斷技術(shù)：
- Hystrix： Hystrix 是 Netflix 開源的一款熔斷器框架，提供了線程隔離、超時(shí)控制、降級處理等功能。通過使用 Hystrix，可以在調(diào)用外部服務(wù)時(shí)設(shè)置超時(shí)時(shí)間和降級策略，并監(jiān)控服務(wù)的健康狀態(tài)，及時(shí)觸發(fā)熔斷操作。Hystrix 提供了豐富的配置選項(xiàng)和監(jiān)控功能，可以方便地集成到 Spring Cloud、Dropwizard 等常見的 Java 微服務(wù)框架中。（用的比較多）
- Resilience4j： Resilience4j 是另一個(gè)流行的 Java 容錯(cuò)庫，提供了熔斷、重試、限流等功能。與 Hystrix 不同，Resilience4j 更輕量級，易于使用，并且對函數(shù)式編程有良好的支持。Resilience4j 提供了類似于 Hystrix 的熔斷器模式，并且可以與 Spring Boot、Micronaut 等框架無縫集成。
- Sentinel： Sentinel 是阿里巴巴開源的一款流量控制和熔斷降級框架，提供了實(shí)時(shí)的流量監(jiān)控、規(guī)則配置和熔斷降級等功能。Sentinel 可以用于保護(hù)微服務(wù)架構(gòu)中的服務(wù)免受流量突發(fā)或異常的影響，具有較高的靈活性和性能。
- Akka： Akka 是一款基于 Actor 模型的并發(fā)編程框架，在分布式系統(tǒng)中也提供了熔斷和容錯(cuò)的支持。通過 Akka 的 Fault Tolerance（容錯(cuò)）機(jī)制，可以實(shí)現(xiàn)監(jiān)控和處理外部服務(wù)的故障，確保系統(tǒng)的穩(wěn)定性和可用性。
熔斷小結(jié)
通過引入熔斷器機(jī)制，系統(tǒng)可以在面臨服務(wù)故障或延遲時(shí)，及時(shí)停止對該服務(wù)的請求，避免了因等待失敗的請求而導(dǎo)致整個(gè)系統(tǒng)的雪崩效應(yīng)。這有助于提高系統(tǒng)的穩(wěn)定性和可靠性，保障用戶的體驗(yàn)和服務(wù)的持續(xù)可用性。
2.3.7限流
限流概述
限流是一種用于控制系統(tǒng)流量的策略，通過限制系統(tǒng)的請求量或者并發(fā)數(shù)，以保護(hù)系統(tǒng)免受過載的影響。限流操作通常在系統(tǒng)的邊界處（如網(wǎng)關(guān)、負(fù)載均衡器或者應(yīng)用程序內(nèi)部）進(jìn)行，可以保障系統(tǒng)安全，防止惡意攻擊。可以有效地保護(hù)系統(tǒng)免受突發(fā)流量的影響，提高系統(tǒng)的穩(wěn)定性和可用性。
以下是一些常見的限流操作和原因：
- 平滑流量： 限流操作可以平滑系統(tǒng)的流量，防止突發(fā)流量對系統(tǒng)造成沖擊。通過限制每個(gè)時(shí)間段內(nèi)的請求數(shù)或者并發(fā)數(shù)，可以有效地控制系統(tǒng)的負(fù)載，避免系統(tǒng)被瞬時(shí)高并發(fā)請求拖垮。
- 保護(hù)系統(tǒng)資源： 限流操作可以保護(hù)系統(tǒng)的資源不被耗盡。在高并發(fā)的情況下，如果系統(tǒng)沒有限制請求量或者并發(fā)數(shù)，可能會導(dǎo)致系統(tǒng)資源（如線程、內(nèi)存、數(shù)據(jù)庫連接等）被耗盡，進(jìn)而導(dǎo)致系統(tǒng)崩潰。
- 防止雪崩效應(yīng)： 限流操作可以防止由于某個(gè)服務(wù)故障或者延遲而導(dǎo)致的雪崩效應(yīng)。通過限制請求量或者并發(fā)數(shù)，可以減輕系統(tǒng)的負(fù)載，降低因單點(diǎn)故障而引發(fā)的連鎖反應(yīng)。
- 保護(hù)下游服務(wù)： 限流操作可以保護(hù)下游服務(wù)免受突發(fā)流量的影響。當(dāng)系統(tǒng)中的某個(gè)服務(wù)產(chǎn)生大量請求時(shí)，可能會對下游服務(wù)造成壓力，通過限制請求量或者并發(fā)數(shù)，可以有效地控制流量，避免對下游服務(wù)造成影響。
- 提高系統(tǒng)穩(wěn)定性： 通過限流操作，可以保證系統(tǒng)在各種負(fù)載情況下都能夠穩(wěn)定運(yùn)行，提高系統(tǒng)的可靠性和穩(wěn)定性，保障用戶的體驗(yàn)。
[限流器] | ↓ [請求] --> [限流判斷] --> [允許通過] --> [目標(biāo)服務(wù)] | | ↓ ↓ [拒絕請求] [等待/重試] ↑ | [DDoS攻擊]
在這個(gè)示意中：
請求首先經(jīng)過限流器，限流器會對請求進(jìn)行判斷。
如果請求被限流器判斷為允許通過，則直接發(fā)送到目標(biāo)服務(wù)。
如果請求被限流器判斷為拒絕，則拒絕請求，返回相應(yīng)的錯(cuò)誤或提示信息給客戶端。
在一些情況下，如果請求被限流器判斷為等待或者需要重試，則可能會等待一段時(shí)間后再次嘗試發(fā)送請求。
-
同時(shí)，如果系統(tǒng)受到惡意的DDoS攻擊，攻擊者可能會發(fā)送大量的無效請求，導(dǎo)致系統(tǒng)負(fù)載過高。在這種情況下，限流器可能會將這些惡意請求識別為拒絕，以保護(hù)系統(tǒng)免受攻擊。 擴(kuò)展內(nèi)容：識別惡意的DDoS攻擊通常需要使用一些特定的技術(shù)和策略，以下是一些常見的方法：
- 流量分析： 監(jiān)控系統(tǒng)的流量模式，如果檢測到突然出現(xiàn)大量的請求流量，而且這些請求流量來源具有相似的特征（如來源IP地址、請求路徑等），很可能是DDoS攻擊。通過分析流量的特征可以識別和過濾惡意請求。
- IP黑名單： 維護(hù)一個(gè)IP黑名單，將一些已知的惡意IP地址或者IP地址段添加到黑名單中，從而阻止這些IP地址的請求?？梢允褂梅阑饓Α⒎聪虼淼裙ぞ邅砼渲肐P黑名單，對來自黑名單中的IP地址的請求進(jìn)行攔截。
- 基于規(guī)則的過濾： 配置一些規(guī)則來過濾惡意請求，例如限制某個(gè)IP地址或者IP地址段的請求頻率、設(shè)置白名單和黑名單等。這些規(guī)則可以根據(jù)請求的特征、行為模式或者來源進(jìn)行定義。
- 行為分析： 對請求的行為進(jìn)行分析，如果檢測到某些請求具有異常的行為模式（如大量的重復(fù)請求、異常的請求路徑、異常的請求參數(shù)等），很可能是DDoS攻擊?？梢允褂眯袨榉治黾夹g(shù)來檢測和識別這些異常行為。
- 機(jī)器學(xué)習(xí)： 使用機(jī)器學(xué)習(xí)算法對請求進(jìn)行分析和分類，訓(xùn)練模型來識別惡意請求。通過監(jiān)督學(xué)習(xí)或者無監(jiān)督學(xué)習(xí)的方法，可以識別出與正常請求不同的惡意請求模式，并及時(shí)做出響應(yīng)。
綜合利用以上方法，可以有效地識別和應(yīng)對惡意的DDoS攻擊，保護(hù)系統(tǒng)免受攻擊的影響。通常，采用多種技術(shù)和策略相結(jié)合的方式，可以提高系統(tǒng)對DDoS攻擊的識別和應(yīng)對能力。
常用的限流技術(shù)：
- 令牌桶算法（Token Bucket）： 令牌桶算法是一種基于令牌的限流算法，它通過維護(hù)一個(gè)令牌桶來控制請求的流量。每當(dāng)有請求到達(dá)時(shí)，算法會檢查令牌桶中是否有足夠的令牌，如果有，則允許請求通過，并從令牌桶中消耗一個(gè)令牌；如果沒有，則拒絕請求或者將請求放入隊(duì)列等待。令牌桶算法可以靈活地調(diào)整令牌產(chǎn)生的速率和令牌桶的容量，從而實(shí)現(xiàn)不同程度的限流。
- 漏桶算法（Leaky Bucket）： 漏桶算法是一種基于漏桶的限流算法，它通過維護(hù)一個(gè)固定容量的漏桶來控制請求的流量。每當(dāng)有請求到達(dá)時(shí)，算法會向漏桶中加入一個(gè)請求，如果漏桶已滿，則拒絕請求；同時(shí)，漏桶以固定的速率漏水，每當(dāng)漏桶中有請求時(shí)，就會以固定的速率處理請求。漏桶算法可以平滑地限制請求的流量，防止突發(fā)流量對系統(tǒng)造成影響。
- 計(jì)數(shù)器算法（Counting）： 計(jì)數(shù)器算法是一種基于計(jì)數(shù)器的限流算法，它通過統(tǒng)計(jì)一定時(shí)間內(nèi)的請求數(shù)量來控制請求的流量。當(dāng)請求到達(dá)時(shí)，算法會將請求計(jì)數(shù)加一，同時(shí)檢查當(dāng)前計(jì)數(shù)是否超過設(shè)定的閾值，如果超過則拒絕請求。計(jì)數(shù)器算法可以簡單地控制請求的總量或者每個(gè)時(shí)間窗口內(nèi)的請求數(shù)量。
- 基于漏斗模型的限流： 基于漏斗模型的限流算法是一種將請求看作流水流入漏斗的模型，漏斗具有固定的容量和固定的漏水速率，當(dāng)請求流入漏斗時(shí)，如果漏斗未滿，則允許請求通過；否則拒絕請求?；诼┒纺Ｐ偷南蘖魉惴梢云交乜刂普埱蟮牧髁浚苊馔话l(fā)流量對系統(tǒng)的影響。
限流小結(jié)
總的來說，限流操作是一種有效的保護(hù)機(jī)制，能夠幫助系統(tǒng)應(yīng)對各種不可預(yù)測的情況，保證系統(tǒng)的穩(wěn)定性和可用性。在設(shè)計(jì)系統(tǒng)時(shí)，合理設(shè)置限流策略是非常重要的一環(huán)。
2.3.8API網(wǎng)關(guān)
[圖片上傳失敗...(image-9c4626-1709663256835)]
API網(wǎng)關(guān)概述
API網(wǎng)關(guān)是現(xiàn)代化微服務(wù)架構(gòu)中的核心組件之一，負(fù)責(zé)管理和控制所有進(jìn)出系統(tǒng)的API請求。其核心內(nèi)容包括以下幾個(gè)方面：
- API路由管理： API網(wǎng)關(guān)負(fù)責(zé)接收所有來自客戶端的API請求，并將其路由到相應(yīng)的后端服務(wù)或微服務(wù)。通過路由管理，API網(wǎng)關(guān)可以根據(jù)請求的路徑、方法、版本等信息，將請求轉(zhuǎn)發(fā)到正確的目標(biāo)服務(wù)。
- 請求轉(zhuǎn)發(fā)和負(fù)載均衡： API網(wǎng)關(guān)可以將接收到的API請求轉(zhuǎn)發(fā)到后端多個(gè)微服務(wù)實(shí)例，實(shí)現(xiàn)負(fù)載均衡和高可用性。通過請求轉(zhuǎn)發(fā)和負(fù)載均衡，API網(wǎng)關(guān)可以提高系統(tǒng)的性能和可靠性，并有效地處理大量的請求流量。
- 安全認(rèn)證和授權(quán)： API網(wǎng)關(guān)負(fù)責(zé)對所有進(jìn)入系統(tǒng)的API請求進(jìn)行安全認(rèn)證和授權(quán)，驗(yàn)證請求的身份和權(quán)限。通過集中管理安全策略和訪問控制，API網(wǎng)關(guān)可以保護(hù)系統(tǒng)免受惡意攻擊和非法訪問。
- API監(jiān)控和分析： API網(wǎng)關(guān)可以收集、監(jiān)控和分析所有進(jìn)出系統(tǒng)的API請求，包括請求的性能指標(biāo)、流量統(tǒng)計(jì)、錯(cuò)誤日志等信息。通過API監(jiān)控和分析，可以實(shí)時(shí)了解系統(tǒng)的運(yùn)行狀態(tài)和性能狀況，及時(shí)發(fā)現(xiàn)和解決問題。
- 請求轉(zhuǎn)換和消息轉(zhuǎn)換： API網(wǎng)關(guān)可以對請求和響應(yīng)進(jìn)行轉(zhuǎn)換和處理，包括參數(shù)校驗(yàn)、格式轉(zhuǎn)換、消息編解碼等操作。通過請求轉(zhuǎn)換和消息轉(zhuǎn)換，可以實(shí)現(xiàn)請求的標(biāo)準(zhǔn)化和規(guī)范化，提高系統(tǒng)的互操作性和靈活性。
- 緩存和數(shù)據(jù)緩存： API網(wǎng)關(guān)可以對請求和響應(yīng)進(jìn)行緩存，減少對后端服務(wù)的請求次數(shù)，提高系統(tǒng)的性能和響應(yīng)速度。通過緩存和數(shù)據(jù)緩存，可以有效地減輕后端服務(wù)的壓力，并提供更好的用戶體驗(yàn)。
綜上所述，API網(wǎng)關(guān)作為現(xiàn)代化微服務(wù)架構(gòu)的核心組件，承擔(dān)著路由管理、請求轉(zhuǎn)發(fā)、安全認(rèn)證、監(jiān)控分析等多種功能，是實(shí)現(xiàn)微服務(wù)架構(gòu)中服務(wù)治理和API管理的重要工具。
國內(nèi)常用的API gateway的技術(shù)：
-
Spring Cloud Gateway
- Spring Cloud Gateway 是基于Spring框架的API Gateway解決方案，提供了路由轉(zhuǎn)發(fā)、過濾器鏈、斷路器、限流等功能，適用于構(gòu)建微服務(wù)架構(gòu)中的API網(wǎng)關(guān)層。由于其深度整合Spring Boot和Spring Cloud生態(tài)，深受國內(nèi)開發(fā)者喜愛。
-
Apache APISIX
- Apache APISIX 是一個(gè)動態(tài)、實(shí)時(shí)、高性能的API網(wǎng)關(guān)，采用LuaJIT編寫，同時(shí)也提供了Java SDK支持。它具有熱更新、豐富的插件機(jī)制以及與眾多云原生基礎(chǔ)設(shè)施的良好集成能力，被越來越多的企業(yè)采納用于微服務(wù)場景下的API管理。
-
Netflix Zuul
- Netflix Zuul 在早期微服務(wù)流行時(shí)期被廣泛使用，盡管現(xiàn)在Netflix已經(jīng)停止維護(hù) Zuul 1.x，但Zuul 2.x（Zuul Proxy）仍在持續(xù)開發(fā)中，它是一個(gè)基于Java的API Gateway，適合構(gòu)建在Spring Cloud體系之外的微服務(wù)環(huán)境。
-
Kong
- Kong 是一個(gè)云原生、高速、可擴(kuò)展的開源API Gateway，支持包括Java在內(nèi)的多種語言的插件開發(fā)，雖然它本身不是用Java編寫的，但由于其易用性、靈活性和強(qiáng)大的插件市場，在國內(nèi)也有一定的應(yīng)用基礎(chǔ)。
-
Alibaba Dubbo Sentinel
- 阿里巴巴Dubbo項(xiàng)目中的Sentinel模塊也可以用來做API流量控制、熔斷降級等，雖然它并不是嚴(yán)格意義上的API Gateway，但在實(shí)際的微服務(wù)治理中，常與API Gateway配合使用，作為微服務(wù)防護(hù)的一部分。
-
Apache ShenYu (incubating)
- Apache ShenYu 是一個(gè)國產(chǎn)的開源API Gateway項(xiàng)目，目前處于孵化階段，由Java編寫，它提供了豐富的流量控制、熔斷降級、認(rèn)證授權(quán)等功能，并且兼容Spring Cloud生態(tài)。
以上技術(shù)在國內(nèi)都有一定數(shù)量的用戶群體，根據(jù)項(xiàng)目需求和技術(shù)棧的不同，開發(fā)者可以根據(jù)功能完備性、性能表現(xiàn)、社區(qū)活躍度等因素選擇合適的API Gateway解決方案。
網(wǎng)關(guān)小結(jié)
一句話概括：
API網(wǎng)關(guān)是一個(gè)位于系統(tǒng)邊緣的中間層，用于統(tǒng)一管理、保護(hù)和控制系統(tǒng)內(nèi)外的所有API請求和流量，通常我們會將安全，限流，緩存，日志，監(jiān)控，重試，熔斷等放到API網(wǎng)關(guān)來做
2.3.9服務(wù)跟蹤
[圖片上傳失敗...(image-337984-1709663256835)]
服務(wù)跟蹤概述
服務(wù)跟蹤是指在分布式系統(tǒng)中追蹤請求的路徑和執(zhí)行時(shí)間，以便識別性能瓶頸和解決問題。
服務(wù)跟蹤的主要功能包括：
- 追蹤請求路徑：記錄請求從客戶端到后端的完整路徑，包括所有中間服務(wù)和調(diào)用鏈。
- 收集性能指標(biāo)：收集每個(gè)服務(wù)的執(zhí)行時(shí)間、響應(yīng)時(shí)間、錯(cuò)誤率等性能指標(biāo)。
- 分析和診斷問題：通過分析性能指標(biāo)和調(diào)用鏈，可以識別性能瓶頸和解決問題。
服務(wù)跟蹤常用的技術(shù)包括：
- 分布式追蹤：使用分布式追蹤系統(tǒng)，例如 OpenTelemetry、Jaeger、Zipkin 等，可以追蹤請求在分布式系統(tǒng)中的完整路徑。
- 日志記錄：在每個(gè)服務(wù)中記錄請求的日志，可以幫助分析請求的執(zhí)行過程。
- 監(jiān)控：使用監(jiān)控系統(tǒng)，例如 Prometheus、Grafana 等，可以收集和分析服務(wù)的性能指標(biāo)。
服務(wù)跟蹤的主要優(yōu)點(diǎn)包括：
- 提高系統(tǒng)性能：通過識別性能瓶頸，可以優(yōu)化系統(tǒng)性能。
- 提高系統(tǒng)可靠性：通過分析請求的執(zhí)行過程，可以發(fā)現(xiàn)潛在的問題，提高系統(tǒng)可靠性。
- 簡化故障排除：通過服務(wù)跟蹤，可以快速定位問題的根源，簡化故障排除過程。
服務(wù)跟蹤小結(jié)： 服務(wù)跟蹤是追蹤分布式系統(tǒng)中請求路徑和執(zhí)行時(shí)間，可以幫助開發(fā)人員更好地管理和維護(hù)分布式系統(tǒng)。
2.3.10彈性云服務(wù)
[圖片上傳失敗...(image-7d2433-1709663256835)]
彈性云服務(wù)概述
彈性云服務(wù)是指一種按需付費(fèi)的云計(jì)算服務(wù)，用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減計(jì)算資源。彈性云服務(wù)具有以下特點(diǎn)：
- 彈性: 用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減計(jì)算資源，無需預(yù)先投資購買硬件設(shè)備。
- 可擴(kuò)展: 彈性云服務(wù)可以提供海量的計(jì)算資源，滿足不同規(guī)模的業(yè)務(wù)需求。
- 高可用: 彈性云服務(wù)提供高可用性保障，確保業(yè)務(wù)持續(xù)運(yùn)行。
- 低成本: 彈性云服務(wù)采用按需付費(fèi)模式，用戶只需為使用的資源付費(fèi)，可以節(jié)省成本。
彈性云服務(wù)主要包括以下幾種類型：
- 彈性計(jì)算服務(wù): 提供虛擬機(jī)、容器等計(jì)算資源，用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減計(jì)算資源。
- 彈性存儲服務(wù): 提供對象存儲、塊存儲等存儲資源，用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減存儲空間。
- 彈性網(wǎng)絡(luò)服務(wù): 提供虛擬私有云、負(fù)載均衡等網(wǎng)絡(luò)資源，用戶可以根據(jù)業(yè)務(wù)需求構(gòu)建安全可靠的網(wǎng)絡(luò)環(huán)境。
彈性云服務(wù)廣泛應(yīng)用于各種行業(yè)，例如互聯(lián)網(wǎng)、金融、制造、零售等。
彈性云服務(wù)的優(yōu)勢
彈性云服務(wù)具有以下優(yōu)勢：
- 降低成本: 用戶只需為使用的資源付費(fèi)，可以節(jié)省成本。
- 提高效率: 用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減資源，提高資源利用率。
- 簡化運(yùn)維: 彈性云服務(wù)提供自動化運(yùn)維工具，簡化運(yùn)維工作。
- 提高可靠性: 彈性云服務(wù)提供高可用性保障，確保業(yè)務(wù)持續(xù)運(yùn)行。
彈性云服務(wù)的應(yīng)用場景
彈性云服務(wù)廣泛應(yīng)用于各種行業(yè)，例如互聯(lián)網(wǎng)、金融、制造、零售等。
以下是一些彈性云服務(wù)的應(yīng)用場景：
- 網(wǎng)站應(yīng)用: 使用彈性云服務(wù)可以快速搭建網(wǎng)站，并根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減資源。
- 移動應(yīng)用: 使用彈性云服務(wù)可以快速開發(fā)和部署移動應(yīng)用，并根據(jù)用戶數(shù)量彈性擴(kuò)展或縮減資源。
- 大數(shù)據(jù)分析: 使用彈性云服務(wù)可以快速構(gòu)建大數(shù)據(jù)分析平臺，并根據(jù)數(shù)據(jù)量彈性擴(kuò)展或縮減資源。
- 人工智能: 使用彈性云服務(wù)可以快速開發(fā)和部署人工智能應(yīng)用，并根據(jù)模型訓(xùn)練需求彈性擴(kuò)展或縮減資源。
彈性云服務(wù)提供商
目前，全球主要的彈性云服務(wù)提供商包括亞馬遜云科技（AWS）、微軟 Azure 和阿里云。
- 亞馬遜云科技（AWS） ：AWS 是全球領(lǐng)先的彈性云服務(wù)提供商，提供豐富的計(jì)算、存儲、網(wǎng)絡(luò)、數(shù)據(jù)庫、分析、人工智能等服務(wù)。
- 微軟 Azure：Azure 是微軟提供的彈性云服務(wù)平臺，提供豐富的計(jì)算、存儲、網(wǎng)絡(luò)、數(shù)據(jù)庫、分析、人工智能等服務(wù)。
- 阿里云：阿里云是中國領(lǐng)先的彈性云服務(wù)提供商，提供豐富的計(jì)算、存儲、網(wǎng)絡(luò)、數(shù)據(jù)庫、分析、人工智能等服務(wù)。（國內(nèi)的云服務(wù)霸主）
彈性云服務(wù)小結(jié)：
一句話概括：彈性云服務(wù)是一種按需付費(fèi)的云計(jì)算服務(wù)，用戶可以根據(jù)業(yè)務(wù)需求彈性擴(kuò)展或縮減計(jì)算資源。彈性云服務(wù)具有降低成本、提高效率、簡化運(yùn)維、提高可靠性等優(yōu)勢，廣泛應(yīng)用于各種行業(yè)。
