从 Dubbo2 到 Dubbo3 Triple + Hessian2：低成本接入 Istio Service Mesh 的实践-散宜生的个人博客

1. 引言

在微服务体系中，Dubbo 一直是 Java 生态里最常见的 RPC 框架之一。
在过去的很长一段时间里，Dubbo2 采用自研的二进制协议，性能出色，但它与云原生的 Service Mesh 架构 之间存在天然的鸿沟。

随着企业逐渐向 Kubernetes + Istio 等云原生基础设施迁移，传统的 Dubbo2 协议暴露出以下问题：

在 Istio 看来，Dubbo2 流量只是 TCP 数据，无法识别请求级别的信息；
无法在 Mesh 中做流量治理（灰度、熔断、重试）；
Dubbo 的应用级注册模型与 Kubernetes Service 的 IP 级注册天然割裂；
观测性不足，链路追踪和染色能力无法在 Mesh 中生效。

因此，如何让 Dubbo 无缝融入 Istio Mesh，成为了很多团队在微服务演进过程中需要解决的关键问题。

迁移目标

本次实践的目标，就是将 Dubbo2 的 RPC 协议迁移到 Dubbo3 Triple + Hessian2 方案：

Triple 协议：基于 HTTP/2，与 gRPC 兼容，Istio 可识别；
Hessian2 序列化：兼容 Dubbo 生态，降低迁移成本；
应用级注册对齐 Kubernetes SVC：通过 ClusterIP 统一入口；
Mesh 流量治理：在东西向流量中引入 Envoy Sidecar，实现 Canary、熔断、链路追踪等能力。

这一方案的优势在于：

成本低：无需大规模改造 DTO，即可平滑迁移；
成果显著：Dubbo 流量立刻具备了 Mesh 的治理与观测能力；
可演进：未来可以逐步切换到 Protobuf，进一步提升性能与跨语言能力。

可以把这次迁移理解为：Dubbo 从一个“协议孤岛”迈向了云原生生态的第一步。

2. 问题与挑战

在谈迁移方案之前，我们需要先理解 为什么 Dubbo2 的传统 RPC 协议在 Service Mesh 场景中会遇到困难，以及迁移到 Dubbo3 Triple 协议能解决什么问题。

2.1 Dubbo2 协议的局限性

Dubbo2 长期以来使用的是自研二进制协议，这种协议在性能上具有优势，但存在以下问题：

非标准化：协议栈无法被 Envoy 等通用代理识别，导致流量无法透明接入到 Service Mesh。
TCP 粒度的通信：所有的请求都封装在 TCP 连接中，Istio 无法解读请求级别的细节。
扩展性受限：要接入跨语言、多协议的生态，需要额外的桥接组件（如 Dubbo Mesh、Sidecar Proxy），增加了复杂度。

换句话说，Dubbo2 的 RPC 调用属于“黑箱流量”，在 Istio 看来就是一堆 TCP 数据包，无法做路由、熔断、指标采集。

📌 示意图：Dubbo2 vs Istio 的脱节

flowchart LR A[Dubbo2 Consumer] -- TCP直连 --> B[Dubbo2 Provider] subgraph Istio Mesh C[Envoy Sidecar] end B -.无法解析.-> C

说明：Dubbo2 自研协议在 Envoy 看来只是 TCP，无法进行解析和治理。

2.2 Service Mesh 与 Istio 的需求

Istio 作为主流的 Service Mesh，依赖 Envoy 代理来实现统一的流量治理，它有几个关键特点：

协议感知：Envoy 原生支持 HTTP/1.1 和 HTTP/2（含 gRPC），可以做请求级路由。
统一治理：熔断、重试、超时、灰度发布等都依赖于对流量的识别。
零侵入：希望应用无需改造就能享受流量治理能力。

但是，如果应用层协议不是标准化的 HTTP/2/gRPC，Envoy 就无法解析，只能退化为 TCP 层的透传代理，治理能力几乎失效。

2.3 Dubbo 应用级注册 vs Kubernetes Service

Dubbo 的服务注册发现机制与 Kubernetes 的 Service 有天然差异：

Dubbo 的模型：注册的是“应用级服务”，Consumer 通过应用名找到 Provider 实例。
Kubernetes 的模型：通过 Service (ClusterIP/Headless) 做“IP 级别”的服务发现。

如果不加以处理，就会出现 两个注册中心并行但割裂 的情况：

Kubernetes DNS 解析走的是 Service 名称 → Pod IP；
Dubbo 注册中心走的是应用名称 → 实例 IP；

最终，Service Mesh 在 DNS/FQDN 层面治理，但 Dubbo 在应用层做直连，两者的逻辑不一致，容易产生“绕过 Mesh”的情况。

📌 示意图：注册模型割裂

说明：Dubbo 和 K8s 各自维护一份注册信息，可能出现不一致。

2.4 流量治理的盲区

在 Dubbo2 场景下，Consumer 与 Provider 之间是直连的：

Consumer 解析出 Provider 的 IP 地址，直接发起 TCP 连接；
Envoy Sidecar 即使存在，也可能因为 Headless Service 的场景而失效（Envoy 采用 ORIGINAL_DST 模式，只做透传）。

这意味着：

无法做流量染色（比如 Canary 流量分流）；
无法做请求级熔断与重试；
无法在链路追踪中精确标记调用路径。

2.5 序列化与协议选择的矛盾

很多团队在迁移 Dubbo3 时会面临一个问题：

Protobuf 是 Triple 协议的默认推荐序列化，但需要改造大量 DTO（数据对象），成本很高。
Hessian2 虽然性能稍逊，但兼容性更好，可以平滑迁移，不需要大改代码。

因此，选择 Triple + Hessian2 的组合，能在不大规模改造业务逻辑的前提下，把协议升级为 HTTP/2，从而无缝接入 Istio。

📌 小结：
Dubbo2 → Dubbo3 的迁移，本质上是为了解决 协议标准化 与 服务发现模型对齐 的问题，让 Istio 能够感知 Dubbo 流量，接管治理能力。

3. 技术选型与设计思路

在面对 Dubbo2 协议的局限性时，迁移到 Dubbo3 不仅是“升级依赖”这么简单，而是一个涉及 协议栈、服务注册模型、Mesh 接入方式 的整体方案。下面逐一展开。

3.1 Triple 协议：兼顾 Dubbo 生态与 Istio Mesh

Dubbo3 推出的 Triple 协议，设计上就是为了兼容 gRPC，同时与 Java 生态结合紧密：

基于 HTTP/2：天然契合 Istio/Envoy，对应的 cluster type 就是 EDS，能够做到请求级别的流量治理。
跨语言支持：Triple 可以通过 Protobuf 定义接口，从而和 gRPC 一样做到多语言互通。
向下兼容 Dubbo 语义：依然保留了 Dubbo 的服务接口模型，Java 开发者改造成本低。

如果直接迁移到原生 gRPC：

好处是和 Istio 完美配合，但需要大改 DTO 与序列化方式；
成本高，不适合一次性替换所有存量系统。

因此，Triple 是 Dubbo 体系与 Service Mesh 融合的“平衡点”。

3.2 Hessian2 序列化：兼容性优先

Triple 协议推荐使用 Protobuf，但在迁移场景下，Hessian2 更加务实：

零改造成本：沿用原有的 POJO，不需要重新生成 .proto 文件与代码。
Dubbo 原生支持：生态完善，适合老系统过渡。
性能足够：虽然序列化速度不如 Protobuf，但在多数业务场景下完全可接受。

可以理解为：

短期：Triple + Hessian2 → 平滑迁移，快速接入 Istio；

长期：Triple + Protobuf → 性能更优，跨语言场景更强。

3.3 Nacos 应用级注册：与 Kubernetes SVC 对齐

Dubbo3 的服务注册模式支持三种：Interface、Application、Instance。
这里选择了：

dubbo.application.register-mode=instance

dubbo.application.service-discovery.migration=FORCE_APPLICATION

原因：

与 Kubernetes Service 粒度对齐：Consumer 通过 SVC 的 FQDN 调用 Provider，而不是直连 Pod IP。
简化服务治理：流量入口统一在 Service 层，Istio 可以基于 FQDN 做治理。
避免“双重注册”冲突：不再出现 Dubbo 维护一份实例列表、Kubernetes 再维护一份的割裂现象。

3.4 ClusterIP vs Headless Service

这是落地方案中非常关键的一点。

ClusterIP Service
- Envoy 识别其 cluster type 为 EDS (Endpoint Discovery Service)；
- 可以感知 Service 下的所有 Pod Endpoint，从而做负载均衡、路由、熔断。
- IP 稳定，Pod 重启不会影响 DNS 缓存。
Headless Service
- Envoy 将其识别为 ORIGINAL_DST 模式；
- 意味着 Consumer 解析到哪个 Pod IP，就直连哪个 Pod；
- Envoy 只做透传，丧失治理能力。

因此，必须选择 ClusterIP，让流量进入 Istio 的治理平面。

📌 示意图：Envoy 处理差异

说明：ClusterIP 能进入 Envoy 的 EDS 流量治理；Headless 会绕过治理。

3.5 Sidecar 注入与标签治理

通过在 Deployment 中启用 istio-injection=enabled 或指定 istio.io/rev=<revision>，Pod 会被注入 Envoy sidecar。

作用：所有出入 Pod 的流量都会经过 Envoy，从而实现统一治理。
分流机制：在 Pod 上加上自定义 label（如 traffic.microsvc.io/track=stable/canary），对应到 Istio 的 DestinationRule.subsets。
场景：
- 灰度发布 → 按比例或标记路由流量到 canary；
- A/B 测试 → 通过 baggage header 将特定用户请求打入某个子集。

3.6 Baggage 传递：让流量染色贯穿调用链

传统 HTTP 请求中可以通过 header 携带标记，但 Dubbo 的调用链是 RPC 协议。通过 W3C Baggage 标准，可以解决：

在入口处打标：API Gateway 注入 baggage=canary=true,tenant=foo。
在调用链中传递：所有服务间的调用都会自动透传 baggage header。
在 Mesh 中识别：Istio VirtualService 可以基于 baggage 做流量匹配。

📌 示意图：流量染色 header 的传递

sequenceDiagram participant G as API Gateway participant A as Service A participant B as Service B participant C as Service C G->>A: 请求 + baggage=canary=true A->>B: RPC调用 + baggage=canary=true B->>C: RPC调用 + baggage=canary=true

说明：通过 W3C Baggage 标准，流量标签在调用链中自动透传。

📌 小结：技术选型遵循了一个原则：短期低成本 → 长期可演进。

协议上：Triple（兼容性） → Protobuf（未来优化）；
序列化上：Hessian2（平滑迁移） → Protobuf（跨语言性能更优）；
Service 模式：ClusterIP（治理能力强） → 避免 Headless（绕过治理）。

4. 实施步骤

接下来，我们将逐步完成从 Dubbo2 → Dubbo3 Triple + Hessian2 的迁移，并实现与 Istio 的集成。

4.1 修改 Dubbo 配置与依赖

首先，需要在 Nacos 配置中心 修改 Dubbo 的协议配置，使其切换到 Triple + Hessian2：

dubbo.protocol.name=tri
dubbo.protocol.id=tri
dubbo.protocol.serialization=hessian2
dubbo.consumer.serialization=hessian2

同时，在 pom.xml 中引入必要的依赖：

<dependencies>
    <!-- Triple 协议 -->
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-rpc-triple</artifactId>
        <version>3.1.3</version>
    </dependency>

    <!-- Hessian2 序列化 -->
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-serialization-hessian2</artifactId>
        <version>3.1.3</version>
    </dependency>

    <!-- Protobuf 运行时（tri 必需，即使业务不用 Protobuf） -->
    <dependency>
        <groupId>com.google.protobuf</groupId>
        <artifactId>protobuf-java</artifactId>
        <version>3.19.6</version>
    </dependency>
</dependencies>

📌 说明：

Triple 协议依赖是必须的；
Hessian2 是当前的序列化方式，方便平滑迁移；
Protobuf 库虽然业务暂时不用，但 Triple 底层依赖它，缺少会启动报错。

4.2 配置服务注册模式

Dubbo 与 Kubernetes Service 模型不同，需要显式配置 应用级服务注册：

dubbo.application.register-mode=instance
dubbo.application.service-discovery.migration=FORCE_APPLICATION

📌 说明：

register-mode=instance：与 Kubernetes SVC 对齐，每个 Pod 实例作为一个注册对象；
service-discovery.migration=FORCE_APPLICATION：强制切换到应用级发现，避免双重模型并存。

4.3 配置 Pod 的环境变量

在 Deployment 中设置 DUBBO_IP_TO_REGISTRY 环境变量，使 Dubbo Consumer 使用 FQDN 调用 Provider：

containers:
- env:
    - name: DUBBO_IP_TO_REGISTRY
      value: provider-ims.test1-microsvc.svc

📌 说明：

这里指定的是 Provider 的 Service FQDN；
Consumer 会将调用请求发往该域名；
Envoy Sidecar 可以基于 :authority 头部解析 FQDN，从而匹配 VirtualService 规则。

4.4 使用 ClusterIP Service

为 Provider 创建一个 ClusterIP 类型的 Service：

apiVersion: v1
kind: Service
metadata:
  name: provider-ims
  namespace: test1-microsvc
  labels:
    app: ims
    run_env: test1
    svc_type: provider
spec:
  type: ClusterIP
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  ports:
    - name: dubbo
      port: 20880
      protocol: TCP
      appProtocol: http2
      targetPort: 20880
  selector:
    app: ims
    run_env: test1
    svc_type: provider

📌 说明：

必须用 ClusterIP，因为 Envoy 会将其识别为 EDS 类型，可做路由与负载均衡；
如果用 Headless Service，则 Envoy 会退化为 ORIGINAL_DST，只做透传，不具备治理能力。

4.5 注入 Istio Sidecar 与打标签

在 Deployment 中添加注解或 label，以便注入 Envoy Sidecar：

spec:
  template:
    metadata:
      labels:
        istio.io/rev: default
        traffic.microsvc.io/track: stable # 或 canary

📌 说明：

istio.io/rev: default → 表示使用默认版本的 Istio 注入规则；
traffic.microsvc.io/track → 用于区分不同的版本（stable/canary），供 DestinationRule 的 subsets 使用。

4.6 配置 DestinationRule 与 VirtualService

创建对应的 DestinationRule 和 VirtualService，实现治理能力：

DestinationRule：定义服务的子集与全局策略

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: provider-ims
  namespace: test1-microsvc
spec:
  host: provider-ims.test1-microsvc.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        connectTimeout: 3s
        maxConnections: 1024
      http:
        h2UpgradePolicy: UPGRADE
        maxRequestsPerConnection: 0
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 5s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
    #portLevelSettings:   # 若要关闭mtls，放开注释。
    #  - port:            # 在上游provider的envoy sidecar放开pod入站流量管控时需要
    #      number: 20880
    #    tls:
    #      mode: DISABLE
  subsets:
    - name: stable
      labels:
        traffic.microsvc.io/track: stable
    - name: canary
      labels:
        traffic.microsvc.io/track: canary

VirtualService：定义路由策略

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: provider-ims
  namespace: test1-microsvc
spec:
  hosts:
    - provider-ims
    - provider-ims.test1-microsvc.svc
    - provider-ims.test1-microsvc.svc.cluster.local
  gateways:
    - mesh
  http:
    - name: canary-by-baggage
      match:
        - headers:
            baggage:
              regex: '.*(^|[,])\s*canary=true(\s*(;[^,]+)?)(,|$).*'
      route:
        - destination:
            host: provider-ims.test1-microsvc.svc.cluster.local
            subset: canary
          weight: 100
    - name: default-stable
      route:
        - destination:
            host: provider-ims.test1-microsvc.svc.cluster.local
            subset: stable
          weight: 100

📌 说明：

DestinationRule 定义了子集和流量治理策略；
VirtualService 基于 baggage header 分流，实现 Canary 发布；
h2UpgradePolicy=UPGRADE 确保 Dubbo Triple 使用 HTTP/2 (h2c)。

4.7 配置 API Gateway 的 Baggage 注入

在网关（如 APISIX）中配置 header 重写，将流量染色信息放入 baggage：

{
  "plugins": {
    "proxy-rewrite": {
      "headers": {
        "trace_id": "$http_traceparent",
        "baggage": "canary=true,tenant=foo"
      }
    }
  }
}

📌 说明：

trace_id （不必要）实际用于链路追踪中traceid传递的header是无需显式赋值传递，此处仅用于向后端传递，便于拦截器拾取。
baggage 用于流量路由与染色，在整条调用链中会自动透传。

到这里，实施步骤就完整串起来了：

修改配置 & 引入依赖；
配置注册模式；
Pod 环境变量 → 指定 Service FQDN；
使用 ClusterIP Service；
Sidecar 注入 + Label 打标签；
配置 Istio 的 DestinationRule & VirtualService；
在入口处注入 baggage header。

5. 流量治理与测试

实施完成后，关键是验证流量是否真正进入了 Istio 的治理平面，并且能够按照预期的策略（如 Canary、熔断、重试）进行控制。下面从几个方面展开。

5.1 Canary 流量测试

我们在 VirtualService 中配置了 基于 baggage header 的流量分流：

- name: canary-by-baggage
  match:
    - headers:
        baggage:
          regex: '.*(^|[,])\s*canary=true(\s*(;[^,]+)?)(,|$).*'
  route:
    - destination:
        host: provider-ims.test1-microsvc.svc.cluster.local
        subset: canary
      weight: 100

📌 示意图：VirtualService 分流

flowchart LR A[Consumer] --> B[Envoy Sidecar] B -->|baggage=canary=true| C[Canary Subset] B -->|无baggage| D[Stable Subset]

说明：Envoy 根据 header 将请求路由到不同子集。

测试方法：

发起一个带 baggage=canary=true 的请求：

curl -H "baggage: canary=true" http://gateway.test1-microsvc.svc/api/ims/getData
- 预期结果：请求会被路由到 canary 子集 的 Pod。
发起一个普通请求（无 baggage header）：

curl http://gateway.test1-microsvc.svc/api/ims/getData
- 预期结果：请求会走 stable 子集。

📌 验证方式：

通过 kubectl logs 查看 canary Pod 和 stable Pod 的日志；
或在 Jaeger/Zipkin 等链路追踪系统里查看调用链，确认不同请求被打到了不同子集。

5.2 Envoy 路由匹配过程

Envoy Sidecar 接收到请求时，会根据以下顺序进行处理：

识别协议：Dubbo3 Triple 基于 h2c（明文 HTTP/2），Envoy 能正确解析为 HTTP/2 请求。
匹配主机名：:authority 头部对应 provider-ims.test1-microsvc.svc.cluster.local。
应用 VirtualService 规则：
- 如果 header 中有 baggage=canary=true → 路由到 canary；
- 否则 → 路由到 stable。

📌 说明：这一步是 Dubbo2 无法做到的，因为旧协议在 Envoy 看来只是 TCP 流量，无法基于 header 匹配。

5.3 熔断与重试验证

在 DestinationRule 中配置了 Outlier Detection 与重试策略：

outlierDetection:
  consecutive5xxErrors: 5
  interval: 5s
  baseEjectionTime: 30s
  maxEjectionPercent: 50
retries:
  attempts: 2
  perTryTimeout: 5s
  retryOn: "5xx,connect-failure,refused-stream,reset"

测试方法：

模拟异常：临时将 canary Pod 的服务逻辑改成返回 500；
观察行为：
- Envoy 会在 5 秒内检测到连续 5xx 错误，将该实例逐出（eject）；
- 之后，Consumer 请求会被路由到其他健康的实例；
- 同时，重试机制会在超时/失败时自动重试一次。

📌 验证方式：

查看 Envoy Sidecar 的统计指标：

curl localhost:15000/stats | grep outlier
查看调用日志，确认异常实例被排除，重试逻辑生效。

5.4 链路追踪验证

由于在 API Gateway 注入了 trace_id 与 baggage，可以在链路追踪系统中看到完整的调用路径：

入口请求：带有 trace_id，贯穿全链路；
baggage 标签：例如 canary=true 会出现在每个 Span 的 Metadata 中；
调用路径：API Gateway → Consumer → Provider（stable/canary），清晰展示出流量染色效果。

📌 示意图：链路追踪中的流量染色

flowchart TD A[API Gateway Span] --> B[Service A Span] B --> |baggage=canary=true|C[Service B Span] B --> E[Service B Span] C --> D[Service C Span] E --> D[Service C Span] style C fill:#bbf

说明：每个 Span 都携带 trace_id 与 baggage=canary=true。

5.5 日志观测

在 Provider Pod 的日志中，可以明显看到流量的区分：

Canary Pod 日志：只会记录到携带 baggage=canary=true 的请求；
Stable Pod 日志：只会记录普通请求。

这种 日志对照验证 是最直观的确认方法。

📌 小结：通过 Canary 测试、熔断与重试验证、链路追踪和日志观测，我们能够确认：

流量染色与分流 在 Istio 中生效；
请求级治理能力（重试、熔断）能够作用于 Dubbo 流量；
链路可观测性增强，方便运维与问题排查。

6. 拓展与思考

完成 Dubbo2 → Dubbo3 Triple + Hessian2 的迁移，解决了协议不兼容和 Mesh 治理缺失的问题。但这并不是故事的终点，背后其实还有不少技术抉择和未来值得探索的方向。

6.1 为什么不是直接 gRPC + Protobuf？

很多读者可能会疑问：既然 gRPC 已经是 HTTP/2 的事实标准，为什么不直接改造 Dubbo 服务，全部换成 gRPC + Protobuf？

答案在于 成本与收益的平衡：

优点：gRPC 与 Istio 完全契合，跨语言生态成熟，性能更优。
缺点：需要大规模修改 DTO，将 Java Bean 全部转换为 .proto 定义，涉及序列化逻辑、IDL 管理、CI/CD 流程改造，代价极高。

相比之下，Triple + Hessian2 能在保持 Dubbo 开发体验的同时，获得 gRPC 类似的流量治理能力，是一个现实可行的“平滑过渡方案”。

6.2 Dubbo Mesh 与 Istio Mesh 的关系

Dubbo 官方也有 Dubbo Mesh 方案，侧重点在 Dubbo 协议的 Sidecar 化治理。

Dubbo Mesh：在 Dubbo 协议层面做代理（比如调用链追踪、治理规则下发），主要是 Dubbo 自己的生态闭环。
Istio Mesh：面向多语言、跨协议的统一治理，协议感知基于 Envoy，生态更广。

📌 可以这么理解：

如果团队主要是 纯 Java 微服务，Dubbo Mesh 就够用；
如果要和 多语言生态（Go、Python、Node.js） 统一治理，Istio 更合适。

本次迁移正是基于这个考量：用 Triple 协议让 Dubbo 融入 Istio Mesh，而不是再造一个 Dubbo 专属的 Mesh。

6.3 ClusterIP 的副作用与优化

虽然选择 ClusterIP 能获得 Istio 的治理能力，但也要注意几个潜在问题：

DNS 缓存延迟：Consumer 解析到 ClusterIP，依赖 Envoy 下发的 EDS 列表，一旦 DNS 缓存或 EDS 同步异常，可能导致短时请求失败。
跳转链路增加：相比直连 Pod IP，多了一层虚拟 IP 转发。

优化方向：

使用 Istio DNS Proxy 来增强 DNS 解析的稳定性；
合理配置 Envoy connectionPool，避免因 HTTP/2 连接复用导致单连接抖动。

6.4 序列化的长期演进

Hessian2 的优点是兼容，但性能与跨语言支持都不如 Protobuf。未来的演进路径可以是：

短期：Triple + Hessian2（迁移成本低，快速落地）；
中期：Triple + Protobuf（提升性能，增强跨语言能力）；
长期：部分高性能场景甚至可以考虑 FlatBuffers/Thrift，但这需要 Dubbo 生态更大调整。

6.5 运维与治理能力的扩展

有了 Mesh 基础后，可以进一步探索：

流量镜像：在 VirtualService 中复制部分请求到 canary 环境，用于灰度观测。
全链路压测：结合 Mesh 的流量路由，将部分流量导入压测集群，提升系统可靠性。
安全治理：未来可以启用 mTLS，让 Dubbo 流量也在 Envoy 层加密，统一安全策略。
可观测性增强：结合 OpenTelemetry，统一采集 Metrics + Traces + Logs，构建完整的观测体系。

📌 小结：Dubbo Triple 协议并不是终点，而是一个 从“黑箱 RPC”到“Mesh 原生协议” 的过渡。

现阶段：Triple + Hessian2 → 平滑接入 Istio，低成本获得治理能力；
未来演进：Triple + Protobuf → 高性能、跨语言生态；
更长远：Dubbo Mesh 与 Istio Mesh 的融合，甚至形成统一治理体系。

7. 总结

在这篇实践中，我们完成了 Dubbo2 → Dubbo3 Triple + Hessian2 的迁移，并让 Dubbo 微服务低成本接入到 Istio Service Mesh。

整个过程的出发点是：

问题：Dubbo2 自研协议是 Istio 的“黑箱流量”，Envoy 无法治理，导致流量染色、熔断、重试、链路追踪等功能缺失。
挑战：Dubbo 与 Kubernetes Service 模型不同，服务注册割裂；Headless Service 下，Envoy 退化为透传代理。
目标：通过协议标准化（HTTP/2）、服务发现对齐（ClusterIP FQDN）、Sidecar 注入，实现东西向流量纳入 Mesh 的统一治理。

迁移路径选择了一个平衡点：

协议层面：Triple 协议（兼容 gRPC、基于 HTTP/2）；
序列化层面：Hessian2（低成本迁移，未来可逐步演进到 Protobuf）；
服务注册：应用级实例注册 + Kubernetes ClusterIP SVC；
流量治理：基于 baggage header 实现 Canary 分流、熔断、重试和链路染色。

最终带来的收益是显而易见的：

Mesh 治理能力增强：请求级路由、熔断、重试等能力真正生效；
流量可观测性提升：通过 OpenTelemetry + baggage，链路追踪清晰可见；
架构演进空间：短期平滑迁移，长期具备向 gRPC/Protobuf 生态过渡的可能性。

📌 这次迁移的意义，不只是技术升级，而是让 Dubbo 从一个“协议孤岛”走向了云原生 Mesh 生态。
这也启示我们：在做架构升级时，不一定要“一步到位”，而是可以选择 低成本可行 → 长期可演进 的渐进式路径。

从 Dubbo2 到 Dubbo3 Triple + Hessian2：低成本接入 Istio Service Mesh 的实践

1. 引言

迁移目标

2. 问题与挑战

2.1 Dubbo2 协议的局限性

2.2 Service Mesh 与 Istio 的需求

2.3 Dubbo 应用级注册 vs Kubernetes Service

2.4 流量治理的盲区

2.5 序列化与协议选择的矛盾

3. 技术选型与设计思路

3.1 Triple 协议：兼顾 Dubbo 生态与 Istio Mesh

3.2 Hessian2 序列化：兼容性优先

3.3 Nacos 应用级注册：与 Kubernetes SVC 对齐

3.4 ClusterIP vs Headless Service

3.5 Sidecar 注入与标签治理

3.6 Baggage 传递：让流量染色贯穿调用链

4. 实施步骤

4.1 修改 Dubbo 配置与依赖

4.2 配置服务注册模式

4.3 配置 Pod 的环境变量

4.4 使用 ClusterIP Service

4.5 注入 Istio Sidecar 与打标签

4.6 配置 DestinationRule 与 VirtualService

4.7 配置 API Gateway 的 Baggage 注入

5. 流量治理与测试

5.1 Canary 流量测试

测试方法：

5.2 Envoy 路由匹配过程

5.3 熔断与重试验证

测试方法：

5.4 链路追踪验证

5.5 日志观测

6. 拓展与思考

6.1 为什么不是直接 gRPC + Protobuf？

6.2 Dubbo Mesh 与 Istio Mesh 的关系

6.3 ClusterIP 的副作用与优化

6.4 序列化的长期演进

6.5 运维与治理能力的扩展

7. 总结

评论区