Dubbo 框架

Dubbo是Alibaba开源的分布式服务框架，它最大的特色是按照分层的方式来架构，使用这种方式可使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种很是简单的模型，要么是提供方提供服务，要么是消费方消费服务，因此基于这一点能够抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

总体架构：


各层说明：
    1. service, 业务层，该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现
    2. config，配置层，对外配置接口，以ServiceConfig, ReferenceConfig为中心，能够直接new配置类，也能够经过spring解析配置生成配置类
    3. proxy，服务代理层，服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory
    4. registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService
    5. cluster，路由层，封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance
    6. monitor，监控层，RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService
    7. protocol，远程调用层，封将RPC调用，以Invocation, Result为中心，扩展接口为Protocol, 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

关系说明：
    1. 在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就能够完成非透明的RPC调用，而后在Invoker的主过程上Filter拦截点。
    2. 图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的缘由是Dubbo在不少场景下都使用Provider, Consumer, Registry, Monitor划分逻辑拓普节点，保持统一律念。
    3. Cluster是外围概念，因此Cluster的目的是将多个Invoker假装成一个Invoker，这样其它人只要关注Protocol层Invoker便可，加上Cluster或者去掉Cluster对其它层都不会形成影响，由于只有一个提供者时，是不须要Cluster的。
    4. Proxy层封装了全部接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是能够Run的，只是不那么透明，不那么看起来像调本地服务同样调远程服务。
    5. Remoting实现是Dubbo协议的实现，若是你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina,Netty,Grizzly的抽象，它也能够扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
    6. Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一块儿。

模块分包：

    模块说明：
    dubbo-common 公共逻辑模块，包括Util类和通用模型。
    dubbo-remoting 远程通信模块，至关于Dubbo协议的实现，若是RPC用RMI协议则不须要使用此。
    dubbo-rpc 远程调用模块，抽象各类协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
    dubbo-cluster 集群模块，将多个服务提供方假装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表能够是静态配置的，也能够是由注册中心下发。
    dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各类注册中心的抽象。
    dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
    dubbo-config 配置模块，是Dubbo对外的API，用户经过Config使用Dubbo，隐藏Dubbo全部细节。
    dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，由于服务一般不须要Tomcat/JBoss等Web容器的特性，不必用Web容器去加载服务。

    总体上按照分层结构进行分包，与分层的不一样点在于：
    container为服务容器，用于部署运行服务，没有在层中画出。
    protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不须要集群时(只有一个提供者)，能够只使用这两层完成rpc调用。
    transport层和exchange层都放在remoting模块中，为rpc调用的通信基础。
    serialize层放在common模块中，以便更大程度复用。

依赖关系：

    1. 节点角色说明：
    Provider: 暴露服务的服务提供方。
    Consumer: 调用远程服务的服务消费方。
    Registry: 服务注册与发现的注册中心。
    Monitor: 统计服务的调用次数和调用时间的监控中心。
    Container: 服务运行容器。

    2. 关系说明：
    服务容器负责启动，加载，运行服务提供者。
    服务提供者在启动时，向注册中心注册本身提供的服务。
    服务消费者在启动时，向注册中心订阅本身所需的服务。
    注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。
    服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。
    服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

暴露服务
时序如图所示：


引用服务
时序如图所示：


Dubbo做为一个分布式服务框架，主要具备以下几个核心的要点：

1. 服务定义
   服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务。
2. 服务注册
   对于服务提供方，它须要发布服务，并且因为应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所须要的服务，而面对复杂的应用系统，须要管理大量的服务调用。并且，对于服务提供方和服务消费方来讲，他们还有可能兼具这两种角色，即既须要提供服务，有须要消费服务。经过将服务统一管理起来，能够有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心能够经过特定协议来完成服务对外的统一。Dubbo提供的注册中心有以下几种类型可供选择：Multicast, Zookeeper, Redis, Simple。
3. 服务监控
   不管是服务提供方，仍是服务消费方，他们都须要对服务调用的实际状态进行有效的监控，从而改进服务质量。
4. 远程通讯与信息交换
   远程通讯须要指定通讯双方所约定的协议，在保证通讯双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通讯框架，主要包括以下几个：Mina, Netty, Grizzly。
5. 协议支持
   Dubbo支持多种协议，在通讯过程当中，不一样的服务等级通常对应着不一样的服务质量，那么选择合适的协议即是一件很是重要的事情。你能够根据你应用的建立来选择。例如，使用RMI协议，通常会受到防火墙的限制，因此对于外部与内部进行通讯的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议以下所示：Dubbo, Hessian, HTTP, RMI, WebService, Thrift, Memcached, Redis

具体可参考dubbo官方文档：
用户指南：http://dubbo.io/User+Guide-zh.htm
开发指南：http://dubbo.io/Developer+Guide-zh.htm
管理指南：http://dubbo.io/Administrator+Guide-zh.htm