dubbo的工作原理

5. Dubbo的工作原理

第一层： service层，接口层，给服务提供者和消费者来实现的

第二层： config层，配置层，主要是对Dubbo进行各种配置的

第三层： proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton

第四层： registry层，服务注册层，负责服务的注册与发现

第五层： cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例这成一个服务

第六层： monitor层，监控层，对rpc接口的调用次数和调用时间进行监控

第七层： protocol层，远程调用层，封装rpc调用

第八层： exchange层，信息交换层，封装请求响应模式，同步转异步

第九层： transport层，网络传输层，抽象mina和netty为统一接口

第十层： serialize层，数据序列化层

工作流程：

(1). provider向注册中心去注册

(2). consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务

(3). consumer调用provider

(4). consumer和provider都异步的通知监控中心

6. 注册中心挂了可以继续通信吗？

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，按照本地缓存的地址进行调用，就算注册中心挂了也可以继续通信。

如果要调用新的服务，则是不行的。

7. Dubbo的执行流程

项目一启动，加载配置文件的时候，就会初始化，服务的提供方Provider就会向注册中心注册自己提供的服务，当消费者在启动时，就会向注册中心订阅自己所需要的服务，如果服务提供方有数据变更等，注册中心将基于长连接的形式推送变更数据给消费者。

默认使用Dubbo协议：
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hession二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用Dubbo协议传输大文件或超大字符串
使用场景：常规远程服务方法调用

从上面的适用范围总结，dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，不适合传输大数据量的服务比如文件、视频等，除非请求量很低。

8. Dubbo的安全性如何得到保障

(1). 在有注册中心的情况下，可以通过dubbo admin中的路由规则，来指定固定ip的消费方来访问。
(2). 在直连的情况下，通过在服务的提供方设置密码（令牌）token，消费方需要在消费时也输入这个密码，才能够正确调用。
(3). Dubbo添加服务ip白名单，防止不法调用。

9. Dubbo中如何保证分布式服务

一般情况下，我们尽量将需要事务的方法放在一个service中，从而避开分布式事务。

Dubbo的底层是基于Socket：Socket通信是一个全双工的方式，如果有多个线程同时进行远程方法调用，这时建立在client与server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是乱七八糟的，server处理完结果后，将结果消息发送给client，client会受到很多消息，怎么知道哪个消息结果是原先哪个线程调用的呢？

答：使用一个唯一ID，然后传递给服务端，在服务端又回传回来，这样就知道是原先哪个线程了。

Dubbo本身目前是暂时不支持分布式事务的，可与通过 tcc-transaction 框架实现。

10. Dubbo的心跳机制

目的：维持provider和consumer之间的长连接

实现：Dubbo心跳时间heartbeat默认是1s，超过heartbeat时间没有收到消息，就发送心跳消息（provider，consumer一样），如果连着3次（heartbeatTimeout为heartbeat*3）没有收到心跳响应，provider会关闭channel（信道），而consumer会进程重连。

不论是provider还是consumer的心跳检测都是通过启动定时任务的方式实现。