From ServiceMesh to Decentralized SOA Bus

I have talked about service mesh, API gateway and traditional centralized architecture ESB service bus many times in my previous articles on Toutiao. Today I will continue to talk about some thoughts on the three.

The origin of this is that when we were discussing ESB products with customers many years ago, the customers asked whether it was possible to decentralize ESB products and put the capabilities of ESB products into various business systems through SDK proxy packages. This is also the core idea of ​​the current ServiceMesh service gateway and Sidecar.

In the traditional monolithic architecture, integration through ESB bus is already a standard practice, but the centralized architecture of ESB bus itself is the most criticized part. Due to the centralization of ESB itself, ESB bus itself may have a performance bottleneck point, and all service call requests go through ESB bus, so if ESB goes down, it will be a huge disaster.

An important core function of ESB is Proxy service routing, which is transparent to the underlying location and provides a unified export, so you can see that Ngnix can also provide this core capability. Currently, many API gateways are also secondary developed based on Ngnix and OpenRestry.

So we have reached the microservices stage.

Many people understand that complete decentralization is achieved through the service registry, but when you consider the integration of multiple independent microservice teams and the need for a large microservice application to uniformly expose API interface services to the outside world, these scenarios still require the use of an API gateway or a microservice gateway.

Therefore, the API gateway itself is also a centralized architecture. Because it is a centralized architecture, it is easier to add various traffic interception plug-ins to achieve various interface management capabilities such as security, logging, flow control, and routing.

So is there a decentralized architecture that can also achieve the above capabilities?

The current mainstream solution has evolved to the ServiceMesh service mesh architecture mode that sends Sidecar proxies and separates control flows and data flows. The following figure is a comparison between the API mesh and ServiceMesh architectures.

It can be seen that most of the capabilities of the API gateway can be replaced by SericeMesh.

The only issue is the exposure of north-south traffic and external unified interface mentioned in the above figure, which still needs to be addressed, that is, to implement the most basic proxy and north-south traffic distribution capabilities.

As long as it has this capability, it will be fine. This capability can be hardware load balancing capability, or software cluster or reverse proxy. If it corresponds to the K8s cluster, it corresponds to the K8s Ingress gateway to provide a unified external export.

In the Docker+K8s container cloud resource scheduling platform, dynamically expanded elastic computing nodes are uniformly managed by K8s, so it is reasonable for the K8s Ingress gateway to expose a unified interface. The remaining interface management capabilities should all be transferred to ServiceMesh.

Therefore: SreviceMesh grid + Ingress gateway can fully realize decentralized ESB capabilities.

Simply put, we still hope to implement a decentralized ESB product, fully retain the various capabilities of the ESB bus, separate data flow and control flow, and cooperate with the idea of ​​ServiceMesh to implement open source.

Service self-discovery or manual service registration?

Based on the microservice architecture framework, service self-discovery can be achieved. Service self-discovery actually has an impact on the development state. Similar development frameworks require development configuration and code annotation additions during the development phase.

Another method is to manually register and access the API interface. As shown in the figure above, the supplier microservice provides a query Rest API interface service.

http://10.0.0.1/VendorInfo

Then we still need to register the interface on the management and control platform. The registration still needs to go through the gateway, and only the most basic proxy routing capability is used to encapsulate and expose it. If it is north-south traffic, it will be exposed through the interface encapsulated by the gateway. If it is east-west traffic, it will directly go through the API interface address provided by the original supplier microservice. Therefore, the actual service call on the consumer side still goes through the service registration center capability.

• First register for the supplier query service on the management and governance platform
• The consumer first queries the supplier query interface service from the registration center
• The consumer initiates an interface call
• The Sidecar on the consumer or provider side performs interception processing

That is, the two traffic scenarios are handled in different ways.

In the scenario of east-west traffic between internal microservices, various security and log control can be performed through Sidecar traffic interception on both the consumer and provider sides. If it is an external APP or external application calling the interface, Sidecar traffic interception and processing is only performed on the service provider side.

Sidecar and control center collaboration

Each interception plug-in in SIdecar actually collaborates with the control center. For example, authentication processing requires access to the service authorization information of the control center, and log processing requires intercepting logs and writing them to the message middleware. Routing processing requires access to the routing configuration table of the control center, etc.

If the control center itself fails, it will still affect the interface service call, and the control center itself needs to be deployed in a distributed cluster to improve high availability. At the same time, a light cache system can be built on the Sidecar to achieve availability when the control center fails.