# Dubbo学习（一）—dubbo基础
## Dubbo架构概述
**什么是dubbo？**
Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。
**dubbo的特性**
参考官网首页
**dubbo的服务治理**
在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。
**当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。** 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。
**当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。** 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。
**接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？** 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
以上是 Dubbo 最基本的几个需求。
## Dubbo的处理流程
##### 节点角色说明
| 节点 | 角色说明 |
| ----------- | -------------------------------------- |
| `Provider` | 暴露服务的服务提供方 |
| `Consumer` | 调用远程服务的服务消费方 |
| `Registry` | 服务注册与发现的注册中心 |
| `Monitor` | 统计服务的调用次数和调用时间的监控中心 |
| `Container` | 服务运行容器 |
调用关系说明:
虚线 代表异步调用 实线代表同步访问
蓝色虚线 是在启动时完成的功能
红色虚线 是程序运行中执行的功能
以上各个组件的调用关系如下：
- 服务提供方在启动时会将自己提供的服务**注册**到服务注册中心。
- 服务消费方在启动时会去服务注册中心**订阅**自己需要的服务的地址列表，然后服务注册中心异步把消费方需要的服务接口的提供者的地址列表返回给服务消费方，服务消费方根据路由规则和设置的负载均衡算法选择一个服务提供者IP进行**调用**。
- 监控平台主要用来**统计**服务的调用次数和调用耗时，即服务消费者和提供者在内存中累计调用服务的次数和耗时，并每分钟定时发送一次统计数据到监控中心，监控中心则使用数据绘制图表来显示。监控平台不是分布式系统必需的，但是这些数据有助于系统的运维和调优。服务提供者和消费者可以直接配置监控平台的地址，也可以通过服务注册中心获取。
## Dubbo分层架构
图例说明：
- 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
- 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
- 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
- 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。
**各层基本解析说明**
- **Service和Config层**为API接口层，是为了让Dubbo使用方方便地发布服务和引用服务；对于服务提供方来说需要实现服务接口，然后使用ServiceConfig API 来发布该服务；对于服务消费方来说需要使用ReferenceConfig 对服务接口进行代理。Dubbo服务发布与引用方可以直接初始化配置类，也可以通过Spring配置自动生成配置类
- **Proxy服务代理层：**该层主要是对服务消费端使用的接口进行代理，把本地调用透明地转换为远程调用；另外对服务提供方的服务实现类进行代理，把服务实现类转换为Wrapper类，这是为了减少反射的调用，后面会具体讲解。Proxy层的SPI扩展接口为ProxyFactory，Dubbo提供的实现类主要有JavassistProxyFactory（默认使用）和JdkProxyFactory，用户可以实现ProxyFactory SPI接口，自定义代理服务层的实现。
- **Registry 服务注册中心层**：服务提供者启动时会把服务注册到服务注册中心，消费者启动时会去服务注册中心获取服务提供者的地址列表，Registry层主要功能是封装服务地址的注册与发现逻辑，扩展接口Registry 对应的扩展实现为ZookeeperRegistry、RedisRegistry、MulticastRegistry、DubboRegistry等。扩展接口RegistryFactory 对应的扩展接口实现为DubboRegistryFactory、DubboRegistryFactory、RedisRegistryFactory、ZookeeperRegistryFactory。另外，该层扩展接口Directory实现类有RegistryDirectory、StaticDirectory，用来透明地把Invoker列表转换为一个Invoker；用户可以实现该层的一系列扩展接口，自定义该层的服务实现。
- **Cluster 路由层**：封装多个服务提供者的路由规则、负载均衡、集群容错的实现，并桥接服务注册中心；扩展接口Cluster 对应的实现类有FailoverCluster（失败重试）、FailbackCluster（失败自动恢复）、FailfastCluster（快速失败）、FailsafeCluster （失败安全）、ForkingCluster（并行调用）等；负载均衡扩展接口LoadBalance 对应的实现类为RandomLoadBalance（随机）、RoundRobinLoadBalance（轮询）、LeastActiveLoadBalance（最小活跃数）、ConsistentHashLoadBalance（一致性Hash）等。用户可以实现该层的一系列扩展接口，自定义集群容错和负载均衡策略。
- **Monitor 监控层**：用来统计RPC 调用次数和调用耗时时间，扩展接口为MonitorFactory，对应的实现类为DubboMonitorFactroy。用户可以实现该层的MonitorFactory扩展接口，实现自定义监控统计策略。
- **Protocol 远程调用层**：封装RPC 调用逻辑，扩展接口为Protocol，对应实现有RegistryProtocol、DubboProtocol、InjvmProtocol等。
- **Exchange 信息交换层**：封装请求响应模式，同步转异步，扩展接口为Exchanger，对应的扩展实现有HeaderExchanger等。
- **Transport网络传输层**：Mina和Netty抽象为统一接口。扩展接口为Channel，对应的实现有NettyChannel（默认）、MinaChannel等；扩展接口Transporter对应的实现类有GrizzlyTransporter、MinaTransporter、NettyTransporter（默认实现）；扩展接口Codec2对应的实现类有DubboCodec、ThriftCodec等。
- **Serialize 数据序列化层**：提供可以复用的一些工具，扩展接口为Serialization，对应的扩展实现有DubboSerialization、FastJsonSerialization、Hessian2Serialization、JavaSerialization等，扩展接口ThreadPool对应的扩展实现有FixedThreadPool、CachedThreadPool、LimitedThreadPool等。
Dubbo学习（一）—dubbo基础