Dubbo的架构设计是怎样的？

架构分层

Dubbo中的架构设计是⾮常优秀的，分为了很多层次，并且每层都是可以扩展的，⽐如：

1. Proxy服务代理层，⽀持JDK动态代理、javassist等代理机制
2. Registry 注册中⼼层，⽀持Zookeeper、Redis等作为注册中⼼
3. Protocol 远程调⽤层， ⽀持Dubbo、Http等调⽤协议
4. Transport ⽹络传输层， ⽀持netty、mina等⽹络传输框架
5. Serialize 数据序列化层，⽀持JSON、Hessian等序列化机制

 各层说明

• config 配置层：对外配置接⼝，以 ServiceConfig , ReferenceConfig 为中⼼，可以直接
  初始化配置类，也可以通过 spring 解析配置⽣成配置类
• proxy 服务代理层：服务接⼝透明代理，⽣成服务的客户端 Stub 和服务器端 Skeleton, 以

  ServiceProxy 为中⼼，扩展接⼝为 ProxyFactory
• registry 注册中⼼层：封装服务地址的注册与发现，以服务 URL 为中⼼，扩展接⼝为

  RegistryFactory , Registry , RegistryService
• cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中⼼，以 Invoker 为中⼼，扩展接⼝为 Cluster , Directory , Router , LoadBalance
• monitor 监控层：RPC 调⽤次数和调⽤时间监控，以 Statistics 为中⼼，扩展接⼝为

  MonitorFactory , Monitor , MonitorService
• protocol 远程调⽤层：封装 RPC 调⽤，以 Invocation , Result 为中⼼，扩展接⼝为
  Protocol , Invoker , Exporter
• exchange 信息交换层：封装请求响应模式，同步转异步，以 Request , Response 为中⼼，
  扩展接⼝为 Exchanger , ExchangeChannel , ExchangeClient , ExchangeServer
• transport ⽹络传输层：抽象 mina 和 netty 为统⼀接⼝，以 Message 为中⼼，扩展接⼝为
  Channel , Transporter , Client , Server , Codec
• serialize 数据序列化层：可复⽤的⼀些⼯具，扩展接⼝为 Serialization , ObjectInput ,
  ObjectOutput , ThreadPool

• 在 RPC 中，Protocol 是核⼼层，也就是只要有 Protocol + Invoker + Exporter 就可以完成⾮透明的 RPC 调⽤，然后在 Invoker 的主过程上 Filter 拦截点。
• 图中的 Consumer 和 Provider 是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不⽤ Client 和 Server 的原因是 Dubbo 在很多场景下都使⽤ Provider, Consumer,Registry, Monitor 划分逻辑拓普节点，保持统⼀概念。
• ⽽ Cluster 是外围概念，所以 Cluster 的⽬的是将多个 Invoker 伪装成⼀个 Invoker，这样其它⼈只要关注 Protocol 层 Invoker 即可，加上 Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有⼀个提供者时，是不需要 Cluster 的。
• Proxy 层封装了所有接⼝的透明化代理，⽽在其它层都以 Invoker 为中⼼，只有到了暴露给⽤户使⽤时，才⽤ Proxy 将 Invoker 转成接⼝，或将接⼝实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务⼀样调远程服务。
• ⽽ Remoting 实现是 Dubbo 协议的实现，如果你选择 RMI 协议，整个 Remoting 都不会⽤上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，⽽ Exchange 层是在传输层之上封装了 Request-Response 语义。
• Registry 和 Monitor 实际上不算⼀层，⽽是⼀个独⽴的节点，只是为了全局概览，⽤层的⽅式画在⼀起。