Dubbo中的Triple协议和应用级服务发现

文章部分内容摘录自Dubbo官方文档 应用级服务发现 | Apache Dubbohttps://dubbo.apache.org/zh/docs/examples/service-discovery/

Triple协议和新的服务注册发现机制，很大程度上都是出于适配云原生。一方面新的协议对应云原生中跨语言的要求，使得Dubbo服务不再局限于特定的开发语言，通过新协议都可以兼容通信。在Cloud Native的潮流下，跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开放标准的RPC技术，而gRPC顺应了历史趋势，得到了越来越广泛地应用。在微服务领域，Triple协议的提出与落地，是 Dubbo3 迈向云原生微服务的一大步。另一方面服务发现机制的调整也是为了对齐主流微服务(如SpringCloud)模型，调注册中心不再包含 RPC 信息，同时也解决了更大规模的微服务集群中的性能瓶颈。

应用级服务发现

在官方文档中对于 应用即服务发现是这样介绍的：

"社区版本 Dubbo 从 2.7.5 版本开始，新引入了一种基于应用粒度的服务发现机制，这是我们为 Dubbo 适配云原生基础设施的一步重要探索，也是 Dubbo 迈出的重要一步。 简单来说，以前 Dubbo 是将接口的信息全部注册到注册中心，而一个应用实例一般会存在多个接口，这样一来注册的数据量就要大很多，而且有冗余。 全新的应用级服务发现机制是同一个应用实例仅在注册中心注册一条数据，注册中心的数据只与实例数量相关，大大降低了注册中心数据的存储与推送压力。"

接口粒度 VS 应用粒度

简单来说，以前 Dubbo2 是将接口的信息全部注册到注册中心，而一个应用实例一般会存在多个接口，这样一来注册的数据量就要大很多，而且有冗余。 应用级服务发现的机制是同一个应用实例仅在注册中心注册一条数据，对于注册中心、订阅方的存储压力都是一个极大的释放。 更重要的是，地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载， 不会像 Dubbo2 一样， 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

• 数据映射关系变了：从 RPC Service -> Instance 变为 Application -> Instance
• 数据变少了：注册中心没有了 RPC Service 及其相关配置信息。

新一代RPC协议-Triple协议

不仅限于服务发现从接口粒度调整为应用级粒度，在Dubbo 3 版本中提供了新一代RPC协议Triple协议，它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。使用 Triple 协议，用户将获得以下能力：

• 更容易到适配网关、Mesh架构，Triple 协议让 Dubbo 更方便的与各种网关、Sidecar 组件配合工作。
• 多语言友好，推荐配合 Protobuf 使用 Triple 协议，使用 IDL 定义服务，使用 Protobuf 编码业务数据。
• 流式通信支持。Triple 协议支持 Request Stream、Response Stream、Bi-direction Stream