使用微服務模式構建應用程式並將這些服務部署到Kubernetes上已成為當今執行雲原生應用程式的實際方法。在微服務架構中，單個應用程式被分解為多個微服務。每個微服務由一個小團隊擁有，該團隊有權並負責為特定的微服務做出正確的決策。

這種責任通常從使用者請求到達的系統邊緣開始，一直到服務的業務邏輯，再到相關的訊息傳遞和資料儲存架構。

什麼是邊緣入口和Kubernetes入口

終端使用者需要訪問微服務。內部微服務和終端使用者之間的邊界稱為edge邊緣。為了使終端使用者訪問內部應用程式，流量需要越過邊緣。在Kubernetes中，流量使用稱為Ingress的軟體穿越邊緣。

將API閘道器與在Kubernetes上執行的基於微服務的應用程式整合時，您必須考慮兩個主要挑戰：

• 如何擴充套件對100多種服務和相關API的管理；和
• 閘道器如何支援通常跨整個邊緣堆疊的廣泛的微服務體系結構，協議和配置。

API閘道器：微服務的聯絡點

API閘道器是如何管理、保護和呈現API的核心。它作為軟體元件（或一系列元件）部署在虛擬機器上或Kubernetes中，並充當系統的單個入口點。API閘道器的主要職責是使使用者能夠可靠，安全地訪問多個API，微服務和後端系統。

微服務和Kubernetes提供了實現靈活性。例如，一個團隊可以選擇在系統的邊緣（內部服務和終端使用者之間的邊界）公開基於容器的微服務，這種公開方式是作為一組基於HTTP的REST API。另一個團隊可能會選擇Protobufs和gRPC。具有實時流需求的團隊可以通過WebSocket API公開其微服務。Kubernetes內部署的任何API閘道器都必須支援所有這些協議。

每個團隊不僅可以自由做出這些選擇，而且對後果負責。這通常轉化為“您構建，執行”。儘管並非每個組織都完全贊同這種工作方式，但每個微服務團隊都需要能夠理解，診斷和配置處理每個服務以及每個使用者對應用程式的請求的各個方面。與應用程式和API相關的執行時要求的多樣性意味著，每個團隊都將使用邊緣堆疊中的所有層，例如，動態請求處理，WAF和任何快取實現。

微服務的開發範例（獨立，授權和負責的團隊）為使用API​​閘道器，Kubernetes入口和邊緣的微服務團隊帶來了新的挑戰。

在本文中，我們確定了邊緣的兩個重要挑戰：管理獨立的微服務以及訪問全面的邊緣堆疊。

挑戰1：擴充套件邊緣管理

隨著部署的微服務數量的增加，管理邊緣的挑戰也越來越多。

在微服務架構中，工程師將管理更多的服務和應用程式。每個團隊都需要能夠獨立管理他們的服務，以使釋出與其他團隊的計劃脫鉤。在邊緣公開應用程式的傳統方法通常是通過集中的操作或平臺團隊來完成的。但是，當組織擁有數百個微服務時，一個平臺運維團隊無法擴充套件以處理必要的變更量。

需要在邊緣修改配置的典型更改：

• 正在部署的服務的新版本。
• 修改端點，路由指令或關聯的後端服務。
• 身份驗證和授權服務的更改。
• 修改非功能性需求，例如速率限制，超時，重試模式和斷路。
• 使用者對新功能的測試，例如，為一小部分Beta測試使用者啟用功能。

採用基於微服務的體系結構將導致版本釋出數量顯著增加。這種增加只會加劇邊緣管理方面的挑戰，並增加集中式操作方法的壓力。

挑戰2：支援各種範圍的邊緣要求

微服務在邊緣引入了許多新問題，微服務架構實現了架構靈活性。應用程式開發人員利用這種靈活性來選擇最適合該服務特定要求的程式語言和體系結構。無論架構如何，邊緣都需要支援需要向使用者公開的廣泛功能。這擴充套件了API閘道器的傳統角色，並且與邊緣整合工具需求相關的一些挑戰包括：

• 熟練地路由各種協議的能力。常見協議包括HTTP / 1.1，HTTP / 2，WebSocket，gRPC，gRPC-Web和TCP。
• 提供任何特定服務所需的完整邊緣功能集合，範圍從流量管理到可觀察性再到身份驗證等等。
• 為應用程式開發人員在自助服務模型中公開這些功能。

鼓勵微服務團隊實施的多樣性使工程師可以選擇“適合工作的工具”。但是，基礎平臺的整合提供了許多好處。與其允許開發人員構建定製的實現以提供額外的協議支援或安全性處理，不如將其提供給邊緣具有預先批准的“ buffet”選項的可管理性和可擴充套件性，以便他們可以選擇最合適的選項。功能組合。

總結

隨著組織採用Kubernetes並轉向基於微服務的體系結構，終端使用者與內部微服務之間的邊界出現了一系列新的挑戰。因此，系統的“邊緣”以及相關技術（例如API閘道器）是採用微服務時的重點。微服務的組織模型驅動著邊緣的這些新挑戰，在這種模型中，獨立團隊有權並負責為微服務制定正確的體系結構和實施決策。

管理系統邊緣一直很複雜。新增具有多種體系結構的更多服務只會增加對邊緣的需求。平臺團隊必須相應地設計，選擇和實現其API閘道器和邊緣管理工具。