Alibaba微服务技术系列「Dubbo3.0技术专题」回顾Dubbo2.x的技术原理和功能实现

将相本无种，男儿当自强。这篇文章主要讲述Alibaba微服务技术系列「Dubbo3.0技术专题」回顾Dubbo2.x的技术原理和功能实现相关的知识，希望能为你提供帮助。
RPC服务
什么叫RPC?

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
【Alibaba微服务技术系列「Dubbo3.0技术专题」回顾Dubbo2.x的技术原理和功能实现】5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。

RPC框架的目标就是要2~8这些步骤都封装起来，这些细节对用户来说是透明的，不可见的
netty通信原理BIO：(Blocking IO)

Alibaba微服务技术系列「Dubbo3.0技术专题」回顾Dubbo2.x的技术原理和功能实现

文章图片

NIO (Non-Blocking IO)

文章图片

Selector 一般称为选择器，也可以翻译为多路复用器，
Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）

Netty基本原理：

文章图片

Dubbo
基本简介框架设计

文章图片

config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory.
registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

启动解析、加载配置信息

文章图片

服务暴露

文章图片

服务引用

文章图片

基本组成

文章图片

服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

调用关系说明

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

环境搭建 windows-安装zookeeper

下载zookeeper网址 https://archive.apache.org/dist/zookeeper/zookeeper-3.4.13/
解压zookeeper解压运行zkServer.cmd ，初次运行会报错，没有zoo.cfg配置文件
修改zoo.cfg配置文件将conf下的zoo_sample.cfg复制一份改名为zoo.cfg即可。注意几个重要位置：dataDir=./临时数据存储的目录（可写相对路径）clientPort=2181zookeeper的端口号修改完成后再次启动zookeeper
使用zkCli.cmd测试ls /：列出zookeeper根下保存的所有节点create –e /atguigu 123：创建一个atguigu节点，值为123get /atguigu：获取/atguigu节点的值

windows-安装dubbo-admin管理控制台

dubbo本身并不是一个服务软件。它其实就是一个jar包能够帮你的java程序连接到zookeeper，并利用zookeeper消费、提供服务。所以你不用在Linux上启动什么dubbo服务。
但是为了让用户更好的管理监控众多的dubbo服务，官方提供了一个可视化的监控程序，不过这个监控即使不装也不影响使用。
下载dubbo-adminhttps://github.com/apache/incubator-dubbo-ops
进入目录，修改dubbo-admin配置修改 src\\main\\resources\\application.properties 指定zookeeper地址
打包dubbo-adminmvn clean package -Dmaven.test.skip=true
运行dubbo-adminjava -jar dubbo-admin-0.0.1-SNAPSHOT.jar注意：【有可能控制台看着启动了，但是网页打不开，需要在控制台按下ctrl+c即可默认使用root/root 登陆

Dubbo配置
配置原则

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。
Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

重试次数

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries=" 2" 来设置重试次数(不含第一次)。

重试次数配置如下：

< dubbo:service retries="2" /> 或< dubbo:reference retries="2" /> 或< dubbo:reference> < dubbo:methodname="findFoo" retries="2" /> < /dubbo:reference>

超时时间
Dubbo消费端全局超时配置

< dubbo:consumer timeout="5000" /> 指定接口以及特定方法超时配置 < dubbo:referenceinterface="com.foo.BarService" timeout="2000"> < dubbo:method name="sayHello" timeout="3000"/> < /dubbo:reference>

Dubbo服务端全局超时配置

< dubbo:provider timeout="5000" /> 指定接口以及特定方法超时配置 < dubbo:providerinterface="com.foo.BarService" timeout="2000"> < dubbo:method name="sayHello" timeout="3000"/> < /dubbo:provider>

配置原则

作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等。
在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。

配置的覆盖规则：

方法级配置别优于接口级别，即小Scope优先
Consumer端配置优于 Provider配置优于全局配置，
最后是Dubbo Hard Code的配置值（见配置文档）

文章图片

版本号

可以按照以下的步骤进行版本迁移：
在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：

< dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服务提供者配置：

< dubbo:service interface="com.foo.BarService" version="2.0.0" />

老版本服务消费者配置：

< dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

新版本服务消费者配置：

< dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

如果不需要区分版本，可以按照以下的方式配置：

< dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

高可用 zookeeper宕机与dubbo直连

现象：zookeeper注册中心宕机，还可以消费dubbo暴露的服务。
原因：健壮性

监控中心宕掉不影响使用，只是丢失部分采样数据
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

集群下dubbo负载均衡配置负载均衡策略
Random LoadBalanceRoundRobin LoadBalanceLeastActive LoadBalanceConsistentHash LoadBalance整合hystrix，服务熔断与降级处理服务降级
什么是服务降级？向注册中心写入动态配置覆盖规则：

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension(); Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181")); registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators& dynamic=false& application=foo& mock=force:return+null"));

其中：

mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

集群容错
集群容错模式 Failover Cluster重试次数配置如下：

< dubbo:service retries="2" /> 或 < dubbo:reference retries="2" /> 或 < dubbo:reference> < dubbo:method name="findFoo" retries="2" /> < /dubbo:reference>

Failfast fastFailsafe SafeFailback overForking ClusterBroadcast Cluster集群模式配置

< dubbo:service cluster="failsafe" /> 或 < dubbo:reference cluster="failsafe" />

整合hystrix置spring-cloud-starter-netflix-hystrix

< dependency> < groupId> org.springframework.cloud< /groupId> < artifactId> spring-cloud-starter-netflix-hystrix< /artifactId> < version> 1.4.4.RELEASE< /version> < /dependency>

然后在Application类上增加@EnableHystrix来启用hystrix starter：

@SpringBootApplication @EnableHystrix public class ProviderApplication {

配置Provider端
在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理。

@Service(version = "1.0.0") public class HelloServiceImpl implements HelloService { @HystrixCommand(commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "https://www.songbingjia.com/android/10"), @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "https://www.songbingjia.com/android/2000") }) @Override public String sayHello(String name) { // System.out.println("async provider received: " + name); // return "annotation: hello, " + name; throw new RuntimeException("Exception to show hystrix enabled."); } }

配置Consumer端

@Reference(version = "1.0.0") private HelloService demoService; @HystrixCommand(fallbackMethod = "reliable") public String doSayHello(String name) { return demoService.sayHello(name); } public String reliable(String name) { return "hystrix fallback value"; }

寻找注册中心、服务提供者、服务消费者（启动加载篇-源码分析） Dubbo自定义标签实现。

注册中心启动，监听消息提供者的注册服务、接收消息消费者的服务订阅（服务注册与发现机制）。
服务提供者向注册中心注册服务。
服务消费者向注册中心订阅服务。

接下来从使用dubbo的角度，从配置文件入手：
Dubbo服务提供者的一般配置如下：

< !-- 提供方应用信息，用于计算依赖关系 --> < dubbo:application name="uop" owner="uce"/> < !-- 使用zookeeper注册中心暴露服务地址 --> < dubbo:registry protocol="zookeeper" address="zookeeper://192.168.xx.xx:2181?backup=192.168.xx.xx:2182,192.168.xx.xx:2183" /> < !--dubbox中引入Kryo和FST这两种高效Java序列化实现，来逐步取代原生dubbo中的hessian2,如果使用kryo记得添加依赖 --> < dubbo:protocol name="dubbo" serialization="kryo"port="20990"/> < !-- 定义服务提供者默认属性值 --> < dubbo:provider timeout="5000" threadpool="fixed"threads="100" accepts="1000" token="true"/> < !-- 暴露服务接口一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心--> < !--Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题--> < dubbo:service interface="com.yingjun.dubbox.api.UserService" ref="userService" />

Spring自定义标签实现原理DubboNamespaceHandler

public class DubboNamespaceHandler extends NamespaceHandlerSupport {static { Version.checkDuplicate(DubboNamespaceHandler.class); }@Override public void init() { registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true)); registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfig.class, true)); registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true)); registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true)); registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true)); registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true)); registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true)); registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true)); registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false)); registerBeanDefinitionParser("annotation", new AnnotationBeanDefinitionParser()); } }

定义dubbo.xsd 文件
Bean解析机制