微服务常用故障处理机制

简介: 【2月更文挑战第11天】微服务系统可能出现故障的种类,主要有三种故障:集群故障、单 IDC 故障、单机故障。

微服务系统可能出现故障的种类,主要有三种故障。

  • 集群故障。微服务系统一般都是集群部署的,根据业务量大小而定,集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug,可能整个集群都会发生故障,不能提供对外提供服务。
  • 单 IDC 故障。现在大多数互联网公司为了保证业务的高可用性,往往业务部署在不止一个 IDC。然而现实中时常会发生某个 IDC 的光缆因为道路施工被挖断,导致整个 IDC 脱网。
  • 单机故障。顾名思义就是集群中的个别机器出现故障,这种情况往往对全局没有太大影响,但会导致调用到故障机器上的请求都失败,影响整个系统的成功率。


集群故障

一般而言,集群故障的产生原因不外乎有两种:一种是代码 bug 所导致,比如说某一段 Java 代码不断地分配大对象,但没有及时回收导致 JVM OOM 退出;另一种是突发的流量冲击,超出了系统的最大承载能力,比如“双 11”这种购物活动,电商系统会在零点一瞬间涌入大量流量,超出系统的最大承载能力,一下子就把整个系统给压垮了。


1)限流

限流就是限制流量,通常情况下,系统能够承载的流量根据集群规模的大小是固定的,可以称之为系统的最大容量。当真实流量超过了系统的最大容量后,就会导致系统响应变慢,服务调用出现大量超时,反映给用户的感觉就是卡顿、无响应。所以,应该根据系统的最大容量,给系统设置一个阈值,超过这个阈值的请求会被自动抛弃,这样的话可以最大限度地保证系统提供的服务正常。


除此之外,通常一个微服务系统会同时提供多个服务,每个服务在同一时刻的请求量也是不同的,很可能出现的一种情况就是,系统中某个服务的请求量突增,占用了系统中大部分资源,导致其他服务没有资源可用。因此,还要针对系统中每个服务的请求量也设置一个阈值,超过这个阈值的请求也要被自动抛弃,这样的话不至于因为一个服务影响了其他所有服务。


在实际项目中,可以用两个指标来衡量服务的请求量,一个是 QPS 即每秒请求量一个是工作线程数。不过 QPS 因为不同服务的响应快慢不同,所以系统能够承载的 QPS 相差很大,因此一般选择工作线程数来作为限流的指标,给系统设置一个总的最大工作线程数以及单个服务的最大工作线程数,这样的话无论是系统的总请求量过大导致整体工作线程数量达到最大工作线程数,还是某个服务的请求量超过单个服务的最大工作线程数,都会被限流,以起到保护整个系统的作用。


2)降级

降级就是通过停止系统中的某些功能,来保证系统整体的可用性。降级可以说是一种被动防御的措施。


具体来讲,就是在系统运行的内存中开辟一块区域,专门用于存储开关的状态,也就是开启还是关闭。并且需要监听某个端口,通过这个端口可以向系统下发命令,来改变内存中开关的状态。当开关开启时,业务的某一段逻辑就不再执行,而正常情况下,开关是关闭的状态。


开关一般用在两种地方,一种是新增的业务逻辑,因为新增的业务逻辑相对来说不成熟,往往具备一定的风险,所以需要加开关来控制新业务逻辑是否执行;另一种是依赖的服务或资源,因为依赖的服务或者资源不总是可靠的,所以最好是有开关能够控制是否对依赖服务或资源发起调用,来保证即使依赖出现问题,也能通过降级来避免影响。


在实际业务应用的时候,降级要按照对业务的影响程度进行分级,一般分为三级:一级降级是对业务影响最小的降级,在故障的情况下,首先执行一级降级,所以一级降级也可以设置成自动降级,不需要人为干预;二级降级是对业务有一定影响的降级,在故障的情况下,如果一级降级起不到多大作用的时候,可以人为采取措施,执行二级降级;三级降级是对业务有较大影响的降级,这种降级要么是对商业收入有重大影响,要么是对用户体验有重大影响,所以操作起来要非常谨慎,不在最后时刻一般不予采用。


单 IDC 故障

在现实情况下,整个 IDC 脱网的事情时有发生,多半是因为不可抗力比如机房着火、光缆被挖断等,如果业务全部部署在这个 IDC,那就完全不可访问了,所以国内大部分的互联网业务多采用多 IDC 部署。具体来说,有的采用同城双活,也就是在一个城市的两个 IDC 内部署;有的采用异地多活,一般是在两个城市的两个 IDC 内部署;当然也有支付宝这种金融级别的应用采用了“三地五中心”部署,这种部署成本显然高比两个 IDC 要高得多,但可用性的保障要更高。


采用多 IDC 部署的最大好处就是当有一个 IDC 发生故障时,可以把原来访问故障 IDC 的流量切换到正常的 IDC,来保证业务的正常访问。

流量切换的方式一般有两种,一种是基于 DNS 解析的流量切换,一种是基于 RPC 分组的流量切换。


1)基于 DNS 解析的流量切换

基于 DNS 解析流量的切换,一般是通过把请求访问域名解析的 VIP 从一个 IDC 切换到另外一个 IDC。比如访问“www.abc.com”,正常情况下北方用户会解析到联通机房的 VIP,南方用户会解析到电信机房的 VIP,如果联通机房发生故障的话,会把北方用户访问也解析到电信机房的 VIP,只不过此时网络延迟可能会变长。


2) 基于 RPC 分组的流量切换

对于一个服务来说,如果是部署在多个 IDC 的话,一般每个 IDC 就是一个分组。假如一个 IDC 出现故障,那么原先路由到这个分组的流量,就可以通过向配置中心下发命令,把原先路由到这个分组的流量全部切换到别的分组,这样的话就可以切换故障 IDC 的流量了。


单机故障

单机故障是发生概率最高的一种故障了,尤其对于业务量大的互联网应用来说,上万台机器的规模也是很常见的。这种情况下,发生单机故障的概率就很高了,这个时候只靠运维人肉处理显然不可行,所以就要求有某种手段来自动处理单机故障。


处理单机故障一个有效的办法就是自动重启。具体来讲,你可以设置一个阈值,比如以某个接口的平均耗时为准,当监控单机上某个接口的平均耗时超过一定阈值时,就认为这台机器有问题,这个时候就需要把有问题的机器从线上集群中摘除掉,然后在重启服务后,重新加入到集群中。


不过这里要注意的是,需要防止网络抖动造成的接口超时从而触发自动重启。一种方法是在收集单机接口耗时数据时,多采集几个点,比如每 10s 采集一个点,采集 5 个点,当 5 个点中有超过 3 个点的数据都超过设定的阈值范围,才认为是真正的单机问题,这时会触发自动重启策略。


除此之外,为了防止某些特殊情况下,短时间内被重启的单机过多,造成整个服务池可用节点数太少,最好是设置一个可重启的单机数量占整个集群的最大比例,一般这个比例不要超过 10%,因为正常情况下,不大可能有超过 10% 的单机都出现故障。


在遇到实际的故障时,往往多个手段是并用的,比如在出现单 IDC 故障,首先要快速切换流量到正常的 IDC,但此时可能正常 IDC 并不足以支撑两个 IDC 的流量,所以这个时候首先要降级部分功能,保证正常的 IDC 顺利支撑切换过来的流量。


而且要尽量让故障处理自动化,这样可以大大减少故障影响的时间。因为一旦需要引入人为干预,往往故障处理的时间都得是 10 分钟以上,这对大部分用户敏感型业务的影响是巨大的,如果能做到自动化故障处理的话,可以将故障处理的时间降低到 1 分钟以内甚至秒级别,这样的话对于用户的影响最小。

相关文章
|
5月前
|
缓存 运维 监控
微服务技术系列教程(22) - SpringCloud- 服务保护机制Hystrix
微服务技术系列教程(22) - SpringCloud- 服务保护机制Hystrix
57 0
|
7天前
|
运维 负载均衡 网络协议
探索微服务架构下的服务发现机制
【4月更文挑战第6天】 随着现代软件工程的发展,微服务架构因其灵活性、可扩展性而日益受到重视。在此架构模式下,服务发现成为了确保系统高可用性和弹性的关键组件。本文将深入探讨微服务环境中服务发现的核心概念、实现方式以及面临的挑战,旨在为开发者提供一套明晰的服务发现指南和实践建议。
|
1月前
|
敏捷开发 缓存 负载均衡
微服务架构下的服务发现与注册机制
【2月更文挑战第21天】 随着现代应用向微服务架构转型,服务的数量和复杂性不断增加。在这种环境下,有效的服务发现与注册机制成为确保系统可伸缩性和高可用性的关键。本文深入探讨了微服务架构中服务发现的基本原则、常用模式及其实现技术,同时分析了服务注册的流程和优势。文章旨在为开发者提供一个清晰的指引,帮助他们在构建分布式系统时做出明智的设计选择。
|
1月前
|
存储 负载均衡 Java
【Spring底层原理高级进阶】微服务 Spring Cloud 的注册发现机制:Eureka 的架构设计、服务注册与发现的实现原理,深入掌握 Ribbon 和 Feign 的用法 ️
【Spring底层原理高级进阶】微服务 Spring Cloud 的注册发现机制:Eureka 的架构设计、服务注册与发现的实现原理,深入掌握 Ribbon 和 Feign 的用法 ️
|
1月前
|
Dubbo 网络协议 应用服务中间件
分布式微服务框架dubbo原理与机制
分布式微服务框架dubbo原理与机制
|
2月前
|
负载均衡 应用服务中间件 nginx
深入探索微服务架构中的服务发现机制
在当今微服务架构盛行的背景下,服务发现成为了保证系统高效运行的关键技术之一。本文将深入探讨服务发现的概念、重要性以及实现方式,通过对比不同服务发现机制的优劣,为读者提供在微服务架构设计中做出合理选择的参考。文章首先介绍了服务发现的基本概念和作用,随后详细分析了客户端发现和服务端发现两种主流机制,并以Eureka、Consul、Zookeeper等常见服务发现工具为例,展开讨论。最后,文章还探讨了服务发现在微服务架构中面临的挑战和未来发展趋势,旨在为微服务架构的设计和实施提供全面而深入的指导。
|
3月前
|
Dubbo Java 应用服务中间件
微服务框架(十五)Dubbo 超时机制及服务降级
此系列文章将会描述Java框架Spring Boot、服务治理框架Dubbo、应用容器引擎Docker,及使用Spring Boot集成Dubbo、Mybatis等开源框架,其中穿插着Spring Boot中日志切面等技术的实现,然后通过gitlab-CI以持续集成为Docker镜像。 本文为Dubbo超时机制及服务降级 当服务出现创建超时的时候,TimeoutFilter会打印该创建记录的详细信息,日志级别为WARN,即为可恢复异常,或瞬时的状态不一致
|
9月前
|
Kubernetes Go 网络架构
Go微服务架构实战 中篇:3. 扩缩容、自愈和故障转移、滚动更新以及回退能力
Go微服务架构实战 中篇:3. 扩缩容、自愈和故障转移、滚动更新以及回退能力
|
11月前
|
缓存 监控 负载均衡
【微服务架构】为故障设计微服务架构
【微服务架构】为故障设计微服务架构
|
11月前
|
自然语言处理 负载均衡 Dubbo
带你读《Apache Dubbo微服务开发从入门到精通》——三、 负载均衡机制(1)
带你读《Apache Dubbo微服务开发从入门到精通》——三、 负载均衡机制(1)
89 0