Dubbo是阿里推出的rpc框架，目前业界使用的比较多的rpc框架，经过大量的企业验证其性能。
1.服务注册于发现机制
使用官方的注册于发现的机制图：

具体有4类角色：

• Registry
  注册中心
• Consumer
  服务调用者、消费端
• Provider
  服务提供者
• Monitor
  监控中心

具体整个服务间的调用流程如下：
1、服务提供者启动的时候会访问注册中心，进行服务的注册
2、服务消费者在启动的时候会访问注册中心，向注册中心订阅指定需要的服务，注册中心会通过某种机制（主动推或消费端拉）模式告知消费端服务提供者的列表（可能存在多个地址，服务提供者的高可用）
3、当服务提供者有变化时（服务提供者扩容、减少、或服务不可用），注册中心需要通知服务消费端，让服务消费方得知哪些服务不可用，及时去除不可用服务
4、服务提供者、消费者之间都会定时向监控中心汇报TPS或其他信息的调用数据，以便监控中心进行可视化的展示，便于进行监控交易

Zookeeper是Dubbo官方提供的最常用的注册中心（后简称zk）
zk中的数据有4种目录结构

• providers
  服务提供者列表
• consumers
  服务消费者列表
• routers
  路由规则列表，一个服务可以设置多个路由规则，怎么设置后续会讲解
• configurators
  条目，可以动态配置的条目，在dubbo中可以不用重启消费者、服务提供者的情况下动态修改服务提供者、服务消费者的配置信息，例如修改线程数量、超时时间等一些服务参数，并可以实时生效

基于ZK注册服务的细节如下：
1、服务提供者启动时候将会连接注册中心，并注册服务相关信息，主要是在对应服务的providers目录下增加一条记录（临时节点），并且它还会监听configurators目录，以便拿到相关配置以及路由信息
2、服务消费者启动时候将会连接注册中心，并订阅它关心的服务信息，主要是在对应服务的consumers目录下增加一条记录（临时节点），并且它还会监听configurators和routers目录，以便拿到相关配置以及路由信息
3、由于当有新的服务提供者上线时，providers目录下回新增一条记录，消费者由于监听了服务提供者目录，那么最新的服务提供者列表会推送给服务调用方（消费端）；服务提供者如果宕机了，由于在providers目录下创建的是临时节点，zk就会将该宕机的节点移除，同样也会触发将最新的服务提供者列表推送给消费者，从而实现路由的动态注册于发现了
4、当dubbo服务又新版本或者新功能上线时，可以对该服务进行灰度发布，可以通过dubbo-admin管理台进行添加路由规则，最终会写入到指定服务的router节点（这个是持久节点），服务调用方会监听该节点的信息变化，从而可以感知到路由信息的变化，获取到最新的路由信息，将用于服务提供者的筛选，实现灰度发布的功能
5、configurators节点也是持久节点，变更会通知相关服务

注册中心宕机会对整个服务体系有影响吗？
注册中心宕机后，整个服务调用还是能正常工作的不会影响服务之间的调用，但是服务的注册与发现不能正常进行了
注册中心相应慢导致超过了zk的会话超时时间，会将造成影响，超过会话超时时间后，导致会触发所有临时节点被删除，最终导致消费端无法感知服务提供者（这些可能会由于Full GC导致相应变慢）

服务调用
dubbo的服务调用的实现很完美，如下图

服务调用，主要是客户端发起一个RPC服务调用时的所有实现细节，包括服务发现、故障转移、路由转发、负载均衡等方面，是Dubbo实现灰度发布的理论基础
服务发现
客户端在向服务端发起请求时，我需要知道要调用哪些服务，通常单体架构或者以前的方式是配置文件中配置固定，这种静态化配置有很多弊端：如果需要调用的服务众多，配置文件会变得臃肿，对扩容缩容的管理、机器宕机等变更不友好，管理非常困难
微服务情况下的动态发现，通常基于注册中心实现服务的注册与动态发现
负载均衡
其实Dubbo中不仅提供了负载均衡机制，还提供了智能路由机制，这是实现Dubbo灰度发布的理论基础。

所谓的路由机制，是在服务提供者列表中，再设置一定的规则，进行过滤选择，负载均衡时只从路由过滤规则筛选出来的服务提供者列表中选择，为了更加形象的阐述路由机制的工作原理，给出如下示意图：

上述设置了一条路由规则，即查询机构ID为102的查询用户请求信息，需要将请求发送到新版本，即192168.3.102上，那主要在进行负载均衡之前先执行路由规则，从原始的服务提供者列表者按照路由规则进行过滤，从中挑选出符合要求的提供者列表，然后再进行负载均衡。
路由机制的核心理念：在进行负载均衡之前先对服务提供者列表运用路由规则，得出一个参与负载均衡的提供者列表。
——————————————
版权声明：本文为CSDN博主「中间件兴趣圈」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/prestigeding/article/details/112724807

故障转移
远程服务调用通常涉及到网络等因素，客户端向服务提供者发起RPC请求调用时并不一定100%成功，当调用失败后该采用何种策略呢？
Dubbo提供了如下策略：
failover
失败后选择另外一台服务提供者进行重试，重试次数可配置，通常适合实现幂等服务的场景。
failfast
快速失败，失败后立即返回错误。
failsafe
调用失败后打印错误日志，返回成功，通常用于记录审计日志等场景。
failback
调用失败后，返回成功，但会在后台定时无限次重试，重启后不再重试。
forking
并发调用，收到第一个响应结果后返回给客户端。通常适合实时性要求比较高的场景，但浪费服务器资源，通常可以通过forks参数设置并发调用度
线程派发机制
Dubbo的通信线程模型入下图所示:

• 网络通信协议
  网络传输通常需要自定义通信协议，通常采用 Header + Body 的协议设计理念，并且 Header 长度固定，并且包含一个长度字段，用于记录整个协议包的大小。
  网络传输为了提高传输效率，可以采取对传输数据进行压缩，通常是对 body 进行序列化与压缩。
  Dubbo支持目前支持 java、compactedjava、nativejava、fastjson、fst、hessian2、kryo等序列化协议。
• 线程派发机制
  在Dubbo中默认会创建200个线程用于处理业务方法，所谓的线程派发机制就是IO线程如何决定何种请求转发到哪类线程中执行。
  目前Dubbo中所有的心跳包、网络读写在IO线程中执行，无法通过配置进行修改,具体可以通过配置进行相应的修改
  Dubbo提供了如下几种线程派发机制(Dispatcher)：
  all
  所有的请求转发到业务线程池中执行（除IO读写、心跳包）
  message
  只有请求事件在线程池中执行，其他在IO线程上执行。
  connection
  请求事件在线程池中执行，连接、断开连接事件排队执行（含一个线程的线程池）。
  direct
  所有请求直接在IO线程中执行
  线程派发机制之所有会有多种策略，主要是考虑线程切换带来的开销是否能容忍，即线程切换带来的开销小于多线程处理带来的提升。
  例如在Dubbo中，对心跳包只需直接返回PONG包（OK），逻辑非常简单，如果将其转换到业务线程池，并不能带来性能提升，反而因为需要线程切换，带来性能损耗，故在IO线程中直接发送响应包是一个非常可取的做法。
  在网络编程中需要遵循一条最佳实践：IO线程中不能有阻塞操作，阻塞操作需要转发到业务线程池

Dubbo服务治理之灰度发布方案

基于Dubbo服务的治理，是否可以支持业务级别的灰度发布、是否基于业务参数的路由转发。例如以GIS为例，当发布一个新版本时，是否可以以按照解析地址或合作伙伴来区分，版本发布之初，只希望地址为：广东省的解析请求发送到新版本，而其他的地址请求还是使用旧版；或者根据合作伙伴例如UCP(优享寄)的请求转发到新版本服务器，其他合作伙伴还是转发到旧版，达成业务级别的灰度发布，控制新版本的影响范围。例如OMS系统，可以根据合作伙伴，将重量级客户的请求转发到单独的服务器集群，确保其高可用
Dubbo的服务调用原理图：

客户端在发起RPC服务调用之前，在客户端首先从服务器列表中选择一个服务调用者，包含如下关键角色：
1、Directory
服务的动态发现，通常基于注册中心进行服务的动态注册与发现，其具体实现类为RegistryDirectory。
2、Router 路由实现，其含义是根据Directory发现的所有服务提供者列表中，进行路由选择，也就是根据一定的路由规则选择合适的服务提供者，为Directory发现的服务提供者列表子集，可以基于Condition或脚本（默认为JS脚本，其实现类为ScriptRouter）。
3、LoadBalance
负载均衡机制，其作用主要是根据负载均衡算法（随机、轮询）
等算法，从（Directory–>Router）中返回的服务提供者列表中选择一个服务提供者，进行本次的RPC服务调用。
4、Cluster
集群（容错机制），就是当从服务提供者列表中按照负载均衡算法选择一个服务提供者，进行RPC服务调用后，发送了异常后的策略，例如failover(重试)、failfast(快速失败)等。
服务的灰度发布，其目标是希望根据请求，某些请求走新版本服务器，某些请求走旧版本服务器，其本质就是路由机制，即通过一定的条件来缩小服务的服务提供者列表，正好与Dubbo的Router相吻合。有关于Dubbo的Router机制，请参考官方文档第【46、47、48】页，如果想从源码的角度了解其实现机制，请参考博文：https://blog.csdn.net/prestigeding/article/details/80848594
上述展示了Dubbo服务基于业务灰度发布的方案，以及基于合作伙伴的服务隔离机制（根据服务调用业务参数来决定服务调用者的筛选）。主要是展示了基于脚步的路由规则，其条件表达式的路由规则请参考其Demo，其核心理论支持是Dubbo提供的Router，在进行负载均衡前，根据路由规则对服务提供者列表进行筛选

原文见： https://blog.csdn.net/prestigeding/article/details/83057273