Dubbo搭建分布式的流程

目录

• 准备工作
• • 1. Dubbo架构
  • 2. Zookeeper注册中心&admin监控中心
  • 3.简易版监控中心（可以不用）
• 普通Maven工程
• • 1. 项目创建
  • 2. 将服务提供者注册到注册中心（都是在user-service-provider中操作）
  • 3. 让服务消费者去注册中心订阅服务提供者的服务（都是在order-service-consumer中操作）
• SpringBoot工程
• • 1. 项目创建
  • 2. 将服务提供者注册到注册中心（都是在boot-user-service-provider中操作）
  • 3. 让服务消费者去注册中心订阅服务提供者的服务（都是在boot-order-service-consumer中操作）
  • 4. 其他Dubbo整合SpringBoot的方式
  • • 1. 使用xml配置文件
    • 2. 使用配置类
• 配置
• • 启动检查
  • 超时&配置覆盖关系
  • 重试次数
  • 多版本控制（灰色发布）
  • 本地存根（我没跑通）
• 高可用
• • zookeeper宕机与dubbo直连
  • 负载均衡
  • 服务降级
  • 服务容错&Hystrix（我没跑通）
• 总结

本文介绍Dubbo构建项目的整体流程。
具体执行参照视频：https://www.bilibili.com/video/BV1ns411c7jV?p=5；
配套CSDN总结笔记：https://blog.csdn.net/qq_41157588/article/details/106737191
GitHub私人项目：https://github.com/hhwucn/Dubbo
注册中心端口：2181
监控中心端口web访问端口：7001
简易监控中心端口web访问端口：8080（可以不用简易监控中心）
mysql端口：3306
Redis端口：6379

准备工作

1. Dubbo架构

RPC（remote procedure calls）两个核心模块：通讯、序列化。
所有的类的对象要进行远程传输，必须要实现序列化接口。

2. Zookeeper注册中心&admin监控中心

下载并配置zookeeper注册中心和admin监控中心（这些在尚硅谷提供的资料中都配置好了，直接用就行，自己配的话参考上边的视频和笔记）。
打开zookeeper/bin/zkServer.cmd即可；打开cmd后，嵌入命令java -jar dubbo-admin-0.0.1-SNAPSHOP.jar即可。
监控中心就是在可视化告诉我们哪个提供者注册了服务，哪个消费者调用了服务。

3.简易版监控中心（可以不用）

普通Maven工程

1. 项目创建

1. 写好服务提供者的模块（user-service-provider）
2. 写好服务消费者的模块(order-service-consumer)
3. 将服务提供者的接口和服务消费者接口、公共实体类抽取出来，放入一个公共模块（gmall-interface模块）（接口的实现、实体类的使用等）。
4. 在服务提供者user-service-provider和服务消费者order-service-consumer的pom.xml中都引入gmall-interface的坐标，即可实现提供者和消费者对该公共的调用。

2. 将服务提供者注册到注册中心（都是在user-service-provider中操作）

1. pom.xml中引入依赖（dubbo、操作zookeeper的客户端）。

2. 配置服务(resources/******.xml)服务名称、注册中心位置、注册中心协议、通信协议、通信端口（与消费者间的通信端口）、连接监控中心、暴露服务。
   最重要的是，理解服务提供者暴露服务的部分。

   <dubbo:service interface="com.atguigu.gmall.service.UserService"
                  ref="userServiceImpl" timeout="1000" version="1.0.0">
       <dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method>
   </dubbo:service>
   

3. 创建IOC启动类，启动IOC容器，便可将暴露的服务放到注册中心，供消费者调用
   此时在监控中心便可以看到注册的服务

3. 让服务消费者去注册中心订阅服务提供者的服务（都是在order-service-consumer中操作）

1. pom.xml中引入依赖（dubbo、操作zookeeper的客户端）

2. 配置服务(resources/******.xml)，应用名称、注册中心位置、连接监控中心
   最重要的是，指定服务消费者同服务提供者同样的接口，便能接收提供者的对象并放入消费者容器，并为其指定id，此时该对象就和消费者容器中的本地对象一样了。

   <dubbo:reference interface="com.atguigu.gmall.service.UserService"
                    id="userService" timeout="5000" retries="3" version="*">
       <!-- <dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method> -->
   </dubbo:reference>
   

3. 创建IOC启动类，启动IOC容器，即可调用放在注册中心的提供者暴露的服务，通过上步的id调用。
   此时在监控中心便可以同时看到提供的和消费的服务

SpringBoot工程

1. 项目创建

1. 创建普通springboot模块（不勾选web，boot-user-service-provider）作为服务提供者
2. 创建web 的springboot模块（boot-order-service-consumer）作为服务消费者
3. 在上边两个模块的pom文件中引入gmall-interface坐标。

2. 将服务提供者注册到注册中心（都是在boot-user-service-provider中操作）

1. pom.xml中引入依赖（dubbo集成springboot的起步依赖，不用导入zookeeper的依赖了）。
2. 配置服务(resources/application.properties)，服务名称、注册中心位置、注册中心协议、通信协议、通信端口（与消费者间的通信端口）、连接监控中心。暴露服务部分可以直接在需要暴露服务的类上加dubbo下的@Service注解，避免一个个配置需要暴露的服务，注意与spring下的@Service注解区分。
3. 在springboot的入口类上加@EnableDubbo注解，开启基于注解的dubbo功能。
4. 启动springboot入口类即可。

3. 让服务消费者去注册中心订阅服务提供者的服务（都是在boot-order-service-consumer中操作）

1. 在消费者中写OrderController，调用自己模块的orderService对象的initOrder方法查询用户地址（initOrder方法依赖服务提供者的userService对象的getUserAddressList方法），写法跟之前的springboot的写法一致。
2. pom.xml中引入依赖（dubbo集成springboot的起步依赖，不用导入zookeeper的依赖了）。
3. 配置服务(resources/application.properties)，应用名称、注册中心位置、连接监控中心。调用服务时
   可以直接在需要注入的属性（使用接口名定义）上写dubbo下的注解@Reference，便可调用服务提供者提供的服务（类的对象）。消费者是根据接口名定义属性的，加上该注解后，会直接将提供者对该注解的实现类注入。
4. 在springboot的入口类上加@EnableDubbo注解，开启基于注解的dubbo功能。
5. 如果开启了简易监控中心，8080端口会被占用，需要在properties文件修改当前的模块部署的Tomcat端口，例如改为8081。
6. 启动springboot入口类即可。

4. 其他Dubbo整合SpringBoot的方式

1. 使用xml配置文件

1. 将xml配置文件放到resources下，并注释properties下的所有内容。
2. 将springboot启动类的@EnableDubbo注解取消，换为@ImportResource(locations = “classpath:******.xml”)
3. 取消服务暴露的@Service的注解

2. 使用配置类

配置

启动检查

设置为false时，当仅启动消费者时，也不报错。

超时&配置覆盖关系

设置超时上限，防止某一程序引起进程阻塞，影响后续进程（默认1000ms）。
配置覆盖规则：

1. 精确优先（方法 先于 接口 先于 全局）
2. 满足1的前提下，消费者优先（消费者 先于 提供者）

重试次数

不包含第一次尝试。

多版本控制（灰色发布）

服务提供者对同一接口实现多个类，用不同的version命名，服务提供者在注册中心注册同一接口的不同版本后，消费者在通过接口名来调用服务提供者的实现类时，只能调用版本匹配的提供者注册的实现类。
现实中的应用，这就可以使一部分人能够使用部分的新功能。
这就可以说明我之前的疑虑：通过接口作为消费者和提供者的连接标识时，提供者有一个接口的多个实现类怎么办？所以答案应该是一个接口只实现一种功能，这种功能可以有新旧版本之分。这里的接口就不能像jdbc这种可以很广泛的实现类，只能针对一种实现类。

本地存根（我没跑通）

类似于本地调用远程前增加了过滤功能，如果不必调用远程，就不调用了，防止资源浪费。。。
其实我没弄懂。。。

高可用

zookeeper宕机与dubbo直连

zookeeper注册中心宕机后，由于有本地缓存，消费者仍知道提供者的通信地址，所以仍能够建立服务。
即便是没有本地缓存，也可以通过Dubbo直连的方式，在消费者的@Reference(url = “localhost:提供者通信地址”)中指定提供者的通信地址，直接建立连接。

负载均衡

在springboot中调用提供者服务时，消费者可以指定@Reference(loadbalance=“random或roundrobin”）指定多个消费调多个提供者时的方式，是随机调还是轮询。同时还可以在监控中心为不同的服务提供者指定被调用的概率权重。

服务降级

在监控中心的消费者处直接操作：
屏蔽：拒绝消费者请求服务，不能访问服务提供者提供的服务，服务器不处理服务；
容错：在消费者请求服务超时返回空而不是异常，注意这时服务器已经处理服务了，只是超时后给用户空值而非报异常。

服务容错&Hystrix（我没跑通）

1. 在提供者的pom中添加服务容错依赖
2. 在服务提供者提供的服务方法上加@HystrixCommand//对可能出现错误的方法添加服务容错注解，在提供者的springboot入口类上加@EnableHystrix//开启服务容错
3. 在消费者的pom中添加服务容错依赖
4. 在服务消费者者调用的提供者方法的方法上加@HystrixCommand(fallbackMethod="hello")//调用提供者方法出错后调用消费者自己的hello方法，在消费者的springboot入口类上加@EnableHystrix//开启服务容错
5. 在消费者本类中声明hello方法。

总结

接口是提供者和消费者之间的标识