【微服务】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默认基于配置文件和注解,需编码实现,永久生效。
相关推荐
2的n次方_2 小时前
Runtime 内存管理深化:推理批处理下的内存复用与生命周期精细控制
c语言·网络·架构
前端市界3 小时前
用 React 手搓一个 3D 翻页书籍组件,呼吸海浪式翻页,交互体验带感!
前端·架构·github
文艺理科生3 小时前
Nginx 路径映射深度解析:从本地开发到生产交付的底层哲学
前端·后端·架构
C澒3 小时前
Vue 项目渐进式迁移 React:组件库接入与跨框架协同技术方案
前端·vue.js·react.js·架构·系统架构
消失的旧时光-19434 小时前
从 Kotlin 到 Dart:为什么 sealed 是处理「多种返回结果」的最佳方式?
android·开发语言·flutter·架构·kotlin·sealed
惊讶的猫4 小时前
OpenFeign(声明式HTTP客户端)
网络·网络协议·http·微服务·openfeign
鹏北海4 小时前
micro-app 微前端项目部署指南
前端·nginx·微服务
L543414464 小时前
告别代码堆砌匠厂架构让你的系统吞吐量翻倍提升
大数据·人工智能·架构·自动化·rpa
子春一5 小时前
Flutter for OpenHarmony:色彩捕手:基于 CIELAB 色差模型与人眼感知的高保真色彩匹配游戏架构解析
flutter·游戏·架构
冻感糕人~6 小时前
收藏备用|小白&程序员必看!AI Agent入门详解(附工业落地实操关联)
大数据·人工智能·架构·大模型·agent·ai大模型·大模型学习