我的dubbo笔记

DUBBO基本理念

dubbo的设计理念与rmi（Remote Method Invocation）相似，将方法注册到远程服务器，客户端却能够像调用本地方法一样调用服务。

rmi亦为dubbo的一个协议，项目的协议为dubbo

一个典型的 RMI 调用如下图所示：

1. 服务端向 RMI 注册服务绑定自己的地址（RPC通信协议）；
2. 客户端通过 RMI 注册服务获取目标地址；
3. 客户端调用本地的 Stub 对象上的方法，和调用本地对象上的方法一致；
4. 本地存根对象将调用信息打包，通过网络发送到服务端；
5. 服务端的 Skeleton 对象收到网络请求之后，将调用信息解包；
6. 然后找到真正的服务对象发起调用，并将返回结果打包通过网络发送回客户端。

 

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.youkuaiyun.com/he90227/article/details/70157046/

https://blog.youkuaiyun.com/hasser1/article/details/80728623

https://github.com/apache/incubator-dubbo