分布式事务解决方案–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接口入口都是由网关实现转发
解决的问题
- 解决微服务登陆验证问题,减少代码冗余
- 跨域问题
- 保护服务 限流 黑名单和白名单
- 权限控制
- 日志控制
过滤器与网关的区别
过滤器适合单个请求过滤(局部)
网关适合过滤整个微服务请求(全局)
整体流程
请求访问网关,网关根据名称去nacos拿去真实对应服务的ip地址,然后进行转发(有点nginx)
底层是基于webflux实现的
搭建gateway集群 前面还有Nginx 有个虚拟vip
sentinel限流降级框架
限流的算法:计数器,令牌桶,滑动窗口,漏桶
服务限流/降级
处理服务雪崩,
服务隔离机制
线程池隔离/信号量隔离
线程池隔离:每个服务接口都有自己独立的线程池,互不影响,缺点就是占用cpu资源很大
服务信号量隔离:最多只有一定阈值的线程数处理我们的请求,超过就会拒绝请求(相当于熔断)
分布式事务
2pc/3pc协议使用场景
LCN,Seata