当前位置: 首页 > 科技观察

日均2000万单的背后,如何保证系统的高可用?

时间:2023-03-18 16:27:37 科技观察

美团外卖始于2013年11月,经过几年的快速发展,不断刷新记录。2018年5月19日,峰值日订单量突破2000万单,成为全球最大的外卖平台。业务的快速发展对系统的稳定性提出了更高的要求。如何为在线用户提供高度稳定的服务体验,保证业务全链路、系统高可用运行,不仅需要后端服务支持,还需要端到端提供全面的技术支持。与服务器端相比,客户端的运行环境差异很大,不可控因素较多,处理突发事件的能力较差。因此,为客户端搭建高可用的构建系统,保证稳定高可??用的服务,不仅是对工程师的技术挑战,也是外卖平台的核心竞争力之一。一个高可用构建系统的思路一个设计良好的大型客户端系统往往是由一系列独立的团队开发的,每个团队应该有明确的职责分工。在业务模块之间实施“松耦合”开发模式,让业务模块具有隔离变化的能力,是能够同时提高开发灵活性和系统健壮性的有效手段。以下是美团外卖的整体业务架构。以商品交易环节(门店召回、商品陈列、交易)为核心方向构建。部分根据业务特点和团队分工划分为多个独立的运维单元。独立运维单元的简单性是可靠性的前提,使我们能够持续专注于功能迭代,持续完成相关工程开发任务。我们把问题按照生命周期分为三个阶段:发现、定位、解决。围绕这三个阶段的持续构建,构成了美团外卖高可用构建体系的核心。美团外卖质量保障体系全景图这是美团外卖客户端整体质量体系全景图。总体思路:监控告警、日志系统、容灾。通过业务稳定性、基础能力稳定性、性能稳定性三类指标数据的采集和上报,提高了衡量客户端系统质量的标准。通过建立基线并应用特定的业务模型对这一系列指标进行监控和告警,使客户端具备分钟级感知核心链路稳定性的能力。通过构建日志系统,使整个系统具备提取关键线索的能力,多维度快速定位问题。一旦定位到问题,我们可以通过美团外卖在线运维规范进行容灾操作:降级、切换通道或限流,从而保证整体核心链路的稳定性。后台监控告警监控系统处于整个服务可靠性层次模型的最底层,是运行和维护可靠稳定系统的重要组成部分。为了保证系统的全链路业务和高可用运行,需要在用户感知到问题之前发现系统的异常。没有监控系统,我们没有能力区分客户端是否正常提供服务。按照监控的领域方向,可以分为系统监控和业务监控:系统监控主要用于端到端成功率、服务响应时间、网络流量、硬件性能等相关基础能力的监控。系统监控侧重于非业务入侵和定制化的系统级监控,更多的是业务应用的底层,多在单系统层面。业务监控侧重于分析一定时间间隔内的业务运行情况。业务监控系统建立在系统监控之上,可根据系统监控数据指标进行计算,并基于具体的业务干预,实现多系统间的数据联合与分析,提供实时的业务监控与监控。对应的商业模式。警报。根据业务监控的时效性,又可以细分为实时业务监控和线下业务监控。实时业务监控,通过实时数据采集和分析,帮助快速发现和定位线上问题,提供告警机制和干预响应(人工或系统)方式,避免系统故障。线下业务监控,对一定时间段内收集到的数据进行数据挖掘、聚合、分析,推断系统业务可能存在的问题,有助于对业务的监控进行重新优化或改进。美团外卖的业务监控大部分是实时业务监控。借助美团统一的系统监控建设基础,美团外卖其他部门对部分监控基础设施进行改造、共建、整合、复用,打通形成闭环(监控、日志,和恢复)。我们构建了专门符合外卖业务流程的实时业务监控,以及线下业务监控,主要通过用户行为的统计和业务数据的挖掘分析,帮助产品设计和运营策略行为。目前这部分监控主要由美团外卖数据组提供。值得注意的是,单纯的信息汇总展示,不需要或不能立即干预的业务监控,都可以称为业务分析。比如特定区域的活动消费、区域订单数、特定路径的转化率、曝光点击率等。除非这些数据用于判断系统的实时状态和健康状况,帮助生成系统维护行为,否则将这部分监控离线处理比较合适。我们将客户端稳定性指标分为三个维度:业务稳定性指标基础能力稳定性指标性能稳定性指标对于不同的指标,我们采用不同的采集方案进行提取上报,归纳到不同的系统中;在指标之后,我们可以根据特定的业务模型制定基线并制定警报策略。美团外卖客户端拥有40多项衡量质量指标,其中25项指标支持分钟级告警。报警通道根据紧急程度支持邮件、IM、SMS三种通道。因此,我们团队有能力及时发现影响核心链路稳定性的关键指标变化。一个完整的监控报警系统是非常复杂的,因此在设计上必须追求简单化。以下是本书中提到的告警设置原则《Site Reliability Engineering:How Google Runs Production Systems》:最能反映真实故障的规则应该是可以预见的,非常可靠的,并且尽可能简单。不经常使用的数据采集、汇总、告警配置要定期清除(有些SRE团队的标准是一季度不用就删掉)没有暴露在任何监控后台和告警中的采集数据指标定期通过监控报警系统清除规则。道路稳定性问题有20多个:包括爬虫、交通、运营商403问题、性能问题等。目前,所有问题都已全面返工。日志系统监控系统的一个重要特征是产生紧急警报。一旦发生故障,需要有人排查告警,判断是否真的有故障,是否需要采取具体的措施来缓解故障,直到找到故障的根本原因。简单定位和深度调试的过程必须非常简单,并且团队中的任何人都必须能够理解。日志系统在简化这个过程中起着决定性的作用。美团外卖的日志系统一般分为三类:全日志系统,主要负责采集网络可用性、埋点可用性等整体指标。我们可以用它来了解系统的整体行情,了解整体的波动,判断问题的范围。个人日志系统用于提取个人用户的关键信息,从而有针对性地分析具体的客户投诉。异常日志系统主要收集异常指标,如大图问题、分享失败、定位失败等。通过它,我们可以快速获取异常上下文信息,分析和解决问题。这三类日志构成了一个完整的客户端日志系统。日志的一个典型使用场景是处理单点客户投诉,解决系统中的潜在隐患。个人日志系统,简化工程师提取关键线索的步骤,提高定位分析问题的效率。在这一领域,美团外卖使用大众点评平台开发的Logan服务。Logan作为美团移动端底层的基础日志库,接入了集团的众多日志系统,比如端到端日志、用户行为日志、代码级日志、崩溃日志等。而这些日志全部存储在本地,并有多重加密机制和严格的权限审核机制。只有在处理用户投诉时才会对数据进行检索和分析,以确保用户隐私和安全。通过设计和实现美团外卖核心链接日志方案,打通了用户交易过程中订单、用户中心、Crash平台、Push后台等各个系统之间的底层数据同步。通过标准问题分析手册的输出,可以规范对常见个别问题的分析处理;通过日志抓取SOP的制定和定期演练,大大提高了线上溯源能力,大部分日常客户投诉的原因可以在30分钟内定位。在这个过程中,所有个人曝光的影响核心链接稳定性的问题也都得到了改善/修复。故障排除是操作大型系统的一项关键技能。使用系统的工具和方法,而不是仅仅依靠经验甚至运气,该技能是自学和内部传授的。容灾备份针对不同级别的服务,应该采用不同的手段来有效止损。非核心依赖通过降级为用户提供可扩展的服务。针对核心依赖,采用多通道备份容灾,保证交易路径链路的高可用;异常流量多维限流,最大化业务可用性,给用户良好体验。归纳为三点,即:非核心依赖降级、核心依赖备份、过载保护和限流。下面,我们就这三个方面分别进行探讨。降级这里选取美团外卖客户端的整体体系结构关系图来介绍一下非核心依赖降级构建的概况。图中红色部分为核心关键节点,即外卖业务的核心环节:定位、商家召回、商品展示、下单;蓝色部分是核心链路所依赖的关键服务;黄色部分是可以降级的服务。通过梳理依赖,改造前后端通信协议,我们实现了客户端非核心依赖的降级。对于后端服务,通过各级缓存和屏蔽隔离策略,可以实现业务模块内部和服务之间的降级。这就构成了美团外卖客户端的整体降级系统。右图为美团外卖客户端业务/技术降级切换流程图。通过推拉结合和缓存更新策略,我们可以在分钟级同步降级配置,快速止损。目前,美团外卖客户端有超过20个业务/能力支持降级。通过有效降级,我们避免了1起S2事故和多起S3、S4事故。此外,降级交换机整体解决方案产生SDK号角,推广至集团酒旅、金融等其他核心业务应用。备份核心依赖于备份建设。这里重点介绍美团外卖的多网渠道。网络通道作为客户端的核心依赖,是整个全链路体系中最不可控的部分,问题时常出现。网络劫持、运营商失误,甚至物理切断光纤等大大小小的故障都严重影响了核心链路的稳定性。因此,要管理网络问题,必须建立可靠的多通道备份。这是美团外卖多网通道备份示意图。美团外卖客户端有四个网络通道:Shark、HTTP、HTTPS、HTTPDNS:整体网络以Shark长期连接通道为主通道,其他三个通道作为备用通道。完整的切换流程,可在网络指标急剧下降时,实现分钟级逐城网络通道切换。通过制定故障应急SOP和持续演练,提高了解决问题的能力和速度,有效应对了各种网络异常。我们的网络渠道切换思路也输出到集团其他部门,有效支撑了业务发展。限速服务过载是另一种典型的事故类型。大多数情况下,原因是少数调用者调用的少数接口性能不佳,导致相应服务的性能下降。如果调用方缺乏有效的降级容错,可以降低某些正常情况下的错误率,比如请求失败后重试,这会进一步恶化服务的性能,甚至影响正常的服务调用。美团外卖业务的订单量在高峰期达到了非常高的规模,业务系统也异常复杂。根据以往经验,在业务高峰期,一旦异常流量激增,导致服务器宕机,损失将不可估量。因此,美团外卖前后端联合开发了一套“流量控制系统”,实现对流量的实时控制。这样既可以保证日常业务系统的稳定运行,又可以在业务系统出现问题时提供优雅的降级解决方案,最大程度保证业务的可用性,给用户良好的体验,同时将损失降到最低。在整个系统中,后端服务负责识别标记类别,并通过统一协议将识别的类别告知前端。在前端,通过多级流控校验,对不同的流量进行不同的处理:弹出验证码,或排队等候,或直接处理,或直接丢弃。面对不同场景,系统支持多级流控方案,可有效拦截系统过载流量,防止系统雪崩。此外,整个系统具备子接口流控监控能力,可以监控流控效果,及时发现系统异常。整个方案经受住了多次异常增长故障的考验。发布随着外卖业务的发展,美团外卖的用户量和订单量已经达到了相当的水平,直接将版本/功能完全发布到线上影响较大,风险较高。版本灰度和功能灰度是一种可以平滑过渡的发布方式:即线上进行A/B实验,让部分用户继续使用产品(功能)A,而其他用户开始使用产品(功能)B。如果指标稳定正常,结果符合预期,扩大范围,将所有用户迁移到B,否则回滚。灰度发布可以保证系统的稳定性。可以在初期测试阶段发现问题,修复问题,调整策略,确保影响范围不扩散。美团外卖客户端版本灰度和功能灰度比较完善:版本灰度,iOS采用苹果官方提供的分阶段发布方式,安卓采用美团自研EVA包管理后台发布。两种类型的发布都支持增量分发。功能灰度,功能发布开关配置系统根据用户特征维度(如城市、用户ID)进行发布,整个配置系统有测试和上线两个不同的环境,有固定的上线窗口保证上线的标准化。相应的,相应的监控基础设施也支持按用户特征维度(如城市、用户ID)进行监控,避免了那些无法反映到整体市场的灰度异常。另外,无论是版本灰度还是功能灰度,我们都有相应的最小灰度周期和回滚机制,保证整个灰度发布过程可控,将问题的影响降到最低。在线运维如何应对故障是整个质保体系中最关键的环节。没有人天生就有完美的处理紧急情况的能力。面对问题,正确处理需要不断练习。美团外卖客户端团队围绕问题的发现、定位、解决(预防)的生命周期,建立了一套完整的处理流程和规范,应对各种影响链路稳定性的在线问题。整体思路:建立规范,事前建设,事后有效应对,事后总结,如下图:在不同的阶段,以不同的方式解决不同的问题,提前确定一个完整的事故过程管理策略,确保顺利实施,频繁演练,问题平均恢复时间大大减少,可以保证美团外卖核心链路的高稳定性。未来展望目前,美团外卖业务仍处于高速增长期。随着业务的发展,业务背后的技术体系也越来越复杂。在搭建美团外卖客户端高可用系统的过程中,我们希望借助智能运维系统,帮助工程师快速准确地识别核心链路各子系统的异常,找到问题根源.并自动执行相应的异常解决方案,进一步缩短服务恢复时间,从而避免或减少线上事故的影响。诚然,业界对自动化运维的探索很多,但大多集中在后台服务领域,前端方向的成果较少。我们的外卖技术团队目前正在同步探索中,处于基础建设阶段。欢迎更多业内同仁与我们共同探讨、学习。作者:陈航、付强、徐红简介:陈航,美团资深技术专家。2015年加入美团,目前负责美团外卖iOS团队。对移动终端架构演进、监控告警备份容灾、移动终端在线运维有深刻理解。付强,美团点评高级工程师。2015年加入美团,是外卖iOS的早期开发者之一。目前作为美团外卖iOS基础设施团队负责人,负责外卖基础设施和广告运营相关业务。徐宏,美团点评高级工程师。2016年加入美团,目前是外卖iOS团队的主要开发人员,负责移动端APM性能监控,高可用基础架构支持相关推广工作。