写点什么

微服务稳定性保障

  • 2022 年 10 月 01 日
    河北
  • 本文字数:1455 字

    阅读完需:约 5 分钟

微服务稳定性保障

微服务改造中,挑战最大的就是拆分之后的稳定性保障,拆分之后链路复杂、故障点众多,需要一套体系化的稳定性保障机制。


  1. 稳定性保障的目标

微服务稳定性保障需要从事前、事中和事后全方位进行考虑。微服务架构下,应用程序、依赖服务、网络、硬件等都有可能出现故障,稳定性设计和保障的具体目标如下。


故障预防,尽可能减少故障的产生,绝大多数稳定性问题和稳定性故障发生都有一定的诱因,并且一般是在多种拦截手段均失灵的情况下故障才会发生,如果我们在故障发生前制定完备的稳定性保障措施,可以最大限度地减少稳定性故障的发生。


故障快速定位,完全不出故障的业务是不存在的,关键是出故障时能够快速发现故障,只有及时发现,才能在最短时间内采取相应的解决措施。


故障快速止损,发生故障后第一时间要进行业务止损,恢复业务的正常运行,故障深层次的具体原因可以事后再分析和复盘解决。


  1. 稳定性保障的 6 个维度

系统故障点很多,稳定性保障就是对故障点进行管理的过程。可以从故障点管理的角度将整个稳定性设计和保障分为如下隔离、冗余、容灾容错、变更管理、时间相关故障管理与运维友好 6 个维度。

  • 隔离

稳定性设计的第一个原则就是“隔离”,通过各种隔离机制,将核心服务之前的故障点隔离出去,保证核心服务的可用性。

隔离机制的指导原则是将变和不变、重要和非重要区分开来,变更是稳定性故障的最主要的来源,将容易发生变化的部分从核心服务和核心流程中剥离开来,减少核心部分的变更,可以保障核心系统的稳定性。隔离机制的一大手段就是解耦,通过解耦可以把核心服务和非核心服务隔离开来,同时核心服务访问非核心服务时,通过熔断、超时和重试等机制,最大限度地保障非核心服务故障不会影响整体的稳定性。


  • 冗余

通过服务级别、机器级别、集群级别、机房级别等多种维度的冗余,我们可以保证:即便核心服务出问题,也可以通过相应的流量切换策略,将流量切到冗余节点上,保证业务不受影响。

为了尽量避免冗余同时失效的情况,冗余副本之间需要相互独立,完全对等,不能相互依赖,机房内副本跨交换机部署(此时一般也能保证跨机柜),如果有多机房冗余的情况,各机房独立,不能有完全相同的依赖。


  • 容灾容错

稳定性设计的第三个原则是“容灾容错”,通过构建多维度的容灾容错体系,保证系统面对异常输入时,仍然能够提高稳定的输出能力。

服务可以通过降级和限流,减少突发大流量对系统的冲击,保证系统稳定输出,为了保证降级和限流操作的即时性,系统需要支持配置的动态修改和生效。


  • 变更管理

绝大部分稳定性故障都是由变更引起,系统如果长时间没有任何变更,很少会有稳定性问题,因此服务稳定性保障的关键一环是严把变更这一关,保证变更质量。

针对变更,需要制定完善的变更规范,变更时严格按照规范进行,再小的变更都可能会产生稳定性隐患,因此变更时一定要加强稳定性意识,变更的每一步操作都要进行各项监控项检查,如果出现问题立即进行回滚。


  • 时间相关故障管理

服务没有变更时,有一类故障很少发生并且很难发现,就是随时间变化而产生的 ID 越界和溢出,这类故障平常测试时很难发现,并且发生时会对整个系统产生很大的影响。


  • 运维友好

为了实现运维友好的系统设计,系统需要将故障分析和定位时涉及的所有相关信息监控起来,构建完善的监控闭环,对系统层、服务层、接口层、业务层等维度进行监控收集和告警。为了减少系统的稳定性隐患,微服务架构设计中尽量遵循简单的设计原则,从业务的真实需求出发,避免纯粹从技术角度出发的高大上技术方案,如果不是业务的核心功能,必要时可以进行一定的折中和裁剪,尽量保证系统的简单和简洁性。


发布于: 刚刚阅读数: 5
用户头像

InfoQ签约作者 2018.11.30 加入

热爱生活,收藏美好,专注技术,持续成长

评论

发布
暂无评论
微服务稳定性保障_微服务_穿过生命散发芬芳_InfoQ写作社区