Dubbo 概述
Dubbo 产生的背景
随着互联网项目用户量的急剧增长，访问并发量的陡然增加，一个应用中所有的功能都集中于一个项目中，已经完全不能满足需要了，系统性能急需提升。提升性能的最直接的方式是构建集群，构建具有负载均衡功能的集群。但仅仅依靠增加具有相同业务功能的主机来提高系统的性能，能力是有限的。需要将应用的功能进行分解，分解为多个子工程，每个子工程仅完成某一特定功能，例如，登录子工程、订单业务子工程、支付业务子工程、红包业务子工程等。即，将原来项目中的业务模块，变为了独立工程。在这种情况下若性能还需要进一步再提升，则可为每个项目构建集群。这种将一个应用使用多个独立的工程实现的系统架构，称为
SOA 系统架构（ServiceOriented Architecture，即面向服务的系统架构）。
这些子工程原本都是为一个应用服务的，而该应用在没有被拆分为多个子工程时，原本都是在一个工程中的，各个模块都是运行在处于同一个主机的同一个 JVM 中，一个类的对象调用另一个类的对象，即各个模块间进行数据通信是没有任何问题的。但拆分为多个子工程后，各个子工程都是运行在各自的主机的 JVM 中的，它们间的数据通信如何实现的呢？可以通过
RPC 协议（Remote Procedure Call Protocol，远程过程调用协议）完成通信。Dubbo就是 RPC 协议的实现者之一。
什么是 SOA?
SOA，Service Oriented Architecture，面向服务的架构，是一个组件模型（即子项目模型），它将应用程序的不同功能单元（称为服务）通过这些服务之间定义的良好接口和契约联系起来。接口是采用中立的方式进行定义的（所谓中立方式是指没有与任何具体实现相绑定的的定义方式，即只有接口，没有实现的方式）。它应该独立于实现服务的硬件平台、操作系统（即跨平台）和编程语言（即已被编译为可执行文件）。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件（即子项目）进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性（即人为参与度更低了）。SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。SOA 可以看作是 B/S 模型、XML（标准通用标记语言的子集）/Web Service 技术之后的自然延伸。SOA 将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以 SOA 架构的系统能够更加从容地面对业务的急剧变化。
什么是 RPC？
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型（OSI 七层网络模型，OSI，Open System Interconnection，开放系统互联）中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。RPC 采用客户机/服务器模式（即 C/S 模式）。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。其实 RPC 的底层就是 Socket 实现的，只要知道对方的主机名与端口号，就可通过网络连接上，而无需知道其底层是怎样实现的通信。
系统架构设计的关键点
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。当流量增加时通过搭建集群增加主机的水平扩展方式可以提升整个系统的性能。此时，用于简化增删改查工作量的数据访问框架是关键。
垂直应用架构
当访问量逐渐增大，单一应用架构的水平扩展，其所带来的速度提升越来越小。此时可以将应用拆成互不相干的几个应用，以提升效率。这时用于加速前端页面开发的 Web 框架是关键。
分布式服务架构
当垂直应用越来越多，应用之间的交互是不可避免的。这时将核心业务抽取出来作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键。
流动计算架构
当服务越来越多，容量的评估（主机所能支撑特定服务的能力称为容量）、小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心，使其基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心是关键。
Dubbo 简介
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。
Dubbo 四大组件
1.Provider：暴露服务方，亦称为服务提供者。
2.Consumer：调用远程服务方，亦称为服务消费者。
3.Registry：服务注册与发现的中心，提供目录服务，亦称为服务注册中心
4.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，领域驱动模型设计）无关。
1.Protocol 服务域：是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
2.Invoker 实体域：是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
3.Invocation 会话域：它持有调用过程中的变量，比如方法名，参数等。
Dubbo 的两大设计原则
Double 这个框架在设计时有两大设计原则：
1.采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。
2.采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息.
Dubbo 整体架构
Dubbo 的架构设计共分为了 10 层。最上面的 Service 层是 Dubbo 开发分布式服务开发者实现业务逻辑的接口层。图中左边淡蓝色背景为服务消费者使用的接口，右边淡绿色背景为服务提供者使用的接口，位于中轴线的为双方都要用到的接口。对于这 10 层，根据其总体功能划分，可以划分为三大层：
Business 层
该层仅包含一个 service 服务层，该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。
RPC 层
该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下 6 层。
config 配置层 ,proxy 服务代理层,
registry 注册中心层 ,
cluster 路由层,
monitor 监控层,
protocol 远程调用层 .
Remotting 层
Remoting 实现是 Dubbo 协议的实现，如果我们选择 RMI 协议，整个 Remoting 都不会用上，Remoting 内部再划为 Transport 传输层和 Exchange 信息交换层，Transport 层只负责单向消息传输，是对 Mina, Netty, Grizzly 的抽象，它也可以扩展 UDP 传输，而 Exchange层是在传输层之上封装了 Request-Response 语义。具体包含以下三层
（1）exchange 信息交换层
封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger和 ExchangeChannel,ExchangeClient 和 ExchangeServer。
（2） transport 网络传输层
抽象和 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、
Client、Server 和 Codec。
（3） serialize 数据序列化层
可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObejctOutput 和 ThreadPool。