我的dubbo笔记
DUBBO基本理念
dubbo的设计理念与rmi（Remote Method Invocation）相似，将方法注册到远程服务器，客户端却能够像调用本地方法一样调用服务。
rmi亦为dubbo的一个协议，项目的协议为dubbo
一个典型的 RMI 调用如下图所示：
- 服务端向 RMI 注册服务绑定自己的地址（RPC通信协议）；
- 客户端通过 RMI 注册服务获取目标地址；
- 客户端调用本地的 Stub 对象上的方法，和调用本地对象上的方法一致；
- 本地存根对象将调用信息打包，通过网络发送到服务端；
- 服务端的 Skeleton 对象收到网络请求之后，将调用信息解包；
- 然后找到真正的服务对象发起调用，并将返回结果打包通过网络发送回客户端。
DUBBO角色
服务提供者（provider）：启动时在指定端口上暴露服务，并将服务地址和端口注册到注册中心上。
服务消费者（customer）：启动时向注册中心订阅自己感兴趣的服务，以便获得服务提供方的地址列表。
注册中心 （register）：负责服务的注册和发现，负责保存服务提供方上报的地址信息，并向服务消费方推送。
监控中心（monitor）：负责收集服务提供方和消费方的运行状态，比如服务调用次数、延迟等，用于监控。
运行容器（container）：负责服务提供方的初始化、加载以及运行的生命周期管理。
DUBBO原理
中介：zookeeper
Client
调用服务的机器，每个Client启动时，主动与ConfigServer建立Socket长连接，并将自己的IP等相应信息发送给ConfigServer。
Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息（这样ConfigServer就知道某个服务是当前哪几个Client在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。
一旦Client使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），ConfigServer就会把最新的服务提供者列表推送给Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接
Server
真正提供服务的机器，每个Server启动时，主动与ConfigServer建立Scoket长连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer就会收集到每个Server提供的服务的信息。
DUBBO的应用
http://start.dubbo.io 快速生成dubbo应用
http://dubbo.apache.org/en-us/docs/user/quick-start.html dubbo文档
DUBBO注册文件
dubbo-provider.xml
dubbo-consumer.xml(controller引用)
添加service，需在dubbo-provider.xml将类名注入
<dubbo:service interface="com.pengji.linker.dubbox.services.modules.goodsmanager.service.IMasterCategoryService"
ref="masterCategoryService" protocol="dubbo" />
再创建接口及其实现，编写业务逻辑
引用service，在dubbo-consumer.xml引入
<dubbo:reference interface="com.pengji.linker.dubbox.services.modules.goodsmanager.service.IMasterCategoryService" id="masterCategoryService" check="false" />
这样就可以在controller中调用新建的service了
启动DubboProvider
再启动consumer
参考
https://blog.****.net/he90227/article/details/70157046/