文章中有對你有幫助的記得在評論中回複喲
希望得到你的回報
團隊考慮采用微服務的最大原因之一是其快速擴充能力。微服務被設計、開發和部署為獨立的服務，是以開發人員可以快速、輕松地擴充應用程式的部分功能。
要實作這一目标，隻需執行以下兩個步驟：
- 啟動一個新的服務執行個體（也稱為水準擴充）。
- 引入負載均衡器，将負載配置設定到兩個服務執行個體之間。
這種方法對于無狀态的微服務非常有效。但是，對于有狀态的微服務來說，擴充并不像這麼簡單。
了解無狀态和有狀态微服務
在我們深入讨論擴充的概念之前，讓我們先明确無狀态微服務和有狀态微服務之間的差別。
無狀态微服務
無狀态微服務不維護任何狀态，也不在請求之間存儲會話特定的資料。每個請求被無狀态微服務獨立處理，不依賴于之前的互動。
它們基于"共享無關"的概念運作。這使得它們可以在多個執行個體之間進行水準擴充，而不會影響其功能。
有狀态微服務
有狀态微服務在多個請求之間維護和管理會話特定的狀态。它們存儲資料并維護上下文，使得它們能夠在互動之間跟蹤和記憶資訊。
如何擴充無狀态微服務？
與有狀态微服務不同，擴充無狀态微服務是比較直接的。有幾種推薦的架構模式可用于擴充無狀态微服務。
- 水準擴充
水準擴充是擴充無狀态微服務最常見的方法之一，也稱為"橫向擴充"。水準擴充涉及添加更多的微服務節點（或執行個體），進而增加服務的整體處理能力。
例如，考慮下面的圖示：
例如，假設您正在使用AWS Lambda建構一個微服務。在這種情況下，微服務将進行水準擴充，并根據使用者負載建立新的微服務執行個體（函數）來處理傳入的使用者請求。
重要的是要了解在無伺服器環境中，水準擴充是自動完成的。像AWS Lambda這樣的服務會自動進行水準擴充，并建立新的函數執行個體，以確定滿足負載需求。
然而，如果您正在通過虛拟機或使用Docker/Kubernetes容器進行伺服器部署，您必須配置一個擴充政策，該政策将根據給定的門檻值來啟動新的微服務執行個體。同時，不要忘記在負載減輕時進行縮減，否則您的财務主管可能對此不滿意。
- 負載均衡
有時，僅僅啟動新的微服務執行個體是不夠的。您的應用程式傳入請求必須根據每個服務所承受的負載智能地路由到每個微服務執行個體。這就是負載均衡器發揮作用的地方。
負載均衡器将傳入的請求分發到多個微服務執行個體上。它確定負載在每個微服務執行個體之間均勻分布，以確定沒有執行個體過載，進而提高服務的可用性。負載均衡器還可以檢測無響應的節點，并停止向這些節點發送新的請求。
AWS提供的應用負載均衡器是其中的一個常見應用場景。
如上所示，兩個微服務執行個體（執行個體A和B）通過應用負載均衡器（ALB）有一個入口點供使用者進行互動。ALB會根據每個執行個體的負載情況将請求路由到執行個體A或B。
由于是無狀态的，将請求路由到兩個微服務執行個體變得非常簡單，因為每個執行個體可以在不考慮任何先前狀态的情況下處理任何請求。
- 自動擴充
自動擴充在擴充無狀态微服務方面起着重要作用。例如，考慮每天根據不同的工作負載來擴充一個服務。有些天，系統可能處理百萬使用者，但在極少數情況下，可能會處理高達一千萬使用者。在這個級别手動擴充您的微服務和資料庫幾乎是不可能的。而這正是自動擴充發揮作用的地方。
通過自動擴充，您可以配置基礎設施，根據預定義的名額（如CPU使用率、記憶體使用率或網絡流量）自動添加或删除執行個體。這使得您的微服務可以動态适應需求的變化，確定性能和成本效率的最優表現。
這不僅适用于執行個體，也适用于資料庫。衆所周知，建議每個微服務使用一個單獨的資料庫，以確定您可以根據需求随時擴充資料庫的某個部分。
舉個例子，想象一種情況，您需要為您的微服務擴充資料庫。由于您的服務具有不可預測的工作負載，您可以設定一個自動擴充政策，自動增加和減少資料庫吞吐量，以滿足需求。
此外，您還可以将自動擴充政策應用于Kubernetes叢集或VM叢集，根據負載自動啟動或删除微服務的執行個體。
- 緩存
将頻繁通路的資料存儲在具有快速資料通路速度的記憶體資料庫中，是擴充微服務以提高性能的一個很好的方法。例如，考慮以下圖示：
上面的圖示展示了一個簡單的微服務從圖像轉文本轉換器中擷取資料。
值得注意的是，“圖像轉文本轉換器”是一個高度資源密集型的資源，在将單個圖像轉換為文本時需要很長時間。
是以，一旦圖像被轉換為文本，其引用以及文本必須被存儲在緩存中，以便快速通路。然後，當使用者請求相同圖像的文本表示時，可以從緩存中傳回，進而避免長時間的等待，確定在您的無狀态微服務上實作更好的可擴充性。
請注意，您可以與多個擴充的微服務執行個體共享緩存，但是您需要注意資料完整性和沖突寫入，并且建議在這種情況下使用分布式讀寫鎖。
如何擴充有狀态的服務？
擴充有狀态的微服務并不像擴充無狀态的微服務那樣簡單。除了擴充服務之外，您還必須考慮在擴充過程中維護資料的一緻性。這就是問題的難點所在。
不過，以下是一些推薦的架構模式，可以幫助您更好地擴充有狀态的微服務。
- 垂直擴充
垂直擴充有時被稱為“向上擴充”。垂直擴充是更新單個微服務執行個體的配置，以改善其性能。通過采用垂直擴充方法，您確定不會建立新的服務執行個體，進而確定您的資料在單個有狀态服務内保持一緻性。
如上所示，當您進行垂直擴充時，實際上是增加了現有執行個體的容量。例如，如果您最初建立執行個體時記憶體為16GB，可以通過增加其記憶體到64GB 來改善性能。
然而，重要的是要了解垂直擴充也有其限制。例如，大多數伺服器運作的内部硬體都有其擴充限制。有時，系統可能隻支援32GB的記憶體。這意味着無論如何，您都無法将記憶體提升到超過32GB。
在這種情況下，建議建立一個具有更好配置（作為基本設定）的新執行個體，并停用低配置的服務。
- 有狀态服務發現與負載均衡
對于有狀态的微服務，建議使用支援它們的服務發現工具。這樣做可以實作為有狀态應用程式設計的負載均衡器，它可以智能地将請求路由到特定的執行個體，并考慮會話關聯。
這確定屬于特定會話的請求始終被路由到同一個服務執行個體，進而可以在不考慮資料同步的情況下擴充有狀态的微服務。
- 資料複制（Data Replication）
資料複制在擴充有狀态的微服務中起着至關重要的作用。這種技術確定在服務執行個體故障或災難發生時，資料具有高可用性、持久性和可恢複性。
負責資料複制的開發團隊可以采用主動-主動（Active-Active）或主動-被動（Active-Passive）政策，并使用不同類型的主資料庫和副本資料庫政策。通過這樣做，可以實作有狀态的微服務：
提高讀取擴充性：資料複制允許您建立多個主資料庫的副本。通過在這些副本之間配置設定讀取操作，您可以顯著提高讀取擴充性和速度，使每個副本可以獨立處理讀取請求。然而，值得注意的是，這種性能改進是以一緻性的犧牲為代價的，因為這是一種最終一緻性的方法，而不是強一緻性的方法。 提高可用性：在多個執行個體之間複制資料可以提高資料的備援性。如果一個節點因故障而不可用，其他副本可以繼續提供讀取操作，并通過自動故障切換維護系統的可用性。
對有狀态微服務進行擴充是一項具有挑戰性的任務，需要深思熟慮的方法和對資料一緻性權衡的了解。盡管無狀态微服務可以通過水準擴充和負載均衡相對輕松地進行擴充，但有狀态微服務需要更仔細的規劃和考慮，以實作高效和可靠的擴充性。