下一代 RPC 通信协议
定义了全新的 RPC 通信协议 – Triple，一句话概括 Triple：它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。 使用 Triple 协议，用户将获得以下能力
更容易到适配网关、Mesh架构，Triple 协议让 Dubbo 更方便的与各种网关、Sidecar 组件配合工作。
多语言友好，推荐配合 Protobuf 使用 Triple 协议，使用 IDL 定义服务，使用 Protobuf 编码业务数据。
流式通信支持。Triple 协议支持 Request Stream、Response Stream、Bi-direction Stream
全新服务发现模型
相比于 2.x 版本中的基于接口粒度的服务发现机制，3.x 引入了全新的基于应用粒度的服务发现机制， 新模型带来两方面的巨大优势：
进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）， Dubbo 可支持集群规模步入百万实例层次。
打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通， 为连通 Dubbo 与其他微服务体系提供可行方案。
在 Dubbo3 前期版本将会同时提供对两套地址发现模型的支持，以最大程度保证业务升级的兼容性。
第一点不用详细解释，阿里作为作为国内互联网三巨头之一，其所拥有的实力自然不言而喻。并且拥有超大量用户规模，所以在这个基础上，迭代升级的Dubbo3在大规模集群实践中的性能与稳定性可以说是经过时间与高峰值用户访问检验的，这一点毋庸置疑。
我感兴趣的是第二点，如果确实如官网新特性描述的那样，同时兼容其他微服务架构体系，实现地址发现层面的互通，那无疑是给已经接入其他微服务架构体系的公司，带来了福音。(毕竟spring clound alibaba/netfilx开箱即用、各种组件眼花缭乱，一套组合拳下来，让人应接不暇，，哈哈)想象下，你所用的spring clound alibaba微服务，在跟Dubbo项目对接时可以随意的通过Rpc访问对方的微服务，该是多么得便利。
{{o.name}}
{{m.name}}