Migrating Dubbo 3.0 to Istio Service Mesh: A Step‑by‑Step Cloud‑Native Guide

Background

Using Dubbo 3.0 framework for microservice development, the cloud‑native wave prompts migration of Dubbo 3.0 services to an Istio service mesh for traffic management.

Solution Overview

Refactor Dubbo 3 code, mainly service discovery configuration.

Deploy Dubbo 3 applications to Kubernetes.

Enable Istio automatic sidecar injection of Envoy containers to intercept traffic and configure Istio traffic‑management policies.

Dubbo 3 Code Adaptation

Modify dubbo.properties . Ensure dubbo.application.name matches the corresponding Kubernetes service name.

Update service annotations. On the client side, explicitly call the provider with providerBy="xxx" , where xxx is the server’s Kubernetes service name.

Practical Steps

Prepare the basic runtime environment: deploy Kubernetes and Istio.

Create a namespace and enable sidecar automatic injection.

apiVersion: v1
kind: Namespace
metadata:
  name: dubbo-demo
  labels:
    istio-injection: enabled

Deploy the Dubbo provider. Provider starts normally; logs show successful registration.

Deployment manifest (v1):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dubbo-samples-mesh-provider-v1
  namespace: dubbo-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dubbo-samples-mesh-provider
      version: v1
  template:
    metadata:
      labels:
        app: dubbo-samples-mesh-provider
        version: v1
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
    spec:
      containers:
        - name: server
          image: apache/dubbo-demo:dubbo-samples-mesh-provider-v1_0.0.1
          imagePullPolicy: Always
          ports:
            - name: grpc-tri
              containerPort: 50052
              protocol: TCP
            - name: http-health
              containerPort: 22222
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /live
              port: http-health
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 1
          readinessProbe:
            httpGet:
              path: /ready
              port: http-health
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
          startupProbe:
            httpGet:
              path: /startup
              port: http-health
            failureThreshold: 30
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 2

Deployment manifest (v2) follows the same pattern with version v2:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dubbo-samples-mesh-provider-v2
  namespace: dubbo-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dubbo-samples-mesh-provider
      version: v2
  template:
    metadata:
      labels:
        app: dubbo-samples-mesh-provider
        version: v2
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
    spec:
      containers:
        - name: server
          image: apache/dubbo-demo:dubbo-samples-mesh-provider-v2_0.0.1
          imagePullPolicy: Always
          ports:
            - name: grpc-tri
              containerPort: 50052
              protocol: TCP
            - name: http-health
              containerPort: 22222
              protocol: TCP
          # probes omitted for brevity

Service definition (port name must start with grpc for Istio protocol detection):

apiVersion: v1
kind: Service
metadata:
  name: dubbo-samples-mesh-provider
  namespace: dubbo-demo
spec:
  type: ClusterIP
  selector:
    app: dubbo-samples-mesh-provider
  ports:
    - name: grpc-tri
      port: 50052
      targetPort: 50052

Deploy the Dubbo consumer. Consumer runs normally; logs show traffic handled by Envoy sidecar.

Consumer deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dubbo-samples-mesh-consumer
  namespace: dubbo-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dubbo-samples-mesh-consumer
      version: v1
  template:
    metadata:
      labels:
        app: dubbo-samples-mesh-consumer
        version: v1
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
    spec:
      containers:
        - name: server
          image: apache/dubbo-demo:dubbo-samples-mesh-consumer_0.0.1
          imagePullPolicy: Always
          ports:
            - name: grpc-tri
              containerPort: 50052
              protocol: TCP
            - name: http-health
              containerPort: 22222
              protocol: TCP
          env:
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          # probes omitted for brevity

Consumer service:

apiVersion: v1
kind: Service
metadata:
  name: dubbo-samples-mesh-consumer
  namespace: dubbo-demo
spec:
  type: ClusterIP
  selector:
    app: dubbo-samples-mesh-consumer
  ports:
    - name: grpc-dubbo
      protocol: TCP
      port: 50052
      targetPort: 50052

Inspect Envoy sidecar logs for provider and consumer to verify inbound and outbound traffic handling.

kubectl logs -f -n dubbo-demo dubbo-samples-mesh-provider-v1-... -c istio-proxy

Logs show inbound traffic for the provider and outbound traffic for the consumer.

Create traffic‑management rules. A canary release directs 80 % of traffic to the old version and 20 % to the new version.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: dubbo-samples-mesh-provider
  namespace: dubbo-demo
spec:
  hosts:
    - dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
  http:
    - route:
        - destination:
            host: dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
            subset: v1
            port:
              number: 50052
          weight: 80
        - destination:
            host: dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
            subset: v2
            port:
              number: 50052
          weight: 20
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dubbo-samples-mesh-provider
  namespace: dubbo-demo
spec:
  host: dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Verify that consumer logs reflect the expected 8:2 traffic split, confirming the canary rule works.