随着互联网项目用户量的急剧增长，访问并发良突然暴增，将一个应用使用多个独立的工程共同实现的系统架构，称为SOA系统架构，各个工程可以允许在不同的机器上，他们之间可以通过RPC协议（远程过程调用协议），完成通信，Dubbo就是RPC协议的实现着之一
Dubbo的简单介绍
Dubbo是阿里的一个开源的服务框架，可以实现应用拆分为多个工程， 通过RPC实现服务间的输出和输入，可以和Spring框架无缝连接，官方原话"Dubbo是一款高性能，轻量级的开源JavaRPC框架，他提供了三大核心能力：”面向接口的远程调用“，”智能容错和负载均衡“，”服务的自动注册和发现““。
-
2011年开源，成为同类框架佼佼者
-
2014年10月30日，发布了2.4.11版本后，Dubbo停止更新
-
2017年9月7号，在GitHub上发布了2.5.4版本
-
2017年10月的云栖大会上，阿里向外公开消息：将其列为重点项目维护
-
2018.2.15,也是酒大年三十，Dubbo进入Apach孵化器
Dubbo的四大组件
-
Provider：服务的暴露者，也就是提供服务的人
-
Consumer：服务的调用方，也就是服务的消费者
-
Registry：服务的注册与发现中心，比如Zeekkper，Eureka，Redis，官方推荐使用ZK
-
Monitor：服务监控中心，统计服务的调用次数、调用时间等信息的日子服务等
官网中的流程图的解释：
0.start ：Dubbo服务器启动，Spring容器首先会创建服务提供者
1.register ：服务提供者创建好了以后，将该服务注册到注册中心，这个过程称为服务暴露
2.subscribe：服务消费者启动后，首先回想注册中心订阅相关的服务
3.notify：消费订阅的服务在注册中心中可能还没有注册，但不不影响，因为是虚线，代表异步，并不会阻塞，还可以订阅其他服务，当相应的服务被注册到注册中心后，注册中心会马上通知订阅了该服务的消费者，
4.invoke：消费者以同步的方式调用服务提供者的请求，消费者通过远程注册中心的服务列表调用远程服务，Dubbo会基于负载均衡算法，选一台服务提供者出路消费者的请求，因为是同步的，所以在服务提供方没有返回服务结果之前，消费者出路阻塞状态，知道服务提供者返回服务结果，或者等待超时，若是等待超时，Dubbo会再选一个服务提供者为消费者提供服务，当然以我Spring cloud的基础来看：(如果服务迟迟不响应，可能造成线程用完要么直接宕机要么服务降级)
5.count 每个消费者对各个服务的累积调用次数，调用时间，每个服务提供者的服务被调用的次数和时间，消费者和提供者都会将数据定时发送给监控中心，这些数据都可以在Dubbo的可视化界面看到
Dubbo的三二一（了解内容）
Dubbo的三大领域模型
为了对Dubbo整体架构叙述的方便，Dubbo抽象出了三个领域模型
-
Protocol服务域：是invoker暴露和引用的主功能入口，它负责invoker的生命周期管理
-
Invoker实体域：是Dubbo的核心模型，它代表一个可执行体，可向他发起invoke调用，它有可能是一个本地的实现，也有可能是一个远程的实现，也可能是一个集群实现
-
Invacation会话域：它持有调用过程中的变量，比如方法名，参数等
Dubbo的两大设计原则
-
采用Microkernel + Plugin模式，Microkernel 只负责组装Plugin,Dubbo自身的功能也是通过扩实现的，也就是Dubbo的所有功能点都可以被用户自定义扩展和替换
-
采用URL作为配置信息的统一公司，所有扩展点都是通过传递URL携带配置信息
Dubbo的一个整体架构
