Dubbo

Dubbo工作流程：
(1). provider向注册中心去注册
(2). consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
(3). consumer调用provider
(4). consumer和provider都异步的通知监控中心

Dubbo的心跳机制
目的：维持provider和consumer之间的长连接
实现：Dubbo心跳时间heartbeat默认是1s，超过heartbeat时间没有收到消息，就发送心跳消息（provider，consumer一样），
如果连着3次（heartbeatTimeout为heartbeat*3）没有收到心跳响应，provider会关闭channel（信道），而consumer会进程重连。
不论是provider还是consumer的心跳检测都是通过启动定时任务的方式实现

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

默认使用Dubbo协议：
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hession二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，
尽量不要使用Dubbo协议传输大文件或超大字符串
使用场景：常规远程服务方法调用
从上面的适用范围总结，dubbo适合小数据量大并发的服务调用，以及消费者机器远大于生产者机器数的情况，
不适合传输大数据量的服务比如文件、视频等，除非请求量很低。

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

Dubbo中如何保证分布式服务
一般情况下，我们尽量将需要事务的方法放在一个service中，从而避开分布式事务。
Dubbo的底层是基于Socket：Socket通信是一个全双工的方式，如果有多个线程同时进行远程方法调用，
这时建立在client与server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是乱七八糟的，
server处理完结果后，将结果消息发送给client，client会受到很多消息，怎么知道哪个消息结果是原先哪个线程调用的呢？
答：使用一个唯一ID，然后传递给服务端，在服务端又回传回来，这样就知道是原先哪个线程了。
Dubbo本身目前是暂时不支持分布式事务的，可与通过 tcc-transaction 框架实现。

Dubbo支持的集群有6种容错方案

1. Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
2. Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
3. Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
4. Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
5. Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源
6. Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。