概述

稳定性大于一切，因此我们需要有更有效的方式避免线上故障。在发生故障不可避免的假设下，我们需要能够快速修复，减少线上影响。基于以上这些想法，我们提出了 1-5-10 的快恢目标，所谓 1-5-10 的目标就是是要我们对于线上问题能够做到 1 分钟发现，5 分钟定位，10 分钟修复。下面将会介绍一些阿里云上关于故障恢复、诊断的一些最佳实践。

1 分钟发现

监控

监控的作用一句话概括就是：发现应用中的问题，并将问题及时告警给技术人员进行处理。监控类型可以分为系统问题的监控与业务问题的监控，系统问题：常见的软硬件相关问题，比如程序异常，内存 fullGC 等，由于没有业务特征，监控策略可适用于各个应用。业务问题：在特定业务场景下定义的问题，比如商品无优惠券，权益超发问题等，需要根据业务特征来定制监控策略。

阿里云实时应用监控服务 ARMS 能够自动发现和监控应用代码中常见的 Web 框架和 RPC 框架，并统计接口的调用量、响应时间、错误数等指标。同时可以进一步获取接口的慢 SQL、MQ 堆积分析报表或者异常分类报表，对错、慢等常见问题进行更细致的分析。

ARMS 还提供了业务监控的能力，以代码无侵入的方式，可视化定义业务请求，提供贴合业务的丰富性能指标与诊断能力。从业务视角衡量应用性能和稳定性的新方式，对业务的关键交易进行全链路的监控。业务监控通过追踪并采集应用程序中的业务信息，实时展现业务级的指标，例如业务的响应时长、次数和错误率，解决了应用程序和业务表现之间无法映射关联的难题。

对于监控的要求有以下三点。实时：要求对问题的发现和预警是实时的，缩短问题产生和发现的时延；准确：要求监控和预警是准确的，包括对监控问题的定义，对预警阀值，预警等级，责任人的配置，避免误报；全面：要求预警信息是全面的，能够帮助排查和解决问题。

“不论应用出现任何问题，ARMS 都可以清楚地展示问题出在哪一行代码。ARMS 对于我们非常重要，大大缩短了修复故障的时间，显著提升了用户体验。自从用了 ARMS，我们能及时发现和修复问题，再也不会被用户投诉所困扰。” —— 华润万家

告警

当监控发现有问题的时候，就需要通过不同等级的告警将问题及时告警给技术人员进行处理。ARMS 告警管理能从以下几点来提升系统的运维效率。

• 集成事件后管理更高效。
  • 告警管理默认支持一键化集成阿里云常见的监控工具，并支持更多的监控工具手动接入，方便统一维护。
  • 事件接入模块稳定，能提供 7x24 小时的无间断事件处理服务。
  • 处理海量事件数据时可以保证低延时。
• 及时准确地将告警通知给联系人。
  • 配置通知规则，对事件合并后再发送告警通知，减少运维人员出现通知疲劳的情况。
  • 根据告警的紧急程度选择邮件、短信、电话、钉钉等不同的通知方式，来提醒联系人处理告警。
  • 通过升级通知对长时间没有处理的告警进行多次提醒，保证告警及时解决。
• 帮助您快速便捷地管理告警。
  • 联系人能通过钉钉随时处理告警。
  • 使用通用告警格式，联系人能更好的分析告警。
  • 多个联系人通过钉钉协同处理。
• 统计告警数据，实时分析处理情况，改进告警处理效率。

5 分钟定位故障

服务实例隔离与诊断

在线上微服务场景中，当服务提供者的某些实例出现异常时，一方面，需要避免服务消费者访问到异常实例，另一方面，需要保留异常现场，便于后续的问题排查。出于另一个思路考虑，我们都知道 Dump 内存在一定程度上会影响我们应用的性能，可能会对我们的线上业务造成影响，我们是否可以在 Dump 内存之前将业务流量从该实例上隔离。MSE 治理中心服务实例隔离与诊断功能可以帮助我们将异常实例的流量隔离，一方面支持将来自微服务的流量进行隔离，另一方面支持将来自 K8s Service 的流量进行隔离，可以彻底隔离掉生产环境中的业务流量，然后我们可以结合阿里云应用实时监控服务 ARMS 所提供的内存快照生成能力，及时生成异常实例的线上环境内存快照，帮助我们进行后续问题分析与诊断。服务实例隔离与诊断功能能很好地帮助我们应对线上突发的事故（比如内存泄露等），提升微服务系统整体稳定性。

• 实践

我们可以在 MSE 服务治理的控制台看到在线的实例列表。

选择特定异常实例，进行服务下线操作，将实例从注册中心中移除，同时如果我们配置了 MSE 提供的就绪检查探针，还会将来自 K8s Service 的流量进行隔离，我们可以在事件中心里查看对应实例是否下线成功。

进行下线操作后，我们可以通过 MSE 提供的秒级节点监控看到是否还有流量。等流量完全停止后，可通过阿里云应用监控服务 ARMS 提供的创建内存快照功能，给异常实例创建内存快照，以便后续进一步的问题排查。

点击去创建内存快照按钮，进行内存快照创建。

点击保存即可创建快照任务。

点击保存后我们看到 172.16.0.200 这个实例已经存在快照

进一步根据控制台的提示，我们分别将 Core File 进行转储、分析、查看

点击查看后，自动跳转至 Grace 分析的页面，我们可以看到内存分析的概况，内存泄露报表、类加载器等等一系列信息。通过详细的内存分析数据查看内存占用的详细信息，从而进一步排查内存泄漏和内存浪费等内存问题。

最后提一下，我们可以通过服务上线恢复隔离的流量。

Arthas 诊断

Arthas 是诊断 Java 领域线上问题的利器，利用字节码增强技术，可以在不重启 JVM 进程的情况下，查看程序的运行情况。

• JVM 概览

JVM 概览支持查看应用的 JVM 相关信息，包括 JVM 内存、操作系统信息、变量信息等，帮助我们了解 JVM 的总体情况。

1、JVM 内存：JVM 内存的相关信息，包括堆内存使用情况、非堆内存使用情况、GC 情况等。

2、操作系统信息：操作系统的相关信息，包括平均负载情况，操作系统名称、操作系统版本、Java 版本等。

3、变量信息：变量的相关信息，包括系统变量和环境变量。

• 线程耗时分析

线程耗时分析支持显示该应用的所有线程和查看线程的堆栈信息，帮助我们快速定位耗时较高的线程。

1、线程耗时分析页签会实时获取当前 JVM 进程的线程耗时情况，并将相似线程聚合。可以查看线程的 ID、CPU 使用率和状态。

2、我们可以在目标线程右侧的操作列，单击查看实时堆栈。

• 方法执行分析

方法执行分析支持抓取方法的某一次执行的耗时、入参、返回值等信息和钻入，帮助您快速定位导致慢调用的根本原因，以及问题线下无法复现或日志缺失等场景。

如下图所示，每一次内部方法的执行耗时都会以注释的方式显示在源代码中。

• 对象查看器

对象查看器用于查看一些单例对象当前的状态，用于排查应用状态异常问题，例如应用配置、黑白名单、成员变量等。

• 实时看板

实时看板用于查看系统中用到的关键组件的实时状态，例如查看数据库连接池的使用情况、HTTP 连接池的使用情况等，有利于排查资源类型的问题。

如下图显示为一个 Druid 连接池的实时状态信息，包括基础配置、连接池状态、执行耗时分布等。

• 性能分析

性能分析支持对 CPU 耗时、内存分配等对象进行一定时间的采样并生成相应的火焰图，帮助您快速定位应用的性能瓶颈。

10 分钟恢复

离群实例摘除

在微服务架构中，当服务提供者的应用的某些实例出现异常，而服务消费者无法感知时会影响服务的正常调用，并影响消费者的服务性能甚至可用性。离群实例摘除功能会检测应用实例的可用性并进行动态调整，以保证服务成功调用，从而提升业务的稳定性和服务质量。

服务熔断与降级

当应用遇到业务高峰期，发现下游的服务提供者遇到性能瓶颈，甚至即将影响业务时。我们可以对部分的服务消费者进行服务熔断操作，针对持续不稳定调用的自动熔断，从而提升整体服务的稳定性。当应用依赖的下游服务出现不可用的情况，导致业务流量损失。您可以通过配置服务熔断能力，当下游服务出现异常时，服务降级使流量可以在调用端 "fail fast"，有效防止雪崩。

在业务高峰期，某些下游的服务提供者遇到性能瓶颈，甚至影响业务。我们对部分非关键服务消费者配置自动熔断，当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果，这样既可以保障调用端不被不稳定服务拖垮，又可以给不稳定下游服务一些“喘息”的时间，同时可以保障整个业务链路的正常运转。

另外一些场景，服务降级可以帮助我们保障一些重要的服务。一些非关键的服务不太稳定，希望在重要活动前临时降级掉这些弱依赖服务调用，把资源保留给其它核心服务，从而保证整体业务的顺畅。

离群实例摘除与服务熔断、服务降级主要是体现在两点：

1、自动完成：服务降级是一种运维动作，需要通过控制台进行配置，并且指定对应的服务名才能做到相应的效果；而离群实例摘除、服务熔断能力是会主动探测上游节点的存活情况或者服务调用的成功异常、慢调用等情况，在这条链路上做自动的隔离或者熔断操作，保障服务的质量。

2、摘除粒度：服务降级降级的是（服务+节点 IP），以 Dubbo 举例子，一个进程会发布以服务接口名（Interface）为服务名的微服务，如果触发到这个服务的降级，下次将不再调用这个节点的此服务，但是还是会调用其他服务。但是离群实例摘除是整个节点都不会去尝试调用。

流控、扩容、重启、回滚

• 流量控制：根据流量、并发线程数、响应时间等指标，把随机到来的流量调整成合适的形状，即流量塑形。通过流控能力，为服务接口配置流控规则，让容量范围内的请求通过，多余的请求被拒绝，相当于安全气囊的作用。层层防护，在 Nginx/Ingress 网关层进行粗粒度保护，在微服务层进行 API、接口、方法、参数粒度控制。避免应用被瞬时的流量高峰冲垮，从而保障应用的高可用性。

• 扩容：水平横向扩容提升集群可用性
• 重启：重新启动 JVM 进程，从而暂时消除长时间运行累积的问题如内存泄露等
• 回滚：消除变更引入的问题

基于同可用区优先的一键切流

同城的特点是 RT 一般处在一个比较底的延迟（< 3ms 以内），所以在默认情况下，我们可以基于同城的不同可用区搭建起来一个大的局域网，然后把我们应用跨可用区分布在多个可用区中，以此来应对单可用区出现故障时可以更好地控制故障的影响面。

MSE 服务治理在服务框架层面提供了同机房优先路由的能力，如果目标服务和自己所在可用区相同，则优先将流量路由至和当前同可用区的节点。当某个可用区出现不可用的情况，我们只需在网关对流量进行切流，将出故障可用区的流量隔离，即马上可恢复我们的业务。

尾

1-5-10 故障快恢，故障 1 分钟响应、5 分钟定位、10 分钟恢复；只有不断地面向失败地设计、基于故障应急方式演练，那么在真正遇到线上故障的时候我们才可以更加从容地面对故障。我们希望新一代的云原生微服务能更多地具备系统自愈能力，微服务架构内部可以自动感知外部组件的失效，自动切换至备用链路，真正地把故障扼杀在摇篮之中。

原文链接

本文为阿里云原创内容，未经允许不得转载。