大家都知道，Spring Cloud和Dubbo早期版本在服务发现以及服务间通信方式上有很大的不同：Spring Cloud使用的是应用粒度的服务发现机制，而Dubbo则使用的是接口粒度的服务发现机制；Spring Cloud使用的是Http的协议进行服务间通信，而Dubbo则使用的是RPC基于Tcp层的方式进行通信。
而这两点，在很大程度上，影响了这两大微服务框架的使用性和扩展性。
服务间的通信方式这方面，强哥认为HTTP和TCP方式各有自己的应用场景和优缺点。新版本Dubbo3定义了全新的 RPC 通信协议–Triple，一款基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。不过由于通信方式还是RPC，所以强哥在这里就不多赘述了，有兴趣的小伙伴可以去了解下。下面重点讲Dubbo3的服务发现机制上的改动。
从服务发现的角度来说，相对于应用粒度的服务发现机制，以接口粒度的服务发现机制存在着许多的弊端：
- 所有接口的信息需要保存至注册中心，对注册中心存储压力大；
- 注册中心需要对所有改动的接口进行推送，注册中心CPU压力大；
- 不利于相同代码不同服务发布的接口隔离区分；
- 不利于与当下应用粒度进行服务发现的其他异构微服务体系进行整合；
- 不利于拥抱云原生，在与调度平台之间的生命周期对齐上存在许多问题。
而早期的Dubbo由于使用的就是接口粒度的服务发现机制，所以很大程度限制了它的发展，尤其是涉及到云原生等新技术上更是很难融入。
在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示，基础设施既承担了注册中心的职责，又完成了服务注册的动作，而 “RPC 接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。
不过，随着Dubbo3的发布，应用粒度的服务发现机制的实现，使得Dubbo将在微服务框架方面更具竞争力。
Dubbo3新模型带来的巨大优势：
- 进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）， Dubbo 可支持集群规模步入百万实例层次。
- 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通， 为连通 Dubbo 与其他微服务体系提供可行方案。
- 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
- 3.x 是完全兼容 2.x 版本，支持双订阅模式：可同时使用应用粒度和接口粒度方式进行服务发现。
双订阅模式，其实用一张图就可以理解：
消费端虽然可同时持有 2.x 地址与 3.x 地址，但选址过程中两份地址是完全隔离的：要么用 2.x 地址，要么用 3.x 地址，不存在两份地址混合调用的情况，这个决策过程是在收到第一次地址通知后就完成了的。
Dubbo这次的3.x版本的更新，也可以说是紧跟时代潮流。Serverless、云原生、服务网格等等新的服务端技术的出现推动着旧技术框架的不断革新。
