20200714 Dubbo+Zookeeper技术栈

Dubbo原理，Zookeeper原理，如何在项目中使用，管理后台的使用。

@Service暴露服务、使用@Reference引用服务；Dubbo-admin：管理控制台. 服务治理与系统管理。

引用接口client jar包即可。

两个作用: 1）服务提供方引用jar包，用于实现接口。2）服务调用方引用jar包，是为了调用其中的方法实现功能，dubbo在代码中的实现。

Zookeeper=文件系统+通知机制。

 

Dubbo+Zookeeper 分布式项目搭建

dubbo主要核心组件：

1、Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制；

2、RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能，可以自定义负载均衡策略；

3、Registry: 服务目录框架用于服务的注册、服务事件发布和订阅；

 

Dubbo工作原理：( 注册中心、监控中心 )

1) Provider 暴露服务方称之为  “服务提供者”。

2) Consumer 调用远程服务方称之为  “服务消费者”。

3) Registry 服务注册与发现的中心目录 服务称之为“服务注册中心”。

4) Monitor 统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。  

5) 调用次数和调用日期日志，获取服务提供者地址列表，消费者在本地缓存了提供者列表。

 

(1) 连通性：

a： 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和服务消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。（只在启动时与注册中心进行交互）

b: 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示；

c: 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销；

d: 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

 

注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外。

注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。

注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。

注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。可以不用这个注册中心，直接连接消费者。

 

(2) 健壮性：

监控中心宕掉不影响使用，只是丢失部分采样数据。

数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务。

注册中心对等集群，任意一台宕掉后，将自动切换到另一台。自动故障转移。

注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯。

服务提供者无状态，任意一台宕掉后，不影响使用。

服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

 

(3) 伸缩性：

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心。

服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。

连通性，健壮性，伸缩性。

在dubbo-test中创建了三个modle，分别为service接口层 (jar包)，service实现层以及MVC层。创建三个module， 和上家公司的项目结构一样。

Service接口与ServiceImpl实现类，使用@Service注解。

实现层导入接口层的依赖jar包；使用maven安装到仓库，然后在pom中直接添加依赖既可。

 

Dubbo使用流程

1、导入dubbo-starter，

2、在appication.properties配置属性，

3、使用@Service暴露服务，

4、使用@Refrence引用服务。

5、注意：开启@EnableDubbo注解。

 

POM文件中添加依赖 Dubbo+Zookeeper

1、在配置文件中，为当前微服务配置别名; 为当前微服务注册命名。

2、配置注册中心的地址;

3、接口全路径，接口实现类类名。 接口，接口的实现类，接口连接超时时间。

mvc层也要使用到service接口，所以也要引入service层生成的jar，同样直接引入依赖既可。

查找远程服务，找到对应的注册中心。

 

导入dubbo-starter的场景启动器和导入dubbo的其他依赖。

<dependency>

<groupId>com.alibaba.boot</groupId>

<artifactId>dubbo-spring-boot-starter</artifactId>

<version>0.2.0</version>

</dependency>

SpringBoot与dubbo整合的三种方式：

一、导入dubbo-starter依赖，在 application.properties 或者 application.yml 配置属性，使用

@Service 用在服务提供者中，在类或者接口中声明。

服务提供者实现相关的服务接口，当消费端调用相关的类时，最终会调用提供者的实现方法。

@Service(version = "1.0.0",timeout = 10000,interfaceClass = RemoteUserService.class) 应该用在接口实现类上。

添加@Service注解，切记注解不是用spring的service注解，是com.alibaba.dubbo.config.annotation.Service，由阿里提供的dubbo的注解，配上版本号1.0.0说明向Zookeeper注册的是版本为1.0.0的TestService接口，超时时长为3000ms等信息。

 

@Reference 用在消费端，表明使用的是服务端的什么服务

@Reference(version = "1.0.0",check = true) private RemoteUserService remoteUserService;

//调用服务提供者的服务（方法即可）

 

需要在SpringBoot启动类添加@EnableDubbo开启基于注解的dubbo功能。

 

#提供者配置：

#当前应用的名字：应用名

dubbo.application.name=dubbo-provider

#指定注册中心的地址和端口号

dubbo.registry.address=xx.xx.xx.xx:2181

dubbo.registry.protocol=zookeeper

#使用dubbo协议，将服务暴露在端口8001，当前服务暴露的端口

dubbo.protocol.name=dubbo

dubbo.protocol.port=8001

#基础包扫描

dubbo.scan.base-packages=com.wangcw.dubbo.provider

 

#消费者配置：

dubbo.application.name=dubbo-consumer

dubbo.protocol.name=dubbo

dubbo.registry.protocol=zookeeper

dubbo.registry.address=xx.xx.xx.xx:2181

dubbo.scan.base-packages=com.wangcw.duboo.consumer

 

Dubbo-admin：管理控制台。相当于eureka Server的注册列表。去上面看服务是否注册成功(启动成功)。在系统管理里可以查看系统状态和系统日志。

Dubbo-admin原理是什么？打好war包，直接部署到tomcat下即可。 部署所在的地址。

Dubbo后台管理界面上：服务提供方和服务消费方。

首页，服务治理，系统管理。

http://192.168.1.84:8080/dubbo/governance/consumers/259

服务治理中的服务提供者，服务提供者的详细信息。服务名，服务所在的主机，应用名称，方法列表，接口名，状态，检查。

在系统管理里可以查看系统状态和系统日志。

系统管理：监控堆内存，是否能够连接上注册中心，连接上正常，连接不上报错；

注册中心的地址和状态。

 

Dubbo路由功能实现灰度发布又叫金丝雀发布。

灰度发布是实现新旧版本平滑过渡的一种发布方式，即让一部分服务更新到新版本，如果这部分服务没有什么问题，再将其它旧版本的服务更新。而实现简单的灰度发布我们可以使用版本号控制，每次发布都更新版本号，新更新的服务就不会调用旧的服务提供者。

路由机制，Dubbo的路由机制主要解决的问题是服务调用时，从已知的所有服务提供者中根据路由规则选择服务提供。

 

admin-parent最外层的父工程用来聚合子模块。

打jar包还是打war包？

1、服务提供者 admin-ucenter-service；

2、服务消费者 admin-ucenter-web；

3、将service层和service实现层分离；

项目部署

1 、启动注册中心

2 、找一个tomcat 放入dubbo-admin-2.8.4.war；

3、 启动server（service的具体实现类–服务提供者） ，这个时候进入 tomcat 的dubbo-admin 管理界面中可以看到 服务提供者，必须有服务提供者启动时，服务消费者才不会报错。

4、启动消费者 (服务启动者与服务消费者的启动是有先后顺序的)

 

核心问题：哪些内容你定义为服务启动者，哪些内容你定义为服务消费者？

使用dubbo架构的好处是什么？

 

Zookeeper注册中心

zookeeper：服务注册与发现中心；用于分布式中一致性处理的框架。

zookeeper的节点结构天然支持命名服务，即把信息集中存储，并以树状管理，方便统一查阅。

集群管理与master管理。分布式锁。树状管理。

 

将当前微服务注册到注册中心，要写上注册中心的地址。

1、Zookeeper:ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务;Zookeeper有配置维护、域名服务、分布式同步、组服务等这些功能，它可以通过投票选举机制选举出leader.

2、查看Zookeeper集群中的zookeeper节点的状态，会发现其中一个是leader，其余是follower。这就是zookeeper的投票选举机制，所以一般zookeeper为单数个节点的集群，这样投票容易一些；

 

Zookeeper=文件系统+通知机制。

1、 文件系统。Zookeeper维护一个类似文件系统的数据结构。

2、 通知机制。客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端.

使用Zookeeper进行配置管理。

程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。好吧，现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。

集群管理

所谓集群管理无在乎两点：是否有机器退出和加入、选举master。

对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入 也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了。

分布式锁

有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。

本文地址：https://blog.csdn.net/chenrushui/article/details/107342173