首页  思维导图  详情

Spring Cloud

2023-12-04 17:47:01   0  举报





AI智能生成

为你推荐

查看更多



Spring Cloud Alibaba学习笔记

spring cloud微服务架构

spring cloud Refresh Scope

Spring Cloud Alibaba微服务架构

架构设计、系统架构、微服务、分布式、spring、spring boot、spring cloud

java

作者其他创作

大纲/内容

独立进程单元通过负载均衡策略，将请求转发到不同的执行单元上，例如Ngnix 。

将负载均衡逻辑以代码的形式封装到服务消费者的客户端上，服务消费者客户端维护了一份服务提供者的信息列表，有了信息列表，通过负载均衡策略将请求分摊给多个服务提供者，从而达到负载均衡的目的。例如Ribbon

将负载分摊到多个执行单元上

是通过Ribbon的ILoadBalancer接口实现

分支主题

负载均衡

ribbon-loadbalancer：可以独立使用或与其他模块一起使用的负载均衡器API 。

ribbon-eureka ：Ribbon 结合Eureka 客户端的API ，为负载均衡器提供动态服务注册列表信息。

ribbon-core: Ribbon 的核心API 。

子模块

声明式的web service客户端

集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端

Feign

Ribbon

微服务架构下，会存在服务之间相互依赖调用的情况，当某个服务不可用时，很容易因为服务之间的依赖关系使故障扩大，甚至造成整个系统不可用的情况，这种现象称为服务雪崩效应。

Hystrix实现了断路器模式，当某个服务发生故障时，通过断路器的监控，给调用方返回一个错误响应，而不是长时间的等待，这样就不会使得调用方由于长时间得不到响应而占用线程，从而防止故障的蔓延

服务雪崩

由于被调用方出现问题，调用方无法及时获取响应结果，而一直在发送请求，最终会耗尽所有线程的资源

避免线程失败

当被调用方出现问题后，调用方发起的请求可以快速失败并返回，这样就不用一直阻塞住，同时也释放了线程资源。

快速失败

在失败后，我们可以让用户有回退的逻辑，比如获取备用数据，从缓存中获取数据，记录日志等操作

支持回退

资源隔离

近实时监控

设计原则

重载getFallback()方法

服务降级

服务熔断

请求缓存

请求合并

服务监控

线程池/信号量对依赖的服务进行隔离

依赖隔离

高可用

1.构建HystrixCommand或者HystrixObservableCommand对象

2.执行命令（即上述 Command 对象包装的逻辑）

3.结果是否有缓存

4.断路器是否打开

5.线程池/请求队列/信号量是否占满

6.使用HystrixObservableCommand.construct()还是HystrixCommand.run()

7.计算链路健康度

8.失败回退逻辑

9.返回正常回应

实现流程

Hystrix

将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而发布方不需要做任何修改。

解耦

将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。

异步

系统慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

削峰

使用场景

系统可用性降低

系统复杂性增加

缺点

基本概念

提高吞吐量

优点

可用性无保障，queue所在节点宕机数据就丢失

集群内部可能产生大量的数据传输，有数据拉取开销

普通集群模式（无高可用）

完整数据存在多个实例中

性能开销较大，消息需要同步到所有机器

无法线性扩展

镜像集群模式

RabbitMq

天然分布式。多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。

kafka

数据库插入唯一键约束

消息加上唯一ID进行判断

消息重复消费

消息积压

会降低吞吐量，因为太耗性能

1. 使用事务

2. 使用Confirm机制

1. 生产者弄丢了数据

开启持久化

2. RabbitMq弄丢了数据

关闭自动ACK

3. 消费端弄丢了数据

如何处理消息丢失

拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点；或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

一个 topic，一个 partition，一个 consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个

写 N 个内存 queue，具有相同业务规则的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性

Kafka

如何保证消息传递的顺序性

问题解决

消息队列

在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服。，服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理（下一篇文章讲述），配置服务的配置文件放在git仓库，方便开发人员随时改配置。

Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如/api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能

路由网关(zuul)

Eureka Server默认每隔一段时间(60S)将当前清单中超时(90S)未续约的服务剔除

失效剔除

当Eureka Server节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

自我保护

服务注册中心

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，Server将其存储在一个双层Map中

服务注册

多个注册中心互相注册成服务，同步注册请求

服务同步

Eureka客户会每隔30秒发送一次心跳来续约

服务续约

服务提供者

Eureka Server缓存一份只读服务清单给客户端，30S更新一次

获取服务

客户端货去到服务清单后，由Ribbon进行负载均衡决定调用具体的服务实例