Triple 协议是 Dubbo3 发布的面向云原生时代的通信协议，它基于 HTTP/2 并且完全兼容 gRPC 协议，原生支持 Streaming 通信语义，自 Triple 协议开始，Dubbo 还支持基于 Protobuf 的服务定义与数据传输。Triple 具备更好的网关、代理穿透性，因此非常适合于跨网关、代理通信的部署架构，如服务网格等。
Triple 协议的核心特性如下：
在编程与通信模型上，Triple 协议支持如下模式：
TCP (Dubbo2)
Dubbo2 协议是基于 TCP 传输层协议之上构建的一套 RPC 通信协议，由于其紧凑、灵活、高性能的特点，在 Dubbo2 时代取得了非常广泛的应用，是企业构建高性能、大规模微服务集群的关键通信方案。在云原生时代，我们更推荐使用通用性、穿透性更好的 Triple 协议。
gRPC
你可以用 Dubbo 开发和治理微服务，然后设置使用 gRPC 协议进行底层通信。但为什么要这么做那，与直接使用 gRPC 框架对比有什么优势？简单的答案是，这是使用 gRPC 进行微服务开发的常用模式，具体请往下看。
gRPC 是谷歌开源的基于 HTTP/2 的通信协议，如同我们在产品对比[1]文档中提到的，gRPC 的定位是通信协议与实现，是一款纯粹的 RPC 框架，而 Dubbo 定位是一款微服务框架，为微服务实践提供解决方案。因此，相比于 Dubbo，gRPC 相对欠缺了微服务编程模型、服务治理等能力的抽象。
在 Dubbo 体系下使用 gRPC 协议 (gRPC over Dubbo Framework) 是一个非常高效和轻量的选择，它让你既能使用原生的 gRPC 协议通信，又避免了基于 gRPC 进行二次定制与开发的复杂度 (二次开发与定制 gRPC，是很多企业规模化实践后证实不可避免的环节，Dubbo 框架替开发者完成了这一步，让开发者可以直接以最简单的方式使用 gRPC)。
REST
微服务领域常用的一种通信模式是 HTTP + JSON，包括 Spring Cloud、Microprofile 等一些主流的微服务框架都默认使用的这种通信模式，Dubbo 同样提供了对基于 HTTP 的编程、通信模式的支持。
其他通信协议
除了以上介绍的几种协议之外，你还可以将以下协议运行在 Dubbo 之上。对 Dubbo 而言微信二次开发需求文档，只需要修改一行简单的配置，就可以切换底层服务的通信协议，其他外围 API 和治理能力不受影响。
单端口多协议
Aliware
自 Dubbo 3.2 版本开始，Dubbo 提供了单个端口上的协议复用能力，通过调整 Protocol 配置即可实现。
比如在开启 HTTP/2 (Triple) 协议 或 gRPC 协议后，如我们同时启动端口复用，还可以在相同的端口上为服务增加 TCP (Dubbo2) 协议、Qos 协议的支持。这些所有流量的入口都在一个统一 port 端口， Dubbo 框架负责在端口之上识别不同的 RPC 协议，并进行处理器分发，从而实现单个端口上的协议复用。
对于需要处理多个协议的场景，端口复用非常有价值。它可以用于服务的协议迁移，并且可以节约端口以及相关的资源微信二次开发需求文档，减少运维的复杂性等。
实现原理
以下是端口复用实现的原理图
使用场景
以下是几种常见的使用场景。
参考用例：
使用方式
在同一主机上部署多个服务或需要通过负载均衡器访问多个服务。
关于 Dubbo 支持的配置方式 配置说明[2]
服务多协议导出
ext-protocol 参数支持配置多个不同的协议，协议之间通过”,”进行分隔。
xml 配置

API 配置

ProtocolConfig config = new ProtocolConfig(CommonConstants.TRIPLE, -1);
config.setExtProtocol(CommonConstants.DUBBO+\”,\”);

yaml 配置
dubbo:
application:
name: dubbo-springboot-demo-provider
protocol:
name: tri
port: -1
ext-protocol: dubbo,

properties 配置

dubbo.protocol.name=tri
dubbo.protocol.ext-protocol=dubbo,
dubbo.protocol.port=20880

Qos 接入Qos 模块导入

org.apache.dubbo
dubbo-qos

完成 Qos 模块的导入之后，相关的配置项可参考 Qos 操作手册[3]进行配置。
默认情况下，基于端口复用的 Qos 服务在模块导入后是启动的。
Qos 使用
将 Qos 协议接入到端口复用的场景下，需要在建立连接之后，客户端先向服务端发送消息，对比将 Qos 协议通过单个端口提供服务，端口复用版的 Qos 协议在处理 telnet 连接的情况下需要用户执行一些操作，完成协议识别（二选一）。
直接调用命令
直接调用 telnet 支持的命令也可以完成识别，在用户不熟悉的情况下可以调用 help 指令完成识别
2. 发送 telnet 命令识别
通过 telnet 命令建立连接之后，执行以下几个步骤：
使用 crtl + “]” 进入到 telnet 交互界面(telnet 默认的 escape character)调用 “send ayt” 向服务端发送特殊识别字段(为 telnet 协议的一个特殊字段)回车完成消息发送并进入到 dubbo 的交互界面
服务引用
以 dubbo-samples-port-unification[4]中的例子作为基础, 引用不同协议的服务和非端口复用情况下的配置是一致的，下面通过 Consumer 端的 InvokerListener 输出调用过程中的 URL 信息。

ReferenceConfig reference = new ReferenceConfig();
reference.setInterface(GreetingService.class);
reference.setListener(\”consumer\”);
reference.setProtocol(this.protocol);
// reference.setProtocol(CommonConstants.DUBBO);
// reference.setProtocol(CommonConstants.TRIPLE);

总结
Aliware
对于微服务实践中经常会遇到的多协议通信的场景，Dubbo 不绑定协议的设计让用户可以灵活的选择通信协议，整个协议选择过程对上层 API 编码与运维治理完全透明；对于要在一个集群内同时处理多个协议的场景，Dubbo 的多协议支持也可以从容应对，而单端口的多协议复用支持进一步简化了这一过程。
在接下来的一篇文章中，我们将详细介绍如何在 Dubbo 框架中开发 gRPC 协议通信的服务，极大的简化了 gRPC 微服务开发成本，避免了二次开发，为原生 gRPC 提供了统一的编程 API 与开箱即用的服务治理能力。
相关链接：
[1]产品对比
[2]配置说明
[3]Qos 操作手册
[4]dubbo-samples-port-unification