终于有人从入门到实战把Dubbo讲的这么清楚了，强烈建议收藏！

Posted 2021-06-16 程序猿就是我

初识 Dubbo

为什么 Dubbo 说自己性能高？

高性能要从底层的原理说起，既然是一个 RPC 框架，主要干的就是远程过程(方法)调用， 那么提升性能就要从最关键、最耗时的两个方面入手：序列化和网络通信。

序列化：我们学习 Java 网络开发的时候知道,本地的对象要在网络上传输，必须要实现Serializable 接口，也就是必须序列化。我们序列化的方案很多：xml、json、二进制流…其中效率最高的就是二进制流(因为计算机就是二进制的)。然而 Dubbo 采用的就是效率最高的二进制。

网络通信：不同于 HTTP 需要进行 7 步走(三次握手和四次挥手)，Dubbo 采用 Socket 通信机制,一步到位,提升了通信效率,并且可以建立长连接,不用反复连接,直接传输数据

别的 RPC 框架

gRPC

Thrift

HSF

...

dubbo 的前世今生

dubbo 之前一直都作为 Alibaba 公司内部使用的框架。

2011 年,dubbo 被托管到了GitHub 上(开源)

2014 年11 月发布2.4.11版本后宣布停止更新。此后一段时间很多公司开源了自己基于Dubbo的变种版本(例如当当网的 Dubbo X,网易考拉的 Dubbo K)

2017 年 SpringCloud 横空出世,Dubbo 感觉到压力后连续更新了几个版本2018 年 1 月,阿里公司联合当当网将 Dubbo 和 Dubbo X 合并,发布了 2.6 版本2018 年除夕夜阿里将 Dubbo 贡献给了 Apache 基金会

2018 除夕夜至今,Apache 维护和更新 Dubbo

dubbo 概述

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案、服务治理方案。

官网：
http://dubbo.apache.org/zh-cn/

特性：

 

面向接口代理：调用接口的方法，在 A 服务器调用 B 服务器的方法，由 dubbo 实现对 B 的调用，无需关心实现的细节，就像MyBatis 访问 Dao 的接口，可以操作数据库一样。不用关心 Dao 接口方法的实现。这样开发是方便，舒服的。

基本架构

• 服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
• 服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
• 监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

调用关系说明:

• 服务容器负责启动，加载，运行服务提供者。
• 服务提供者在启动时，向注册中心注册自己提供的服务。
• 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

dubbo 支持的协议

支持多种协议：dubbo , hessian , rmi , http, webservice , thrift , memcached , redis。dubbo 官方推荐使用dubbo 协议。dubbo 协议默认端口 20880

使用 dubbo 协议，spring 配置文件加入：

<dubbo:protocol name="dubbo" port="20880" />

电商平台需求

某电商平台系统需求，用户浏览商品；选择商品下订单，订单系统需要获取用户信息中的送货地址；向支付系统请求完成付款。

直连方式 dubbo

点对点的直连项目:消费者直接访问服务提供者，没有注册中心。消费者必须指定服务提供者的访问地址（url）。

消费者直接通过 url 地址访问固定的服务提供者。这个 url 地址是不变的。

实现目标

用户访问 ------>【商品网站服务】访问-----> 【订单服务】

实现方式

以 JavaSE 为例，服务提供者，服务消费者都是 JavaSE项目

（1） 创建服务提供者：订单服务

A、 新建 java project

项目名称：
link-orderservice-provider

设置 version 为 1.0.0

B、 maven pom.xml

在<build> 下的 <plugins>标签中加入 JDK1.8 编译插件

C、 创建订单实体类：Order

D、 新建订单服务接口：OrderService

E、新建接口的实现类：OrderServiceImpl

F、创建 dubbo 配置文件

orderservce-provider.xml

G、 测试配置文件

H、 安装本地 jar 到 maven 仓库

服务接口中的方法要给消费者使用，消费者项目需要知道接口名称和接口中的方法名称、参数等。这些信息服务提供者才知道。需要把接口的 class 文件打包为jar .

服务接口项目的类文件打包为jar， 安装到 maven 仓库，仓库中的提供者 jar 可以被消费者使用。

使用 IDEA 的 maven 窗口执行 install

（2） 创建服务消费者：商品网站

I、 新建 java project

项目名称：link-main-web

J、 maven pom.xml

在<build> 下的 <plugins>标签中加入 JDK1.8 编译插件

K、 创建购买商品接口

L、创建购买接口的实现类

M、 创建 dubbo 配置文件

shop-consume.xml

N、 执行消费者

dubbo 服务化最佳实践

分包

建议将服务接口、服务模型、服务异常等均放在公共包中。

粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。

不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

版本

每个接口都应定义版本号，区分同一接口的不同实现，如： <dubbo:service interface="com.xxx.XxxService" version="1.0" />。