mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
150 lines
12 KiB
Markdown
150 lines
12 KiB
Markdown
|
[#]: 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: " "
|
|||
|
[#]: 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]
|
|||
|
译者:[译者ID](https://github.com/译者ID)
|
|||
|
校对:[校对者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/
|