1.2. Dubbo 新版本特性_Dubbo 教程

Dubbo3 相比 2.7 版本进行了全面的升级，以下是新增的一些核心特性：

全新服务发现模型

相比于 2.x 版本中的基于接口粒度的服务发现机制，3.x 引入了全新的基于应用粒度的服务发现机制，新模型带来两方面的巨大优势：

进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）， Dubbo 可支持集群规模步入百万实例层次。
打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通，为连通 Dubbo 与其他微服务体系提供可行方案。

在 Dubbo3 前期版本将会同时提供对两套地址发现模型的支持，以最大程度保证业务升级的兼容性。

下一代 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

云原生

Dubbo3 构建的业务应用可直接部署在 VM、Container、Kubernetes 等平台，Dubbo3 很好的解决了 Dubbo 服务与调度平台之间的生命周期对齐，Dubbo 服务发现地址与容器平台绑定的问题。

在服务发现层面，Dubbo3 支持与 Kubernetes Native Service 的融合，目前限于 Headless Service。

Dubbo3 规划了两种形态的 Service Mesh 方案，在不同的业务场景、不同的迁移阶段、不同的基础设施保障情况下，Dubbo 都会有 Mesh 方案可供选择，而这进一步的都可以通过统一的控制面进行治理。

经典的基于 Sidecar 的 Service Mesh
无 Sidecar 的 Proxyless Mesh

用户在 Dubbo2 中熟知的路由规则，在 3.x 中将被一套统一的流量治理规则取代，这套统一流量规则将覆盖未来 Dubbo3 的 Service Mesh、SDK 等多种部署形态，实现对整套微服务体系的治理。

扩展点分离

Dubbo3 的 maven 也发生了一些变化，org.apache.dubbo:dubbo:3.0.0 将不再是包含所有资源的 all-in-one 包，一些可选的依赖已经作为独立组件单独发布，因此如果用户使用了不在 dubbo 核心依赖包中的独立组件，如 registry-etcd、rpc-hessian 等，需要为这些组件在 pom.xml 中单独增加依赖包。

Zookeeper 扩展实现仍在核心依赖包中，依赖保持不变：

<properties>
    <dubbo.version>3.0.0</dubbo.version>
</properties>
<dependencies>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-dependencies-zookeeper</artifactId>
        <version>${dubbo.version}</version>
        <type>pom</type>
    </dependency>
</dependencies>

Redis 扩展实现已经不在核心依赖包中，如启用了 Redis 相关功能，需单独增加依赖包：

<properties>
    <dubbo.version>3.0.0</dubbo.version>
</properties>
<dependencies>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-dependencies-zookeeper</artifactId>
        <version>${dubbo.version}</version>
        <type>pom</type>
    </dependency>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-registry-redis</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
</dependencies>

服务柔性

Dubbo3.0 的柔性增强以面向失败设计为理念，提供包括精准容量评估、自适应限流、自适应负载均衡的支持，自底向上的分步构建大规模可靠应用。从单一服务的视角看，服务是压不垮的，稳定的。从分布式视角看，复杂的拓扑不会带来性能的下降，分布式负载均衡能够以最优的方式动态分配流量，保证异构系统能够根据运行时的准确服务容量合理分配请求，从而达到性能最优。

全面的性能提升

对比 2.x 版本，Dubbo3 版本

服务发现资源利用率显著提升。
- 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)
- 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零
Dubbo 协议性能持平，Triple 协议在网关、Stream吞吐量方面更具优势。
- Dubbo协议（3.0 vs 2.x），3.0 实现较 2.x 总体 qps rt 持平，略有提升
- Triple协议 vs Dubbo协议，直连调用场景 Triple 性能并无优势，其优势在网关、Stream调用场景。

下一节：服务是 Dubbo 中的核心概念，一个服务代表一组 RPC 方法的集合，服务是面向用户编程、服务发现机制等的基本单位。Dubbo 开发的基本流程是：用户定义 RPC 服务，通过约定的配置方式将 RPC 声明为 Dubbo 服务，然后就可以基于服务 API 进行编程了。对服务提供者来说是提供 RPC 服务的具体实现，而对服务消费者来说则是使用特定数据发起服务调用。

下面从定义服务、编译服务、配置并加载服务三个方面说明如何快速的开发 Dubbo 服务。