Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Exploration and Practice of Proxyless Mesh for Spring Cloud Applications

Exploration and Practice of Proxyless Mesh for Spring Cloud Applications

This article uses a Demo to demonstrate how the SpringCloud application can support Proxyless Mesh without modifying any code when connected to the MSE service governance.

By Shimian

An Introduction to Service Mesh

Service Mesh is no longer an emerging concept, and there have been 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, the first Service Mesh project in the industry. Later in 2016, Lyft released Envoy, the second Service Mesh project.
  • In 2017, Google, IBM, and Lyft jointly released Istio. Compared with projects (such as Linkerd and Envoy), it introduces the concept of the control plane and provides powerful traffic control capabilities. After years of development, Istio has gradually become the de facto standard for the control plane.
  • The advent of version 1.0 marks the beginning of the era when Istio can be available in production. More companies are applying service mesh to production.
  • Version 1.5 integrated multiple original components into a single structure istiod. At the same time, the long-criticized Mixer component was discarded and unified as Istiod to facilitate deployment and O&M.

Currently, Istio is the most popular open-source service mesh, which consists of a control plane and a data plane.

1

In the Istio Mesh architecture, the control plane is a process named Istiod, and the network proxy is Envoy. As a unified component of the control panel, Istio is used to integrate capabilities (such as service registration and discovery, routing rule management, and certificate management). Envoy acts as the data plane to proxy business traffic in Sidecar mode. Data (such as service discovery and routing rules) are transmitted between Istio and Envoy through xDS protocol interfaces. Istiod monitors Kubernetes resources (such as Services and Endpoints) to obtain service information and sends these resources to the network proxy on the data plane through the xDS protocol. Envoy is a process that is independent of an application. It runs along with the application Pods in Sidecar mode (commonly in the Container mode). It shares the same host network with the application process and hijacks the network traffic of the application by modifying the routing table.

Please see xDS REST and gRPC protocol Document[1] for more information about the xDS protocol interface.

With the increase in cluster size and business complexity, it is difficult for the container orchestration solution based on the native Kubernetes to cope with the business requirements, and developers have to face huge service governance challenges. Service Mesh can solve this problem. It encapsulates the service governance capabilities in the control plane and proxy, and business developers only need to focus on the business logic. After the application is deployed, O&M personnel only need to modify the configuration to implement many service governance capabilities (such as fault recovery, load balancing, and grayscale release). This significantly improves the R&D and iteration efficiency.

The Sidecar of Istio accompanies the entire lifecycle of business application processes through container injection. It is non-intrusive to business applications. This solves the problems of business application migration, multi-language, and infrastructure coupling. However, this brings problems (such as high resource consumption and increased request latency). Considering the disadvantages of Sidecar, we can consider using SDK to replace Sidecar to support the data plane, which leads to the architecture of Proxyless Mesh.

Proxyless Service-Mesh

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

2

gRPC Proxyless Architecture

Currently, the gRPC project provides certain support for the xDS API protocol, which means we can manage gRPC services through Istio without deploying the Envoy sidecar.

3

As shown in the preceding figure, the gRPC Proxyless mode requires the Istio Agent to initialize and communicate with the control panel. First, the Istio Agent generates a boot file at startup, which is the same way the boot file is generated for Envoy. It is used to tell the gRPC library how to connect to istiod, where to find the certificate for data panel communication, and what metadata to send to the control panel. Next, the Istio Agent acts as an xDS proxy to connect and authenticate with istiod on behalf of the application. Finally, the Istio Agent obtains and rotates the certificate used in data plane communication.

Please see gRPC Proxyless Mesh Document[2] for details.

Advantages and Disadvantages of Proxyless Architecture

This section briefly introduces some advantages and disadvantages of Proxyless Mesh architecture.

Advantages of Proxyless Mesh

  • Performance: The network call in the Proxyless mode is a point-to-point direct communication, and the network latency is much smaller than in the proxy mode.
  • Stability: The Proxyless mode is single-process with a simple topology, easy to debug, and highly stable.
  • Cost: No sidecar and 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: It is necessary to develop SDKs in multiple languages and frameworks to support Proxyless Mesh. Currently, many frameworks on the market do not support Proxyless Mesh.
  • Low Portability: You cannot switch to Sidecar to non-intrusively upgrade the infrastructure. You need to modify the code for upgrade and maintenance.

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

How Does MSE Address the Shortcomings of Proxyless Mesh?

We adopted a strategy to implement the xDS protocol through JavaAgent. As such, Spring Cloud can access the Mesh ecosystem through JavaAgent and support the routing rules configured by Istio. JavaAgent pulls the address lists of other services from istiod through the xDS protocol and converts them into the ServerList of Spring Cloud Load Balancer Ribbon for a collection of address lists. This way, native Spring Cloud applications can support the Proxyless Mesh mode without modifying code and are compatible with the service discovery of the original Nacos system.

4

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

Non-Intrusive Upgrade of Spring Cloud Applications to Proxyless Mesh Architecture

Let's use a simple practical example to experience how to non-intrusively upgrade Spring Cloud applications to the Proxyless Mesh architecture.

Demo: How can we implement intercommunication between Spring Cloud applications and the multi-language microservices of Service Mesh architecture?

5

Prerequisites

Enable the governance capability of MSE and create an ASM Istio instance for the Kubernetes cluster.

Step One: Deploy Spring Cloud Services and Multi-Language Services

We need to deploy Spring Cloud applications and multi-language Go applications.

Please see the following documentation[3] for an example of the demo application.

Spring Cloud applications call multi-language services the same way other Spring Cloud applications call each other. For example, the A interface that calls the Spring Cloud service (the application name is go-sc-a) using restTemplate is listed below:

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

You can use other methods to call the service. You can directly access the service without using the port number of the service.

Step Two: Enable the Capability of the 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:

Type Variable Name Variable/Variable Reference Description
Custom profile.micro.service.envoy.xds.enable true Enable MSE service governance to support the xDS protocol

Step Three: Result Verification

Spring Cloud services can interoperate with the multi-language service of Service Mesh. The way the Spring Cloud service calls the multi-language services does not require any code changes.

  • Spring Cloud services access multi-language services:
~ curl localhost:20003/go
[Java Spring Cloud ] -> [Service Mesh APP10.191.XX.XX ]
  • Multi-language services call Spring Cloud services:
~ curl localhost:8085/java
[ Service Mesh APP ] -> [Java Spring Cloud10.191.XX.XX]

Summary

This article uses a Demo to demonstrate how the SpringCloud application can support Proxyless Mesh without modifying any code when connected to the MSE service governance. Currently, the support for MSE service governance has some limitations, which are being improved. The Proxyless mode of MSE service governance supports basic service discovery and the Subset capability of DestinationRule. You can use MSE traffic governance to implement end-to-end canary release, label-based routing, and other governance capabilities in the Mesh architecture.

It is also 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 summarize the scenarios and best practices of microservice governance in enterprises and communities into standards and specifications.

We welcome more communities and enterprises to participate in the co-construction of OpenSergo microservice governance standards. The OpenSergo community is now in a high-speed development stage. There is still a lot of evolution work, including defining microservice governance standards, implementing Control Plane, implementing multi-language SDK and governance functions (such as Java, Go, C++, and Rust), and integrating and implementing various microservice ecosystems. You are welcome to participate in the standard improvement and code contribution.

The OpenSergo open-source contribution group is recruiting contributors. If you have time, enthusiasm, and willingness, please contact the community to join the open-source contribution group. Let's work together to improve OpenSergo and Sentinel and lead the evolution of microservice governance technologies and standards.

Related Links

[1] https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol

[2] https://istio.io/latest/blog/2021/proxyless-grpc/

[3] https://www.alibabacloud.com/help/en/microservices-engine/latest/best-practices-2

spring Architecture Cloud Computing Computing Istio Spring Cloud Service Mesh gRPC Istio Mesh MSE Proxyless Mesh
0 1 0
Share on

Read previous post:

Higress Practice: Use 30 Lines of Code to Write a Wasm Go Plugin

Read next post:

Best Practices for Prometheus Monitoring RocketMQ

Alibaba Cloud Native Community

481 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

481 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All