最近在推荐我们业务线的核心链路稳定性，将中间所做的工作的总结梳理一下。

核心链路梳理

第一步要做的，就是要理清楚自己业务的核心链路包括哪些，作为一个后端开发人员，总会自己感觉这一块比较简单很容易说出口，但是，有两点需要注意的：

  • 核心链路要全盘梳理，不要只关注自己的模块。比如，在A模块的核心链路里面依赖了B的一个功能，而B模块在梳理的时候觉得这个功能不是核心的，就没有做稳定性的考虑，这就会导致整体上核心链路不稳定。
  • 核心链路除了要理清楚“业务”上的核心链路，还要跟前端开发人员一起看看，“界面”的核心链路。不要让一些界面的操作因为一个后端非核心链路而阻塞了用户的核心行为。

核心链路技术点

理清楚核心链路之后，就可以有针对性的进行改造，力求核心链路的高稳定性。下面是我们用到的一些技术点：

  • 异步改造：将过长的非核心流程异步化，通过MQ或者RPC的异步都可以，设置基于线程池的异步任务也可以考虑，重点是保障核心链路快速返回
  • 定时任务异步Check：特别针对一些回调更新的数据，需要一些主动核对的功能，防止异步回调没有触发；
  • MQ延迟队列代替异步定时任务：异步定时任务有的时候如果数据太多，性能就会下降，这个时候，可以考虑使用MQ的延迟队列
  • B端库和C端库隔离：防止B端的一些操作对C端请求有影响，也可以将B的请求使用ES，Hive，备库进行处理，就是为了保护C端的库
  • 线程池隔离：核心业务和非核心业务在线程池上隔离开
  • 一键降级：降级的时候，跟产品确认降级数据是否合理
  • MQ监控：一般而言，RPC的监控还是比较好做，但是，MQ的监控往往很容易被忽略，比如，发送失败，发送延迟拉高，消费异常，消息堆积等等，都要监控起来
  • 扩容方案：不要等待有问题再找机子，事先想好扩容的方案是什么；另外，扩容一方面可以应对突发流量，另一方面，也可以应对自己应用一些隐藏的bug，这些bug可能会导致CPU和内存异常。

核心指标监控和报警

梳理清楚了核心链路，那么，核心的指标也很容易梳理清楚，关键是把核心的指标监控起来，并且一定要实时的监控和报警， 比如，购买次数，成单量，成单金额等等，核心指标一旦有问题，立马报警。整个故障的排除路线：

  • 核心指标报警
  • 核心链路监控查看
  • 模块链路监控查看
  • 模块日志查看

这样，能够快速的定位出问题在哪儿，然后快速止损。

核心链路定期演练

基本上，演练包括四个部分：

  • 全链路压测演练：对核心链路的处理能力进行摸底
  • 一键降级演练：对第三方依赖故障的应对方案
  • 故障演练：对自己系统的容错性进行摸底，故障不一定非得抛异常，RT拉高也算
  • 扩容演练：扩容几台机子看看，防止云端，配置，白名单等各方面有遗漏

演练一定要做，即使看起来很简单的事也要做，因为开发往往会把事情想的很简单，并且，更重要的是，有的时候一个降级，一个故障，影响不是一个模块，而是对整个链路有影响，所以单纯从一个模块很难评估准确。