【微服务】4、服务保护

微服务架构与组件介绍

  1. 单体架构拆分:黑马商城早期为单体架构,后拆分为微服务架构。
  2. 跨服务调用与组件使用
    • 服务拆分后存在跨服务远程调用,如下单需查询商品信息,使用openfeign组件解决。
    • 服务间调用关系复杂,需维护服务地址和健康状态,采用Nacos组件进行服务治理。
    • 前端因服务增多不知调用哪个服务,引入网关组件,实现前端请求路由转发和身份认证。
    • 微服务增多致配置复杂,学习配置管理组件(Nacos),可抽取共享配置、实现热更新,提高服务可用性。

服务保护

雪崩问题引入

  • 微服务中一个小故障可能引发雪崩,如某服务故障处理不当,可能导致整个链路乃至微服务群不可用。

雪崩问题举例分析

  1. 购物车服务调用场景:以购物车服务为例,其业务复杂,可能调用多个其他服务,如商品服务等,正常情况下调用返回结果处理成功。
  2. 商品服务故障影响
    • 若商品服务故障,请求卡住不返回或处理时间过长(如正常几十毫秒,故障时达几秒),购物车服务调用商品服务的请求无法得到响应,导致购物车服务请求也无法返回给用户。
    • 在高并发场景下,每秒请求量多,处理速度跟不上请求速度,购物车服务所在服务器资源有限,请求堆积会耗尽资源。
    • 新请求因购物车服务资源耗尽无法进入,即使其原本要调用的服务正常,也会导致购物车服务瘫痪,类似地,其他调用商品服务或购物车服务的服务也可能因资源耗尽出现故障,最终可能使整个微服务群多数服务宕机,形成雪崩。

雪崩问题产生原因

  1. 服务提供者故障:某微服务提供者出现故障,如进入请求阻塞或处理速度极慢。
  2. 调用者异常处理不当:服务调用者未做好应对,在调用故障服务时被卡住或等待时间长,导致自身资源耗尽,调用链中所有调用者接连失败。

雪崩问题解决思路

  1. 避免服务故障思路
    • 保证代码质量,避免代码逻辑复杂(如for循环嵌套、频繁查数据库)导致响应时间变长、内存溢出等问题。
    • 确保网络畅通,满足微服务间相互调用的网络消耗,保证足够带宽。
    • 应对高并发请求,具备处理大量请求能力,避免服务被压垮。
  2. 故障应对处理
    • 无法保证服务百分百不故障,服务调用者需做好远程调用异常后备方案,发现调用异常时做好处理,避免故障扩散,具体后备处理方式将后续分析。

服务保护

请求限流

  1. 雪崩问题解决方案概述

    • 解决思路

      • 保护服务提供者,避免出现故障。
      • 服务调用者隔离故障,防止故障传递。
    • 服务保护方案分类

      • 请求限流:限制访问微服务的请求并发量,保护服务提供者。
      • 线程隔离(舱壁模式):限定每个业务使用的线程数量,实现业务隔离,避免故障扩散。
      • 服务熔断与fallback逻辑:断路器监控请求异常比例和慢调用比例,超出阈值熔断接口请求,熔断后走fallback逻辑,避免资源浪费。
  2. 请求限流

    • 原理:通过限流器按设定流量放行请求,将狂暴波动的并发处理成平稳请求,保护服务提供者。
    • 作用:避免服务因流量激增出现故障,是流量整形的一种方式。
  1. 线程隔离(舱壁模式)
    • 思想来源:模拟船舱隔板防水原理,将故障隔离在一定范围内。
    • 实现方式:限定每个业务能够使用的线程数量。例如服务A调用服务B和C,可限定业务一调用服务B使用10个线程,业务二调用服务C使用4个线程。当服务C故障时,业务二最多占用4个线程,不会耗尽服务A资源,保证其他业务不受影响。
    • 作用:实现业务隔离,避免故障扩散,但仅做隔离仍可能浪费资源。
  1. 服务熔断与fallback逻辑

    • 服务熔断
      • 原理:断路器统计请求异常比例和慢调用比例,超出阈值熔断接口请求。
      • 举例:服务A调用服务C,若多次调用异常或慢调用比例高,断路器断开,拒绝后续请求。
    • fallback逻辑
      • 概念 :熔断后定义的后备处理方案。
      • 实现:在服务调用者处提前写好业务逻辑,如查询广告数据业务,熔断后可返回默认广告数据;无返回值业务可返回友好提示给前端。
      • 作用 :减少远程调用和等待,提高处理速度,避免资源浪费,提高前端响应速度。
  2. Sentinel与Hystrix对比

    • 产品信息
      • Sentinel:Spring Cloud阿里巴巴产品。
      • Hystrix:Spring Cloud Netflix(网飞)产品。
    • 功能特性对比
      • 线程隔离:Sentinel基于信号量隔离;Hystrix默认基于线程池隔离,也可支持信号量(需调整配置)。
      • 熔断策略:Sentinel熔断策略较多,慢调用或异常调用比例过高都会触发;Hystrix主要是异常比例中断。
      • 限流:Sentinel限流方式多样,功能强大;Hystrix相对简单,基于线程池简单限流。
      • fallback:两者均支持。
    • 控制台
      • Sentinel提供开箱即用可配置控制台,可实时监控项目运行状态。
      • Hystrix控制台较简陋。
    • 配置方式
      • Sentinel可基于控制台或代码实现,仅基于控制台重启会失效。
      • Hystrix默认基于配置文件和注解,需编码实现,永久生效。
相关推荐
程序猿零零漆1 小时前
SpringCloud系列教程:微服务的未来(十)服务调用、注册中心原理、Nacos注册中心
java·spring cloud·微服务
-Bin2 小时前
net-http-transport 引发的句柄数(协程)泄漏问题
网络·网络协议·http·云原生·golang
筑梦之路10 小时前
k8s helm部署kafka集群(KRaft模式)——筑梦之路
云原生·容器·kubernetes
宋冠巡10 小时前
Eureka Client 服务消费者(调用API接口)(使用OpenFeign)
云原生·eureka
元气满满的热码式12 小时前
K8S中的Pod生命周期之容器探测
云原生·容器·kubernetes
天草二十六_简村人19 小时前
微服务框架,Http异步编程中,如何保证数据的最终一致性
java·spring boot·后端·http·微服务·架构
Stanford_110619 小时前
关于物联网的基础知识(三)——物联网技术架构:连接万物的智慧之道!连接未来的万物之网!
c++·物联网·学习·微信小程序·架构·twitter·微信开放平台
码农小灰20 小时前
微服务拆分的艺术:构建高效、灵活的系统架构
微服务·架构·系统架构