Spring Cloud失散多年的哥哥Dubbo学习笔记

Spring Cloud失散多年的哥哥Dubbo

随着互联网项目用户量的急剧增长，访问并发良突然暴增，将一个应用使用多个独立的工程共同实现的系统架构，称为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的一个整体架构

　　

• Dubbo的整体架构如上所示，总共分了10层，最上面Service层是Dubbo开发分布式服务开发着实现业务逻辑的接口层，图中淡蓝色背景为服务消费者使用的接口，右边淡青色背景为服务提供者使用的接口，位于中轴线的为双方都要使用到的接口。

• 详细见官网 ： http://dubbo.apache.org/en-us/docs/dev/design.html