MQ消息队列-RabbitMQRabbitMQ的整体架构以及核心概念：
VirtualHost：虚拟主机，起到数据隔离的作用（类似于Mysql中的一个个的数据库）
publisher：消息发送者
consumer：消息的消费者
queue：队列，存储消息
exchange：交换机，负责路由消息
Spring AMQPAMQP是用于应用程序之间传递业务消息的开放标准。该协议与语言和平台无关，更符合微服务中独立性的要求。
而Spring AMQP 就是基于AMQP定义的一套API规范，提供了模板来发送和接收消息。包含两部分，其中spring-amqp是基础抽象，spring-rabbit是底层的默认实现。 废话太多，其实这个东西就是让我们收发消息更加简单的
Work QueuesWork Queues ,任务模型，就是让多个消费者绑定到一个队列，共同消费队列中的消息
向队列中发消息同一个消息只能被一个消费者能处理
消费者轮询处理消息
当有高并发的时候可以多加几个消费者，解决了消息堆积问题（多个消费者绑定到一个队列，可以加快消息处理速度）
设置preFetch实现能者多劳
默认情况下 ...
MQ消息队列初识同步调用优势：
时效性强， 等待结果后才返回问题：
扩展性差
性能下降
级联失败（雪崩）
异步调用优势：
解除耦合，扩展性强
无需等待，性能好
故障隔离
缓存消息，流量削峰填谷问题：
不能立即得到调用结果，可能都得不到结果，时效性差
不能确定下游业务执行是否成功
业务安全依赖于Broker（消息代理） 的可靠性
MQ技术RabbitMQ消息队列是用来做消息收发的。
对比项
RabbitMQ
ActiveMQ
RocketMQ
Kafka
公司 / 社区
Rabbit
Apache
阿里
Apache
开发语言
Erlang
Java
Java
Scala&Java
协议支持
AMQP, XMPP, SMTP, STOMP
OpenWire,STOMP,REST,XMPP,AMQP
自定义协议
自定义协议
可用性
高
一般
高
高
单机吞吐量
一般
差
高
非常高
消息延迟
微秒级
毫秒级
毫秒级
毫秒以内
消息可靠性
高
一般
高
一般
Seata
未读分布式事务解决方案 - Seata在分布式系统中，如果一个业务需要多个服务合作完成，而且每一个服务都有事务，多个事务必须同时成功或失败，这样的事务就是分布式事务。其中的每个服务的事务就是一个分支事务。整个业务称为全局事务。
应该是都成功或者都失败才对
分布式事务解决思路：Seata架构
相互之间不知道对方成没成功，想办法让事务分支之间感知到彼此的事务状态，才能保证状态一致。
Seata架构
TC - 事务协调者
TM - 事务管理器
RM - 资源管理器
Dcoker部署Seata
注意：部署之前先看有哪些网桥
1docker network ls
然后看自己的mysql容器是不是在这个网桥下：
1docker inspect mysql
我这里查出来的是在hmall下
再查以下nacos容器，我这里查出来是不在hmall里的如果不在就可以把已经存在的加进来：
1docker network connect hmall nacos
最后执行如下命令即可完成seata的容器化部署
123456789docker run --name seata \-p 8099:80 ...
Sentinel
未读微服务保护- Sentinel流控Sentinel 是阿里巴巴开源的一款微服务控制组件。官网地址：[[https://sentinelguard.io/zh-cn/index.html\]\]
启动准备好的sentinel jar包
1java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar
用户密码默认是sentinel
整合到微服务
引入依赖
12345<!--sentinel--><dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId></dependency>
配置控制台
12345spring: c ...
SpringCloud
未读雪崩问题雪崩问题产生的原因是什么？
微服务互相调用，服务提供者出现故障或阻塞
服务调用者没有做好异常处理，导致自身故障
调用链中的所有服务级联失败，导致整个集群故障## 解决问题的思路有哪些
尽量避免服务出现故障或阻塞·✔保证代码的健壮性·✔保证网络的畅通·✔能应对较高的并发请求
服务调用者做好远程调用异常的后备方案，避免故障扩散
服务保护方案 – 请求限流（保护服务提供者）请求限流：限制访问微服务的并发量，避免服务因流量激增出现故障
服务保护方案 – 线程隔离（服务调用的这一方）线程隔离：也叫做舱壁模式，模拟船舱隔板的防水原理。通过限定每个业务能使用的线程数量将故障业务隔离，避免故障扩散## 服务保护方案 – 服务熔断
既然服务C挂了，那干嘛还要访问呢，为了避免资源浪费，直接拒绝访问挂掉的服务C
服务熔断：由熔断器统计请求的异常比例或慢调用比例，如果超出阈值则会熔断该业务，则拦截该接口的请求
失败处理：熔断器件，所有请求快速失败，全都走fallback逻辑这样就提高了前端的响应速度
以上这些都让我一一实现吗，这显然是难，所以spring都给我们提供好了一些服务保护技术
Sentin ...
SpringCloud
未读网关、配置管理（热更新）、动态路由1.什么是网关就是网络的关口，负责请求的路由、转发、身份校验以前我们单体项目前端要向后端发起请求，很简单，直接发就行了但是拆分成微服务之后就麻烦了：所以有了网关
就比如找人，你得有户口簿、打野才会给你开门，如果你不知道你要找的人在哪，大爷会带你去，这就叫做网关。下面给你看更加专业的图网关始终请求8080，这毋庸置疑，然后到了网关，他去判断前端请求的业务需要的是哪个微服务处理这个请求
那么这个判断的过程就是请求的路由
接下来网关就会将躯体的请求转发到具体的微服务了，这就是路由转发
当然了，部署上线 后的服务里面可能有多个实例，形成集群，所以要在多个实例之间运用负载均衡
所有的微服务信息就会服务注册到注册中心，它里面就会有多有的微服务信息
当然网关也是一个微服务，启动之后也可以去注册中心拉取所有的服务地址由于前端只知道网关地址，因此整个微服务对前端来讲，是隐藏起来的黑盒，这样在前端看来现在的后端跟原来的单体架构没什么区别，这时候微服务就不用向外界暴露自己的端口地址了，也是对后端的一种保护。
2. 配置路由规则123456789101112spring: ...
SpringCloud
未读OpenFeign–简化远程调用1. 如何使用步骤
引入依赖，包括OpenFeign和负载均衡组件SpringCloudLoadBalancer
1234567891011<!--OpenFeign--><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId></dependency><!--负载均衡--><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-loadbalancer</artifactId> </dependency><!-- 以前用的是Ribbon>
通过 @Ena ...
服务治理1.注册中心原理服务治理中有三个角色：
服务提供者：暴露服务接口，供其他服务调用
服务调用者：调用其他服务提供的接口
注册中心：记录并监控微服务各实例状态，推送服务变更信息
解决了哪些问题
服务的调用者不知道该调用谁，只需要找到注册中心，他就会告诉你，额日期额还能告诉你一堆让你挑（==负载均衡==）
==有的服务挂了呢==，服务（微服务）提供者不仅要注册到注册中心，还要与注册中心之间形成心跳续约（定期向注册中心发请求，证明我还活着），如果不跳了，注册中心也会把你从这个服务列表中去掉，注册中心会推送变更。
注册中心原理总结消费者如何得知服务状态变更？
服务提供者通过心跳机制向注册中心报告自己的健康状态，当心跳异常时注册中心会将异常服务剔除，并通知订阅了该服务的消费者当提供者有多个实例时，消费者该选择哪一个？
消费者可以通过负载均衡算法，从多个实例中选择一个当然了，自己实现注册中心还是有难度的，我们不需要自己实现，因为有很多框架已经为我们实现了==Nacos注册中心 ...
海林OJ在线系统技术选型
技术分类
具体技术栈
前端技术
vue3、html、JavaScript、scss、element plus
服务架构
Spring Cloud 微服务架构
代理服务器
Nginx
分布式任务调度中心
Xxl-Job
注册与发现中心 / 配置中心
Nacos
服务间调用
OpenFeign
网关
Spring Cloud Gateway
数据存储
MySQL
数据库持久层
MyBatis/MyBatis-Plus
缓存
Redis
消息队列
rabbitMQ
搜索引擎
ElasticSearch
加密算法
Bcrypt
身份认证
JWT
代码沙箱
Docker
对象存储
OSS
短信服务
阿里云短信服务
开发环境Windows - 10/11后端：
idea 社区版 2022.1.4
JDK17
SpringBoot 3 （3.0.1）
SpringCloud
docker前端：
Node.js 18.3 或以上部署环境：
开发完成后再说
系统架构- ...
认识微服务1.单体架构把所有业务功能集成在以哦个项目中开发，打成一个包部署优点：
部署简单
部署成本低缺点：
团队协作太难了
系统发布效率低
系统可用性差（线上运行，有些并发量搞，如果部署在一台服务器上，可能资源耗尽，等待释放，用户体验差）某一个线程并发量太高，就吃完了Tomcat的资源，当访问其他接口的时候就会出现看卡顿/延迟现象
==总结：单体架构适合开发功能简单，规模较小的项目。==
2.微服务把单个架构中的功能模块拆分为多个独立项目
粒度小
团队自治
服务自治==拆分为多个小的模块之后，编译速度大幅度提高，每个服务独立在一个服务器上，解决了系统可用性差问题，数据库也是隔离的每个服务独立的，避免了高并发访问时的影响其他服务了。==
3.微服务技术栈SpringCloud3.1单体拆分成微服务有纵向拆分和横向拆分我这里就给大家展示纵向拆分，具体怎么拆分是要看具体的项目的
首先创建一个module
拆分可以是对某个服务进行拆分，从数据库再到整体的业务，要做到：高内聚，低耦合
像大型项目 ...
