Triple 协议是 Dubbo3 提出的基于 HTTP2 + gRPC 的开放协议，完整兼容 gRPC over HTTP/2，旨在解决 Dubbo2 私有协议带来的互通性问题。一句话概括 Triple：它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。
相比于原有 Dubbo2 协议，Triple 有以下优势:
原生和 gRPC 协议互通。打通 gRPC 生态，降低从 gRPC 至 Dubbo 的迁移成本。
增强多语言生态。避免因 CPP/C#/RUST 等语言的 Dubbo SDK 能力不足导致业务难以选型适配的问题。
网关友好。网关无需参与序列化，方便用户从传统的 HTTP 转泛化 Dubbo 调用网关升级至开源或云厂商的 Ingress 方案。
完善的异步和流式支持。带来从底层协议到上层业务的性能提升，易于构建全链路异步以及严格保证消息顺序的流式服务。
目前 Java 和 Go 的 Dubbo SDK 已全面支持 Triple 协议。在阿里巴巴，Triple 协议广泛用于跨环境、跨语言、跨生态互通，已有数十万容器生产级使用。
Java SDK 支持 IDL 生成 Stub 和 Java Interface 两种方式，多语言、生态互通、流式需求推荐使用 IDL 方式，现有服务平滑升级推荐使用 Interface 方式。
坑一、consumer端调用provider端调用失败在应用triple协议时，在测试环境同一台机器部署了provider和consumer，注册到同一个nacos，但是consumer始终调用不到provider，排查后发现因为测试环境加了http_proxy和https_proxy代理
export http_proxy=http://10.126.138.71:3128 export https_proxy=http://10.126.138.71:3128
为什么服务器上加了http代理会导致dubbo服务调用不通呢？
原因是因为triple协议本身，triple协议是基于HTTP2和gRPC协议扩展的，故使用Triple协议时如果加了代理，会受代理影响。
解决办法通过在服务器上配置no_proxy 来屏蔽内网代理，配置指定IP或者全部内网IP
配置指定IP
export no_proxy="127.0.0.1, localhost, *.cnn.com, 192.168.1.10"
配置所有内网IP
export no_proxy="`echo 10.1.{1..255}.{1..254},` 10.1.255.255"
no_proxy配置参考
坑二、triple协议在docker用应用在讲dubbo服务build成docker镜像部署应用时，由于docker的隔离特性，consumer端与provider端大都不在同一个局域网内，以至于consumer端provider端无法正常的通信
在dubbo2中，通常在docker镜像启动时通过配置docker环境变量DUBBO_IP_TO_REGISTRY和DUBBO_PORT_TO_REGISTRY绑定当前宿主机的IP和端口，通过宿主机的端口暴露注册provider服务
DUBBO_IP_TO_REGISTRY=172.16.0.1 # 当前服务以此IP注册到注册中心 DUBBO_PORT_TO_REGISTRY=20981 # 当前服务以此端口注册到注册中心
但是在使用Triple协议时，使用这两个配置不能完全解决问题，原因是因为dubbo3中元数据和服务使用了不同的端口，以至于DUBBO_PORT_TO_REGISTRY注册的端口不能满足，因此需要暴露两个端口，此时则不可使用此环境变量DUBBO_PORT_TO_REGISTRY指定端口（这是官方的一个bug，后续版本应该会修复）
解决办法dubbo.application.metadata-service-port=20982 # 指定元数据端口 dubbo.protocol.port=50052 # 指定服务端口
并将指定好的端口映射到宿主机上
以docker-compose配置为例，完整配置如下
以上阐述均基于dubbo3.0.8版本
