一、引言
闲鱼作为C2C电商交易平台,消息系统是导购链路上关键的一环。用户依赖聊天建立买家与卖家的信任,进一步获取商品信息。闲鱼消息的稳定性直接影响到闲鱼用户体验,成交效率。为强化闲鱼消息系统的稳定性,保障用户体验。闲鱼消息团队在2022年8月份对消息系统稳定性进行了体系化治理。本文将从闲鱼消息团队视角出发,讲讲我们怎么做稳定性治理。
二、问题定义
我们的目标很明确:减少线上问题。我们通过分析系统现状、回顾历史问题,将问题分为两类,一类是高风险高概率,需要重点突击解决的主要问题,包括变更风险、弱依赖风险。另一类是存在潜在风险,但治理成本高,需要长期投入建设的深水区问题,包括强依赖风险,系统设计。我们针对问题,制定了对应的治理措施。包括:灰度、监控告警、自动化回归、强弱依赖治理、演练、重构等。因篇幅有限,本文将聚焦于主要问题的治理措施。
三、问题治理
安全生产环境是由集团层面为保障线上稳定性的灰度流量生产环境。通过接入层网关的流量控制为环境提供1%线上流量+100%办公网流量,还原线上环境为系统验证提供场所。
我们以安全生产环境为基础展开一系列治理:
安全生产流量闭环
常规场景下,安全生产流量能保证从入口到后续全链路都在安全生产环境闭环。但在闲鱼消息场景里,强依赖MQ做流量的负载均衡,而安全生产流量经过MQ之后会被均匀打散,逃逸到线上,失去灰度观察能力。针对该问题,我们通过spring的Conditional条件注入能力,将线上和安全生产的MQ bean隔离,从而将线上和安全生产MQ topic隔离,使流量能够在安全生产环境完整闭环。
安全生产独立的监控告警,监控大盘
安全生产环境和生产环境的监控基线不同,告警阈值不同,为了能及时发现灰度问题,我们以安全生产环境的水位单独配置了监控告警。覆盖调用量、RT、错误量、消息延迟等多个指标维度,覆盖发送消息、创建会话等所有核心链路场景。我们将安全生产监控聚合成监控大盘,实时和线上监控水位做对比,不仅能发现变更引起的问题,还能发现变更对性能指标的影响。
安全生产独立的离线监控报表
监控告警是实时的异常指标监控,而离线报表是更长时间窗口的指标聚合。我们针对安全生产环境配置独立的离线监控报表,它不仅能发现细微波动的异常指标,也能发现变更对业务指标(例如消息到达率、点击率)的影响。
安全生产的自动化回归
自动化回归保障系统的底线,核心场景回归能避免引起严重的问题。我们将自动化回归与CICD集成,当发布到安全生产环境时自动执行自动化回归。
发布规范
在完善安全生产建设后,如果没有规范去标准化流程,建立行为准则同样达不到保障稳定性的目标。我们结合消息本身的业务特点,约定了消息团队内部的发布规范:发布必须在安全生产停留一晚,第二天灰度放量。确保:1. 覆盖时间相关的代码逻辑。2. 足够久的灰度观测。3. 产出t+1的离线监控报表
监控告警的生命周期可以分为监控数据准备、监控配置、监控验证、告警配置、告警验证五个环节。
监控数据准备环节我们有完善的基础设施。基于这个基础,我们对监控告警进行覆盖率、及时性、有效性治理:
监控覆盖率治理
治理的第一个目标是要确保监控覆盖全,不遗漏。我们分为三步确保覆盖完整:1. 梳理出系统的核心场景链路,链路上的核心观测指标,查缺补漏监控告警。2. 通用的监控告警作为兜底,覆盖资源水位、接口调用、中间件性能等基础指标。3. 最后,通过监控告警离线报表整体性review监控告警覆盖率。
告警及时性/有效性治理
治理的第二个目标是能及时发现问题、有效发现问题。告警的及时性与有效性是互斥的关系,为达到告警及时性与有效性的最佳平衡,我们按照从严到松的方式逐步调整告警条件。同时为了持续维持告警及时性有效性,我们建立监控告警离线报表,定期review告警记录,对告警调优。
提供长效机制持续保鲜监控告警
监控告警治理需要持续投入,持续保鲜。我们搭建了监控告警离线报表,它包含所有的监控告警配置,告警历史流水,提供告警历史的聚合试图。为我们覆盖率治理、有效性治理提供全局视图,支撑我们定期对监控告警调优。
自动化回归的目标是保障底线,确保核心链路场景的稳定性。
端到端级别的自动化回归
端到端级别的自动化回归能从真实使用角度去验证稳定性。我们设计端到端的自动化回归用例,覆盖软件从安装、使用、卸载的完整生命周期,覆盖消息核心场景链路。我们将自动化回归与CICD集成,每天定时自动化回归,在发布流程做自动化回归卡口。
接口级别的流量回放
凤凰回放工具是基于JVMTI实现的流量回放测试工具。我们使用凤凰回放工具录制RPC流量,回放流量,diff结果,验证接口级别的稳定性。
依赖治理的目标是强弱依赖关系合理,并且弱依赖具备降级快恢能力。我们进行了以下治理:
依赖梳理:代码级别review依赖的合理性,review是否具备降级快恢能力
依赖改造:对不合理的强依赖降级为弱依赖,完善弱依赖的监控告警,降级快恢预案
依赖演练:依赖演练是对依赖治理的验收环节。目的是验证强弱依赖关系和预期一致,避免出现“我以为”但“实际是”的问题,同时验证弱依赖的问题发现能力,降级快恢能力。
四、总结思考
写这篇文章的时候,距离稳定性治理已经过去6个月。经过半年的实践,能体会到以上治理确实能有效解决问题。从主观来说,做线上变更时,灰度的停留规范+独立的监控告警让人心里有底。从过程来看,灰度环境的建设也确实帮我们规避了多起线上问题。从结果来看,这半年的线上问题趋近于0。稳定性治理我们经历了从一开始的无从下手,到后来逐渐找到思路,再逐渐找到确定性的路径,明确的解决了一些问题。对稳定性也有了几点思考:
1. 问题是消灭不完的,不要焦虑治理完还会出现问题,尽力减少问题;
2. 稳定性治理需要结合实际情况找到重点,网上大而全的治理经验不一定适用;
3. 稳定性治理需要持续投入,持续保鲜。例如告警问题跟进、告警降噪;
4. 最重要的还是要时刻绷紧一根弦,敬畏每次线上变更。
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721