第一层：service层，接口层，给服务提供者和消费者来实现的 第二层：config层，配置层，主要是对dubbo进行各种配置的 第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton 第四层：registry层，服务注册层，负责服务的注册与发现 第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务 第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控 第七层：protocol层，远程调用层，封装rpc调用 第八层：exchange层，信息交换层，封装请求响应模式，同步转异步 第九层：transport层，网络传输层，抽象mina和netty为统一接口 第十层：serialize层，数据序列化层
1）第一步，provider向注册中心去注册 2）第二步，consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务 3）第三步，consumer调用provider 4）第四步，consumer和provider都异步的通知监控中心
可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。
在早期的项目中，代码全在一个工程中，对于简单的项目来说还好，如果后期涉及的功能增多。涉及订单、物流等多个功能模块，只是简单的一个项目的话，就变得十分糟糕。
那么如果项目具有多个系统，各个系统需要实现相互通讯，哪怎么办呢。一般来说使用RPC框架，如dubbo
为什么使用Dubbo
1、Dubbo一款优秀的分布式服务框架
2、Dubbo提供高性能的RPC服务
3、Dubbo具有注册中心、监控中心。
当一台服务器的性能达到极限时，我们可以使用服务器集群来提高网站的整体性能。那么，在服务器集群中，需要有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台后端服务器去处理。
那么在这个过程中，调度者如何合理分配任务，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡问题。
目的： 维持provider和consumer之间的长连接 实现： dubbo心跳时间heartbeat默认是1s，超过heartbeat时间没有收到消息，就发送心跳消 息(provider，consumer一样),如果连着3次(heartbeatTimeout为heartbeat*3)没有收到心跳响应，provider会关闭channel，而consumer会进行重连;不论是provider还是consumer的心跳检测都是通过启动定时任务的方式实现；
Dubbo的zookeeper做注册中心，如果注册中心全部挂掉，发布者和订阅者还能通信吗？ 可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用； 注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复； 挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。
SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。
优点：
-
传输效率高(二进制传输)
-
发起调用的一方无需知道RPC的具体实现，如同调用本地函数般调用
缺点：
- 通用性不如HTTP好(HTTP是标准协议)
总结：RPC适合内部服务间的通信调用；HTTP适合面向用户与服务间的通信调用
1、调用方持续把请求参数对象序列化成二进制数据，经过 TCP 传输到服务提供方；
2、服务提供方从 TCP 通道里面接收到二进制数据；
3、根据 RPC 协议，服务提供方将二进制数据分割出不同的请求数据，经过反序列化将二进制数据逆向还原出请求对象，找到对应的实现类，完成真正的方法调用；
4、然后服务提供方再把执行结果序列化后，回写到对应的 TCP 通道里面；
5、调用方获取到应答的数据包后，再反序列化成应答对象。
这样调用方就完成了一次 RPC 调用。
RPC 通信流程中的核心组成部分包括了协议、序列化与反序列化，以及网络通信。