当前位置: 首页>后端>正文

微服务 Spring Cloud Alibaba 三高架构实战

简单记录笔记,不详细说明如何使用。

1、传统单体架构
普通错误可能会导致整个系统无法使用。集体开发困难。水平扩展只能整体。等等。。。

2、nacos
注册中心,服务把ip端口注册上去,使用者拉取下来。
服务治理,心跳检测
高并发:服务注册与服务拉取,如何避免冲突,通过“加锁”(不是真的加锁,copyOnWrite思想),在往注册表写的时候就不能读。但加锁,还能高并发吗?所以底层其实并不是加锁的,加锁就变串行化了。
读是读真正内容,写是写到副本,这就是写时复制(复制一份来写),读写分离,自然就高并发,当然fork的时候也得考虑,这就要看看源码,没记错的话是加锁,并且操作量小并快速,所以加锁影响小。
eureka:多级缓存设计思想:

  • 在拉取注册表的时候:
    • 首先从ReadOnlyCacheMap里查缓存的注册表
    • 若没有,就找ReadWriteCacheMap里缓存的注册表
    • 如果还没有,就从内存中获取实际的注册表数据
  • 在注册表发生变更的时候:
    • 会在内存中更新变更的注册表数据,同时过期掉ReadWriteCacheMap
    • 此过程不会影响ReadOnlyCacheMap提供人家查询注册表
    • 默认美30秒Eureka Server会将ReadWriteCacheMap更新到ReadOnlyCacheMap里
    • 默认每180秒Eureka Server会将ReadWriteCacheMap里的数据失效
    • 下次有服务拉取注册表,又会从内存中获取最新的数据了,同时填充各级缓存。

所以Eureka启动一个服务,要过一段时间才能感知得到,因为写的是真正的注册表,但读的是缓存,而缓存是定时从真正注册表那里复制的。懂了就能优化

3、ribbon
服务列表拉取下来之后想通过服务名来请求,就需要ribbon负载均衡,就可以通过服务名来发起restTemplate请求。是用拦截器实现的,截取url中的域名,然后从缓存注册表中拿到对应域名的所有地址,然后负载均衡选择一个来替换url


微服务 Spring Cloud Alibaba 三高架构实战,第1张

4、服务剔除
当注册中心一段时间内没有收到服务的心跳,就会从服务中剔除

5、服务高可用
在服务不可用时,但注册中心还没剔除的时候,有这么一个时间段,如果这时发起对该服务的请求,请求失败就会ribbon重试

6、nacos其实很简单
其实就是维护一堆的open-api,然后api有各自对应的功能。
例如注册服务:POST /nacos/v1/ns/instance
例如发送实例心跳:PUT /nacos/v1/ns/instance/beat
其他服务只要发起这个地址的请求,按要求给定参数,就完成服务注册了、心跳续约等等

7、openfeign
用了ribbon之后,url变成了"http://stock-service/stock/deduct/"+productId+"/"+stockCount,需要自己获取参数,再拼接参数,甚至post请求的要获取参数,然后又再构造参数来发起请求,这样处理比较麻烦,就可以使用openfeign,像dubbo那样调用service来调用远程接口
低层是动态代理,主要是做一些拼接、参数处理,还会使用ribbon处理服务名

微服务 Spring Cloud Alibaba 三高架构实战,第2张

8、服务降级
通常需要用feign调用多个远程接口,这时如果一个调用有异常,会导致整个接口抛出异常。
例如下订单,加积分,减库存,如果加积分错误了,会导致后面无法减库存,可以通过捕捉异常,然后记录日志,然后定时的读取日志看谁的积分没加上的,然后再次补偿操作,这种思想就是服务降级
可以使用sentinel、hystrix。

9、限流
sentinel的客户端主要是做服务降级,限流需要sentinel的服务端。
服务端会有一个管理系统,类似nacos,可视化操作


微服务 Spring Cloud Alibaba 三高架构实战,第3张

10、熔断
思想:加积分接口如果已经能猜到是调用失败的,那还需要每次请求都调用一次吗?
明显是没必要的,直接调用本地的服务降级方法。
同样可以在可视化界面上操作


微服务 Spring Cloud Alibaba 三高架构实战,第4张

10秒内至少5个请求,并且失败次数达到80%,就会熔断,这10秒内的剩余时间都是调用本地服务降级的方法

11、sentinel底层
最主要的是滑动时间窗口,来计算QPS来决定是否熔断

12、分布式事务seata
默认是AT模式,所以也是要特别去理解的模式
有一个协调中心(协调者),然后订单服务和库存服务,两个服务各自的本地事务都提交成功,都会各自告诉协调者,协调者收到之后就不用做回滚。如果有一个服务本地事务回滚的,协调者就会查询undo_log表,回滚操作,主要回滚的是那个本地提交成功的。
seata其实也是加锁操作,本地锁、全局锁,所以一般seata用在并发量不高,数据一致性高的场景,例如资金(seata就是蚂蚁金服和阿里内部的中间件融合出来的)

13、网关 gateway
有旧的用zuul,网关好处很多,服务屏蔽、鉴权、统一入口(前端不用记录一堆地址)。。。。
网关最重要是路由,可以通过yml配置,所有网关代码量非常少的。


https://www.xamrdz.com/backend/3tk1935207.html

相关文章: