文档背景
在很多后台服务的架构中，采用了RPC+微服务的架构思想。
RPC采用dubbo框架作为治理框架，对外接口采用RESTful和GraphQL接口方式
所以学习一下dubbo是很有必要的
1、什么是Dubbo
官网：https://dubbo.apache.org/zh/docs/
背景介绍
Apache Dubbo™ (incubating)是一款高性能Java RPC框架
duboo是由阿里团队开发的RPC框架，由Apache孵化
早期介绍
Dubbo是一个分布式框架，最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦。
从服务模型的角度，Dubbo采用的是一种非常简单的模型。1.提供服务方 2.消费方 3.第三方(注册中心、协议支持、服务监控)
1.1、什么是RPC
RPC（Remote Procedure Call Protocol）——远程过程调用协议，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。它假定某些传输协议的存在，如TCP或UDP，以便为通信程序之间携带信息数据。通过它可以使函数调用模式网络化。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
2、Dubbo服务治理
在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具。
简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。
弊端：
当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。
当进一步发展，服务间依赖关系变得复杂，无法描述架构关系。
服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
- Provider 暴露服务的提供方
- Concumer 调用远程服务的服务消费方
- Registry 服务注册与发现的注册中心
- Monitor 统计服务的调用次数和调用时间的监控中心
- Container 服务运行容器
调用关系
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
Dubbo架构具有一下几个特点：分别是连通性、健壮性、伸缩性、以及向未来架构的升级性
3、注册中心
注册中心有很多种，而Dubbo也支持很多注册中心，一般推荐使用Zookeeper。注册中心有点类似与SpringCloud中常用的微服务治理工具 Eureka。
3.1、为什么使用Zookeeper
Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务.
支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明:
- 服务提供者启动时: 向 dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
- 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向
/dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址 - 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。
支持以下功能：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置 <dubbo:registrycheck=“false” > 时，记录失败注册和订阅请求，后台定时重试
- 可通过 <dubbo:registryusername=“admin” password=“1234” /> 设置 zookeeper 登录信息
- 可通过 <dubbo:registrygroup=“dubbo”/ > 设置 zookeeper 的根节点，不设置将使用无根树
- 支持 * 号通配符 <dubbo:referencegroup=" * " version=" * "/ >,可订阅服务的所有分组和所有版本的提供者
4、Dubbo Admin
Dubbo提供了可视化的界面管理工具，方便我们对服务进行管理，它就是Dubbo Admin,
代码地址：https://github.com/apache/incubator-dubbo-ops
部署安装
第一步，下载并解压
git clone https://github.com/apache/incubator-dubbo-ops.git
第二步，修改配置文件
## 这里就是我们配置利用Docker安装好的 Zookeeper地址
在 dubbo-admin-backend/src/main/resources/application.properties 中指定注册中心地址。
第三步，使用maven进行构建项目(都要在Maven环境下执行)：
#构建 打包
mvn clean package
#通过Maven插件启动项目
mvn --projects dubbo-admin-backend spring-boot:run
最后，访问系统
打开浏览器：输入对应地址就行
该工具可以查看 搜索服务信息，可以查看服务提供者和服务消费者的详细信息
5、服务的负载均衡
在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 random 随机调用。
负载均衡的策略
Random LoadBalance
- 随机，按权重设置随机概率
- 在一个界面上碰撞的概率高，但调用越大分布越均匀，而且概率使用权重也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
- 轮询，按公约后的权重设置轮询比率。
- 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台就卡在那，久而久之，所有请求都会卡在第二台服务器上。
6、Dubbo://协议
dubbo提供9种协议，分别是
dubbo://
rmi://
hessian://
http://
webservice://
thrift://
memcached://
redis://
rest://
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远
大于服务提供者机器数的情况。
反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
- Transporter （传输）: mina, netty, grizzy
- Serialization（序列化）: dubbo, hessian2, java, json
- Dispatcher（分发调度）: all, direct, message, execution, connection
- ThreadPool（线程池）: fixed, cached
7、代码资源
写的一个消费者 RPC调用远端服务API，开启提供者多实例，测试 dubbo的随机调用和轮询机制。
核心测试类如下
配置好就可以启动了
@RunWith(SpringRunner.class)
@SpringBootTest
public class UserServiceTest {
@Reference(version = "1.0.0", loadbalance = "roundrobin")
private UserService userService;
@Test
public void testQueryAll() {
for (int i = 0; i < 100; i++) {
System.out.println("开始调用远程服务 >>>>>" + i);
List<User> users = this.userService.queryAll();
for (User user : users) {
System.out.println(user);
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
当出现如下说明dubbo的服务端启动成功并且成功将自己注册进了zookeeper
487
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
