转载

关于Dubbo的记忆

现在微服务的概念已经很普遍了，目前的微服务框架主要有Dubbo、DubboX和Spring Cloud，关于Spring Cloud可以参考我的另一篇文章关于Spring Cloud 的记忆。本篇文章主要以Dubbo为例展开说明，在进行Dubbo模块之前，我们来说一下为什么要对系统进行拆分，简单来说可以总结为一下几点

随着业务的发展，单机版本不能满足业务需求，所以模块服务化是一个趋势，需要采用分布式架构来对系统进行拆分
如果不进行系统的拆分的话，大家一起来维护一套代码，那会出现各种代码冲突，解决起来非常耗时间，效率很低

当拆分的服务规模比较小的时候，各个模块之前可以直接通过http协议来进行通讯，但是http接口通信维护起来的成本是非常高的，我们得需要考虑超时重试、负载均衡等等各种分布式中的问题，所以这个时候就可以引入dubbo了，我们可以像调用本地接口一样来调用远程接口，dubbo会代理这个调用请求，去跟远程机器进行网络通信，同时可以解决负载均衡、超时重试等一些常见的问题。

二 Dubbo是什么

什么是RPC

RPC全名是Remote Procedure Call,远程过程调用，是一种通过网络从远程计算机上请求服务而不需要了解底层网络技术的协议。比如A、B两个服务部署在不同的服务器上，如果服务A想要来调用服务B的话，可以直接通过http来请求，我们在上面也说了，http存在很多问题，所以RPC的出现就解决了这些问题。RPC框架的调用过程。

什么是Dubbo Apache Dubbo是阿里开源的一款高性能、轻量级的RPC框架，Dubbo提供了服务治理(自动注册与发现)、智能容错、负载均衡等，简单的来说Dubbo就是一个分布式服务框架，致力于提供高性能和透明化的RPC远程调用方案。

当然任何框架，官方的文档是最详细的，大家也可以去了解一下dubbo的官方文档 dubbo.apache.org/en-us/

三 Dubbo的架构模式

3.1 Dubbo的架构图解

节点角色说明：

节点	角色说明
Provider	服务提供者
Consumer	服务消费者
Registry	服务注册发现中心
Monitor	监控中心
Container	服务运行容器

调用关系说明：

0.服务容器负责启动，加载，运行服务提供者。

1.服务提供者在启动时，向注册中心注册自己提供的服务。 2.服务消费者在启动时，向注册中心订阅自己所需的服务。 3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心，并以报表的形式展开

3.2 Dubbo的工作原理

图中从上到下分为十层，各层均为单向依赖，右边的黑色箭头代表各层之间的依赖关系，其中Service和Config层为API，其他各层均为SPI。

各层说明：

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

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

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

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

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

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

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

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

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

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

3.3 Dubbo支持的通讯协议和序列化协议

3.3.1 通信协议

dubbo协议
默认使用dubbo协议，单一长连接，非阻塞异步通信，基于hessian进行序列化，适用于传输数据量小，但是并发量很高的场景。
rmi协议
使用java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用。
hessian协议(Hessian是一个动态类型,二进制序列化,也是网络协议为了对象的定向传输)
使用hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用
http协议使用Json序列化协议
webservice协议
使用SOAP文本序列化协议

3.3.2 序列化协议

从上面的通信协议我们可以知道，基于不同的通信协议，dubbo支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。但是hessian是其默认的序列化协议。

3.4 Dubbo的负载均衡策略

Random LoadBalance(默认)
可以对不同的provider设置不同的权重，然后会根据权重来进行负载均衡的调用，权重高的分配的请求越多。
RoundRobin LoadBalance(不推荐)
均衡的将请求发送到provider，但是这样存在着一定的问题，可能会导致性能比较差的服务器负载过高，所以一般不推荐使用。
ConsistentHash LoadBalance(一致性Hash)
相同的请求肯定会到同一个provider，如果需要一类请求都到一个节点的话就可以使用这种。

3.5Dubbo服务集群容错模式

dubbo框架为服务集群容错提供了一系列好的解决方案，在此称为dubbo服务集群容错模式。

failover cluster模式(默认)
当出现失败时，重试其他服务器，为缺省值。通常用于读操作，但重试会带来更长的延迟。可通过可通过retries="2"来设置重试次数
failfast cluster模式
只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如：新增记录。
failsafe cluster模式
出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
Failback Cluster模式
后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster模式
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求比较高的读操作，但需要浪费更多的服务资源。
broadcacst cluster模式
逐个调用所有的 provider，任何一个provider出错则报错（从2.1.0 版本开始支持），通常用于通知所有提供者更新缓存或日志等本地资源信息。

3.6 Dubbo SPI

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下。

更多可以参考理解Dubbo的SPI机制

3.7 注册中心

注册中心有Multicast、Zookeeper、Nacos等，但是Dubbo官方推荐使用Zookeeper，所以在本文也使用Zookeeper,zk是Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心。下篇文章会对Zookeeper做详细的介绍，大家可以持续关注