服务网格
Dubbo Mesh 是 Dubbo 在云原生环境下的综合微服务解决方案。它帮助开发者将 Dubbo 服务与标准 Kubernetes 原生服务系统集成，实现与 Istio 等领先服务网格产品的无缝连接。
以下是 Dubbo Mesh 的部署架构图。
- 控制平面：Istio 作为统一的控制平面，提供集群范围内的功能，如 Kubernetes 适配、服务发现、证书管理、可观察性和流量管理。
- 数据平面：Dubbo 应用实例充当数据平面组件，支持两种部署模式
- 代理模式：Dubbo 和 Envoy 部署在同一个 Pod 中，所有进出 Dubbo 的流量都由 Envoy 拦截和管理。
- 无代理模式：Dubbo 实例独立部署，彼此直接通信，并通过 xDS 协议直接与控制平面交互。
有关服务网格架构和为什么要与 Istio 控制平面集成的常规内容，请参阅 Istio 官方网站。本文档将重点介绍 Dubbo Mesh 解决方案本身。
Dubbo Mesh
代理网格
在代理模式下，Dubbo 与 Envoy 等 Sidecar 一起部署。
上图展示了 Dubbo 代理网格部署
- Dubbo 和 Envoy 部署在同一个 Pod 中，Istio 管理流量和治理。
- Dubbo 为业务应用程序提供编程 API 和 RPC 通信功能，而地址发现、负载均衡和路由等其他功能则委托给 Envoy，Envoy 拦截所有传入和传出流量。
- 控制平面通过 xDS 协议将配置分发到 Envoy，如图表中的虚线所示。
在代理模式下，使用基于 HTTP 的 Dubbo3 通信层（如 Triple、gRPC 和 REST）可以实现更好的网关穿透和性能。
无代理网格
在无代理模式下，没有 Envoy 等代理组件。Dubbo 的进程独立部署，直接通信。Istio 的控制平面通过 xDS 协议与 Dubbo 进程交互以进行治理。
在无代理模式下，Dubbo 部署与以前基本相同，但 Dubbo3 SDK 直接实现 xDS 协议解析。
为什么选择无代理网格？
虽然代理模式提供了许多优势，例如平滑升级、多语言支持和最小的业务入侵，但也带来了一些挑战
- Sidecar 通信会增加额外的性能开销，尤其是在复杂的网络拓扑中。
- Sidecar 的存在会使应用程序生命周期管理变得复杂。
- 并非所有环境都能容纳 Sidecar 部署和请求拦截。
在无代理模式下，Dubbo 进程继续直接通信
- 没有额外的与代理相关的开销，使其更适合性能敏感的应用程序。
- 它简化了遗留系统的迁移。
- 架构简单易于管理。
- 它适用于几乎所有部署环境。
示例任务
在掌握了足够的理论知识后，建议您访问以下 示例 进行实践操作。
可视化
建议使用 Dubbo Admin 作为 Dubbo 集群的可视化控制台。它与所有 Kubernetes、Mesh 和非 Mesh 架构部署兼容。
此外，您可以使用 Istio 官方推荐的可视化工具 来管理您的 Dubbo Mesh 集群。
与非 Istio 控制平面的集成
Dubbo Mesh 本身不依赖于任何控制平面产品实现。您可以使用 Istio、Linkerd、Kuma 或任何支持 xDS 协议的控制平面产品。Sidecar 也是如此。
如果您已经体验过 基于 Istio 的 Dubbo Mesh 示例任务，并且发现 Istio 满足您对 Dubbo Mesh 的治理需求，那么采用 Istio 作为您的控制平面是首选解决方案。
如果您发现 Dubbo 的功能在 Istio 模式下有限，并且需要这些功能，您可以考虑集成 Dubbo 的控制平面来替换 Istio，以获得更好的原生 Dubbo 支持和性能。有关详细信息，请参阅 基于自定义 Dubbo 控制平面的 Dubbo Mesh 示例任务。
简而言之，这是 Dubbo 社区基于 Istio 发布的控制平面的自定义版本。有关 Dubbo 控制平面的安装和功能差异，请参阅上面的示例任务链接。
