RPC框架Dubbo学习 --- Dubbo架构与实战（架构篇）
文章内容输出来源：拉勾教育Java高薪训练营。
本篇文章是 Dubbo学习课程中的一部分笔记。
1，Dubbo架构概述
1.1 什么是Dubbo
1.2 Dubbo的特性
参考官网首页 http://dubbo.apache.org/zh-cn/index.html
1.3 Dubbo的服务治理
在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。
当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
以上是 Dubbo 最基本的几个需求。
（来自Dubbo官网：http://dubbo.apache.org/zh-cn/docs/user/preface/requirements.html）
2，Dubbo处理流程
(虚线代表异步调用，实线代表同步访问，蓝色虚线程序启动时完成，红色虚线程序运行中完成)
注意：
第三步：提供者列表发生变更，Registry会基于长连接推送变更数据给消费者。
第四步：基于软负载均衡算法选则Provider。
节点说明：
| 节点 | 角色名称 |
| Provider | 暴露服务的服务提供方 |
| Consumer | 调用远程服务的服务消费方 |
| Registry | 服务注册与发现中心 |
| Monitor | 统计服务的调用次数喝调用时间的监控中心 |
| Container | 服务运行容器，负责启动加载运行服务提供者 |
（更多内容参考官网：http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html）
3，服务注册中心Zookeeper
（来自Dubbo官网：http://dubbo.apache.org/zh-cn/docs/user/references/registry/zookeeper.html）
Zookeeper 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [1]。
流程说明：
- 服务提供者启动时: 向
/dubbo/com.foo.BarService/providers目录下写入自己的 URL 地址 - 服务消费者启动时: 订阅
/dubbo/com.foo.BarService/providers目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers目录下写入自己的 URL 地址 - 监控中心启动时: 订阅
/dubbo/com.foo.BarService目录下的所有提供者和消费者 URL 地址。
支持以下功能：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置
<dubbo:registry check="false" />时，记录失败注册和订阅请求，后台定时重试 - 可通过
<dubbo:registry username="admin" password="1234" />设置 zookeeper 登录信息 - 可通过
<dubbo:registry group="dubbo" />设置 zookeeper 的根节点，不配置将使用默认的根节点。 - 支持
*号通配符<dubbo:reference group="*" version="*" />，可订阅服务的所有分组和所有版本的提供者
本文地址：https://blog.csdn.net/duanzy1994/article/details/107552504