Dubbo的体系结构和原理
-从官方网站整理文档
简介Dubbo是阿里巴巴开源的分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动检测等有效的服务治理方案。 主要功能包括高性能NIO通信和多协议集成、服务动态寻址和路由、软负载平衡和容错、相关性分析和降级。
l远程通信—基于多个长连接(如“请求-响应”模式下的线程模型、序列化和信息交换)提供NIO框架的抽象封装。
l群集容错：提供基于接口的透明远程过程调用，包括多协议支持以及群集支持，如软负载平衡、容错、地址路由和动态配置。
l自动发现：基于注册中心目录服务，服务消费者动态搜索服务提供者，使地址透明，使服务提供者顺利增减机器。
随着需求和背景互联网的发展，网站APP应用的规模不断扩大，普通的垂直APP应用体系结构无法适应，分布式服务体系结构和移动计算体系结构势在必行，体系结构发展完善
单一应用架构
如果网站流量很少，则通过在一个APP应用程序中聚合所有功能来降低部署节点和成本。 此时，用于简化追加删除重新审视作业的数据访问框架(ORM )很重要。
垂直应用架构
随着访问次数的逐渐增加，一个APP应用程序增加机器所带来的加速度越来越小，将APP应用程序分解为几个相互无关的APP应用程序以提高效率。 此时，用于加快前端页面开发的Web框架(MVC )是关键。
分布式服务架构
随着垂直的APP应用越来越多，APP应用之间的交互不可避免，提取核心业务，作为独立的服务，逐渐形成稳定的服务中心，使前端APP应用能够更快地适应变化的市场需求。 此时，用于提高业务复用和整合的分布式服务框架(RPC )很重要。
流动计算架构
随着服务增加，容量评估、小服务资源浪费等问题日益突出，需要增加基于访问压力实时管理集群容量的调度中心，提高集群利用率。 此时，用于提高设备利用率的资源调度和管理中心(SOA )很重要。
在大规模服务化之前，APP应用程序可能只需要通过RMI和Hessian等工具，轻松暴露和引用远程服务，设置和调用服务的URL地址，并通过F5等硬件平衡负载。
)1)随着服务的增加，服务URL的配置管理变得非常困难，F5硬件负载平衡器的单点压力也越来越大。
此时，为了使服务的位置透明，需要服务注册中心。 需要动态注册和发现服务。 另外，通过在消费者端获取服务提供者地址列表，实现软负载均衡和Failover，还可以降低对F5硬件负载均衡器的依赖，降低部分成本。
)进一步发展，服务之间的依赖关系变得复杂，甚至不知道哪个APP应用程序在哪个APP应用程序之前启动，体系结构无法完全描述APP应用程序的体系结构关系。
此时，需要自动创建APP应用程序之间的依赖关系图，以帮助修订者组织关系。
)3)接下来，随着服务调用量的增加，服务容量问题会变得突出。 这项服务需要多少机器支持？ 我应该什么时候添加机器？
为了解决这些问题，第一步统计服务当前每天的调用量、响应时间，作为容量修订版的参考指标。 接下来，为了能够动态调整权重，在线上，在一直增大某个设备的权重的同时，记录响应时间的变化，直到响应时间达到阈值为止，记录此时的访问数，将该访问数乘以设备数，反算总容量。
框架设计下图是dubbo框架的设计示意图。
在图中，左边的浅蓝色背景是用于服务消费者的接口，右边的浅蓝色背景是用于服务提供者的接口，中心轴上的是用于双方的接口。
l图中自下而上分为10层，各层均为单向依赖关系，右侧黑色箭头表示层间依赖关系，可以逐层剥离上层进行复用。 其中，服务和配置层为API，其他各层均为SPI。
图中绿色小块是扩展接口，蓝色小块是安装类，图中只示出了用于关联各层的安装类。
l图中的蓝色虚线是初始化过程，即在启动时构造链的过程，红色实线是方法调用过程，即运行时链，紫色三角箭头是继承，子类可以被视为父类的同一节点，o
各层说明：
配合l config
置层，对外提供配置接口，以SeviceConfig和Reference为中心，可以直接new配置类，也可以通过Spring加载配置类；l proxy服务代理层，服务接口透明代理，生产客户端的Stub和服务器端的Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory;
l register注册中心层，封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService。
l cluster路由层，封装多个服务提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster, Router, Directory, LoadBalance；
l monitor监控层，RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService；
l protocol远程调用层，封装RPC调用，以Invocation，Result为中心，扩展接口为Protocal, Invoker, Exporter；
l exchange信息交换层，封装请求响应模式，同步转异步，以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient,ExchangeServer；
l transport网络传输层，抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec；
l serialize数据序列化层，可复用的一些工具，扩展接口为Serialization, ObjectInput, ObjectOutput,ThreadPool
关系说明：
l 在RPC中，Protocol是核心层，也就是只要有Protocol+Invoker+Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
l 图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端和服务端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider, Consumer, Registry, Monitor划分逻辑拓扑节点，保持统一概念。
l 而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其他人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其他层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
l Proxy层封装了所有接口的透明化代理，而在其他层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
l 而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划分为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina, Netty, Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
l Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
依赖关系
图例说明：
l 图中小方块Protocol, Cluster, Proxy, Service,Container, Registry, Monitor代表层或模块，蓝色的表示与业务有交互，绿色的表示只对Dubbo内部交互。
l 图中背景方块Consumer, Provider, Registry, Monitor代表部署逻辑拓普节点。
l 图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。
l 图中只包含RPC的层，不包含Remoting的层，Remoting整体都隐含在Protocol中。
调用链Dubbo的调用链如下：
暴露服务时序
引用服务时序 领域模型在Dubbo的核心领域模型中：
l Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。
l Invoker是实体域，它是Dubbo的核心模型，其他模型都向它靠拢，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
l Invocation是会话域，它持有调用过程中的变量，比如方法名，参数等。
基本原则l 采用Microkernel+ Plugin模式，Microkernel只负责组装Plugin，Dubbo自身的功能也是通过扩展点实现的，也就是Dubbo的所有功能点都可被用户自定义扩展所替换。
l 采用URL作为配置信息的统一格式，所有扩展点都通过传递URL携带配置信息