Dubbo3探索之路（一）
- 为啥要研究 Dubbo 3
- 协议
- 最终的选择 Triple
- Triple 协议
- 协议长什么样
- IDL 文件形式
- java 接口形式
- 实验情况
- Dubbo 3.0 的 Service Mesh 能力
为啥要研究 Dubbo 3
今年来公司内部微服务越来越多，微服务架构搞了好多套。协议有 http、dubbo2、grpc、thrift。注册中心有 nacos、k8s 原生的、公司自研注册中心。服务治理有dubbo自带的、公司自研的。什么组合都有，很难管理、很难运维。于是乎，打算使用 Dubbo3.0 接入 Service Mesh 实现服务的统一治理。先搞定那么几点：协议、升级方案、Mesh能力。
协议
Triple 协议是 Dubbo3 推出的主力协议。Triple 意为第三代，通过 Dubbo1.0/ Dubbo2.0 两代协议的演进，以及云原生带来的技术标准化浪潮，Dubbo3 新协议 Triple 应运而生。
最终的选择 Triple
最终我们选择了兼容 gRPC ，以 HTTP2 作为传输层构建新的协议，也就是 Triple。
容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议（ RESTFUL或其他基于 HTTP 的自定义协议）难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后，包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态，作为云原生的微服务化框架， Dubbo 的新协议也完美兼容了 gRPC。并且，对于 gRPC 协议中一些不完善的部分， Triple 也将进行增强和补充。
那么，Triple 协议是否解决了上面我们提到的一系列问题呢？
性能上: Triple 协议采取了 metadata 和 payload 分离的策略，这样就可以避免中间设备，如网关进行 payload 的解析和反序列化，从而降低响应时间。
路由支持上，由于 metadata 支持用户添加自定义 header ，用户可以根据 header 更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。
安全性上，支持双向TLS认证（mTLS）等加密传输能力。
易用性上，Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言，修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可，改造成本几乎为 0。
Triple 协议
官方现状
1、完整兼容grpc、客户端/服务端可以与原生grpc客户端打通
2、目前已经经过大规模生产实践验证，达到生产级别
特点与优势
1、具备跨语言互通的能力，传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式。
2、提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional。
3、易扩展、穿透性高，包括但不限于 Tracing / Monitoring 等支持，也应该能被各层设备识别，网关设施等可以识别数据报文，对 Service Mesh 部署友好，降低用户理解难度。
4、多种序列化方式支持、平滑升级
5、支持 Java 用户无感知升级，不需要定义繁琐的 IDL 文件，仅需要简单的修改协议名便可以轻松升级到 Triple 协议
协议长什么样
IDL 文件形式
通过 Wireshark 抓包，识别出来了这个是grpc。数据有认识 protobuf
java 接口形式
通过 Wireshark 抓包，没识别出来是 grpc。数据应该是 Hessian
实验情况
使用 IDL 文件形式的 Triple 协议暴露服务，使用 go 作为GRPC客户端调用，结果：调用成功。所以兼容GRPC这件事是没问题的，但是java 接口形式的本身没有proto文件，代码也不知道怎么写，看来完全迁移 Triple 协议这件事可能绕不开 IDL，官方也是推荐IDL形式。
IDL 文件形式和java 接口形式都是基于http2协议建立的，其中java 接口形式保留了3个关键的header（:scheme、:method、:path），有这三个也许足以集成 Service Mesh能力
Dubbo 3.0 的 Service Mesh 能力
先来看看官方是怎么说的
Dubbo3.0 在原有功能集与 API 完全兼容的前提下，同时具备了以下几大面临云原生挑战下的新特性
- Dubbo 3.0 支持全新的服务发现模型，Dubbo 3.0 尝试从应用模型入手，优化存储结构，对齐云原生主流设计模型，避免在模型上带来的互通问题。新模型在数据组织上高度压缩，能有效提高性能和集群的可伸缩性。
- Dubbo 3.0 提出了下一代 RPC 协议 —— Triple。这是一个基于 HTTP/2 设计的完全兼容 gRPC 协议的开放性新协议，由于是基于 HTTP/2 设计的，具有极高的网关友好型和穿透性；完全兼容 gRPC 协议是的天然在多语言互通方面上具有优势。
- Dubbo 3.0 面向云原生流量治理，提出了一套能够覆盖传统 SDK 部署、Service Mesh 化部署、VM 虚拟机部署、Container 容器部署等场景的统一治理规则，支持一份规则治理大部分场景，大大降低流量治理治理成本，使得异构体系下全局流量治理变得可能。
- Dubbo 3.0 将提供接入 Service Mesh 的解决方案，面向 Mesh 场景，Dubbo 3.0 提出了两种接入方式，一种是 Thin SDK 模式，部署模型和当前 Service Mesh 主流部署场景完全一样，而 Dubbo 将进行瘦身，屏蔽掉与 Mesh 相同的治理功能，仅保留核心的 RPC 能力；第二种是 Proxyless 模式，Dubbo 将接替 Sidecar 的工作职责，主动与控制面进行通信，基于 Dubbo 3.0 的统一治理规则应用云原生流量治理功能。
我翻了翻文档、github、网上大佬的文章发现。Thin SDK 模式没有、Proxyless 模式也没有（可能目前的sdk就是Proxyless 模式）。理论上Thin SDK 模式可能更适合我们。那么现有的未精简版本应该说是也不是不能用。
