Shulou(Shulou.com)06/03 Report--

Translation | Li Shouchao

Original text | https://www.getambassador.io/about/microservices-api-gateways/

Guide reading

Enterprise API gateway is a very mature tool, and there are many related mature products in the market. However, in the micro-service architecture with high requirements for lightweight and fast response, the traditional enterprise-level API gateway as the public infrastructure of the enterprise appears to be a bit heavy. In this article, we will discuss how the differences in business objectives (productivity and management) require us to implement a completely different API gateway.

Over the past decade, business organizations have been committed to exposing internal business systems through well-defined API. The huge challenge of how to securely expose hundreds or thousands of API to end users (internal and external) has led to the emergence of API gateways. When publishing services to the outside world, the traditional enterprise API gateway, as the back-end main entrance of a system, carries the work of composite route translation of all services. In addition, we generally put security, current restriction, cache, log, monitoring, retry, circuit breaker and so on to the API gateway to do. With the passage of time, the API gateway has gradually become one of the core and important infrastructure.

With the continuous promotion and use of the concepts of cloud native and micro services, we begin to encounter some new problems. Different from the traditional enterprise-level API gateway, the industry has proposed a micro-service API gateway to accelerate the development workflow of independent service teams. The microservice API gateway provides the team with all the functions of independently publishing, monitoring and updating microservices, focusing on accelerating the workflow of development, test and deployment.

Micro service organization

In a micro-service organization, small development teams work independently of each other to quickly provide functionality to customers. In order for each service team to work independently, through an efficient workflow, the service team needs to be able to:

1. Publish the service so that others can use it

two。 Monitor the service and observe its operation

3. Test and update the service so that you can continue to improve it

The team needs to do all of this without the help of other operations or platform teams, because as long as the service team needs another team, they are not working independently, leading to bottlenecks.

For service publishing, the microservice API gateway provides consumers with static addresses and dynamically routes requests to appropriate service addresses, where service addresses generally refer to multiple instances of one or more services developed and maintained by the service team. In addition, providing authentication for security and TLS termination are typical considerations for exposing services to other consumers.

Understanding the end-user experience of the service is critical to improving the service. For example, software updates may inadvertently affect the delay of some requests. Micro-service API gateways can well collect key observability indicators of end-user traffic because it can route traffic to Terminal Services.

The microservice API gateway also supports dynamic routing of user requests to different service versions for canary testing. By routing a small number of end-user requests to the new version of the service, the service team can safely test the impact of this update on a small number of users.

Micro Service API Gateway and Enterprise API Gateway

At first glance, the above use case can be achieved through an enterprise-centric API gateway. Although it can be implemented, the actual focus of enterprise API gateways and micro-service API gateways is somewhat different:

Self-service publishing

The team needs to be able to release new services to customers without the need for operations or API management teams. This ability to deploy and publish self-service enables the team to maintain high release speed and frequency. Although traditional enterprise API gateways can provide a simple mechanism for publishing new services (for example, REST API), they are actually limited to teams responsible for gateway operations. The main reason for restricting the release of API by a single team is for security reasons: incorrect API calls can have a disastrous impact on the production environment.

The micro-service API gateway allows the service team to easily and securely release new services because in the micro-service scenario, our default service team has a clear understanding of micro-services and takes full responsibility. Once a problem arises, it can be solved quickly. And the micro-service gateway can provide configurable monitoring to facilitate the discovery of problems and provide debugging hooks, such as checking traffic or traffic transfer / replication.

Monitoring and rate limiting

The common business model of API is metrology, in which consumers are charged different fees according to the use of API. Traditional enterprise API gateways generally do better at this: they provide the ability to monitor the use of each client API and have the ability to limit the use of clients when they exceed quotas.

Microservice gateways also require monitoring and rate limiting, but for different reasons. It is important to monitor user-visible metrics, such as throughput, latency, and availability, to ensure that updates to microservices do not affect end users. Stable and reliable monitoring indicators are very important for the realization of fast incremental updates. Rate limiting is used to improve the overall resilience of the service. When the service does not respond as expected, the API gateway can restrict incoming requests to allow the service to resume and prevent cascading failures, that is, circuit breakers, degradations and other modes that are often used in micro-service designs.

Testing and updating

Microservice applications have multiple services, each of which is updated independently. Automated testing is necessary before going to a production environment, but it is not enough for micro-services. Canary deployment routes a small portion of production traffic to the new service version and is an important tool to help test updates. By limiting the version of the new service to a small number of users, even if something goes wrong, the impact of the service failure is limited. When the test is stable, gradually replace the old version, and finally achieve the version update of all service instances.

In traditional enterprise API gateways, routes are used to isolate or combine / aggregate changed API versions. Automatic testing before production environment and manual verification and inspection after production environment are both necessary.

Summary

Traditional enterprise API gateways are designed to solve the challenges of API management. Although they seem to solve some of the challenges under the micro-service architecture, the reality is that the micro-service workflow puts forward a different set of requirements. Integrate the micro-service API gateway into the micro-service development workflow, so that the service team can quickly and securely publish, monitor and update its services. This will enable us to release software faster and more reliable than ever before.

This article is translated and published by Boyun Research Institute. Please indicate the source when reproduced.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.