What is the relationship between API, ESB, ServiceMesh, and microservices?

Introduction

I mentioned before that I would like to introduce the API Gateway. In fact, whether it is microservices, service mesh, cloud native, or digital construction, the API Gateway is an unavoidable topic. Since the introductions of the API Gateway on the Internet vary, today we will no longer simply introduce the basic knowledge and functions of the API Gateway, but will go straight to the point and talk about the relationship between ESB, ServiceMesh, microservices, and API Gateway.

[[421537]]

01 The Core of API Gateway

With the widespread use of microservice scenarios, API gateways have gradually attracted attention. Aggregating interfaces and services to provide front-end calls and business encapsulation is the main scenario of API gateways.

The API gateway is a bridge between internal and external business communications or the front and back ends of the system. In addition to establishing communications and routing forwarding, it also undertakes many non-business functions, such as security, flow control, filtering, caching, monitoring, etc.; in the service-oriented model, some operational functions will also be added, such as API management, metering and billing, service subscription, etc.

It can be seen that we can do a lot on the API gateway, just because it undertakes and forwards the traffic, which is also the core of the API gateway.

This role is not unfamiliar. The ESB and ServiceMesh mentioned in my previous two articles both rely on the traffic reception and forwarding functions to form solutions. The same tool, placed in different positions, has different forms. API Gateway is such a tool.

02 The relationship between API, ESB, ServiceMesh, and microservices

Scenarios for replacing ESB

There is no need to introduce ESB in depth. Its core is also routing, forwarding, conversion, and flow control. As ESB gradually withdraws from the digital stage, most companies are also thinking about how to gradually replace ESB with a substitute. We at Boyun have made a variety of solutions and functions for smoothly replacing ESB through microservice framework and service grid framework in multiple projects. At the same time, it covers its original routing forwarding, protocol conversion, and flow control functions. The most direct solution is to implement it through API gateway.

The ESB architecture is responsible for both east-west access control and north-south traffic control. The solution using the API gateway is more flexible. Its scalable size, flexible dynamic configuration, and self-service consumption model are more in line with the diverse new digital architecture. If planned properly, the API gateway can replace the ESB while also serving as a gateway for the entire network domain or even the entire enterprise. This is the first step in the service middle platform.

Applications in a service mesh

The concept of ServiceMesh is actually very easy to understand. Through a proxy service, all traffic is taken over, and non-business governance, monitoring and other functions are implemented through the proxy service. Then this proxy service (proxy) is another application scenario of API gateway. Hijack the traffic and then add the required customized functions.

Compared with other scenarios, the gateway function here has not changed much, but the location of use is very different. In the ServiceMesh scenario, the gateway is a very small and lightweight proxy unit, and each business operation unit will be equipped with the proxy unit to start together, so in the ServiceMesh scenario, it is usually called a sidecar. In other words, the Sidecar in ServiceMesh is an API gateway application. For example, in the Istio framework, the data plane Sidecar is Envoy (an API gateway based on the C++ language).

Microservice Gateway

It is worth mentioning the API gateway in the microservice scenario. Isn't this scenario the most basic application? In fact, the microservice gateway is also the result of the scenario-based transformation of the API gateway. For example, SpringcloudGateway and Zuul are microservice gateways developed in Java based on the netty framework, and are mainly used in the Springcloud microservice scenario.

In the microservice scenario, the addressing of inter-service communication needs to rely on the registration center. When the microservice gateway performs routing forwarding, the upstream address also needs to be obtained from the registration center. At the same time, when the microservice accesses the gateway, it can also be addressed directly through the registration center. Therefore, the microservice gateway needs to comply with the registration and discovery mechanism of the microservice framework.

03 Conclusion

The core of the three types of gateways are communication proxy and forwarding. When replacing ESB, they have the feature of protocol conversion. When connecting to microservices, they add the function of synchronization with the registration center. When acting as a sidecar, they need to hijack traffic and communicate with the control plane. In addition, there is the scenario of API market that has not been mentioned. This scenario requires the addition of metering and billing functions.

Therefore, according to different usage scenarios and different application methods, you can freely adjust it by relying on the API gateway. In Boyun, at least three types of gateways and multiple scenarios are involved.

The first type: enterprise-level API gateways, which mainly focus on providing service capabilities and handle the traffic of the entire enterprise, so they have extremely high requirements for the performance of the gateway. The component we use is based on openresty+lua's kong to solve the problem, and the performance guarantees the interaction pressure of the entire enterprise.

The second type: microservice gateway, which is mainly the encapsulation of microservices, but it is not the focus and difficulty. Through the delivery of many projects, it is found that the needs of microservices are easy to meet, but the transition solution is more difficult. The so-called transition solution refers to the Sidecar solution made by API gateway when non-microservice applications need to be uniformly governed with microservice applications. We use SpringcloudGateway internally in Boyun, and perform protocol conversion, service detection and other functions on it to achieve unified management and governance of monolithic applications and traditional architecture systems.

The third type: service mesh, which is mainly the data sidecar part. The difference is that the microservice framework above is basically determined to be Springcloud, while the service mesh originally uses the Istio framework inside our Boyun, and the sidecar under the Istio framework uses Envoy. We expand the ESB scenario and the traditional architecture compatible scenario on Envoy, and add protocol support, protocol conversion, data collection, link collection and other functions to meet the complex microservice transformation needs.

The formation is the basis for fighting, and the key to success lies in one's heart. The technology of API gateway is almost mature, and its reasonable application in the right scenario will play a great role.