“When we talk about architecture, what are we talking about?” “Microservices!” Now it seems that no matter how large the R&D team is, it is either already using microservices or on the way to microservices. It is not clear whether microservices will be more beneficial or more troublesome for teams of two or three people. Instead of talking about microservices, this article will briefly discuss the so-called “next generation of microservices” called Service Mesh and “cloud native.”

Cloud native

What is “cloud native”? It is essentially a design pattern that requires cloud-native applications to be available and scalable, capable of automated deployment and management, and able to leverage some of the features offered by the cloud platform. The cloud platform environment is constantly changing. For example, there may be outages and insufficient resources. To ensure the normal operation of these applications deployed on the cloud, highly distributed, adaptive and highly resilient applications are required. Representative technologies include containers, service grids, microservices, immutable infrastructure, and declarative apis.

Service grid

Microservices are not a “silver bullet”, which not only solve problems but also bring a lot of complexity. In order to realize microservices, each service needs to deal with many common functions unrelated to business, such as service discovery, load balancing, and current limiting circuit breaker. Microservices were originally introduced to solve problems and support the rapid development of the business. However, when they were implemented, they found that there were still so many non-functional requirements, which even slowed down the development schedule and became worse than before. Frameworks like Spring Cloud have emerged to avoid code duplication and integrate into each service in the form of a class library. The current mainstream approach is an intrusive approach that shields complexity to some extent, but still has many pain points of its own, such as high barriers to learning — each component requires time and effort to learn, incomplete functionality, inability to cross languages, and difficulty upgrading. Each of these pain points undermines the benefits of microservices.

In the process of solving the above pain points, there have been many solutions.

  • Proxy solution (such as nginx proxy).
  • Sidecars mode.
  • First generation Service Mesh (data side, no control side).
  • Second generation Service Mesh (data plane, control plane).

Up to now, the most mature solution is the second-generation Service Mesh, represented by Istio.

So what is the service grid? Think of it as an infrastructure that addresses issues related to communication between microservices, shields communication complexity, addresses microservice governance issues, and allows us to use microservices as if they were local calls. It decouples the service governance-related capabilities introduced in the microservices process from business implementation down to the infrastructure level, while shielding the problems caused by language diversity. Unlike mainstream frameworks such as Spring Cloud, it is non-invasive and transparent to existing implementations. This makes it easier to transform traditional services into cloud-native applications.

It correlates invocation relationships through the Sidecar pattern, forming a network that forms the “service grid” shown in the figure below.

The separation of data plane and control plane is adopted in the architecture. The data plane is responsible for communication between proxy microservices and related functions, such as RPC, service discovery, load balancing, degraded fuses, traffic limiting and fault tolerance, etc. The control plane manages the data plane and defines policies for service discovery, routing, traffic control, and statistics monitoring. Istio, for example, takes over the full flow of microservice traffic as an envoy data surface, completely shielding the complexity of networking and communication.

The adoption of a service grid reduces the complexity of microservices, but it is not without cost, as it takes over all the traffic and therefore incurs a performance penalty. Of course, in the high kernel version, we can use cilium, EBPF and other related technologies to accelerate it, I believe that the future will not be a problem.

Development of China

Service grid also has certain development in China, major companies have begun to launch their own service grid, interested to know about it.

  • Ant Financial’s Sofa Mesh control platform is based on Istio and its data platform is developed by itself.
  • Weibo’s Motan-Go.
  • Huawei’s Mesher.

The original link