上篇文章介绍了架构方面的演进，Dubbo项目的历史以及作用等内容。今天我们站得高一点，从整体的分层上面来看一下Dubbo的结构。
我在村口等小芳：《深入理解Apache Dubbo与实战》第1章上zhuanlan.zhihu.com
Dubbo的总体分层
Dubbo从分包的角度上来看，总共包括了Biz层，RPC层，以及Remote层。
Service层以及Config层可以认为是API层，这两层也是我们开发人员经常接触的层面。后面的各层，则可以宽泛的认为是SPI层，扩展层，当然如果这个我们需要自定义，当然可以在其规范的情况下进行二次开发，实现自己的协议以及远程调用方式。
Dubbo的核心组件
书上列举的内容比较多，我每一个组件用一句话来概括下：
Service：业务层，主要是业务实现。
Config：配置层，管理整个Dubbo的配置。
Proxy：服务代理，对Dubbo生产者，消费者真是对象的封装。
Registry：服务注册通知层。
Cluster：集群容错层，失败重试，负载均衡等。
Monitor：管理层，统计各种调用信息。
Protocol：远程调用层。
Exchange：信息交换层，建立Request-Response模型，封装请求响应模式。
Transport：网络传输层。
Serialize：序列化层。
Dubbo总体的调用过程
- 服务的暴露过程
首先，服务器端（服务提供者）在框架启动时，会初始化服务实例，通过Proxy组件调用具体协议（Protocol），把服务端要暴露的接口封装成Invoker（真实类型是AbstractProxylnvoker，然后转换成Exporter，这个时候框架会打开服务端口等并记录服务实例到内存中，最后通过Registry把服务元数据注册到注册中心。
通过用户配置的Config和Service生成实例，然后根据Dubbo注解，使用Proxy根据不同的Protocol生成不同的invoker对象，然后通过用户指定的Registy注册到注册中心，因此完成了服务提供方的暴露。
Dubbo组件调用的总体流程：
首先，调用者拥有一个invoker对象，invoker在调用方法的时候，使用cluster以及loadBalance来进行选择调用那一个服务实例，最后使用客户端直接进行消息编码，然后序列化发起远程的调用。
服务提供者在收到消息后就会进行消息的解码以及反序列化，将Request对象分配到线程池中进行处理。
小结
本章内容主要是围绕着Dubbo的产生，发展，结构部分来展开，大多是科普性的内容，有喜欢的同学也可以多找些材料来开下。
