（注：init：表示初始化过程，只会执行一次 async：异步处理过程 sync：同步处理过程）
0.start：Dubbo 服务启动，Spring 容器首先会创建服务提供者。
1.register：服务提供者创建好后，马上会注册到服务注册中心 Registry，这个注册过程称为服务暴露。服务暴露的本质是将服务名称（接口）与服务提供者主机写入到注册中心 Registry 的服务映射表中。注册中心充当着“域名服务器”的角色。
2.subscribe：服务消费者启动后，首先会向服务注册中心订阅相关服务，当然，该服务必须是 Provider 暴露于注册中心中的服务。
3.notify：消费者可能订阅的服务在注册中心还没有相应的提供者。当相应的提供者在注册中心注册后，注册中心会马上通知订阅该服务的消费者。但消费者在订阅了指定服务后，在没有收到注册中心的通知之前是不会被阻塞的，而是可以继续订阅其它服务。注意，一个消费者可以订阅多个服务。
4.invoke：消费者以同步的方式调用提供者提供的请求。消费者通过远程注册中心的服务列表调用远程服务，Dubbo 会基于负载均衡算法，选一台提供者处理消费者的请求。而消费者的这个调用是同步的，即提供者在没有向消费者返回处理结果之前，消费者处于阻塞状态，直到提供者返回处理结果，或等待超时。等待超时，Dubbo 会再选一个提供者为消费者服务。
5.count：每个消费者对各个服务的累计调用次数、调用时间；每个提供者被消费者调用的累计次数和时间，消费者与调用者都会定时发送到监控中心，由监控中心记录。这些统计数据可以在 Dubbo 的可视化界面看到。
Dubbo 三大领域模型
为了对 Dubbo 整体架构叙述的方便，Dubbo 抽象出了三大领域模型。注意，这里的领域模型与 DDD（Domain Driven Design，领域驱动模型设计）无关。
1.Protocol 服务域：是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
2.Invoker 实体域：是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
3.Invocation 会话域：它持有调用过程中的变量，比如方法名，参数等。
Dubbo 的两大设计原则
Double 这个框架在设计时有两大设计原则：
1.采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
2.采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息.
Dubbo 整体架构
Dubbo 的架构设计共分为了 10 层。最上面的 Service 层是 Dubbo 开发分布式服务开发者实现业务逻辑的接口层。图中左边淡蓝色背景为服务消费者使用的接口，右边淡绿色背景为服务提供者使用的接口，位于中轴线的为双方都要用到的接口。对于这 10 层，根据其总体功能划分，可以划分为三大层：
Business 层
该层仅包含一个 service 服务层，该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。
RPC 层
该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下 6 层。
config 配置层 ,proxy 服务代理层,
registry 注册中心层 ,
Remoting 实现是 Dubbo 协议的实现，如果我们选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange层是在传输层之上封装了 Request-Response 语义。具体包含以下三层
（1）exchange 信息交换层
封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger和 ExchangeChannel,ExchangeClient 和 ExchangeServer。
（2） transport 网络传输层
抽象和 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec。
（3） serialize 数据序列化层
可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObejctOutput 和 ThreadPool。
