一、软件系统架构的演变
单一架构：网站流量小，只需要把所所有应用部署在一起
垂直架构：将应用拆成几个互不相干的应用，分别部署
分布式架构：
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求，这时候分布式架构就出现了
二、RPC:Remote Procedure Call,远程过程调用
不知道大家看了分布式架构的定义后，有没有思考这样一个问题，这些抽取出来独立的服务模块之间是互相有联系的，举个栗子，订单页面需要调用订单服务、用户服务还有可能调用商品服务，但是这些不同的服务都是在不同的应用服务器上，如何解决这个问题呢？这时候就引入了RPC，是进行远程调用的一个过程。
三、Dubbo
RPC只是一个过程，不是具体的技术，这个过程里面到底怎么通信、不同应用之间怎么调用、怎么传递数据？
Dubbo就是干这个事的，所以Dubbo就出现了，它是阿里巴巴开源的Java RPC框架（2011年开源在github上，2014年跟新2.4.1版本，之后再没跟新，知道2017年，spring cloud抢占分布式巨头，阿里有将dubbox和dubbok合并跟新到dubbo2.6,2018年除夕开源给apache）
目前Dubbo更新到了3.0版本。
四、Dubbo的特性
面向接口代理的高性能RPC调用：如果A服务器要调用B服务器的应用上的方法，只需要将B服务器的应用上的方法的接口拿来，调一下接口的方法，dubbo就会自动去找B服务器上的代码，为我们屏蔽了远程调用的细节，类似于用mybatis一样。
智能负载均衡：比如说用户业务访问量特别大，一台服务器不够，我们多放几台服务器；可能有十几台服务器都在跑用户业务，用户web想要调用用户业务，那么调用那个服务器上的用户业务呢？有些服务器上的应用少比如10个，有些多比如100个，这个决策过程就是负载均衡，每个服务器都有一个合理的负载量，不要让一个服务器做太多的活，也不能资源浪费。
服务的自动注册与发现：业务很多的时候，比如用户服务在1、2、3、4、5、7这几台服务器上，支付业务在6、8、9、10这几台服务器上，我们的订单业务想要调用支付业务模块，我们的dubbo又如何知道支付业务在哪些服务器上，如果一些服务器宕机了，又该怎么解决呢，这时候就需要一种机制叫注册中心，为了动态的感知到，将所有的服务都注册到注册中心，注册中心相当于维护了一个清单，哪些业务在哪些服务器上，如果某一个服务器有问题了，注册中心就将其删掉，通过注册中心，dubbo实时感知服务上线是不是能用了，还是下线用不了了。
这里引用官网的一个图
服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
调用关系说明
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。