【学习打卡】第13天 Dubbo学习

课程名称：Java架构师-技术专家
课程章节：第25周 服务治理的另一条路 - Dubbo
主讲老师：慕课讲师团：Geely、风间影月、阿神……

课程内容：

1、认识 RPC 和 Dubbo

1.1、认识RPC

RPC 全称 Remote Procedure Call，使用RPC都需要自定义 RPC 协议

1.2、RPC vs REST HTTP

• RPC 面向执行过程
• REST HTTP 面向所操作的资源

问：RPC那么好，为啥还用 SpringCloud
答：RPC 再好也就是服务治理框架，并不能解决所有微服务问题

1.3、Dubbo的特性

Dubbo是一款轻量级+ 高性能的RPC 框架，Dubbo的很多理念和SpringCloud中的组件都差不多。
（1）基于接口+动态代理的远程方法调用
Dubbo 对开发这屏蔽了底层的调用细节，在实际代码中调用远程服务就像调用一个本地接口类一样方便。这个功能和Feign很类似。
（2）负载均衡
Dubbo内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。这部分功能和 Ribbon十分接近，但是Dubbo的负载均衡策略不如Ribbon 的多，而且Dubbo的负载均衡能力只能供自己享用，而 Ribbon 可以赋能给SpringCloud 里的各个组件。
（3）集群容错
Dubbo提供了一个Culster组件专门用来做集群容错，它其实并不是Hystix这类降级组件，而是一种”异常重试”组件。
（4）服务治理
支持多种注册中心服务，服务实例上下线实时感知。
服务注册、服务发现、服务下线之类的流程，这里的功能和Eureka里的概念是一模一样的，只是实现方式却大有不同。比如Dubbo在服务下线后会主动将可用服务列表下发到各个服务节点，送货上门服务周到，而Eureka每次都等着服务节点自己上注册中心拿数据，不给包邮的。
Dubbo的技能加点比较专一，全点在了 服务治理系，但论体系的化，是不可能和SpringCloud 相提并论的。

1.4、Dubbo架构

Dubbo有五个基础组件，下面图中紫色线条带代表了组件初始化的路径，蓝色虚线是异步通知流程，蓝色实线则是同步阻塞调用。

上图中出现的五个组件分别对应如下功能

• Start：服务容器启动后初始化服务提供者
• Register：服务提供者在启动的过程中，向注册中心发起注册，这个步骤和Eureka的流程很像
• Subscribe：服务消费者在启动的同时，向注册中心订阅所需的服务。这一个流程就和Eureka大不相同了，Eureka是Consumer主动到服务中心去拉取数据，而Dubbo采用了 一种 Pub/Sub模式，也就是发布订阅模式。
• Notify：注册中心将Provider地址列表发送给消费者，对于服务下线之类的变更，注册中心会主动推送变更数据到Consumer（建立在长连接之上）
• invoke：服务消费者发起远程调用，这个过程会使用负载均衡算法挑选目标服务器。
• Count：Consumer 和 Provider 每隔一段时间将统计信息发送到监控中心，平时这些信息就暂存于内存当中。

1.5、Dubbo 和 Eureka 中服务发现的不同

服务发现应该是 Dubbo和Eureka 最大的一个不同之处。
Dubbo里的注册中心、Provider和Consumer三者之间都是长连接，借助于Zookeeper的高吞吐量，实现基于为服务端的服务发现机制。因此Dubbo利用Zookeeper+发布订阅模型可以很快将服务节点的上线和下线同步到Consumer集群。如果服务提供者宕机，那么注册中心的长连接会立马感知到这个时间，并且立即推送到消费者。

Eureka使用客户端的服务发现机制，因此对服务列表的变动响应会稍慢，比如在某台机器下线以后，在一段时间内可能还会陆续有服务请求发送过来，当然这些请求会收到 Service Unavaliable的异常，需要借助Ribbon或Hystix实现重试或者降级措施。

对于注册中心宕机的情况，Dubbo和Eureka的处理方式相同，这两个框架的服务节点都本地缓存 了服务提供者的列表，因此仍然可以发起调用，但服务提供者列表无法被更新，因此可能导致本地缓存的服务状态与实际情况有别。

学习收获

今天学习了

1. RPC 和HTTP 的区别
2. dubbo的特性以及和 springcloud 的区别
3. dubbo架构及核心组件
4. dubbo的工作原理，dubbo 和 eureka 的不同