Exploration and Practice of Proxyless Mesh Mode in Spring Cloud Application

Introduction to Service Mesh

Service Mesh is no longer a new concept. At present, there are many explorations and practices about Service Mesh.

• 2016 can be said to be the first year of Service Mesh. William Morgan, CEO of Buoyant, took the lead in releasing Linkerd, becoming the first Service Mesh project in the industry. In the same year, Lyft released Envoy, becoming the second Service Mesh project.

• In 2017, Google, IBM and Lyft jointly released Istio. Compared with Linkerd/Envoy and other projects, it added the concept of control plane to everyone for the first time, providing a strong flow control capability. After years of development, Istio has gradually become the de facto standard of the control plane.

• The release of version 1.0 marks that Istio has entered the era of production availability, and more and more enterprises apply service grid to production.

• Version 1.5 starts to integrate multiple original components into a single structure; At the same time, the long criticized Mixer component has been abandoned and unified as Istiod service, facilitating deployment and operation and maintenance.

At present, Istio is the most popular open source service grid, which consists of control plane and data plane.

In the Istio Mesh architecture, its control plane is a process named Istiod, and the network proxy is Envoy. Istiod, as a unified component of the control plane, is responsible for interfacing with the capabilities of service registration discovery, routing rule management, certificate management, etc. Envoy, as a data plane, proxies business traffic through Sidecar. Istio and Envoy complete the transfer of service discovery, routing rules, and other data through XDS protocol interfaces. Istiod obtains service information by listening to K8S resources, such as Service and Endpoint, and distributes these resources to network agents on the data plane through the xDS protocol. Envoy is a process independent of the application. It runs with the business application Pod in the Sidecar mode (generally Container mode). It shares the same host network with the application process and hijacks the network traffic of the business application by modifying the routing table.

See the xDS REST and gRPC protocol document for the xDS protocol interface [1]

With the expansion of cluster size and the growth of business complexity, the container choreography scheme based on native K8S will be difficult to cope with, and developers have to face huge service governance challenges. Service Mesh can solve this problem well. It encapsulates the service governance capability in the control plane and proxy. Business developers only need to focus on the business logic itself. After application deployment, only the operation and maintenance personnel need to modify the configuration to achieve many service governance capabilities, such as fault recovery, load balancing, grayscale publishing, etc., which greatly improves the efficiency of R&D and iteration.

Istio's Sidecar accompanies the entire life cycle of the business application process in the form of container injection. It is non-invasive for business applications, which solves the problems of business application migration, multilingual, infrastructure coupling, etc. But it also brings about the problems of high resource consumption and request delay growth. Considering the disadvantages of Sidecar, we can consider using the SDK to support the data plane instead of Sidecar. Then the Proxyless Mesh architecture is introduced.

Proxyless Service-Mesh

What is Proxyless Service Mesh? This is a new concept put forward in recent years. Open source communities such as isito, gRPC and brpc have explored and practiced in this direction. The agentless service grid framework is introduced by business applications in the form of SDK and is responsible for communication and governance between services.

GRPC Proxyless architecture

At present, the gRPC project provides some support for the xDS API protocol, that is, we can manage gRPC services through the isio, and we do not need to deploy the Envoy sidecar.

As shown in the figure above, the gRPC Proxyless mode requires the Istio Agent to initialize and communicate with the control surface. First, the Istio Agent generates a boot file at startup, which is the same way as generating a boot file for Envoy. It is used to tell the gRPC library how to connect to the inventory, where to find the certificate for data plane communication, and what metadata to send to the control plane. Next, the Istio Agent, as an xDS proxy, connects and authenticates with the history on behalf of the application. Finally, the Istio Agent acquires and rotates the certificates used in data plane communication.

See the gRPC Proxyless Mesh document [2] for details

On the Advantages and Disadvantages of Proxyless Architecture

Briefly sort out some advantages and disadvantages of Proxyless Mesh architecture

Advantages of Proxyless Mesh:

• Performance: The network call in agentless mode is a point-to-point direct communication, and the network delay will be much smaller than that in proxy mode.

• Stability: Proxyless is a single process model with simple topology, easy debugging and high stability.

• Cost: No sidecar, low resource consumption.

• Framework integration: There are many service frameworks in SDK mode on the market. After switching to Mesh, the original capabilities of the framework can still be reused

Disadvantages of Proxyless Mesh:

• Framework and language binding: SDKs of multiple languages and frameworks need to be developed to support Proxyless Mesh. At present, many frameworks on the market do not support Proxyless Mesh.

• Low portability: It is impossible to upgrade the infrastructure non invasively by switching Sidecar, and the code needs to be modified for upgrading and maintenance.

The advantages of Proxyless architecture are obvious. Especially for large-scale business scenarios, it can save a lot of machine resources and additional maintenance costs. However, the disadvantages are also very obvious. Once we need to upgrade the Proxyless SDK, we need to upgrade the SDK, modify the code, and upgrade the framework version.

How does MSE solve the problem that customers need to face with Proxyless Mesh

We have adopted a strategy to implement the xDS protocol through JavaAgent. In this way, the Spring Cloud can access the Mesh ecosystem by accessing the JavaAgent and support the routing rules configured by the istio. The JavaAgent pulls the address list of other services from the istiod through the xDS protocol and converts it to the ServerList of the Spring Cloud load balancing Ribbon for a collection and consolidation of address lists. In this way, native Spring Cloud applications can support the Proxyless Mesh mode without modifying a line of code, and are also compatible with the service discovery of the original Nacos system.

On the other hand, compared with Envoy, Java Agent can also provide more governance capabilities for Java applications, such as service contracts, interface information, database traffic governance, JVM monitoring and governance, etc.

Non intrusive upgrade of Spring Cloud applications to Proxyless Mesh architecture

Let's use a simple practical example to experience how the Spring Cloud application can be upgraded to the Proxyless Mesh architecture without invasion.

Demo: How to realize the interworking between Spring Cloud applications and multilingual microservices of Service Mesh architecture?

Prerequisite

Enable MSE service governance capabilities, and create an AliCloud ASM Istio instance for the current K8s cluster.

Step 1: Deploy Spring Cloud services and multilingual services.

We need to deploy Spring Cloud applications and multilingual Go applications

Demo application examples can be obtained from the following documents [3]

The Spring Cloud application calls multilingual services in the same way as other Spring Cloud applications call each other. For example, the A interface for calling Spring Cloud services (application name is go sc-a) through the restTemplate tool is as follows:

restTemplate.getForObject(" http://go-sc-a/A ", String.class)

You can also use other methods to call it. You do not need the port number of the corresponding service to directly access it.

Step 2: Enable MSE Agent to support the xDS protocol by configuring environment variables

We need to add the following environment variables to enable the MSE Agent to support the xDS protocol

Step 3: Result verification

The Spring Cloud service and the multilingual service of the service grid can realize interoperability, and the method of calling multilingual service by Spring Cloud service does not need to modify any code.

• Spring Cloud service accesses multilingual services:

Summary

This article uses a Demo to demonstrate that after the Spring Cloud application accesses MSE service governance, it can have the Proxyless Mesh capability without modifying any code. Currently, MSE service governance support has some limitations, which are being continuously supplemented and improved. The current MSE service governance proxy mode supports the basic service discovery capability and the subset capability of DestinationRule. We can cooperate with MSE traffic governance to achieve the full link grayscale, label routing and other governance capabilities under the Mesh architecture.

In addition, it is worth mentioning that we are working with CloudWeGo, Kratos, Spring Cloud Alibaba, Dubbo, ShardingSphere, Database Mesh and other communities to build OpenSergo microservice governance standards. We hope to extract the microservice governance scenarios and best practices in enterprises and communities into standard specifications.

We welcome more communities and enterprises to participate in the co construction of the OpenSergo microservice governance standard. The OpenSergo community is now in a rapid development stage. From the definition of the microservice governance standard to the implementation of the Control Plane, to the implementation of Java/Go/C++/Rust and other multilingual SDKs and governance functions, to the integration and implementation of various microservice ecosystems, there is still a lot of evolution work, The community is welcome to participate in standard improvement and code contribution.