dubbo学习记录

简介

Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。它有三大功能：面向接口的远程方法调用、服务自动注册和发现、智能容错和负载均衡。

RPC介绍

RPC全称为remote procedure call，即远程过程调用。比如两台服务器A和B，A服务器上部署一个应用，B服务器上部署一个应用，A服务器上的应用想调用B服务器上的应用提供的方法，由于两个应用不在一个内存空间，不能直接调用，所以需要通过网络来表达调用的语义和传达调用的数据。
需要注意的是RPC并不是一个具体的技术，而是一个泛化的概念，严格来说一切远程过程调用手段都属于RPC范畴。各种开发语言都有自己的RPC框架。Java中的RPC框架比较多，广泛使用的有RMI、Hessian、Dubbo等。

dubbo了解

作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件，这包括：
注册中心（registry）：
协调 Consumer 与 Provider 之间的地址注册与发现
配置中心（config Center）：
存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
负责服务治理规则（路由规则、动态配置等）的存储与推送。
元数据中心（Metadata）：
接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展。
下面是这三个组件的相互关系。

当然，这三个中心并不是运行 Dubbo 的必要条件，可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。
下面是dubbo的分层架构：

大的来说可分为三层，分别为 Business（业务层）、RPC 层、Remoting，也可分为两层，API 层和 SPI 层。
细分的话有十层，其各自的功能如下：
Service，业务层，即开发的业务逻辑层。
Config，配置层，初始化配置信息。
Proxy，代理层，服务提供者还是消费者都会生成一个代理类，使得服务接口透明化，代理层做远程调用和返回结果。
Register，注册层，封装了服务注册和发现。
Cluster，路由和集群容错层，负责选取具体调用的节点，处理特殊的调用要求和负责远程调用失败的容错措施。
Monitor，监控层，负责监控统计调用时间和次数。
Portocol，远程调用层，主要是封装 RPC 调用，主要负责管理
Invoker，Invoker代表一个抽象封装了的执行体，之后再做详解。
Exchange，信息交换层，用来封装请求响应模型，同步转异步。
Transport，网络传输层，抽象了网络传输的统一接口，这样用户想用 Netty 就用 Netty，想用 Mina 就用 Mina。
Serialize，序列化层，将数据序列化成二进制流，当然也做反序列化。

下面我们来看看dubbo的整个工作流程是怎样的。

从服务提供者开始，首先 Provider 启动，通过 Proxy 组件根据具体的协议 Protocol 将需要暴露出去的接口封装成 Invoker，Invoker 是 Dubbo 一个很核心的组件，代表一个可执行体。再通过 Exporter 包装一下，这是为了在注册中心暴露自己套的一层，然后将 Exporter 通过 Registry 注册到注册中心。 这就是服务暴露的过程。

然后是消费者，首先消费者启动会向注册中心拉取服务提供者的元信息，然后调用流程也是从 Proxy 开始，Proxy 持有一个 Invoker 对象，调用 invoke 之后需要通过 Cluster 先从 Directory 获取所有可调用的远程服务的 Invoker 列表，如果配置了某些路由规则，比如某个接口只能调用某个节点的那就再过滤一遍 Invoker 列表。剩下的 Invoker 通过 LoadBalance 做负载均衡来选取一个调用。再通过 Client 做数据传输，比如用 Netty 来传输。传输需要经过 Codec 接口做协议构造，再序列化。发往对应的服务提供者。

回到服务提供者，服务提供者接收到之后也会进行 Codec 协议处理，然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 Exporter ，而找到 Exporter 其实就是找到了 Invoker，但是还会有一层层 Filter，经过一层层过滤链之后最终调用实现类然后原路返回结果。下面是整个详细的流程图