微服務api網關

重點 (Top highlight)

According to the definition by Gartner: “Microservice is a tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable application component.”

根據Gartner的定義： “微服務是范圍狹窄，封裝緊密，松散耦合，可獨立部署且可獨立擴展的應用程序組件 。”

The goal of the microservices is to sufficiently decompose/decouple the application into loosely coupled microservices/modules in contrast to monolithic applications where modules are highly coupled and deployed as a single big chunk. This will be helpful due to the following reasons:

與將模塊高度耦合并部署為單個大塊的單片應用程序相比，微服務的目標是將應用程序充分分解/解耦為松散耦合的微服務/模塊。 由于以下原因，這將有所幫助：

• Each microservice can be deployed, upgraded, scaled, maintained, and restarted independent of sibling services in the application.
  每個微服務都可以獨立于應用程序中的同級服務進行部署，升級，擴展，維護和重新啟動。
• Agile development & agile deployment with an autonomous cross-functional team.
  通過自治的跨職能團隊進行敏捷開發和敏捷部署。
• Flexibility in using technologies and scalability.
  使用技術的靈活性和可擴展性。

Different loosely coupled services are deployed based upon their own specific needs where each service has its fine-grained APIs model to serve different clients (Web, Mobile, and 3rd party APIs).

根據各自的特定需求部署不同的松耦合服務，其中每個服務都有其細粒度的API模型以服務于不同的客戶端(Web，移動和第三方API)。

客戶端到微服務的連接 (Client to Microservices connections)

Fig. Communication in Microservices圖：微服務中的通信

While thinking of the client directly communicating with each of the deployed microservices, the following challenges should be taken into consideration:

在考慮客戶端與每個已部署的微服務直接通信時，應考慮以下挑戰：

In the case where microservice is exposing fine-grained APIs to the client, the client should request to each microservice. In a typical single page, it may be required for multiple server round trips in order to fulfill the request. This may be even worse for low network operating devices such as mobile.

如果微服務向客戶端公開了細粒度的API，則客戶端應向每個微服務請求。 在典型的單頁中，可能需要進行多次服務器往返 ，才能滿足請求。 對于低網絡操作設備(例如移動設備)，這可能更糟。

Diverse communication protocol (such as gRpc, thrift, REST, AMQP e.t.c) existing in the microservices makes it challenging and bulky for the client to adopt all those protocols.

微服務中存在的多種通信協議(例如gRpc，節儉，REST，AMQP等)使客戶端采用所有這些協議具有挑戰性和體積。

Common gateway functionalities (such as authentication, authorization, logging) have to be implemented in each microservice.

必須在每個微服務中實現通用網關功能 (例如身份驗證，授權，日志記錄)。

It will be difficult to make changes in microservices without disrupting client connection. For e.g while merging or dividing microservices, it may be required to recode the client section.

在不中斷客戶端連接的情況下， 很難在微服務中進行更改 。 例如，在合并或劃分微服務時，可能需要重新編碼客戶端部分。

API網關 (API Gateway)

To address the above-mentioned challenges, an additional layer is introduced that sits between the client and the server acting as a reverse proxy routing request from the client to the server. Similar to the facade pattern of Object-Oriented Design, it provides a single entry point to the APIs encapsulating the underlying system architecture which is called API Gateway.

為了解決上述挑戰，引入了一個附加層，該附加層位于客戶端和服務器之間，充當從客戶端到服務器的反向代理路由請求。 與面向對象設計的外觀模式相似，它為封裝底層系統架構的API提供了一個單一的入口點，稱為API網關。

In short, it behaves precisely as API management but it is important not to confuse API management with API Gateway.

簡而言之，它的行為就像API管理一樣，但重要的是不要將API管理與API Gateway混淆。

Fig. Microservice API Gateway圖。微服務API網關

API網關的功能： (Functionalities of API Gateway:)

路由 (Routing)

Encapsulating the underlying system and decoupling from the clients, the gateway provides a single entry point for the client to communicate with the microservice system.

網關封裝了底層系統并與客戶端分離，為客戶端提供了與微服務系統進行通信的單個入口點。

卸貨 (Offloading)

API gateway consolidates the edge functionalities rather than making every microservices implementing them. Some of the functionalities are:

API網關整合了邊緣功能，而不是讓每個微服務都實現它們。 一些功能是：

• Authentication and authorization
  認證與授權
• Service discovery integration
  服務發現集成
• Response caching
  響應緩存
• Retry policies, circuit breaker, and QoS
  重試策略，斷路器和QoS
• Rate limiting and throttling
  限速和節流
• Load balancing
  負載均衡
• Logging, tracing, correlation
  記錄，跟蹤，關聯
• Headers, query strings, and claims transformation
  標頭，查詢字符串和聲明轉換
• IP whitelisting
  IP白名單
• IAM
  我是
• Centralized Logging (transaction ID across the servers, error logging)
  集中式日志記錄(服務器之間的事務ID，錯誤日志記錄)
• Identity Provider, Authentication and Authorization
  身份提供者，身份驗證和授權

后端用于前端(BFF)模式 (Backend for Frontend (BFF) pattern)

It is a variation of the API Gateway pattern. Rather than a single point of entry for the clients, it provides multiple gateways based upon the client. The purpose is to provide tailored APIs according to the needs of the client, removing a lot of bloats caused by making generic APIs for all the clients.

它是API網關模式的一種變體 。 它提供了基于客戶端的多個網關，而不是客戶端的單個入口點。 目的是根據客戶端的需求提供量身定制的API，從而消除了為所有客戶端制作通用API造成的大量膨脹。

Fig. Backend For Frontend (BFF) Pattern圖。后端(BFF)模式

您需要多少個BFF？ (How many BFFs do you need?)

The base concept of BFF is developing niche backends for each user experience. The guideline by Phil Cal?ado is ‘one experience, one BFF’. If the requirements across clients (IOS client, android client, a web browser e.t.c) vary significantly and the time to market of a single proxy or API becomes problematic, BFFs are a good solution. It should also be noted that the more complex design requires a complex setup.

BFF的基本概念是為每種用戶體驗開發利基后端。 菲爾·卡爾薩多(PhilCal?ado )的指導方針是“ 一種經驗，一種BFF ”。 如果跨客戶端(IOS客戶端，Android客戶端，Web瀏覽器等)的要求差異很大，并且單個代理或API的上市時間出現問題，則BFF是一個很好的解決方案。 還應注意，更復雜的設計需要復雜的設置。

GraphQL和BFF (GraphQL and BFF)

GraphQL is a query language for your API. Phil Cal?ado presents in this article that BFF and GraphQL are related but not mutually exclusive concepts. He adds that BFFs are not about the shape of your endpoints, but about giving your client applications autonomy where you can build your GraphQL APIs as many BFFs or as an OSFA (one-size-fits-all) API.

GraphQL是API的查詢語言。 菲爾Cal?ado這禮物文章是BFF和GraphQL相關但不相互排斥的概念。 他補充說，BFF與端點的形狀無關，而在于賦予客戶端應用程序自治權，您可以在其中構建與許多BFF或OSFA(一刀切)的GraphQL API。

著名的API網關 (Notable API Gateways)

Netflix API網關： Zuul (Netflix API Gateway: Zuul)

The Netflix streaming service available on more than 1000 different device types (televisions, set?top boxes, smartphones, gaming systems, tablets, e.t.c) handing over 50,000 requests per second during peak hours, found substantial limitations in OSFA (one-size-fits-all) REST API approach and used the API Gateway tailored for each device.

Netflix的流媒體服務可在1000多種不同類型的設備(電視，機頂盒，智能手機，游戲系統，平板電腦等)上使用，在高峰時段每秒處理50,000個請求，這在OSFA(單一尺寸安裝)中存在重大局限性-all)REST API方法，并使用為每個設備量身定制的API網關。

Zuul 2 at Netflix is the front door for all requests coming into Netflix’s cloud infrastructure. Zuul 2 significantly improves the architecture and features that allow our gateway to handle, route, and protect Netflix’s cloud systems, and helps provide our 125 million members the best experience possible.

Netflix的Zuul 2是所有進入Netflix云基礎架構的請求的前門。 Zuul 2大大改進了架構和功能，使我們的網關能夠處理，路由和保護Netflix的云系統，并有助于為我們的1.25億會員提供最佳體驗。

Fig. Zuul in Netflix Cloud Architecture (Image Source: https://netflixtechblog.com)Netflix Cloud Architecture中的Zuul圖(圖片來源： https : //netflixtechblog.com )

Amazon API網關 (Amazon API Gateway)

AWS provides fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket where developers can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud.

AWS提供了用于創建，發布，維護，監視和保護REST，HTTP和WebSocket的完全托管服務，開發人員可以在其中創建用于訪問AWS或其他Web服務的API以及存儲在AWS Cloud中的數據。

Fig. AWS API Gateway圖。AWS API網關

Kong API網關 (Kong API Gateway)

Kong Gateway is an open-source, lightweight API gateway optimized for microservices, delivering unparalleled latency performance and scalability. If you just want the basics, this option will work for you. It is scalable easily horizontally by adding more nodes. It supports large and variable workloads with very low latency.

Kong Gateway是為微服務優化的開源，輕量級API網關，可提供無與倫比的延遲性能和可伸縮性。 如果您只需要基礎知識，此選項將為您服務。 通過添加更多節點，可以輕松地水平擴展它。 它以非常低的延遲支持大量可變的工作負載。

Fig. Kong API Gateway圖。Kong API網關

其他API網關 (Other API Gateways)

• Apigee API Gateway

  Apigee API網關

• MuleSoft

  MuleSoft

• Tyk.io

  Tyk

• Akana

  赤名

• SwaggerHub

  SwaggerHub

• Azure API Gateway

  Azure API網關

• Express API Gateway

  Express API網關

• Karken D

  卡肯D

選擇正確的API網關 (Choosing the right API gateway)

Some of the common baseline for evaluation criteria include simplicity, open-source vs propriety, scalability & flexibility, security, features, community, administrative (support, monitoring & deployment), environment provisioning(installation, configuration, hosting offering), pricing, and documentation.

評估標準的一些常見基準包括簡單性，開源與專有性，可伸縮性和靈活性，安全性，功能，社區，管理(支持，監視和部署)，環境配置(安裝，配置，托管產品)，定價和文檔。

API組成/匯總 (API Composition / Aggregation)

Some API requests in API Gateway map directly to single service API which can be served by routing request to the corresponding microservice. However, in the case of complex API operations that requires results from several microservices can be served by API composition/aggregation (a scatter-gather mechanism). In case of dependency of one another service where synchronous communication is required, the chained composition pattern has to be followed. The composition layer has to support a significant portion of ESB/integration capabilities such as transformations, orchestration, resiliency, and stability patterns.

API網關中的一些API請求直接映射到單個服務API，可以通過將請求路由到相應的微服務來進行服務。 但是，對于復雜的API操作，需要幾種微服務的結果，可以通過API組合/聚合 ( 分散收集機制)。 在需要同步通信的情況下，如果彼此依賴服務，則必須遵循鏈式組合模式。 組成層必須支持很大一部分的ESB /集成功能，例如轉換，編排，彈性和穩定性模式。

A root container is deployed with the special distributor and aggregator functionalities (or microservices). The distributor is responsible for breaking down into granular tasks and distributing those tasks to microservice instances. The aggregator is responsible for aggregating the results derived by business workflow from composed microservice.

根容器具有特殊的分發器和聚合器功能(或微服務)。 分發者負責分解成細粒度的任務，并將這些任務分發給微服務實例。 聚合器負責聚合業務工作流從組合微服務中得出的結果。

API網關和聚合 (API Gateway and Aggregation)

API gateway with added features results in overambitious gateways that encourage designs that continue to be difficult to test and deploy. It is highly recommended to avoid aggregation and data transformation in the API Gateway. Domain smarts are better suited to be done in application code that follows the defined software development practices. Netflix API Gateway, Zuul 2 removed a lot of the business logic from Gateway that they had in Zuul to origin systems. For more details, refer here.

具有附加功能的API網關導致了過分的網關，從而鼓勵了仍然難以測試和部署的設計。 強烈建議避免API網關中的聚合和數據轉換。 域智能更適合在遵循定義的軟件開發實踐的應用程序代碼中完成。 Netflix API Gateway Zuul 2從他們在Zuul到原始系統的網關中刪除了許多業務邏輯。 有關更多詳細信息，請參閱此處 。

Fig. Composite / Integration service in layered Microservices圖。分層微服務中的復合/集成服務

服務網格和API網關 (Service Mesh and API Gateway)

Service mesh in microservices is a configurable network infrastructure layer that handles interprocess communication. This is akin to what is often termed as sidecar proxy or sidecar gateway. It provides a lot of functionalities such as:

微服務中的服務網格是處理進程間通信的可配置網絡基礎結構層。 這類似于通常稱為Sidecar代理或Sidecar網關的東西。 它提供了許多功能，例如：

• Load Balancing
  負載均衡
• Service Discovery
  服務發現
• Health Checks
  健康檢查
• Security
  安全

On the surface, it appears as though API gateways and service meshes solve the same problem and are therefore redundant. They do solve the same problem but in different contexts. API gateway is deployed as a part of a business solution that is discoverable by the external clients handling north-south traffic(face external client), however, service mesh handles east-west traffic (among different microservices).

從表面上看， API網關和服務網格似乎解決了相同的問題，因此是多余的。 它們確實解決了相同的問題，但是在不同的情況下。 API網關被部署為業務解決方案的一部分，該業務解決方案可由處理南北向流量的外部客戶端(面對外部客戶端)發現，但是，服務網格可以處理東西向流量(在不同的微服務之間)。

Implementing service mesh avoids the resilient communication pattern such as circuit breakers, discovery, health checks, service observability in your own code. For a small number of microservices, alternative strategies for failure management should be considered as service mesh integration may overkill you. For a larger number of microservices, it will be beneficial.

實施服務網格可避免在您自己的代碼中出現彈性的通信模式，例如斷路器，發現，運行狀況檢查以及服務可觀察性。 對于少量的微服務，應考慮使用其他替代方法來進行故障管理，因為服務網格集成可能會使您過分殺傷。 對于大量的微服務，這將是有益的。

Combining these two technologies can be a powerful way to ensure application uptime and resiliency while ensuring your applications are easily consumable. Viewing two as a contemporary can be a bad idea and it is better to view two as being complementary to one another in deployments that involve both microservices and APIs.

結合這兩種技術可能是確保應用程序正常運行時間和彈性的一種有效方法，同時又可以確保您的應用程序易于使用。 將兩者視為當代可能不是一個好主意，并且最好將兩者視為在涉及微服務和API的部署中相互補充。

Fig Layered Microservices with Service Mesh圖帶服務網格的分層微服務

API網關實現的注意事項： (Considerations for API Gateway implementation:)

• Possible single point of failure or bottleneck.
  可能的單點故障或瓶頸。
• Increase in response time due to additional network hop through API Gateway and risk of complexity.
  由于通過API網關進行額外的網絡跳轉以及復雜性風險，響應時間增加了。

翻譯自: https://medium.com/dev-genius/microservices-design-api-gateway-pattern-980e8d02bdd5

微服務api網關

總結

以上是生活随笔為你收集整理的微服务api网关_微服务设计api网关模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。