了解dubbo和zookeeper

什么是dubbo？

dubbo是阿里巴巴开源的基于Java的高性能，轻量级的RPC分布式服务框架，提供服务自动注册，自动发现等高效服务治理方案，可以与Spring框架无缝集成，因为是阿里巴巴开源的项目，国内很多互联网公司都在用，使用dubbo可以将核心业务抽取出来，作为独立的服务，逐渐作为稳定的服务中心，可用于提高业务的复用灵活扩展，使前端应用快速响应多变的市场需求。

dubbo的使用场景

1. 服务自动注册和发现：不需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加和删除服务提供者；

2. 透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入

3. 软负载均衡及容错机制：可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

dubbo核心功能

1. Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括"同步转异步"和"请求-响应"模式的信息交换方式

2. Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持

3. Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加和减少机器。

dubbo核心组件

• Provider：暴露服务的服务提供方
• Consumer：用远程服务消费方
• Registry：服务组册与发现注册中心
• Monitor：监控中心和访问调用统计
• Container：服务运行容器

dubbo服务注册与发现的流程

服务容器Container：负责启动，加载，运行服务提供者

服务提供者Provider：在启动时，向注册中心注册自己提供的服务

服务消费者Consumer：在启动时，向注册中心订阅自己所需的服务

注册中心Registry：返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者

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

服务消费者Consumer和提供者Provider：在内存中累计调用的次数和调用的时间，定时每分钟发送一次统计数据到监控中心Monitor。

dubbo的整体架构设计分层

接口服务层Service：该层与业务逻辑相关，根据Provider和Consumer的业务设计对应的接口和实现

配置层Config：对外配置接口，以ServiceConfig和ReferenceConfig为中心

服务代理层Proxy：服务接口透明代理，生成服务的客户端Stub和服务端端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory

服务注册层Registry：封装服务地址的注册和发现，以服务URL为中心，扩展接口为RegistryFactory，Registry，RegistryService

路由层Cluster：封装多个提供者的路由和负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster，Directory，Router和LoadBlance

监控层Monitor： RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory，Monitor，MonitorService​​​​

远程调用层Protocal：封装RPC调用，以Invocation和Result为中心，扩展接口为Protocal，Invoker和Exporter

信息交换层Exchange：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger，ExchangeChannel，ExchangeClient和ExchangeServer

网络运输层Transport：抽象mina和netty为统一接口，以message为中心，扩展接口为channel，Transporter，Client，Server和Codec

数据序列化层Serialize：可复用的一些工具，扩展接口为Serialization，ObjectInput，ObjectOutput和ThreadPool

dubbo Monitor实现原理

consumer端在发起调用之前会先走filter链，provider端在接受到请求时也是先走filter链，然后才进行真正的业务逻辑处理。默认情况下，在consumer和provider的filter链中都会有MonitorFilter。

1. MonitorFilter向DubboMonitor发送数据

2. DubboMonitor将数据进聚合后（默认聚合1min中的统计数据）暂存到ConcurrentMap<Statistics，AtomicReference>statisticsMap，然后使用一个含有3个线程（线程名字：DubboMonitorSendTimer）的线程池每隔1min，调用SimpleMonitorService遍历发送statisticsMap中的统计数据，每发送完毕一个，就重置当前的Statistics的AtomicReference。

3. SimpleMonitorService将这些聚合数据塞入BlockingQueue queue中（队列大写为100000）

4. SimpleMonitorService使用一个后台线程（线程名字：DubboMonitorAsyncWriteLongThread）将queue中的数据写入文件（线程以死循环的形式来写）

5. SimpleMonitorService还会使用一个含有1个线程（线程名字：DubboMonitorTimer）的线程池每隔5min钟，将文件中的统计数据画成图表

dubbo和Spring cloud有什么关系，有什么区别？

dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发，流量监控和熔断。而Spring cloud诞生于微服务时代，考虑的是微服务的治理，另外由于在Spring，Springboot优势之上，两个框架的目标本来就不一致，dubbo定位服务治理，Springcloud是打造一个生态。

dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化的完成RPC通信。

SpringCloud是基于http协议rest接口调用远程过程通信的，相对来说http请求会有更大的报文，占的带宽也会更多。