一. Dubbo诞生背景
随着互联网的发展和网站规模的扩大，系统架构也从单点的垂直结构往分布式服务架构演进，如下图所示：
单一应用架构：一个应用部署所有功能，此时简化CRUD的ORM框架是关键
垂直应用架构：应用拆分为不相干的几个应用，前后端分离，此时用于加速前端页面开发的Web MVC框架是关键
分布式服务架构：抽取各垂直应用的核心业务作为独立服务，形成稳定的服务中心，此时用于提高业务复用及整合的分布式服务框架(RPC)是关键
流动计算架构：当服务越来越多，容量的评估、小服务资源的浪费等问题逐渐显现，此时用于提高机器利用率的实时资源调度和治理中心(SOA)是关键
当服务比较少时，可以通过 RMI 或 Hession 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址来调用，通过F5等硬件负载均衡
当服务越来越多时，服务配置URL变的困难，F5硬件负载均衡的单点压力越来越大。此时需要服务注册中心，动态的注册和发现服务，使服务的位置透明。服务调用实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖
当服务间关系越来越复杂时，此时需要自动画出服务间的依赖关系图，来帮助架构师理清服务关系
当服务调用量越来越大时，服务需要多少台机器支撑，服务容量的问题就暴露出来了，此时需要统计服务每天的调用量、响应时间等性能指标作为容量规划的参考。其次，还可以动态调整权重，将某台机器权重一直加大，直到响应时间到阀值，按照此时的访问量反推服务的总容量
以上是Dubbo的基本需求，如下图所示：
Dubbo的整体架构设计如图所示：
Dubbo框架一共分10层，各层单向依赖。最上面的 Service 和 Config 为API，其他均为 SPI。左边淡蓝色的为 consumer 使用的接口，右边淡绿色的为 provider 使用的接口，中间的为双方都用到的接口。
黑色箭头代表层之间的依赖关系；蓝色虚线为初始化过程，即启动时组装链；红色实线为方法调用过程；紫线为继承关系。线上的文字为调用的方法。
1、接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现
2、配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心
3、服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory
4、服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService
5、路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以Invoker 为中心，扩展接口为 Cluster、Directory、Router和LoadBlancce
6、监控层（Monitor）：RPC调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor和MonitorService
7、远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocal、Invoker和Exporter
8、信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer
9、网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为Channel、Transporter、Client、Server和Codec
10、数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool
各层关系说明：
Portocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点