Dubbo
1 RPC
RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
1.1 RPC场景
分布式系统
1.2 RPC实现
RMI、Dubbo等
2 Dubbo简介
在分布式服务架构下，各个服务间的RPC调用会越来越复杂。最终形成网状结构，服务治理变得极为关键。 Dubbo是一个带有服务治理功能（负载、容错等）的高性能、透明化的RPC框架。
Dubbo的核心部分包含：
- 远程通信
提供对多种基于长连接的NIO框架抽象封装，包括多种线程
模型、序列化以及“请求-响应”模式的信息交换方式。
- 集群容错
提供基于接口方法的透明远程过程调用，包括多协议支持以
及软负载均衡，失败容错、地址路由、动态配置等集群支持。
- 服务注册及发现
基于注册中心目录服务，使服务消费方能动态的查找提
供方，服务提供方可以平滑增加或减少机器。
2.1 Dubbo的架构及特点
Dubbo总体架构设计划分为10层：
服务接口层（service）
配置层（config）
服务代理层（proxy）
服务注册层（registry）
集群层（cluster）
监控层（monitor）
远程调用层（protocol）
信息交换层（exchange）
网络传输层（transport）
数据序列化层（serialize）
2.2 Dubbo角色关系
调用关系说明： 服务容器负责启动、加载、运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者从提供者地址列表中，基于负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
3 Dubbo的使用
3.1 xml方式
dubbo的功能标签：
<dubbo:service/>
服务配置，用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心。
<dubbo:reference/>
引用配置，用于创建一个远程服务代理，一个引用可以指向多个注册中心。
<dubbo:protocol/>
协议配置，用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受。
<dubbo:application/>
应用配置，用于配置当前应用信息，不管该应用是提供者还是消费者。
<dubbo:registry/>
注册中心配置，用于配置连接注册中心相关信息。
<dubbo:module/>
模块配置，用于配置当前模块信息，可选。
<dubbo:monitor/>
监控中心配置，用于配置连接监控中心相关信息，可选。
<dubbo:provider/>
提供方的缺省值，当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选。
<dubbo:consumer/>
消费方缺省配置，当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选。
<dubbo:method/>
方法配置，用于ServiceConfig和ReferenceConfig指定方法级别的配置信息。
<dubbo:argument/>
用于指定方法参数配置。
3.2 注解方式
Springboot集成dubbo：
https://blog.csdn.net/led1114/article/details/118280866
4 Dubbo的高级特性
4.1 Dubbo控制台搭建
git clone https://github.com/apache/dubbo-admin.git
4.2 Dubbo常用配置策略
4.2.1 启动时检查
Dubbo在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成。
默认为true，可以通过 check="false"关闭检查。
关闭某个服务的启动时检查（没有提供者时报错）：
<dubbo:reference id="xxxService" check="false" interface="com.xxx.XxxService"/>
关闭所有服务的启动时检查（没有提供者时报错）：
<dubbo:consumer check="false" />
关闭注册中心启动时检查（注册订阅失败时报错）：
<dubbo:registry check="false" />
4.2.2 超时
Dubbo 消费端在发出请求后，需要有一个临界时间界限来判断服务端是否正常。这样消费端达到超时时间，那么 Dubbo 会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间
<dubbo:reference id="xxxService" interface="com.xxx.XxxService"
retries="0" timeout="5000"/>
4.2.3 重试
Dubbo 在调用服务不成功时，默认会重试 2 次
Dubbo 的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 Dubbo 的重试机制也能一定程度的保证服务的质量
<dubbo:reference id="xxxService" interface="com.xxx.XxxService"
retries="5" timeout="5000"/>
4.2.4 集群容错（失败重试策略）
当消费端某次调用失败是一些环境偶然因素造成的（如网络抖动），dubbo还给予了容错补救机会。补救方式存在以下几种：
- failover
当出现失败，重试其它服务器。 retries=“2” 来设置重试次数(不含第一次)。幂等性操作使用，如读操作。
<dubbo:consumer cluster="failover” retries="2" forks="2" />
-
failfast
快速失败，只发起一次调用，失败立即报错。 -
failsafe
出现异常时，直接忽略，无关紧要的旁支操作，如记录日志。 -
failback
后台记录失败请求，定时重发后续专业处理。 -
forking
并行调用多个服务器，只要一个成功即返回forks=“2” 来设置最大并行数。
4.2.5 负载均衡策略
random 随机
roundRobin 轮询
leastActive 最少活跃数（正在处理的数），慢的机器，收到的请求少。
4.2.6 禁止注册/订阅
禁止注册
<dubbo:registry register="false"/>
<dubbo:service register="false"/>
禁止订阅
<dubbo:registry subscribe="false"/>
服务分组
使用一个注册中心分成多个环境来使用。
<dubbo:registry group="group1"/>
多版本
<dubbo:service version="1.0"/>
<dubbo:reference version="1.0"/>
结果缓存
<dubbo:consumer cache="lru"/>
<dubbo:reference cache="lru"/>
异步调用
<dubbo:consumer async="true"/>
5 Dubbo源码解读
5.1 SPI
场景：日志、JDBC驱动、spring等
5.1.1 JDK提供的SPI使用 
5.1.2 Dubbo中的SPI
5.2 Dubbo核心流程
未完待续，故事还将继续....