How to seamlessly transition from traditional microservice framework to service grid ASM

Background

The history of software technology has evolved from individual applications to distributed applications, especially the rise of the concept of microservices, making large-scale, highly concurrent, and low-latency distributed applications possible. In the cloud native era, the microservice framework itself is also continuously evolving and iteratively evolving.

The microservice framework generally involves the following knowledge points:

In this article, we focus on the following three micro service frameworks:

• SpringCloud

• Dubbo

• ServiceMesh (new generation)

The three different frameworks differ in their weak coverage of functional points in the field of service governance. This article does not focus on discussing the advantages and disadvantages of these frameworks, but mainly discusses how to seamlessly transition from the traditional microservice frameworks Dubbo and SpringCloud to the ServiceMesh architecture. Istio is the hottest project in the current ServiceMesh field.

Alibaba Cloud Service Grid ASM is based on Istio, which provides cloud hosting and adaptation for Istio, and adds related functions, as well as performance optimization in large-scale service grid scenarios. As the industry's first fully hosted Istio compatible Alibaba Cloud service grid product, ASM has been architecturally consistent with community and industry trends from the beginning. The components of the control plane are hosted on the Alibaba Cloud side, independent of the user clusters on the data side. ASM products are customized and implemented based on community Istio, providing component capabilities to support refined traffic management and security management on the managed control surface side. The managed mode decouples the lifecycle management of Istio components and the managed K8s cluster, making the architecture more flexible and improving the scalability of the system. From April 1, 2022, Alibaba Cloud Service Grid ASM officially launched a commercial version, providing richer capabilities, larger scale support, and more complete technical support to better meet customers' different demand scenarios. For details, see the product introduction:

https://www.aliyun.com/product/servicemesh

Let's take a look at the known issues with migrating traditional microservices to the service grid technology stack, and how Alibaba Cloud Service Grid ASM seamlessly supports Spring Cloud and Dubbo services.

Follow the [Alibaba Cloud Native] official account and reply to the keyword [0621] to get the download address of the code compression package in the article!

Some known issues and scenarios for migrating traditional microservices to service grids

Common Problems

After the service is containerized, the service deployment is updated in a rolling manner. The IP of the service instance changes frequently, and there will be a delay in synchronizing the corresponding service instance IP to the registry. This process can cause 503 service requests.

• The Istio community version has limited support for other rpc protocols other than HTTP and gRPC, and cannot provide a unified form of routing management and related governance capabilities.

• Due to the service routing model designed by Istio itself, which relies on inter service requests being ServiceName or ClusterIp, the SpringCloud service cannot be meshed directly. Due to the interface based service invocation design, the Dubbo service has interfaces that are passed in the context of Dubbo protocol requests. Although not limited by this mode, the support for Dubbo routing in the Istio community version does not have corresponding RDS support, Dubbo routing cannot be configured directly with the community version of VirtualService.

In addition to the above common issues, there are also specific business scenarios that are often encountered during the business cloud virtualization process.

Scenario 1: How to interwork services inside and outside a container cluster

• Partial business containerization and migration to Kubernetes cluster

• There are still some legacy services that need to be deployed on ECS virtual machines

Through ASM docking with the registry, service interoperability within and outside the container cluster can be achieved, and service governance capabilities can be preserved. In addition, container business services are managed through ASM services grid, which sinks service governance capabilities to Sidecar, facilitating businesses to quickly obtain declarative configurations brought by Istio, perform service governance and orchestration capabilities such as traffic management and grayscale publishing, and naturally acquire three observable capabilities for interfacing with Trace, Log, and Metrics.

Scenario 2: Multilingual service interworking

With the arrival of the wave of cloud computing, businesses are generally more complex and diverse. Many customers have adopted multiple languages or even multiple development frameworks due to business development needs. How can different language services be interconnected, or is there a unified service framework to manage these multilingual services?

The ASM service grid has expanded its functionality based on the Istio community version to support seamless migration of Spring Cloud and Dubbo services to the service grid, which means that businesses can naturally enjoy the capabilities provided by the service grid without any code modifications. Below, we will provide specific analysis and explanation for Spring Cloud and Dubbo respectively.

Managing Spring Cloud Services

Spring Cloud service communication uses the HTTP protocol, and Istio's support for the HTTP protocol is very friendly. We only need to solve the problem of how Istio manages Spring Cloud services, that is, how to adapt Spring Cloud service requests to Istio's dependent Servicename or ClusterIp.

Simply put, because the service grid adopts the Sidecar mode, it needs to know who the target service is for the traffic sent by the request, and this information needs to be declared in the Host field of the Http request.

Option 1: Adopt the EnvoyFilter+Lua method

The core implementation is to modify the return of service subscription requests by configuring a section of Lua logic under the EnvoyFilter, and modify the target IP address returned by the service subscription to the corresponding service name. For specific demo examples, please refer to the ASM Help documentation:

https://help.aliyun.com/document_detail/383257.html

However, due to the need to understand specific service subscription agreements, this solution currently only supports Nacos and does not support other non Nacos registries. Although we provide some service registry migration solutions, users may not want to modify the code to adapt to the registry center due to various reasons. Based on this, we provide Scheme 2 that can be adapted to support any registry.

Scenario 2: Obtain ServiceName through Reverse DNS Filter reverse lookup

Solution 1 currently only supports Nacos, and many users have feedback on whether they can support service registration centers such as Eureka and ZooKeeper. Based on this, we have introduced the following general solutions:

Btw, because Istio naturally supports the gRPC protocol, while Dubbo3's new protocol, Triple, is based on gRPC. Dubbo3 services can gracefully upload Mesh,

The above scheme is also applicable to Dubbo3 services.

Summary: Through the above two solutions (Scheme 2 is recommended), we have solved the problem of Spring Cloud services adapting to the Istio routing model. From then on, Spring Cloud can enjoy the full capabilities of Istio without any code modifications.

Of course, if the user is willing to modify the code, we recommend that the customer remove relevant annotations such as load balancing, fusing, and current limiting from the original Spring Cloud, because in the Mesh scenario, the original capabilities are no longer necessary.

Scheme 2 The ReverseDNS Filter scheme has been built into ASM version 1.13 and is expected to be released and launched at the end of June

Managing Dubbo Services

Here, when we talk about Dubbo services, we refer to Dubbo2. Dubbo3 can adopt similar solutions as above. We are also connecting to the Dubbo3 community and supporting the Dubbo3 Proxyless Mesh mode. Currently, Dubbo2 still has a large number of users, so Alibaba Cloud Service Grid also provides in-depth support for Dubbo2. The Dubbo2 versions mentioned below are only Dubbo2 versions.

Most Dubbo users use the Nacos or ZooKeeper registry, and the ASM product level currently supports the MSE Nacos registry.

Simply associate an MSE Nacos instance under the ASM setup menu to discover the service information under the corresponding Nacos.

Support for Dubbo+Nacos service migration to ASM

The overall architecture diagram is as follows:

Related documents:

• Hosting Dubbo services

• Manage Dubbo service traffic

• Description of virtual service parameters for Dubbo service

• Integrate self-built Prometheus to achieve Dubbo service observability

ASM extends support for Dubbo routing based on the Istio community version of VirtualService. A more complex configuration example is as follows:

For specific Spec definitions and example descriptions of Dubbo routing, please refer to the above Dubbo service governance series documents

Support for Dubbo+ZooKeeper

For Dubbo open source users, in addition to Nacos, there are also many users who use the ZooKeeper registry. However, ZooKeeper currently does not officially provide support for Istio's service discovery capability, which is the MCP over XDS protocol that Istio relies on.

The MCPBridge component solves this problem. In the Alibaba Cloud service grid ASM scenario, the specific implementation scheme is as follows:

Due to the diversity of registration centers, the subsequent MCPBridge will be submitted to the open source community. We welcome everyone to join us for maintenance.

Users can manually install the MCPBridge to the ACK cluster where the business deployment is located by downloading the MCPBridge Helm installation package.

The installation method is simple. After downloading, extract the Helm installation package, and then execute it in the directory:

helm install -f values.yaml mcp-bridge .

After the installation is completed, the mcp-bridge will provide a VPC intranet address through the SLB, and it is necessary to associate the ConfigSource corresponding to Istide with this address. This feature of ASM is currently open on the whitelist, and it is necessary to raise a work order or contact product operation and maintenance personnel with groups at the end of the article.

After the installation is completed, we can then configure the upstream registry address to be ZooKeeper. If the environment does not have a ZooKeeper server available, we can quickly create one through Alibaba Cloud mse ZooKeeper, as follows:

Configuring an MCPBridge component with its associated registry is simple, just creating an MCPBridge CR. The specific configuration format is as follows:

After the kubectl apply - f zk-mcpbridge.yaml takes effect, the MCPBridge component will automatically synchronize the service information under the dubbo node under the ZooKeeper to the istiod.

If you want to experience specific examples of MCPBridge supporting Dubbo+ZK, you can download test samples.

The following package contains the above yaml configuration of McpBridge and an example of the dubbo demo service for testing.

Next, let's briefly explain how to use this Demo example.

After downloading and decompressing dubbo-zk-demo.tar.gz, we first need to modify the zk address "mse-7e74ff00-zk. mse. aliyuncs. com" under yaml to the actual corresponding zk service address (this address needs to ensure that the MCPBridge component can access it). After the address is modified, execute the following command in the dubbo-zk-demo file directory:

After successful startup, we will return to Zookeeper and see that the service registration information has been reported: (under the dubbo node)

Next, we will map the consumer service to the ASM gateway for test access. Through the ASM console, we can quickly create an ASM gateway. If using solutions such as CICD or GitOps, we can also directly create an IstioGateway Yaml.

After the gateway entity is successfully created (gateway deployment, svc, etc.), we also need to configure a logical gateway, which only requires two steps;

• Create a gateway rule (gateway CRD under istio), declare a logical gateway, and the specific domain name, declared port, and protocol type bound to this logical gateway (test gateway)

• Configure gateway routing to forward/sayHello requests to the dubbo-consumer-zk.dubbo.svc.cluster.local target service

Gateway rules and routing can refer to the following Yaml. We just need to save this Yaml as a local file, and then apply kubectl under the asm cluster.

After the gateway rules and routing configuration take effect, we can use browser or terminal commands to:

curl http://$INGRESS_ GATEWAY_ IP/sayHello/world to access the previously deployed Dubbo demo service, execute the following command, and you can see the relevant results after execution: The load balancing of the previous and subsequent requests has reached the v1 and v2 versions of the provider.

For more traffic management, grayscale publishing, and observable examples, please refer to the relevant documents on Istio and Dubbo service governance under ASM for configuration.

Summary

For traditional microservice frameworks such as SpringCloud and Dubbo, Alibaba Cloud Service Grid ASM provides expanded support based on Istio for customers' commonly used scenario needs and problems. It can seamlessly manage SpringCloud and Dubbo services and provide Istio's native service governance capabilities.

Alibaba Cloud Service Grid ASM, as a pioneer in the managed service grid, has received a large number of users, who have strengthened our confidence in making this product. The service grid is no longer a stack of buzzwords, but is actually applied to the production environment to handle one technical issue after another in the field of service governance. Returning to the essence, the service grid still needs to solve real business problems.