dubbo核心组件
层次名 作 用
Service 业务层。包括业务代码的接口与实现，即开发者实现的业务代码
config 配置层。主要围绕ServiceConfig （暴露的服务配置）和ReferenceConfig （引用的服务配置）两个实现类展开，初始化配置信息。可以理解为该层管理了整个Dubbo的配置
proxy 服务代理层。在Dubbo中，无论生产者还是消费者，框架都会生成一个代理类，整个过程对上层是透明的。当调用一个远程接口时，看起来就像是调用了一个本地的接口一样， 代理层会自动做远程调用并返回结果，即让业务层对远程调用完全无感
registry 注册层。负责Dubbo框架的服务注册与发现。当有新的服务加入或旧服务下线时，注册中心都会感知并通知给所有订阅方。整个过程不需要人工参与
cluster 集群容错层。该层主要负责：远程调用失败时的容错策略（如失败重试、快速失败）； 选择具体调用节点时的负载均衡策略（如随机、一致性Hash等）；特殊调用路径的路由
策略（如某个消费者只会调用某个IP的生产者）
monitor 监控层。这一层主要负责监控统计调用次数和调用时间等
protocol 远程调用层。封装RPC调用具体过程，Protocol是Invoker暴露（发布一个服务让别人
可以调用）和引用（引用一个远程服务到本地）的主功能入口，它负责管理Invoker的
整个生命周期。Invoker是Dubbo的核心模型，框架中所有其他模型都向它靠拢，或者
转换成它，它代表一个可执行体。允许向它发起invoke调用，它可能是执行一个本地的
接口实现，也可能是一个远程的实现，还可能一个集群实现
exchange 信息交换层。建立Request-Response模型，封装请求响应模式，如把同步请求转化为异步请求
transport 网络传输层。把网络传输抽象为统一的接口，如Mina和Netty虽然接口不一样，但是Dubbo在它们上面又封装了统一的接口。用户也可以根据其扩展接口添加更多的网络传
输方式
Serialize 序列化层。如果数据要通过网络进行发送，则需要先做序列化，变成二进制流。序列化层负责管理整个框架网络传输时的序列化/反序列化工作
服务暴露：
注册中心：
动态加入。一个服务提供者通过注册中心可以动态地把自己暴露给其他消费者，无须消费者逐个去更新配置文件。
动态发现。一个消费者可以动态地感知新的配置、路由规则和新的服务提供者，无须重启服务使之生效。
动态调整。注册中心支持参数的动态调整，新参数自动更新到所有相关服务节点。
统一配置。避免了本地配置导致每个服务的配置不一致问题。
注册中心的四种实现：ZooKeeper、 Redis 、 Simple 、Multicast
ZooKeeper是官方推荐的注册中心，在生产环境中有过实际使用，具体的实现在Dubbo 源码的dubbo-registry-zookeeper模块中。
Redis 注册中心并没有经过长时间运行的可靠性验证，其稳定性依赖于Redis本身。
Simple注册中心 是一个简单的基于内存的注册中心实现，它本身就是一个标准的RPC服务，不支持集群，也可 能出现单点故障。
Multicast模式则不需要启动任何注册中心，只要通过广播地址，就可以互相 发现。服务提供者启动时，会广播自己的地址。消费者启动时，会广播订阅请求，服务提供者 收到订阅请求，会根据配置广播或单播给订阅者。不建议在生产环境使用。
zookeeper：
是树形结构的注册中心，每个节点的类型分为持久节点、持久顺序节点、临时节点和临时顺序节点。
持久节点：服务注册后保证节点不会丢失，注册中心重启也会存在。
持久顺序节点：在持久节点特性的基础上增加了节点先后顺序的能力。
临时节点：服务注册后连接丢失或session超时，注册的节点会自动被移除。
临时顺序节点：在临时节点特性的基础上增加了节点先后顺序的能力。
- /dubbo
±- service
±- providers
±- consumers
±- routers
±- configurators
（1）树的根节点是注册中心分组，下面有多个服务接口，分组值来自用户配置
dubbo:registry中的 group 属性，默认是/dubbo。
(2) 服务接口下包含4类子目录，分别是providers、consumers、 routers、 configurators,这个路径是持久节点。
(3) 服务提供者目录(/dubbo/service/providers)下有多个服务者URL元数据信息。
(4) 服务消费者目录(/dubbo/service/consumers)下有多个消费者元数据信息。
(5) 路由配置目录(/dubbo/service/routers)下面包含多个用于消费者路由URL策略元数据信息。
(6) 动态配置目录(/dubbo/service/configurators)下面包含多个用于服务者动态配置URL元数据信息。
配置中心的订阅/发布
订阅通常有pull和push两种方式，一种是客户端定时轮询注册中心拉取配置，另一种是注册中心主动推送数据给客户端。这两种方式各有利弊，Dubbo采用的是第一次启动拉取方
式，后续接收事件重新拉取数据。
在服务暴露时，服务端会订阅configurators用于监听动态配置，在消费端启动时，消费端会订阅providers、routers和configuratops这三个目录，分别对应服务提供者、路由和动
态配置变更通知。
ZooKeeper注册中心采用的是“事件通知” + “客户端拉取”的方式，客户端在第一次连接上注册中心时，会获取对应目录下全量的数据。并在订阅的节点上注册一个watcher,客户端与
注册中心之间保持TCP长连接，后续每个节点有任何数据变化的时候，注册中心会根据watcher的回调主动通知客户端（事件通知），客户端接到通知后，会把对应节点下的全量数据都拉取过
来（客户端拉取），这一点在NotifyListener#notify List urls 接口上就有约束的注释说明。全量拉取有一个局限，当微服务节点较多时会对网络造成很大的压力。
注册中心的缓存：在类AbstractRegistry中实现
private final Properties properties = new Properties();
private File file;//磁盘文件服务缓存对象
private final ConcurrentMap Map>> notified = new ConcurrentHashMap List>>(); //内存中的服务缓存对象
notified是ConcurrentHashMap里面又嵌套了一个Map,外层Map的key是消费者的 URL,内层 Map 的 key 是分类，包含 providers、 consumers、 routes、 configurators
四种。value则是对应的服务列表，对于没有服务提供者提供服务的URL,它会以特殊的empty://前缀开头
在服务初始化的时候，AbstractRegistry构造函数里会从本地磁盘文件中把持久化的注册数据读到Properties对象里，并加载到内存缓存中
Properties保存了所有服务提供者的URL,使用URL#serviceKey()作为key,提供者列表、 路由规则列表、配置规则列表等作为value。由于value是列表，当存在多个的时候使用空格隔
开。还有一个特殊的key.registies,保存所有的注册中心的地址。如果应用在启动过程中，注册中心无法连接或宕机，则Dubbo框架会自动通过本地缓存加载Invokers。
首先在客户端启动时会从注册中心拉取和订阅对应的服务列表，Cluster会把拉取的服务列
表聚合成一个Invoker,每次RPC调用前会通过Directory#list获取providers地址（已经生成
好的Invoker列表），获取这些服务列表给后续路由和负载均衡使用。对应图6.1,在①中主要
是将多个服务提供者做聚合。在框架内部另外一个实现Directory接口是RegistryDirectory
类，它和接口名是一对一的关系（每一个接口都有一个RegistryDirectory实例），主要负责拉取
和订阅服务提供者、动态配置和路由项。
dubbo发起服务调用，在客户端经过负载均衡选择一台机器进行RPC调用。
Dubbo协议详解
一次RPC调用包括协议头和协议体两部分。
16字节长的报文头部主要携带了魔法数(0xdabb),以及当前请求报文是否是Request、Response 心跳和事件的信息，请求时也会携
带当前报文体内序列化协议编号。除此之外，报文头部还携带了请求状态，以及请求唯一标识和报文体长度。
魔法数：来分割处理粘包问题
Dubbo中的编码器（123）主要将Java对象编码成字节流返回给客户端，主要做两部分事情，构造报文头部，然后对消息体进行序列化处理。所有编解码层实现都应该继承自Exchangecodec,
Dubbo协议编码器也不例外。当Dubbo协议编码请求对象时，会调用ExchangeCodec#encode方法。
