The Seamless Transition from Traditional Microservice Frameworks to ASM

By Yuzeng

Background

The development of software technology has evolved from single applications to distributed applications. The rise of the concept of microservices makes large-scale, high-concurrency, and low-latency distributed applications possible. The microservice framework is constantly evolving in the cloud-native era.

The microservice framework generally involves the following points:

This article focuses on the following three microservice frameworks:

SpringCloud
Dubbo
Service Mesh (New Generation)

These three different frameworks have different coverage of functions in the field of service governance. This article does not focus on the advantages and disadvantages of these frameworks. It mainly discusses the seamless transition from the traditional microservice frameworks Dubbo and SpringCloud to Service Mesh architecture. Currently, Istio is the hottest project in the Service Mesh field.

Based on Istio, ASM has managed and adapted Istio on the cloud, added features, and optimized performance in large-scale service mesh scenarios. As the industry's first fully managed Istio-compatible service mesh product, ASM has maintained consistency with the community and industry trends from the beginning in terms of architecture. The components of the control panel are hosted on the Alibaba Cloud side and are independent of the user clusters on the data side. ASM products are customized based on community Istio. They provide component capabilities to support refined traffic management and security management on the managed control panel side. The managed mode decouples the Istio components and the lifecycle management of Kubernetes clusters, making the architecture flexible and improving system scalability. ASM officially launched a commercial version on April 1, 2022. The new version provides richer capabilities, larger-scale support, and more complete technical assurance to meet different customer requirements better. Please see the Service Mesh product introduction for more information.

Let's take a look at the known issues when traditional microservices are migrated to service mesh technology stacks and how ASM seamlessly supports SpringCloud and Dubbo services.

Known Issues and Scenarios of Migrating Traditional Microservices to Service Mesh

Common Issues

After the service is containerized, the service deployment is updated in a rolling manner. The IP of the service instance changes frequently. There will be a delay in synchronizing the IP of the corresponding service instance to the registry. This process will cause some service requests to be 503.
The Istio community version has limited support for other RPC protocols that are not HTTP or gRPC and cannot provide unified routing management and related governance capabilities.
As the service routing model designed by Istio itself depends on the inter-service request being ServiceName or ClusterIp, SpringCloud service cannot be Meshed directly. Interface is passed in the context of Dubbo protocol request since Dubbo service is based on the service call design. It is not limited by this mode, but the Istio community version does not have corresponding RDS support for Dubbo routing. Dubbo routing cannot be directly configured by the community version VirtualService.

In addition to the common problems above, some specific business scenarios are often encountered in the process of business cloud-native.

Scenario 1: How Do Internal and External Services in a Container Cluster Communicate with Each Other?

Some businesses are containerized and migrated to Kubernetes clusters.
There are still some services that need to be deployed in the ECS cloud host.

You can use ASM to connect to the registry. This allows you to interconnect services within and outside the container cluster and retain service governance capabilities. In addition, containerized business services are managed through ASM, and service governance capabilities are sunk to Sidecar. This allows the business to obtain declarative configurations brought by Istio quickly and perform service governance and orchestration capabilities (such as traffic management and gray release). At the same time, it naturally obtains the observable capabilities of trace, log, and metrics.

Scenario 2: Multi-Language Business Interoperability

With the advent of cloud-native, businesses are more complex and diverse. Many customers have adopted multi-language or 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 multi-language services?

ASM pays attention to the preceding related scenarios and common issues and is extended based on the Istio community version. It can support seamless migration of SpringCloud and Dubbo services to service mesh. This means businesses can enjoy the capabilities provided by service mesh without any code modification. The following section gives specific descriptions for SpringCloud and Dubbo.

Manage SpringCloud Services

SpringCloud service communication uses HTTP protocol. Istio supports the HTTP protocol. We only need to solve how Istio manages SpringCloud services, which means how to adapt SpringCloud service requests to Servicename or ClusterIp dependent on Istio.

Since the service mesh uses the Sidecar mode, you need to know who is the traffic target service sent by the request. This information needs to be declared under the Host field of the Http request.

Solution 1: Use EnvoyFilter + Lua

The core implementation is to modify the return of a service subscription request using the Lua logic configured in EnvoyFilter and change the target IP address returned by the service subscription to the corresponding service name. Please refer to the ASM help document for specific Demo examples.

However, this solution only supports Nacos since it needs to understand the specific service subscription agreement. We have provided some solutions for the migration of service registries, but users may not want to modify the code to adapt to the registries due to various reasons. Based on this, we provide Solution 2, which can be adapted to support any registry.

Solution 2: Obtain the ServiceName by Reverse DNS Filter Reverse Searching

Solution 1 can only support Nacos at the moment. Many users give feedback on whether it can support registries (such as Eureka and ZooKeeper). Based on this, we have launched the following general solutions:

As Istio naturally supports the gRPC protocol, the new version of Dubbo3 protocol triple is based on gRPC, andDubbo3 services can migrate to Mesh well.

The solution above also applies to Dubbo3 services.

Summary

We have solved the adaptation problem of SpringCloud services to the Istio routing model through the two solutions above (Solution 2 is recommended). From then on, SpringCloud can enjoy the full Istio capability without any code modification.

If the user is willing to modify the code, we recommend that the customer remove the relevant annotations (such as SLB, fusing, and throttling under the original SpringCloud). In the Mesh scenario, the original capability is no longer necessary.

The ReverseDNS Filter solution (Solution 2) is built in ASM 1.13.

Manage Dubbo Services

The Dubbo service here refers to Dubbo2. Dubbo3 can use a similar solution to the one above. We are also connecting with the Dubbo3 community and supporting Dubbo3 Proxyless Mesh mode. Currently, Dubbo2 still has a large number of users. Therefore, ASM also provides deep support for Dubbo. The Dubbo2 versions are mentioned below.

Dubbo users mostly use the Nacos or ZooKeeper registry. ASM products currently support the MSE Nacos registry.

You only need to associate the MSE Nacos instance under the ASM Settings menu to discover the service information under the corresponding Nacos.

Support for Migrating Dubbo + Nacos Services to ASM

The overall architecture diagram is shown below:

Support Dubbo + ZooKeeper

Dubbo open-source users use the ZooKeeper registry in addition to Nacos. However, ZooKeeper currently does not provide support for Istio service discovery capabilities (Istio-dependent MCP over XDS protocols).

The MCPBridge component solves this problem. In the ASM scenario, the specific implementation solution is shown below:

Due to the diversity of registries, MCPBridge will be submitted to the open-source community in the future.

You can download the Helm installation package of MCPBridge and manually install MCPBridge to the ACK cluster where your business is deployed.

Decompress the Helm installation package and run it in the directory:

helm install -f values.yaml mcp-bridge .

After the installation is complete, the mcp-bridge provides a VPC internal endpoint through SLB. You need to associate the ConfigSource corresponding to Istiod with this endpoint. This feature of ASM is currently available on the whitelist. You need to submit a ticket or add a group at the end of the article to contact product O&M personnel.

After the installation is completed, we can configure the upstream registry address as ZooKeeper. If there is no available ZooKeeper server in the environment, you can use Alibaba Cloud MSE ZooKeeper to create one quickly:

It is simple to configure the associated registry for the MCPBridge component. You only need to create an MCPBridge CR. The specific configuration format is listed below:

file: zk-mcpbridge.yaml

apiVersion: istio.aliyun.cloud.com/v1
kind: McpBridge
metadata:
  name: default
  namespace: istio-system
spec:
  registries:
  - domain: mse-7e74ff00-zk.mse.aliyuncs.com   ### zookeeper address
    name: zookeeper
    port: 2181
    type: zookeeper

After the kubectl apply -f zk-mcpbridge.yaml takes effect, the MCPBridge component automatically synchronizes the service information of the Dubbo node under ZooKeeper to istiod.

If you want to experience the specific example that MCPBridge supports Dubbo + ZK, you can download the test example: dubbo-zk-demo.tar.gz

The package contains the McpBridge yaml configuration above and the dubbo demo service example for testing:

root@service-mesh-test011122063081:~/test/mcpbridge/dubbo-zk-demo# tree .
.
├── dubbo-services.yaml                    ## dubbo + zk registry test service example
├── zk-mcpbridge.yaml                      ## mcpbridge zk configuration, you need to modify the zk address accordingly.
└── zk-registry-service-alias.yaml         ## The service alias of the zk address. You need to modify the zk address.

Next, let's briefly explain how to use this demo example:

After the dubbo-zk-demo.tar.gz is downloaded and decompressed, we need to change the zk address (mse-7e74ff00-zk.mse.aliyuncs.com) under yaml to the actual corresponding zk service address. (This address needs to be accessible to the MCPBridge component.) After the address is modified, run the following command in the dubbo-zk-demo file directory:

kubectl create ns dubbo 
kubectl label ns dubbo istio-injection=enabled
kubectl apply -f .

Then, run the command kubectl get pods -n dubbo to check whether the consumer and provider of the corresponding dubbo service are started:

root@service-mesh-test011122063081:~/test/mcpbridge# kubectl get pods -n dubbo
NAME                                    READY   STATUS    RESTARTS   AGE
dubbo-consumer-zk-5cd8f6c6bf-bscd2      2/2     Running   0          83m
dubbo-provider-zk-v1-54cd888957-k7bg4   2/2     Running   0          83m
dubbo-provider-zk-v2-cf58ccc79-sg94l    2/2     Running   0          83m

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

Then, we map the consumer service to an ASM gateway for test access. You can quickly create an ASM gateway in the ASM console. If you use CICD or GitOps, you can also create an ASM gateway by creating IstioGateway YAML:

After the gateway entity (gateway deployment, svc, etc.) is created, you need to configure a logical gateway, which only needs 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 a gateway route to send/sayHello requests to the dubbo-consumer-zk.dubbo.svc.cluster.local target service

You can refer to the following YAML for gateway rules and gateway routes. You only need to keep this YAML file and apply it to kubectl in the ASM cluster.

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: test-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: consumerhttp
spec:
  hosts:
  - "*"
  gateways:
  - test-gateway
  http:
  - match:
    - uri:
        prefix: /sayHello
    route:
    - destination:
        host: dubbo-consumer-zk.dubbo.svc.cluster.local ## The Kubernetes service name of the consumer service.
        port:
          number: 17080

After the gateway rules and route configurations take effect, we can use the browser or terminal command:

Use curl http:// $INGRESS_GATEWAY_IP/sayHello/world to access the previously deployed Dubbo demo service. Run the following command to see the relevant output results after the execution: the request was load balanced to the Provider's v1 and v2 versions twice.

#export INGRESS_GATEWAY_IP=YOUR_GATEWAY_IP
 
 #curl http://$INGRESS_GATEWAY_IP/sayHello/world
 
 V2 Gray1: hello world - 172.22.32.143:20880
 
 #curl http://$INGRESS_GATEWAY_IP/sayHello/world
 
 V1 Gray1: hello world - 172.22.32.39:20880

Summary

For traditional microservice frameworks (such as SpringCloud and Dubbo), ASM provides extended support based on Istio to meet the requirements of customers in common scenarios. It can seamlessly manage SpringCloud and Dubbo services and provide service governance capabilities in the native form of Istio.

Community

The Seamless Transition from Traditional Microservice Frameworks to ASM

Background

Known Issues and Scenarios of Migrating Traditional Microservices to Service Mesh

Common Issues

Scenario 1: How Do Internal and External Services in a Container Cluster Communicate with Each Other?

Scenario 2: Multi-Language Business Interoperability

Manage SpringCloud Services

Solution 1: Use EnvoyFilter + Lua

Solution 2: Obtain the ServiceName by Reverse DNS Filter Reverse Searching

Summary

Manage Dubbo Services

Support for Migrating Dubbo + Nacos Services to ASM

Support Dubbo + ZooKeeper

Summary

Read previous post:

Read next post:

Alibaba Cloud Native

You may also like

Comments

Alibaba Cloud Native

Related Products

Cloud-Native Applications Management Solution

Function Compute

Container Service for Kubernetes

Microservices Engine (MSE)