dubbo是阿里开源的高可用服务端架构，只要用于后端服务器的调度，今天小松心血来潮，在b站搜了一个课程来学一学，不过我并没有实操，毕竟没有那么多时间，算是“云学习”哈哈，这篇文章就当是我学过dubbo的证据了
文章最后会附上视频地址，有兴趣的小伙伴可以去看看，因为我对dubbo算是初学，下面的总结都是来自视频，可能有过时或者错误的地方，欢迎探讨
基础知识
Dubbo架构
使用方法：
-
将服务提供者注册到zookeeper注册中心
- 导入dubbo依赖，操作zookeeper的客户端
- 配置provider
- 指定当前服务/应用的名字
- provider注册到注册中心，指定位置
- 指定通信规则，协议和端口
- 暴露服务service让别人调用，ref指向service真正的实现对象
可以在后端浏览器看到已经提供了服务
-
消费者consumer注册到zookeeper注册中心
- ref接口引用 provider提供的服务类名，生成远程服务代理
- 给服务增加注解，自动注入，并scan service
-
测试
在应用中获取consumer 容器，拿到service对象，传入consumerId，调用service的方法进行服务，此时servcie在远程，完成RPC（远程服务调用）
-
监控中心 监控服务调用
配置流程 ：引入依赖，配置name和port，连接注册中心，监控中心，使用注解设置为暴露功能，最后在本地浏览器访问
高可用场景
权重随机负载
当任务来的时候，为了避免单个服务器过载，我们需要适当分配任务到不同的服务器
下图是轮询，权重的机制，
简单说就是按照service 1，2，3的顺序轮流访问，但是设置了权重，每7次访问，必须1号机有2次命中，2号机有4次命中，所以1，2，3轮流一遍，第二遍从1开始，然后2，随后由于3已经用掉一次，1已经用掉2次，所以接下来都是访问2
访问顺序就是1，2，3，1，2，2，2
还有最小活跃数，一致性哈希机制，大家有兴趣可以搜搜看
其他场景
除了上面的策略，还有一些常见的情况处理
-
注册中心挂掉
缓存:依然能够访问服务，因为consumer连接一次后会在本地进行缓存
dubbo直连: service显示指定provider地址，可以不用从注册中心查询
-
服务降级
服务器压力剧增时，降级一些边缘服务，释放资源处理核心服务，调用时返回null即可避免调用边缘服务
-
集群容错
配置重试次数，多次提供服务失败的服务器及时切换到其他服务器处理
并行调用，可以多个服务器同时处理，任意服务器完成成功即可返回，适用于核心紧急服务，但是浪费资源
广播通知，逐个调用，任意服务器报错则失败，适用于更新缓存和日志
实际编码：整合hystrix
原理
RPC原理：完成远程过程调用
computer 01作为消费方，computer 02作为服务方的过程
netty 通信原理
BIO 阻塞式IO
每一个线程对应一个服务，服务在IO的时候容易阻塞
NIO 非阻塞式IO
有总的selector监听，哪一个channel的任务准备好了就可以直接运行
框架设计
下图是dubbo的整体结构图
第一层是程序员调用的，下面全部是底层，东西很多，我就不一一列举了，主要是对dubbo有一个直观的印象
主要分为Business， RPC， Remoting三个大层
后面更深的源码讲解有点听不懂了，需要自己下载源码debug才能明白，后端的小伙伴建议实操一下哦
一早上基本在看这个视频，如果对dubbo有兴趣的小伙伴可以去看看，传送门
