一、dubbo

Dubbo 是一个分布式、高性能、透明化的 RPC （Remote Procedure Call ，远程过程调⽤）服务框架，提供服务自动注册、自动发现等服务治理方案。采⽤微内核设计+SPI扩展。

二、dubbo分层架构

• Service，业务层。开发的业务逻辑层。
• Config，配置层。主要通过 ServiceConfig 和 ReferenceConfig 初始化配置信息。
• Proxy，代理层。服务提供者、消费者都会⽣成⼀个代理类，使得服务接⼝透明化，代理层做远程调⽤和返回结果。
• Register，注册层。服务注册和发现。
• Cluster，路由和集群容错层。负责选取具体调⽤的节点，处理特殊的调⽤要求和负责远程调⽤失败的容错措施。
• Monitor，监控层。负责监控统计调⽤时间和次数。
• Portocol，远程调⽤层。封装 RPC 调⽤，负责管理 Invoker，Invoker代表⼀个抽象封装了的执⾏体。
• Exchange，信息交换层。封装请求响应模型，同步转异步。
• Transport，⽹络传输层。抽象了⽹络传输的统⼀接⼝，可以⽤ Netty或 Mina。
• Serialize，序列化层。将数据序列化成⼆进制流，也做反序列化。

dubbo完整流程

三、dubbo注册服务

⾸先 provider 启动，通过 proxy 组件根据具体的协议 protocol 将需要暴露出去的接⼝封装成 Invoker，invoker 代表⼀个可执⾏体。再通过 export 包装，这是为了在注册中⼼暴露⾃⼰套的⼀层，然后将 exporter 通过registry 注册到注册中⼼。 这就是注册服务过程。
proxy，protocol，invoker，export，registry。

四、dubbo消费服务

⾸先，消费者启动时会从注册中⼼拉取服务提供者的元信息。
调⽤流程也是从 proxy 开始，毕竟都需要代理才能⽆感知。proxy 持有⼀个 invoker 对象，调⽤ invoke 之后需要通过 cluster 先从 directory 获取所有可调⽤的远程服务的 invoker 列表，如果配置了某些路由规则，⽐如某个接⼝只能调⽤某个节点，那就再过滤⼀遍invoker 列表。
剩下的 invoker 再通过 loadBalance 做负载均衡选取⼀个。然后再经过 filter 做统计等，再通过 vlient 做数据传输，⽐如⽤ netty 来传输。传输需要经过 codec 接⼝做协议构造，再序列化。最终发往对应的服务提供者。
服务提供者接收到之后也会进⾏ codec 协议处理，然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 exporter ，⽽找到 exporter 其实就是找到了invoker，但是还会有⼀层层Filter，经过过滤链之后最终调⽤实现类然后原路返回结果。
proxy，invoker，cluster，directory，loadbalance，filter，codec，seriable
codec，dseriable、filter、exporter、invoker

五、dubbo 通信协议

• dubbo， 单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步，Hessian 序列化。默认
• rmi，采用 JDK 标准的 rmi 协议实现，java 标准序列化机制，使用阻塞式短连接，可传文件，传输协议 TCP。
• webservice， 基于webService 的远程调用协议。基于 http传输，适用系统集成和跨语言调用。
• http， 基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。
• hessian， 集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。
• memcache， 基于 memcached 实现的 RPC 协议
• redis： 基于 redis 实现的 RPC 协议

六、dubbo 注册中心

• multicast 注册中心，不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现。
• zookeeper 注册中心，利用Zookeeper 的 watch 机制实现数据变更。
• redis 注册中心， 基于 redis 实现，采用 key/Map 存储，住 key 存储服务名和类型，Map 中 key 存储服务 URL，value 服务过期时间。基于 redis 的发布/订阅模式通知数据变更。
• simple 注册中心

七、dubbo消费者负载均衡

• random ，随机选取提供者，可以动态调整提供者权重。
• roundRobin ，轮循选取提供者，平均分布，但存在请求累积的问题。
• leastActive ，最少活跃调用，解决慢提供者接收更少的请求。
• constantHash ， 一致性 Hash ，相同参数请求总是发到同一提供者。一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动。

八、dubbo消费者的容错方案

• failover （默认），失败自动切换。用于读操作，但重试会带来更长延迟。
• failfast ，快速失败，只发起一次调用，失败立即报错。用于非幂等性的写操作，比如新增记录。
• failsafe ，失败安全，出现异常时，直接忽略。用于写入审计日志等操作。
• failback ，失败自动恢复，后台记录失败请求，定时重发。用于消息通知操作。
• forking ，并行调用多个服务器，只要一个成功即返回。用于实时性要求较高的读操作，但需要浪费更多服务资源。
• broadcast ，广播调用所有提供者，任意一台报错则报错 。用于通知所有提供者更新缓存或日志等本地资源信息。

九、dubbo 支持的序列化方法

hessian 序列化（默认），duddo、fastjson、Java 自带序列化。

十、补充其他

dubbo 超时时间

推荐服务提供者端设置超时时间，因为服务提供者比消费者更清楚自己提供的服务特性。
服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。
dubbo 在调用服务不成功时，默认重试两次。

dubbo 的安全机制

Dubbo 通过 Token 令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo 还提供服务黑白名单，以控制服务所允许的调用方。

dubbo与spring

Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何API 侵入，只需用 Spring 加载 Dubbo 的配置即可，Dubbo 基于Spring 的 Schema 扩展进行加载。

dubbo与spring cloud

Dubbo 底层使用NIO 框架 Netty ，是基于TCP ，配合以 Hession 序列化完成 RPC 通信。
SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信。相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是REST 相比 RPC 更为灵活，服务提供方和调用方不存在代码级别的强依赖。
Dubbo 是 SOA 时代的产物，关注于服务的调用，流量分发、流量监控和熔断。Spring Cloud 诞生于微服务时代，考虑的是微服务治理。
Dubbo 定位服务治理、Spirng Cloud 是一个生态。

核心组件的连接关系

注册中⼼、提供⽅和消费⽅之间都是⻓连接，和监控⽅不是⻓连接，并且消费⽅是直接调⽤提供⽅，不经过注册中⼼。
服务提供者在zk上是最后的节点是临时节点。前面的/dubbo/com.xxxx/providers是持久化节点。

问题归纳

• 1、Dubbo调用接口，该接口抛出的运行时异常，在调用函数里面无法捕获的。
• 2、一个经典问题： Forbid consumer 127.0.0.1 access service XXXX from registry localhost:2181 use dubbo version 2.9.2-SNAPSHOT, Please check registry access list (whitelist/blacklist).
  这个错误一般表面上说禁止消费服务，实际上开发人员并没有做任何限制。其实，这个问题一般由两种情况引起的
  （1）第一种情况：没有provider提供对应的服务
  （2）第二种情况：消费者消费的服务的“版本号 version”和生产者提供的服务的“版本号 version”不一致，或者没有显式说明版本号。

参考