當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

通讯网关 api网关_API网关正在经历身份危机

發布時間：2023/12/3 编程问答 49 豆豆

生活随笔收集整理的這篇文章主要介紹了通讯网关 api网关_API网关正在经历身份危机小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

通訊網關 api網關

這些年來，API網關正在經歷一些身份危機。

它們是否是集中的共享資源，從而促進了API對外部實體的公開和治理？
它們是集群入口哨兵，可以嚴格控制哪些用戶流量進入或離開集群嗎？
還是他們根據自己擁有的客戶端類型，使用某種API合并膠來更簡潔地表達API？
當然，房間里的大象和我經常聽到的一個問題：“服務網格會使API網關過時嗎？”

一些背景

隨著技術的發展日新月異，以及整個行業通過技術和架構模式進行快速洗牌，您會被認為是“所有這些都使我旋轉”。在本文中，我希望歸納出“ API網關”的不同身份，闡明組織中的哪些組可以使用API??網關（他們正在嘗試解決的問題），并重新關注第一原理。理想情況下，在本文結束時，您將更好地理解API基礎結構在不同層次上對不同團隊的作用，以及如何從各個層次中獲得最大價值。

在深入探討之前，讓我們先清楚一下術語“ API”。

我對API的定義：

一個明確定義的目的明確的接口，旨在通過網絡調用，該接口使軟件開發人員能夠以受控且舒適的方式對組織內的數據和功能進行編程訪問。

這些接口抽象了實現它們的技術基礎結構的細節。對于這些設計的網絡端點，我們希望獲得一定程度的文檔，使用指南，穩定性和向后兼容性。

相反，僅因為我們可以通過網絡與另一軟件進行通信，并不一定意味著遠程端點就是此定義的API。許多系統相互通信，但是通信更加隨意發生，并且在耦合和其他因素之間進行權衡取舍。

我們創建API來為業務的各個部分提供周到的抽象，以實現新的業務功能以及偶然的創新。

在談論API網關時，首先要列出的是API管理。

API管理

許多人從API管理的角度考慮API網關。這是公平的。但是，讓我們快速看一下此網關的功能。

借助API Management ，我們正在尋求解決“何時我們希望公開現有的API供其他人使用”的問題，我們如何跟蹤誰使用這些API，實施關于允許誰使用它們的策略，建立安全性流程以進行身份??驗證和授權許可使用并建立可在設計時使用的服務目錄，以促進API使用并為有效治理奠定基礎。

我們要解決“我們想與其他人共享，但要按我們的條件共享這些現有的，經過策劃的API”的問題。

API管理也做得很好，它允許用戶（潛在的API使用者）進行自助服務，簽署不同的API使用計劃（請考慮：給定時間范圍內，指定價格點上每個終結點的每個用戶的調用次數）。我們能夠執行這些類型的管理功能的基礎架構是我們的API流量經過的網關。至此，我們可以執行諸如身份驗證，速率限制，指標收集，其他策略執行等操作。等

利用API網關的API管理軟件示例：

Google Cloud Apigee
紅帽3Scale
Mulesoft
Kong

在此級別上，我們正在考慮API（如上定義）以及如何最好地管理和允許對其進行訪問。我們不是在考慮服務器，主機，端口，容器甚至服務（另一個定義不明確的詞，但請堅持我！）。

API管理（以及它們相應的網關）通常被實現為“平臺團隊”，“集成團隊”或其他API基礎架構團隊所擁有的受嚴格控制的共享基礎架構。

需要注意的一件事：我們要小心，不允許任何業務邏輯進入這一層。如前一段所述，API管理是共享的基礎結構，但是由于我們的API流量經過了它，因此它傾向于重新創建“全知全能”（認為是企業服務總線）治理門，必須所有人協調以更改我們的服務。從理論上講，這聽起來不錯。在實踐中，這最終可能成為組織瓶頸。有關更多信息，請參見這篇文章：具有ESB，API管理和Now…Service Mesh的應用程序網絡功能？

集群入口

為了構建和實現API，我們專注于代碼，數據，生產力框架等內容。但是，要想使這些事情中的任何一個產生價值，就必須對其進行測試，部署到生產中并進行監控。當我們開始部署到云原生平臺時，我們開始考慮部署，容器，服務，主機，端口等，并構建我們的應用程序以生活在這種環境中。我們可能正在設計工作流（CI）和管道（CD），以利用云平臺快速移動，進行更改，將其展示在客戶面前，等等。

在這種環境下，我們可能會構建和維護多個群集來承載我們的應用程序，并且需要某種方式來訪問這些群集中的應用程序和服務。以Kubernetes為例思考。我們可能使用Kubernetes Ingress控制器來允許訪問Kubernetes集群（集群中的其他所有內容都無法從外部訪問）。這樣，我們就可以通過定義明確的入口點（例如域/虛擬主機，端口，協議等），嚴格控制哪些流量可以進入（甚至離開）我們的集群。等

在此級別上，我們可能希望某種“入口網關”成為允許請求和消息進入群集的流量哨兵。在這個級別上，您的思考更多是“我的集群中有此服務，我需要集群外的人才能調用它”。這可能是服務（公開API），現有的整體組件，gRPC服務，緩存，消息隊列，數據庫等。有些人選擇將其稱為API網關，其中有些人實際上可能會做更多比流量的入口/出口要大，但是重點是在集群操作級別存在此級別的問題。隨著我們傾向于部署更多集群（相對于一個單一的，高度多租戶的集群），我們最終會有更多的入口點，并且需要這些入口點之間進行交互。

這些類型的入口實現的示例包括：

Envoy代理及其基礎上的項目包括：
- 數據線大使
代理
- 包括OpenShift的路由器
NGINX
特拉菲克

此級別的集群入口控制器由平臺團隊操作，但是，這部分基礎架構通常與更分散的自助服務工作流相關聯（正如您對云原生平臺所期望的那樣）。參見Weaveworks的好伙伴介紹的“ GitOps”工作流程

API網關模式

術語“ API網關”的另一種擴展是我在聽到該術語時通常會想到的擴展，它與API網關模式最相似。克里斯·理查德森（Chris Richardson）在第8章的“微服務模式”一書中很好地介紹了這種用法。我強烈建議您將此書用于此以及其他微服務模式教育。可以在他的microservices.io網站上的API Gatway Pattern上進行快速瀏覽。簡而言之，API-gateway模式是管理API，以使不同類別的消費者更好地使用。此策展涉及一個API間接級別。您可能會聽到另一個代表API網關模式的術語是“后端的后端”，其中“前端”可以是文字前端（UI），移動客戶端，IoT客戶端甚至其他服務/應用程序開發人員。

在API網關模式中，我們顯著簡化了一組API的調用，以針對特定的用戶，客戶端或使用者組為“應用程序”模擬內聚的API。回想一下，當我們使用微服務構建系統時，“應用程序”的概念就消失了。 API網關模式有助于恢復此概念。這里的關鍵是API網關，一旦實現，它將成為客戶端和應用程序的API，并負責與任何后端API和其他應用程序網絡端點（不滿足上述API定義的端點）進行通信。

與上一節中的Ingress控制器不同，此API網關更接近于開發人員對世界的看法，并且較少集中在暴露給集群外使用的端口或服務上。此“ API網關”也不同于我們管理現有API的API管理世界觀。該API網關將對后端的調用混搭在一起，這些調用可能會公開API，但也可能會與未描述為API的事物進行對話，例如對舊系統的RPC調用，協議與“ REST”的外觀不符，例如被黑通過HTTP，gRPC，SOAP，GraphQL，websocket和消息隊列的JSON。也可以調用這種類型的網關來進行消息級轉換，復雜的路由，網絡彈性/后備以及響應的聚合。

如果您熟悉REST API的Richardson Maturity模型，則將調用實現API網關模式的API網關，以集成比Level 1 – 3實現更多的Level 0請求（及其之間的所有內容）。

這些類型的網關實現仍需要解決速率限制，身份驗證/授權，斷路，度量收集，流量路由等問題。這些類型的網關可以在集群的邊緣用作集群入口控制器，也可以在集群內部用作應用程序網關。

此類API網關的示例包括：

Spring Cloud Gateway
格洛
Netflix Zuul
IBM-Strongloop回送/微網關

也可以使用更多通用的編程或集成語言/框架來構建此類網關，例如：

阿帕奇駱駝
Spring整合
Ballerina
Eclipse Vert.x
節點JS

由于這種類型的API網關與應用程序和服務的開發密切相關，我們希望開發人員能夠參與幫助指定API網關公開的API，了解所涉及的任何mashup邏輯以及需求快速測試和更改此API基礎結構的能力。我們還希望操作或SRE對API網關的安全性，彈性和可觀察性配置有一些意見。這種級別的基礎結構還必須適應不斷發展的按需自助服務開發人員工作流。再次查看GitOps模型以獲取更多信息。

啟用服務網格

在云基礎架構上運行服務體系結構的一部分包括難以在網絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中，我們使用了應用程序庫和希望的開發人員治理來實現此目的。但是，在大規模和跨多種環境的情況下，服務網格技術的出現提供了更好的解決方案。服務網格通過透明地實現，為平臺及其組成服務帶來以下功能

服務到服務（即東西向交通）的彈性
安全性包括最終用戶身份驗證，相互TLS，服務到服務RBAC / ABAC
黑匣子服務的可觀察性（專注于網絡通信），例如請求/秒，請求延遲，請求失敗，斷路事件，分布式跟蹤等
服務到服務速率限制，配額執行等

精明的讀者會認識到， API網關和服務網格在功能上似乎有所重疊。服務網格的目標是通過在L7透明地解決所有服務/應用程序的這些問題。換句話說，服務網格希望融合到服務中（實際上并沒有被編碼為服務的代碼）。另一方面，API網關位于服務網格上方并與應用程序一起使用（L8？）。服務網格為服務，主機，端口，協議等（東西方流量）之間的請求流帶來了價值。他們還可以提供基本的集群入口功能，以將某些此功能引入南北交通。但是，這不應與API網關可以帶來北/南通信量的功能（如在集群的北/南和應用程序或一組應用程序在北/南）中混淆。

Service Mesh和API網關在某些方面在功能上有重疊，但是是互補的，因為它們位于不同的級別并解決不同的問題。理想的解決方案是將每個組件（API管理，API網關，服務網格）插入并播放到您的解決方案中，并在需要時在組件之間建立良好的邊界（或在不需要時排除它們）。同樣重要的是找到適合分散式開發人員和運營工作流程的這些工具的實現。即使這些不同組件的術語和標識存在混淆，我們也應該依靠基本原理，并了解這些組件在我們的體系結構中帶來了價值，以及它們如何獨立存在和互補并存。

我們很樂意為您服務！

你們中的有些人可能知道我非常熱衷于幫助人們，尤其是在云，微服務，事件驅動的體系結構和服務網格領域。在我的公司Solo.io中，我們正在幫助組織消除混亂，并以適當的級別以及成功使用它們的步伐（如果需要，更重要的是，成功地）采用網關和服務網格之類的API技術。！）。我們正在建設的工具，如GLOO ，東張西望，并SuperGloo技術類似的頂部特使代理， GraphQL和Istio以幫助實現API網關和服務網格管理。請直接與我們聯系（ @soloio_inc ， http : //solo.io ）或與我聯系（ @christianposta ， blog ），以深入了解我們的愿景以及我們的技術如何為您的組織提供幫助。在接下來的系列博客中，我們將更深入地探討API網關模式，多個集群的困難，多服務網格的困難等等！敬請關注！

還相關閱讀：

http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/

翻譯自: https://www.javacodegeeks.com/2019/01/api-gateways-going-identity-crisis.html