此系列文章整理是以Dubbo官方文档作为参考，主要为自己学习使用。不足之处请多见谅。官网地址：Dubbo官网

Dubbo是什么？

官网描述：

Apache Dubbo™ 是一款高性能Java RPC框架。

Dubbo是由Alibaba提供已经孵化成功的Apache*开源项目。目前已发布稳定版本2.7.5 (2019-12-29)。
官网地址：http://dubbo.apache.org/en-us/index.html
那既然Dubbo是高性能的RPC框架，那什么是RPC?

RPC

RPC英文全名为Remote Procedure Call，远程过程调用，其实就是一个计算机通信协议，它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。计算机通信协议有很多种，类比下我们熟悉的是HTTP协议，我这里就做个简单的比较，HTTP协议是属于应用层的，而RPC跨越了传输层和应用层。HTTP本身的三次握手协议，每发送一次请求，都会有一次建立连接的过程，就会带来一定的延迟，并且HTTP本身的报文庞大，而RPC可以按需连接，调用结束后就断掉，也可以是长链接，多个远程过程调用共享同一个链接，可以看出来RPC的效率要高于HTTP，但是相对于开发简单快速的HTTP服务,RPC服务就会显得复杂一些。
那Dubbo作为RPC框架是怎样诞生的呢，首先还是得说下系统架构的发展。

背景

参考官方文档：
Dubbo诞生背景

这里稍做补充，网站应用的发展从单一应用架构，垂直应用架构，分布式应用架构，微服务应用架构，还有文中提到的流动计算架构，再到目前也比较火的基于独立代理进程的架构Service Mesh。目前蚂蚁金服提供了一套金融行业应用的解决方案SOFAStack，就是基于Service Mesh实现的，其中有部分项目也开源了，了解详情可以参考官网：SOFAStack官网，其中SOFAMesh已经开源：SOFAMesh介绍

分布式的几种解决方案

根据上面说的架构的演进，其实对应互联网应用系统的分布式解决方案可以有几种不同的实现形式，这里做简单介绍。其实也是可以说根据系统的应用范围，复杂度和实际使用情况进行区分。
1 集中式中心化分布式架构
看下图其实很好理解，消费者和服务提供者之间通过负载和反向代理实现服务的调用。这个也是目前一般中小应用的实现形式，实现简单。

2 去中心化分布式架构
目前应用较广的就为此类型的架构，Duboo和Spring Cloud就是此类型的解决方案。此类型架构实现方案是在应用内部集成服务注册发现、客户端负载均衡、代理等功能。此类型架构有以下特点：去中心化，客户端直连服务端；动态注册和发现服务；高效稳定的网络传输；可扩展性较高，可扩展容错、限流、服务降级等；还可以做到定制服务监控。

3 基于独立代理进程的分布式架构(Service Mesh)
这个就是上面说的目前也比较火的一种实现，但是实际应用的却不多，因为对于这种系统的运维要求十分高，也只有像阿里这样的大厂才玩的转。不多做介绍了。

Dubbo就是上述第二种实现。后面文章也是主要介绍Dubbo。

Dubbo架构

这个图应该都见过，这就是Dubbo官网给的架构图，是不是很简单。
节点角色说明：

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

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

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。
上面都是来自官网，就不拷贝了。详情：Dubbo架构

设计的意义：

1. Consumer 与Provider 解偶，双方都可以横向增减节点数。
2. 注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台。
3. 去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用。
4. 服务提供者无状态，任意一台宕掉后，不影响使用。

---

参考:
1.http://dubbo.apache.org/zh-cn/docs/user/preface/background.html