mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #29581 from cool-summer-021/Use-this-open-source-API-gateway-to-scale-your-API
Update and rename 20230109.1 ⭐️⭐️ Use this open source API gateway to…
This commit is contained in:
Xingyu.Wang
GitHub
commit
b0312c3dfa
@ -1,149 +0,0 @@
|
||||
[#]: subject: "Use this open source API gateway to scale your API"
|
||||
[#]: via: "https://opensource.com/article/23/1/api-gateway-apache-apisix"
|
||||
[#]: author: "Bobur Umurzokov https://opensource.com/users/iambobur"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "cool-summer-021"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Use this open source API gateway to scale your API
|
||||
======
|
||||
|
||||
An API gateway is a single point of entry for incoming calls to an [application programming interface (API)][1]. The gateway aggregates the services being requested and then returns the appropriate response. To make your API gateway effective, it's vital for you to design a reliable, efficient, and simple API. This is an architectural puzzle, but it's one you can solve as long as you understand the most important components.
|
||||
|
||||
### API-Led approach
|
||||
|
||||
An API-Led approach puts an API at the heart of communication between applications and the business capabilities they need to access in order to consistently deliver seamless functionality across all digital channels. **API-Led connectivity** refers to the technique of using a reusable and well-designed API to link data and applications.
|
||||
|
||||
### API-Led architecture
|
||||
|
||||
API-Led architecture is an architectural approach that looks at the best ways of reusing an API. API-Led architecture addresses things like:
|
||||
|
||||
- Protecting an API from unauthorized access.
|
||||
- Ensuring that consuming applications can always find the right API endpoint.
|
||||
- Throttling or limiting the number of calls made to an API to ensure continuous availability.
|
||||
- Supporting continuous integration, testing, lifecycle management, monitoring, operations, and so on.
|
||||
- Preventing error propagation across the stack.
|
||||
- Real-time monitoring of an API with rich analytics and insight.
|
||||
- Implementing scalable and flexible business capabilities (for example, supporting a [microservice][2] architecture.)
|
||||
|
||||
### API resource routing
|
||||
|
||||
Implementing an API gateway as the single entry point to all services means that API consumers only have to be aware of one URL. It becomes the API gateway's responsibility to route traffic to the corresponding service endpoints, and to enforce policies.
|
||||
|
||||
![Image depicting the API routing traffic.][3]
|
||||
|
||||
This reduces complexity on the API consumer side because the client applications don't need to consume functionality from multiple HTTP endpoints. There's alsono need to implement a separate layer for authentication, authorization, throttling, and rate limiting for each service. Most API gateways, like the open source [Apache APISIX][4] project, already have these core features built in.
|
||||
|
||||
### API content-based routing
|
||||
|
||||
A content-based routing mechanism also uses an API gateway to route calls based on the content of a request. For example, a request might be routed based on the HTTP header or message body instead of just its target URI.
|
||||
|
||||
Consider a scenario when database sharding is applied in order to distribute the load across multiple database instances. This technique is typically applied when the overall number of records stored is huge and a single instance struggles to manage the load.
|
||||
|
||||
A better solution is to spread records across multiple database instances. Then you implement multiple services, one for each unique datastore, and adopt an API gateway as the only entry point to all services. You can then configure your API gateway to route calls to the corresponding service based on a key obtained either from the HTTP header or the payload.
|
||||
|
||||
![Image of the API gateway exposing a single customer.][5]
|
||||
|
||||
In the above diagram, an API gateway is exposing a single `/customers` resource for multiple customer services, each with a different data store.
|
||||
|
||||
### API geo-routing
|
||||
|
||||
An API geo-routing solution routes an API call to the nearest API gateway based on its origin. In order to prevent latency issues due to distance (for example, a consuming application from Asia calling an API located in North America), you can deploy an API gateway in multiple regions across the world. You can use a different subdomain for each API gateway in each region, letting the consuming application determine the nearest gateway based on application logic. Then, an API gateway provides internal load balancing to make sure that incoming requests are distributed across available instances.
|
||||
|
||||
![Image of a DNS traffic management system.][6]
|
||||
|
||||
It's common to use a DNS traffic management service and an API gateway to resolve each subdomain against the region's load balancer to target the nearest gateway.
|
||||
|
||||
### API aggregator
|
||||
|
||||
This technique performs operations (for example, queries) against multiple services, and returns the result to the client service with a single HTTP response. Instead of having a client application make several calls to multiple APIs, an API aggregator uses an API gateway to do this on behalf of the consumer on the server side.
|
||||
|
||||
Suppose you have a mobile app that makes multiple calls to different APIs. This increases complexity in the client-side code, it causes over-utilization of network resources, and produces a poor user experience due to increased latency. An API gateway can accept all information required as input, and can request authentication and validation, and understand the data structures from each API it interacts with. It's also capable of transforming the response payloads so they can be sent back to the mobile app as a uniform payload needed for the consumer.
|
||||
|
||||
![Image of an API gateway.][7]
|
||||
|
||||
### API centralized authentication
|
||||
|
||||
In this design, an API gateway acts as a centralized authentication gateway. As an authenticator, an API gateway looks for access credentials in the HTTP header (such as a bearer token.) It then implements business logic that validates those credentials with an identity provider.
|
||||
|
||||
![Image of a tree showing API gateway's centralized authentication.][8]
|
||||
|
||||
Centralized authentication with an API gateway can solve many problems. It completely offloads user management from an application, improving performance by responding quickly to authentication requests received from client applications. Apache APISIX offers a [variety of plugins][9] to enable different methods of API gateway authentication.
|
||||
|
||||
![Image showing Apache ASPISIS and various plugins.][10]
|
||||
|
||||
### API format conversion
|
||||
|
||||
API format conversion is the ability to convert payloads from one format to another over the same transport. For example, you can transfer from XML/SOAP over HTTPS to JSON over HTTPS, and back again. An API gateway offers capabilities in support of a [REST API][11] and can do payload conversions and transport conversions. For instance, a gateway can convert from a message queue telemetry transport (MQTT) over TCP (a very popular transport in IoT) to JSON over HTTPS.
|
||||
|
||||
![Image depicting APISIX transfers.][12]
|
||||
|
||||
Apache APISIX is able to receive an HTTP request, transcode it, and then forward it to a gRPC service. It gets the response and returns it back to the client in HTTP format by means of its [gRPC Transcode][13] plug-in.
|
||||
|
||||
### API observability
|
||||
|
||||
By now, you know that an API gateway offers a central control point for incoming traffic to a variety of destinations. But it can also be a central point for observation, because it's uniquely qualified to monitor all traffic moving between the client and service networks. You can adjust an API gateway so that the data (structured logs, metrics, and traces) can be collected for use with specialized monitoring tools**.**
|
||||
|
||||
Apache APISIX provides [pre-built connectors][14] so you can integrate with external monitoring tools. You can leverage these connectors to collect log data from your API gateway to further derive useful metrics and gain complete visibility into how your services are being used. You can also manage the performance and security of your API in your environment.
|
||||
|
||||
### API caching
|
||||
|
||||
API caching is usually implemented inside the API gateway. It can reduce the number of calls made to your endpoint, and also improve the latency of requests to your API by caching a response from upstream. If the API gateway cache has a fresh copy of the requested resource, it uses that copy to satisfy the request directly instead of making a request to the endpoint. If the cached data is not found, the request travels to the intended upstream services.
|
||||
|
||||
![Image depicting how the API gateway cache functions.][15]
|
||||
|
||||
### API fault handling
|
||||
|
||||
API services may fail due to any number of reasons. In such scenarios, your API service must be resilient enough to deal with predictable failures. You also want to ensure that any resilience mechanisms you have in place work properly. This includes error handling code, circuit breakers, health checks, fallbacks, redundancy, and so on. Modern API gateways support all the most common error-handling features, including automatic retries and timeouts.
|
||||
|
||||
![Image depicting some of the many mechanisms that the modern API Gatway can support.][16]
|
||||
|
||||
An API gateway acts as an orchestrator that can use a status report to decide how to manage traffic, send load balances to a healthy node, and can fail fast. It can also alert you when something goes wrong. An API gateway also ensures that routing and other network-level components work together successfully to deliver a request to the API process. It helps you detect a problem in the early stage, and to fix issues. A fault injection mechanism (like the one Apache APISIX uses) at the API gateway level can be used to test the resiliency of an application or microservices API against various forms of failures.
|
||||
|
||||
### API versioning
|
||||
|
||||
This refers to having the ability to define and run multiple concurrent versions of an API. This is particularly important, because an API evolves over time. Having the ability to manage concurrent versions of an API enables API consumers to incrementally switch to newer versions of an API. This means older versions can be deprecated and ultimately retired. This is important because an API, just like any other software application, should be able to evolve either in support of new features or in response to bug fixes.
|
||||
|
||||
![Image of using the API Gateway to implement API versioning.][17]
|
||||
|
||||
You can use an API gateway to implement API versioning. The versioning can be a header, query parameter, or path.
|
||||
|
||||
### Gateway to APISIX
|
||||
|
||||
If you want to scale your API services, you need an API gateway. The Apache APISIX project provides essential features for a robust entrypoint, and its benefits are clear. It aligns with an API-Led architecture, and is likely to transform the way your clients interact with your hosted services.
|
||||
|
||||
_This article has been adapted and republished from the [Apache APISIX blog][18] with the author's permission._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/23/1/api-gateway-apache-apisix
|
||||
|
||||
作者：[Bobur Umurzokov][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[cool-summer-021](https://github.com/cool-summer-021)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/iambobur
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces
|
||||
[2]: https://www.redhat.com/en/topics/microservices/what-are-microservices?intcmp=7013a000002qLH8AAM
|
||||
[3]: https://opensource.com/sites/default/files/2022-12/API.routing.traffic.png
|
||||
[4]: https://apisix.apache.org/docs/apisix/terminology/api-gateway/
|
||||
[5]: https://opensource.com/sites/default/files/2022-12/API%20gateway%20%20exposing%20a%20singlecustomer.png
|
||||
[6]: https://opensource.com/sites/default/files/2022-12/DNS-traffic%20management%20.png
|
||||
[7]: https://opensource.com/sites/default/files/2022-12/API-gateway.png
|
||||
[8]: https://opensource.com/sites/default/files/2022-12/Apigateway.centralized.png
|
||||
[9]: https://apisix.apache.org/docs/apisix/plugins/openid-connect/
|
||||
[10]: https://opensource.com/sites/default/files/2022-12/Apache.ASPISISplugins.png
|
||||
[11]: https://www.redhat.com/en/topics/api/what-is-a-rest-api?intcmp=7013a000002qLH8AAM
|
||||
[12]: https://opensource.com/sites/default/files/2022-12/APISIX.transfers.png
|
||||
[13]: https://apisix.apache.org/docs/apisix/plugins/grpc-transcode/
|
||||
[14]: https://apisix.apache.org/docs/apisix/plugins/prometheus/
|
||||
[15]: https://opensource.com/sites/default/files/2022-12/APIgatewaycache.png
|
||||
[16]: https://opensource.com/sites/default/files/2022-12/ModernAPIGatways.png
|
||||
[17]: https://opensource.com/sites/default/files/2022-12/API.gateway.version.png
|
||||
[18]: https://apisix.apache.org/blog/2022/10/27/ten-use-cases-api-gateway/
|
||||
@ -0,0 +1,149 @@
|
||||
[#]: subject: "Use this open source API gateway to scale your API"
|
||||
[#]: via: "https://opensource.com/article/23/1/api-gateway-apache-apisix"
|
||||
[#]: author: "Bobur Umurzokov https://opensource.com/users/iambobur"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "cool-summer-021"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
使用这个开源 API 网关实现可伸缩 API
|
||||
======
|
||||
|
||||
API 网关是一个单一节点，提供对 [API][1] 调用入口。网关聚集了被请求的服务，并相应传回合适的响应信息。为了令你的API 网关有效地工作，设计一个可靠、高效且简洁地API 至关重要。本文介绍一种设计风格，但只要你理解其中的重点内容，它就能解决你的相关问题。
|
||||
|
||||
### 由 API 主导的方法
|
||||
|
||||
API主导的方法将API置于应用程序和它们需要访问的业务能力之间通信的核心，从而在所有数字通道上一致地交付无缝功能。API主导的连接是指使用一种可重用且设计得当的API 来连接数据和应用程序的方法。
|
||||
|
||||
### API 主导的架构
|
||||
|
||||
API主导的架构是一种架构方法，它着眼于实现重用 API 的最佳方式。它能解决以下问题：
|
||||
|
||||
- 保护 API ,使外界无法在未授权情况下访问API
|
||||
- 确保应用程序能找到正确的API 节点
|
||||
- 限制对 API 的请求次数，从而确保持续的可用性
|
||||
- 支持连续性的集成、测试、生命周期管理、监控、运营等等
|
||||
- 防止错误在栈间传播
|
||||
- 对 API 的实时监测和分析
|
||||
- 实现可伸缩和灵活的业务能力（例如支持[微服务][2]架构）
|
||||
|
||||
### API 资源路由
|
||||
|
||||
实现一个 API 网关，把它作为与所有服务通信的单一节点，意味着使用者只需要知道 URL 就能使用 API。将请求路由到相应的服务端点并执行相应的功能是 API 网关的职责。
|
||||
|
||||
![Image depicting the API routing traffic.][3]
|
||||
|
||||
由于客户端应用程序不需要从多个HTTP端点调用功能，这个办法就减少了API 使用者的操作复杂度。对单个服务来说，也不需实现一个单独的层级去实现认证、授权、节流和速度限制。大多数API 网关，类似于[Apache APISIX][4]，已经包含了这些核心功能。
|
||||
|
||||
### API 基于内容的路由
|
||||
|
||||
基于内容的路由机制也使用 API 网关根据请求的内容进行路由调用。例如，一个请求可能是基于 HTTP 请求的头部内容或消息体被路由，而不基只基于它的目标 URI。
|
||||
|
||||
考虑这样一个场景：为了将负载在多个数据库实例间均分，需要对数据库进行分区。当记录总数较大，单个数据库实例难以管理负载时，常常会用这个办法。
|
||||
|
||||
还有一个更好的办法，就是把记录在多个数据库实例间分散开来。你实现了多个服务，每个数据库都有一个服务，把一个API 网关作为访问所有服务的唯一入口。
|
||||
|
||||
![Image of the API gateway exposing a single customer.][5]
|
||||
|
||||
在上面的图表中，一个 API 网关向多个服务暴露一个单一的 `/customers` 资源，每个服务对应的数据库却是不同的。
|
||||
|
||||
### API 地理路由
|
||||
|
||||
API地理路由解决方案根据API调用的来源将其路由到最近的API网关。为了防止地理距离导致的延迟问题（例如一个位于亚洲的客户端调用了位于北美地区的API）,你可以在多个地区部署同一个 API 网关。对于一个 API 网关，你可以在每个区域使用不同的子域名，让应用程序基于业务逻辑选择最近的网关。因此 API 网关就提供了内部负载均衡，确保进入的请求分布于可用的实例之间。
|
||||
|
||||
![Image of a DNS traffic management system.][6]
|
||||
|
||||
针对区域的负载均衡器，使用 DNS 流量管理服务和API 网关解析子域名，定位到距离最近的网关，这种做法很常见。
|
||||
|
||||
### API 整合器
|
||||
|
||||
这项技术对多个服务执行操作（例如查询），并向客户端服务以单个 HTTP 响应的形式返回结果。API 整合器使用 API 网关来执行这项工作，而非让客户端程序多次调用 API。
|
||||
|
||||
.假定你有一款移动端 APP，对不同的 API发起多次调用。这增加了客户端代码的复杂性，导致网络资源的重复使用，而且由于延迟性，用户体验也不好。网关可以接收一切信息，可以请求认证，并理解来自每个API的数据结构。它也可以传递响应负载，因此它们也会作为一个用户需要的统一负载传回移动端。
|
||||
|
||||
![Image of an API gateway.][7]
|
||||
|
||||
### 以API 为中心的认证
|
||||
|
||||
在这种设计中， API 网关就是一个集中式认证网关。作为一个认证者，API 网关在 HTTP 请求头中查找访问凭据（例如不记名的令牌）。然后它借助于身份验证提供方执行验证凭据的业务逻辑。
|
||||
|
||||
![Image of a tree showing API gateway's centralized authentication.][8]
|
||||
|
||||
使用 API 网关的集中式身份验证能解决很多问题。它完全取代了应用程序中的用户管理模块，通过对来自客户端应用程序的身份验证请求的快速响应来提高性能。Apache APISIX 提供了一系列插件，支持不同的API 网关认证方法。
|
||||
|
||||
![Image showing Apache ASPISIS and various plugins.][10]
|
||||
|
||||
### API 格式转换
|
||||
|
||||
API 格式转换是通过相同的传输方式将有效载荷从一种格式转换为另一种格式的能力。例如，你可以通过 HTTPS 从XML/SOAP格式转换为JSON格式，反之亦然。API网关提供了支持[REST API][11]的功能，可以有效地进行负载和传输的转换。例如，它可以把消息队列遥测传输（MQTT）转换为 JSON 格式。
|
||||
|
||||
![Image depicting APISIX transfers.][12]
|
||||
|
||||
Apache APISIX能够接收HTTP请求，对其进行代码转换，然后将其转发给gRPC服务。它通过[gRPC Transcode][13]插件获取响应并将其以HTTP格式返回给客户端。
|
||||
|
||||
### API 的可观察性
|
||||
|
||||
现在，你知道API 网关为进入各种目的地的流量提供了一个中心控制点。但它也可以是一个中心观察点，因为就监控客户端和服务器端的流量来说，它是唯一合格的。为了收集监测工具所需要的数据（结构化日志、度量和跟踪），你可以对 API 网关作出调整。
|
||||
|
||||
Apache APISIX提供[预先构建的连接器][14]，因此你可以跟外部监测工具结合使用。您可以利用这些连接器从您的API网关收集日志数据，进一步获得有用的指标，并获取完整可见的服务使用情况。
|
||||
|
||||
### API 缓存
|
||||
|
||||
API 缓存通常在网关内部实现。它可以减少对端点的调用次数，同时通过缓存上游的响应，改进了请求延迟的情况。如果网关缓存对请求资源进行了备份，它会直接使用这个备份来响应这个请求，而不必对端点发出请求。如果缓存数据不存在，就将请求传到目标上游服务。
|
||||
|
||||
![Image depicting how the API gateway cache functions.][15]
|
||||
|
||||
### API 错误处理
|
||||
|
||||
由于各种原因，API 服务可能会出错。在这种情况下，API 服务需要有一定的弹性，来应对可预见的错误。你也希望确保弹性机制能正常工作。弹性机制包括错误处理代码、断路器、健壮性检查、备用程序、冗余等等。新式的API 网关支持一切错误处理功能，包括自动重试和超时设置。
|
||||
|
||||
![Image depicting some of the many mechanisms that the modern API Gatway can support.][16]
|
||||
|
||||
API 网关也充当管弦乐演奏者的角色，它会根据各方面情况来决定如何管理流量、向忙碌的节点发送负载均衡器，还能快速停止运行。当有异常状况，它也会向你发出警示。API网关也保证路由和其他网络级组件能协同将请求传给API 进程。它能帮助你在早期检测出问题，并修复问题。网关的错误注入机制（类似于Apache APISIX使用的那种）用于测试应用程序或微服务在各种错误发生时的弹性。
|
||||
|
||||
### API 版本管理
|
||||
|
||||
版本管理是指定义和运行多个同步的 API 版本的功能。这点也很重要，因为 API 是随着时间推移不断改进的。如果能对API 的同步版本进行管理，那么API 使用者就可以较快地切换到新地版本。这也意味着较老的版本将会被弃用。API 也跟其他应用程序类似，无论是开发新功能还是进行BUG 修复，都存在演变的过程。
|
||||
|
||||
![Image of using the API Gateway to implement API versioning.][17]
|
||||
|
||||
你可以使用API 网关来实现 API 版本管理。版本管理可以是请求头，查询参数或路径。
|
||||
|
||||
### APISIX 的网关
|
||||
|
||||
如果你需要令 API 服务可伸缩，就需要使用 API 网关。Apache APISIX 提供了必要的功能，可以实现健壮的入口，它的好处是显而易见的。它遵循API主导的架构，并且有可能改变客户端与托管服务交互的方式。
|
||||
|
||||
_This article has been adapted and republished from the [Apache APISIX blog][18] with the author's permission._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/23/1/api-gateway-apache-apisix
|
||||
|
||||
作者：[Bobur Umurzokov][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[cool-summer-021](https://github.com/cool-summer-021)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/iambobur
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces
|
||||
[2]: https://www.redhat.com/en/topics/microservices/what-are-microservices?intcmp=7013a000002qLH8AAM
|
||||
[3]: https://opensource.com/sites/default/files/2022-12/API.routing.traffic.png
|
||||
[4]: https://apisix.apache.org/docs/apisix/terminology/api-gateway/
|
||||
[5]: https://opensource.com/sites/default/files/2022-12/API%20gateway%20%20exposing%20a%20singlecustomer.png
|
||||
[6]: https://opensource.com/sites/default/files/2022-12/DNS-traffic%20management%20.png
|
||||
[7]: https://opensource.com/sites/default/files/2022-12/API-gateway.png
|
||||
[8]: https://opensource.com/sites/default/files/2022-12/Apigateway.centralized.png
|
||||
[9]: https://apisix.apache.org/docs/apisix/plugins/openid-connect/
|
||||
[10]: https://opensource.com/sites/default/files/2022-12/Apache.ASPISISplugins.png
|
||||
[11]: https://www.redhat.com/en/topics/api/what-is-a-rest-api?intcmp=7013a000002qLH8AAM
|
||||
[12]: https://opensource.com/sites/default/files/2022-12/APISIX.transfers.png
|
||||
[13]: https://apisix.apache.org/docs/apisix/plugins/grpc-transcode/
|
||||
[14]: https://apisix.apache.org/docs/apisix/plugins/prometheus/
|
||||
[15]: https://opensource.com/sites/default/files/2022-12/APIgatewaycache.png
|
||||
[16]: https://opensource.com/sites/default/files/2022-12/ModernAPIGatways.png
|
||||
[17]: https://opensource.com/sites/default/files/2022-12/API.gateway.version.png
|
||||
[18]: https://apisix.apache.org/blog/2022/10/27/ten-use-cases-api-gateway/
|
||||
Loading…
Reference in New Issue
Block a user