Dubbo相关介绍

一、Dubbo产生的背景
      互联网项目用户量增加，访问并发量的增加，一个应用中所有的功能都集中于一个项目已经不能满足需要了，系统性能急需提升。提升性能的最直接的方式是构建集群，构建具有负载均衡功能的集群。但仅仅依靠增加具有相同业务功能的主机来提高系统的性能能了是有限的。需要将应用的功能进行分解，分解为多个子工程，每个子工程仅完成某一特定功能，例如，登录子工程、订单业务子工程、支付业务子工程、红包业务子工程等。即，将原来项目中的业务模块，变为了独立工程。在这种情况下若性能还需要进一步再提升，则可为每个项目构建集群。
这种将一个应用使用多个独立的工程实现的系统架构，称为SOA系统架构（Service Oriented Architecture，即面向服务的E系统架构）。
这些子工程原本都是为一个应用服务的，而该应用在没有被拆分为多个子工程时，原本都在一个工程中的，各个模块都是运行在处于同一个主机的同一个JVM中，一个类的对象调用另一个类的对象，即各个模块间进行数据通信是没有任何问题的。但拆分为多个子工程后，各个子工程都是运行在各自的主机的JVM中的，它们之间的数据通信是如何实现？通过RPC协议（Remote Procedure Call Protocol，远程过程调用协议）完成通信。Dubbo就是RPC协议的实现者之一。
    PS：
    1）什么是SOA？
      SOA，Service Oriented Architecture，面向服务的架构，是一个组件模型（即子项目模型），它将应用程序的不同功能单元（称为服务）通过这些服务之间定义的良好接口和契约联系起来。接口是采用中立的方式进行定义的（所谓中立方式是指没有与任何具体实现相绑定的定义方式，即只有接口，没有实现方式）。它应该独立于实现服务的硬件平台、操作系统（即跨平台）和编程语言（即已被编译为可执行文件）。这使得构建在各种各样的系统中的服务可以以一种同意和通用的方式进行交互。
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件（即子项目）进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性（即人为参与度更低了）。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA能够帮助软件工程师站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
     2）什么是RPC？
       RPC（Remote Procedure Call Protocol）--远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定默写传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型（OSI七层网络模型，OSI，Open System Interconnection，开放系统互联）中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式，即（C/S模式）。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
其实RPC的底层就是Socket实现的，只要知道对方的主机名与端口号，就可通过网络连接上，而无需知道其底层是怎样实现的通信。

二、系统架构设计的关键点
   1. 单一应用架构
       当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。当流量增加时通过搭建集群增加主机的水平扩展方式可以提升整个系统的性能。此时，用于简化增删改查工作量的数据访问框架是关键。
   2. 垂直应用架构
       当访问量逐渐增大，单一应用架构的水平扩展，其所带来的速度提升越来越小。此时可以将应用拆成互不相干的几个应用，以提升效率。这时用于加速前端页面开发的Web框架是关键。
   3. 分布式服务架构
       当垂直应用越来越多，应用之间的交互是不可避免的。这时将核心业务抽取出来作为独立的业务，主键形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键。
   4. 流动计算架构
       当服务越来越多，容量的评估（主机所能支撑特定服务的能力称为容量）、小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心，使其基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心是关键。

 三、 Dubbo简介
       Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。
       Dubbo原官网为：http://dubbo.io。
       2018年2月15日，Dubbo正式进入Apache开源孵化器后，官网更新为 http://dubbo.apache.org

 四、Dubbo四大组件
        Provider：暴露服务方，亦称为服务提供者。
        Consumer：调用远程服务方，亦称为服务消费者。
        Registry：服务注册与发现的中心，提供目录服务，亦称为服务注册中心。
        Monitor：统计服务的调用次数、调用时间等信息的日志服务，亦称为服务监控中心。

 

                                   （图片摘自官网）

（注：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，领域驱动模型设计无关）。
                 Protocol 服务域：是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。
                 Invoker 实体域：是Dubbo的核心模型，其它模型都向它靠拢，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
                 Invocation 会话域：它持有调用过程中的变量，比如方法名，参数等。

六、Dubbo的两大设计原则
       1. 采用Microkernel + Plugin 模式，Microkernel只负责组装Plugin，Dubbo自身的功能也是通过扩展点实现的，也就是Dubbo的所有功能点都可被用户自定义扩展所替换。
       2. 采用URL作为配置信息的统一格式，所有扩展点都通过传递URL携带配置信息。

 

七、 Dubbo整体架构 

           Dubbo的架构设计共分为10层。最上面的Service层是Dubbo开发分布式服务开发者实现业务逻辑的接口层。图中左边淡蓝色北京为服务消费者使用的接口，右边淡绿色背景为服务提供者使用的接口，位于中轴线的为双方都要用到的接口。对于这10层，根据其总体功能划分，可划分为三大层：
     1. Business层
          该层仅包含一个service服务层，该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。
     2. RPC层
          该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下6层：
              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
     3. Rmeotting层
           Remoting 实现是Dubbo协议的实现，如果我们选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对 Mina,Netty,Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是传输层之上封装了Request-Response语义。
          具体包含以下三层：
             exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
             transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
             serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool