SpringCloud学习笔记

分布式事务解决方案–seata解决

服务治理–用于模块之间发现服务，用一个治理中心解决 nacos

分布式服务追踪

分布式任务调度 分片定时任务 xxl-job

分布式日志 elk

分布式配置中心 动态化配置 nacos

传统RPC调用会有什么问题

1.超时问题，调用无响应，需要设置超时时间

2.安全问题，https，加密，令牌传输，限流，服务保护

3.服务与服务之间URL地址管理，因为服务与服务之间依赖关系很复杂，接口写死，后期难以管理

接口超时时间与连接不上的问题

连接不上是因为服务器宕机了

超时是请求到服务端了，只是服务器没有及时响应

服务治理的问题

如果要动态化的实现服务治理可以用数据库的解决方案，建个表每次调用就查表，发现地址。但效率极低!而且如果要进行扩容，或者增加服务都要对数据进行插入

可以采用注册中心解决，动态感知

本地负载均衡

从注册中心获取到地址以后，需要本地做负载均衡–Rebbin

1.轮询策略

2.随机策略

3.权重策略

4.一致性hash策略

feign客户端调用接口

原本的接口调用太不优雅了，所以有了feign，加个注解就可以进行调用了

feign底层原理

通过代理模式实现

1.通过反射获取@FeignClient注解下的类

2.获取类调用方法上的名称@Getmapping，通过拼接实现

nacos分布式配置中心

为什么需要配置中心？

因为传统项目如果修改配置文件需要对整个项目进行重启，很不方便

原理

就如下图所示，

本地项目和配置中心建立长连接，如果git或者svn中配置文件被修改了，nacos会对项目进行通知，将最新配置文件刷新过去

流程：

管理人员发布配置文件，将配置文件持久化到硬盘里

分布式配置中心服务端监听 客户端连接

本地项目连接到分布式配置中心服务端，分布式配置中心服务端读取文件返回给本地项目（客户端）

如果分布式配置中心服务端发现配置文件有改动，会自动通知本地项目刷新配置文件

nacos集群–nignx实现+db

zookeeper选举原理

每个节点是zxid，先会去判断zxid是否相等，相等的话比较myid（不可重复）

然后比较myid

投票机制

能者多劳，过半机制，参与选举的时候，环境是无法使用的

zookeeper流程

但写请求来的时候，会想在leader节点写入，然后zxid会+1

然后依次将zxid发到从节点上，从节点的zxid进行修改和同步，假如此时第一个从节点修改成功，然后leader宕机了，那么会进行重新选举，整个环境是不可用的

zookeeper做注册中心，是使用zab协议，保证节点的数据一致性问题，模型：cp保证数据一致性，但zk节点要满足过半的机制，不满足可能会无法访问，因为要保证数据一致性

Eruka去中心化

节点之间相互注册，人人平等

微服务网关 gateway

所有微服务api接口入口都是由网关实现转发

解决的问题

1. 解决微服务登陆验证问题，减少代码冗余
2. 跨域问题
3. 保护服务 限流 黑名单和白名单
4. 权限控制
5. 日志控制

过滤器与网关的区别

过滤器适合单个请求过滤（局部）

网关适合过滤整个微服务请求（全局）

整体流程

请求访问网关，网关根据名称去nacos拿去真实对应服务的ip地址，然后进行转发（有点nginx）

底层是基于webflux实现的

搭建gateway集群 前面还有Nginx 有个虚拟vip

sentinel限流降级框架

限流的算法：计数器，令牌桶，滑动窗口，漏桶

服务限流/降级

处理服务雪崩，

服务隔离机制

线程池隔离/信号量隔离

线程池隔离：每个服务接口都有自己独立的线程池，互不影响，缺点就是占用cpu资源很大

服务信号量隔离：最多只有一定阈值的线程数处理我们的请求，超过就会拒绝请求（相当于熔断）

分布式事务

2pc/3pc协议使用场景

LCN，Seata