在微服務架構中，API 閘道和服務登記扮演著至關重要的角色。API 閘道作為單一入口點簡化了客戶端與微服務之間的互動，同時也提供了負載平衡、身份驗證等功能。服務登記則負責儲存微服務的位置資訊，讓 API 閘道能有效率地找到並呼叫所需的微服務。這兩個元件共同作用，確保了微服務架構的彈性、可擴充套件性和可靠性。然而，API 閘道也可能成為單點故障，因此需要仔細設計和維護。服務登記也需要搭配可靠的工具，例如 Consul 和 SkyDNS，以確保微服務的自動發現和健康檢查。這些工具可以幫助維護微服務叢集的健康狀態，並提供高用性。在實際應用中，需要根據具體情況選擇合適的工具和策略。
API 閘道與服務登記：微服務架構的核心元素
在微服務架構中，客戶端通常需要與多個微服務進行互動，這可能會導致複雜性增加及靈活性降低。若是以硬編碼（hardcoded）方式處理這些互動，我們將失去調整的靈活性，例如在需要時將一個微服務進一步細分為多個微服務。此外，客戶端必須知曉所有需要呼叫的微服務位置。因此，我們需要一個系統來作為總入口點，處理客戶端及外部呼叫，並另一個系統來儲存微服務的最新位置。
API 閘道的角色與功能
API 閘道解決了上述問題，並作為所有呼叫的入口點。它負責接收客戶端請求、呼叫所需的微服務並將聚合結果回傳給客戶端。使用 API 閘道後，客戶端只需進行一次呼叫即可完成服務呼叫。這種模型提供了多項優勢：
- 隱藏應用內部複雜性：簡化了客戶端程式碼
- 提供更多靈活性：可以根據需求變更、合併、細分、新增或移除微服務
- 減少客戶端與應用之間的往返次數，提升效率
此外，API 閘道還可以作為負載平衡、身份驗證、監控和管理的點。它可以提供不同的 API 給不同的客戶端（如網頁和行動裝置），並可對請求進行優先處理。
然而，API 閘道也有其缺點。它可能成為單一故障點和瓶頸，無論是在效能還是開發方面都可能會遇到問題。因此，需要確保 API 閘道的設計和維護過程高效且輕量化，例如在修改、新增或刪除微服務時能夠即時更新。從操作效能來看，彈性負載平衡器可以確保滿足效能和可用性指標。
服務登記的必要性
在擁有數千個微服務的情況下，API 閘道也需要知曉所有服務的位置（如 IP 地址），以便能夠正確執行任務。服務登記提供了一個所有微服務及其位置的資料函式庫，可以在需要時進行查詢。
當一個微服務啟動時，它會自動註冊到這個服務登記中。當客戶端發出請求時，API 閘道會查詢所需微服務的位置並進行呼叫，最後將結果聚合並回傳給客戶端。
然而，實際情況往往比這更複雜。例如，如果我們丟失了登記資料呢？解決這個問題有多種開源工具可以使用。例如 Consul 和 SkyDNS 這類別工具可以自動發現微服務並確保它們正常運作。Consul 是一個成熟的發現工具，可以使用自定義 DNS 名稱來存取微服務並將資訊儲存在登記中。它還可以進行持續健康檢查並保持叢集健康。
資料流程圖示
資料流程圖示：
graph TD;
C[C]
D[D]
A[Client Service] --> B[API Gateway];
B --> C{Account Service};
B --> D{Checkout Service};
subgraph Account Service
C1[μS a] --> C2[μS b];
C1 --> C3[μS d];
C1 --> C4[μS e];
C1 --> C5[μS f];
C1 --> C6[μS x];
C1 --> C7[μS y];
end
subgraph Checkout Service
D1[μS a] --> D2[μS b];
D1 --> D3[μS c];
D1 --> D4[μS l];
D1 --> D5[μS m];
D1 --> D6[μS x];
D1 --> D7[μS y];
end
次段落標題：此圖示說明：
此圖示展示了基本的微服務架構模型中的資料流程。其中 Client Service（客戶端）直接與 Account Service（帳戶服務）和 Checkout Service（結帳服務）進行互動。Account Service 和 Checkout Service 分別包含多個微服務（µS），每個微服務之間有明確的依賴關係。
新增 API 閘道
接下來我們新增一個 API 閘道來封裝所有應用程式的業務邏輯，隱藏其複雜性對於 Client Service 的影響。
資料流程圖示：
graph TD;
A[Client Service] --> B[API Gateway];
B -->|Account Request| C{Account Service};
B -->|Checkout Request| D{Checkout Service};
subgraph Account Service
C1[µS a] --> C2[µS b];
C1 --> C3[µS d];
C1 --> C4[µS e];
C1 --> C5[µS f];
C1 --> C6[µS x];
C1 --> C7[µS y];
end
subgraph Checkout Service
D1[µS a] --> D2[µS b];
D1 --> D3[µS c];
D1 --> D4[µS l];
D1 --> D5[µS m];
D1 --> D6[µS x];
D1 --> D7[µS y];
end
次段落標題：此圖示說明：
此圖示展示了在基本模型上增加了 API 閘道後的資料流程。現在 Client Service 不再直接呼叫每個微服務；相反地，它透過 API 閘道來進行所有請求。
新增服務登記
接下來我們引入一個服務登記系統，使得 API 閘道能夠查詢每個微服務的位置。
資料流程圖示：
graph TD;
B[B]
Call[Call]
E[E]
F[F]
Location[Location]
Microservices[Microservices]
Query[Query]
Response[Response]
Return[Return]
Send[Send]
A[Client Service] --> B{API Gateway};
B -- Query Location--> E{Registry Service};
E -- Return Location--> B;
B -- Call Microservices--> F{Microservices};
F -- Return Response--> B;
B -- Send Response--> A;
subgraph Microservices
direction TB
F0["Register Location: μSa, μSb..."]
F0 ---> G["IP Address: μSa"]
F0 ---> H["IP Address: μSb"]
end
次段落標題：此圖示說明：
此圖示展示了在基本模型上增加了 Registry Service（註冊登記系統）後的資料流程。當 Client Service 呼叫 API Gateway 時, API Gateway 查詢 Registry Service 取得所需 Microservice 的位置, 呼叫 Microservice, 聚合結果後傳回給 Client service.
模型擴充套件與負載平衡
最後我們再進一步擴充套件模型，增加彈性負載平衡器以提升各級別的擴充套件能力。
資料流程圖示：
graph TD;
-[-]
RS-B[RS-B]
RS-D[RS-D]
A[Client Service] ---> |HTTP Request| ELB-API-Gateway["Elastic Load Balancer"];
subgraph Elastic Load Balancer for APIs {
direction TB;
ELB-API-Gateway ---> |Call Microservices| ELB-MicroServices-A["Elastic Load Balancer"];
subgraph Elastic Load Balancer for Microservices {
direction TB;
ELB-MicroServices-A ---> |Microservice A| MS-A["Microservice A"];
ELB-MicroServices-A ---> |Microservice B| MS-B["Microservice B"];
}
ELB-MicroServices-B["Elastic Load Balancer"] ---> |Microservice Z| MS-Z["Microservice Z"];
subgraph Elastic Load Balancer for Registry Services {
direction TB;
ELB-MicroServices-C["Elastic Load Balancer"] ---> |Query Location| RS-A["Registry Services"];
}
RS-A ---> |Return Location| ELB-MicroServices-C;
RS-B ---> |Return Location| ELB-MicroServices-D["Elastic Load Balancer"];
RS-D ---> |Return Location| ELB-MicroServices-E["Elastic Load Balancer"];
ELB-API-Gateway ---> |Send Response| A;
subgraph Registry Services {
direction TB;
RS-A ["IP Address μSa"];
RS-B ["IP Address μSb"];
RS-C ["IP Address μSz"];
RS-D ["IP Address μSz"];
}}
次段落標題：此圖示說明：
此圖示展示了在基本模型上增加了多層次彈性負載平衡器後資料流程：包括 API Gateway 、各 Microservices 、以及 Registry Services 的負載平衡機制。
轉移與實施微服務
在這一章中，玄貓將探討如何從傳統單體架構轉移到微服務架構，並詳細解說實施微服務的步驟。假設你已經瞭解什麼是微服務以及它們如何運作，並且對這些技術感興趣，那麼現在是時候深入瞭解如何實施微服務了。
轉移的需求
單體應用通常是大型且複雜的，擁有數十萬行程式碼、多種功能依賴、龐大的資料函式庫，並且需要數十位開發者和 IT 工程師來維護。這些應用通常會服務於數十萬使用者，並且分佈在不同的地理區域。儘管如此，單體應用在初期可能會執行得相當順利，但在時間和使用量增加後，問題便會逐漸浮現。例如，雲端或網頁應用可能會因為更多使用者消費服務而遇到擴充套件性問題，或者因為更長的建置時間和迴歸測試而變得昂貴且難以發布新更新。
這時候，轉移到微服務架構就不僅僅是一個流行的想法，而是一個必須考慮的解決方案。正如前面所提到的，微服務可以幫助應用更好地擴充套件、提高效能、降低維護成本、提高開發和佈署速度，並且提供更多技術自由度。
建立新的微服務應用
要實施微服務架構有兩種主要情況：建立全新的應用或轉換現有的單體應用。後者較為常見，但瞭解兩者都很重要。
新建全新應用
現實中，從零開始構建根據微服務架構的應用並不常見。通常情況下，應用已經存在，開發者和架構師希望將其轉換為微服務架構。然而，隨著市場上技能的普及和成功案例的發表，我們會看到更多從零開始建立微服務應用的例子。
假設你已經有了所有需求並準備好進行應用設計。以下是一些需要考慮的常見最佳實踐：
組織準備
首先要問的是你的組織是否準備好轉移到微服務架構。這意味著各部門需要改變他們對於軟體開發和發布的思維方式：
- 團隊結構：單體應用團隊（如果存在）需要拆分為多個小型高效團隊，這些團隊需要熟悉或接受微服務最佳實踐的培訓。每個團隊負責獨立的服務，每個服務提供特定功能。這是微服務架構的一個關鍵優勢——減少溝通開銷。
- 敏捷性：每個團隊必須能夠獨立運作。團隊規模應該控制在標準敏捷團隊範圍內，以避免溝通問題。
- 工具與培訓：組織需要準備投資新工具和人員培訓。現有工具和流程可能需要淘汰並引入新工具。這需要大量資本投資以及徵才具備新技能的人員並重訓現有員工。
根據服務的方法
與單體應用不同，微服務需要採取自主化的根據服務的方法。將你的應用視為一組鬆耦合的服務，這些服務之間透過通訊來提供完整的應用功能。每個服務都應該被視為獨立、自包含、具有自己的生命週期的一項獨立服務。
此圖示
graph LR A[Func 1] --> B[Service 1] A --> C[Service 2] A --> D[Service n] B --> E[Database] C --> E D --> E
內容解密：
此圖示展示了從單體架構轉移到微服務架構後的結構變化。
- Func 1：原單體應用中的某個功能模組。
- Service 1, Service 2, Service n：代表各自獨立運作且可互相通訊的微服務。
- Database：所有微服務分享的一個資料函式庫。
轉換現有單體應用
對於已有單體應用來說，轉換到微服務架構是一個逐步推進的過程。首先需要進行詳細評估和計劃：
評估與計劃
- 評估現有系統：分析現有系統中的各個模組和它們之間的依賴關係。
- 制定轉換策略：確定哪些部分可以優先轉換為獨立微服務。
- 逐步轉換：從簡單模組開始逐步進行轉換，確保每個階段都能正常執行。
技術選型
在轉換過程中，技術選型也是非常關鍵的一步：
- 選擇適合的語言和框架：根據各個模組的需求選擇適合的程式語言和框架。
- 資料管理：確保資料一致性和完整性。
成功案例分析
玄貓來看看一些成功轉換到微服務架構的案例：
Amazon
Amazon 是早期採納微服務架構的一家公司。他們將大型單體應用拆分為多個獨立執行、松耦合、可獨立開發和佈署的小型應用來實作業務需求。這使得Amazon能夠更快地回應市場變化並提高系統可靠性。
Netflix
Netflix 是另一家成功轉向微服務架構的一家公司。他們將單體應用拆分為數百個獨立執行、松耦合、可獨立開發和佈署的小型應用來實作業務需求。這使得Netflix能夠更快地回應市場變化並提高系統可靠性。
