美团扫码付的前端可用性保障实践

本文根据美团高级工程师田泱在美团技术沙龙第31期《线下支付千万级订单服务——先后端架构实践》的演讲内容整理而成。

导读

2017年，美团金融前端遇到了不少通用性问题，特别是在保障前端可用性的过程当中，咱们团队也踩了很多“坑”。在梳理完这些问题之后，咱们还举办了第31期线下技术沙龙（点击查看PPT及视频资料），跟你们进行了分享和交流。

无论是在面试过程当中与候选人讨论，仍是在团队内和前端小伙伴进行讨论，都能发现不少同窗有一个共同点：对所作的工做缺少判断。如何评判工做交付的质量，如何评判产品与客户之间的触达率等等，这些问题其实比“埋头敲代码”重要不少。

今天抛砖引玉，分享一下咱们团队的思考，但愿能帮助更多的同窗对前端可用性的保障工做，有一个更全面的认识，后续还会分享不少美团前端相关的内容，你们能够关注咱们美团技术团队（meituantech）的公众号进行阅读，也欢迎你们跟咱们一块儿交流、讨论。

业务介绍

近几年，随着移动支付的普及，衍生出来聚合支付产品逐渐成为了你们进行移动支付第一选择。而对美团金融平台而言，支付这件事的意义和挑战就彻底不同，咱们把它定义为“搭载火箭的冰山式服务”。

之因此称之为“火箭”，是由于咱们在过去一年中，迅速成为公司最新一个日订单千万级的业务，整个业务是火箭式的发展速度。为何叫“冰山式的服务”？这是由于，经过咱们平台的一个二维码、一个页面就能够实现扫码支付，虽然操做比较简单，可是其背后却涉及不少商家系统、供应链系统，并且还须要不少平台系统的支撑，对技术和系统稳定性的要求很是之高。但对用户来讲，他们只是看到了“冰山一角”。

前期，咱们在作服务设计的时候，咱们觉得这个产品就是一个很简单的服务，按照传统前端的定义，咱们只是把前端的多个界面完成就能够了，后端服务以及不少第三方的接口咱们不须要花太多精力去关注。可是真正接触到项目后，咱们发现金融服务跟传统的服务彻底不同，甚至还须要作政府方面的一些工做。

好比金融最大的问题要合规，这就致使不少业务设计上，必须强制作不少功能节点，随着业务发展过程当中节点愈来愈多，这必然致使服务的可用性愈来愈差，可能实际状况比下面这张图更复杂：

当咱们把产品串起来以后，发现有不少端，每一个端同时又有不少的逻辑线互相交叉。这就形成了整个产品和前端服务在快速发展过程当中缺少设计性，同时也缺少可靠性、稳定性的保证。

不少同窗天真的认为，前端服务应该像奥尼尔同样稳定、强壮。可是实际状况，更可能像下了班后“葛优躺”的那种状态。今天咱们讲的目标就是：如何提升本身对所负责业务服务的信心？

之因此提这个目标，是由于有次在提休假时，老大问，能不能保证负责的服务不会出问题。相信不少同窗都会遇到这种状况，在出去度假或者看电影时，忽然接到老大的电话。对你们来讲，这种事情出现直接会影响到生活质量。因此保障服务的可用性，其实也是提升你们生活质量的重要因素。本文将会从四个方面进行分享：

• 第一，如何定义前端可用性。

• 第二，影响前端可用性的关键因素是什么。

• 第三，解决这些关键问题的处理方式，端到端监控与降级处理方案。

• 第四，总结一下标准的前端保障工做流程，但愿能对你们有所启发。

扫码付前端可用性定义

你们对于“系统可用性”这个概念都不陌生，其定义也比较简单，比较好理解。业界通用的计算公式是：

%availability=（Total Elapsed Time－Sum of Inoperative Times）/ Total Elapsed Time

也就是 平均无端障时间/（平均无端障时间+平均故障修复时间） 的百分比。

可是，前端和后端对这个可用性的认知并不同。由于对于后端服务的可用性来讲，执行环境较为可控，基本上不会存在中间的状态。而前端服务却大为不一样，前端会面临各式各样不肯定的用户使用场景。好比咱们使用iPhone访问没有问题，测试的同窗使用小米6也没有问题，可是老板用的华为P10就有问题了。

因此，前端服务的可用性没法像后端同样，有准确的数字指标，或者有精确的定义公式。这也是前端可用性提高面临的问题，由于咱们没法将最终的工做归结在一个衡量指标上。这里给你们留一个思考题：若是你负责的业务提升了万分之一的可用性，对整个业务可以产生多大大价值？

在美团金融，咱们团队粗略算过，若是业务的可用性提升万分之一，对业务部门的价值提高，至少在五位数以上。不积跬步，无以致千里。能够说在前端领域，任何一点微小的进步或者提高，都值得咱们付出百分之一百的努力。

影响可用性的关键因素

咱们把2017年前端发生的故障分为四种类型：

1. 客户端升级兼容性问题：在作前端开发时，不少组件依赖于容器。好比美团App升级，可是在升级时可能并不会通知全部的业务方，而升级不免会形成兼容性问题，这种状况会形成业务不可用，甚至带来其余相关的问题。这个问题没有办法彻底避免。

2. 代码优化、服务迁移后遗症：代码优化和改造，这点也不可避免。由于技术在更新代码的过程当中，很难兼顾到全部的细节问题，容易形成线上事故。

3. 外部依赖服务故障：这是比较典型的问题，对于前端来讲，最多见的就是接口服务或者依赖的基础服务组件出现故障，这些都会致使前端业务的不可用。

4. 研发流程执行不完全：其实代码优化层面的问题，能够经过流程或者标准化的动做进行规避。但实际过程当中，不少问题是由于投入的精力有限，或者着急上线等因素，致使研发执行的不完全或者不规范。

虽然看起来很复杂，可是归根结底能够归纳成两大类：第一类问题，就是咱们自身的问题，能够比喻成“我撞在猪身上了”；第二类问题就是别人的问题，能够理解成“猪撞我身上了”，咱们常常说这样一句话，“不怕神同样的对手，就怕猪同样的队友”，在前端开发问题上，这个道理同样适用。

内部节点可用性

第一点就是如何把本身的事情作好。相信不少同窗都看过网上不少文章，也听过线下不少大牛的分享，都很是有经验了。这里还有几个须要强调的地方：

1. 流程规范：不少的前端事故的主要缘由就是流程不规范，因此建议整个研发流程要用SOP来规避一些问题。好比上线的准入标准，服务必须达到必定的标准才能上线，在没有明确以前不许上线等等。

2. 方案合理：须要根据不一样的业务场景，来完成合理的方案设计，以前总结过一篇文章《前端常见开发模式及相关技术介绍》，这篇文章里讲到了三种不一样的业务场景，以及他们适合什么样的技术方案。若是你们不知道选择什么样的技术方案，那么咱们给的建议就是，尽可能选择简单。这样的目的是，当真正发生问题的时候，可以快速解决问题，不少前端开发同窗属于“热闹驱动式”选型，但在优化时却无从下手，这点并不可取。

3. 代码规范：通常而言，不多有前端代码写的不规范，可是能够在流程和制度层面进行额外的要求。不少时候，前端的语法要求不是特别严格，可是服务可用性有额外的要求，代码规范，能够帮助规避简单的问题。

除了上述三点以外，还有一点建议提高测试的效率，虽然整个行业都在作，可是也不是特别理想。之因此提倡单元化测试和自动化测试，主要是由于能够帮助咱们减小工做流程中重复的工做，将更多时间投入到业务开发层面。目前已经实现了Android容器上的自动化测试，同时咱们也在使用一些标准规避容器和外部依赖形成的故障。

外部链路的可用性

对技术同窗来讲，在作任何一个服务的时候，咱们常常喊的口号都是“简单可依赖”。可是在现实中，“简单可依赖”几乎是不存在的，没有任何一我的敢说本身负责的服务可以达到简单可依赖，这只是愿景而不是现实。

咱们使用外部服务的时，怎么保证它的可用性呢？对于前端开发者来讲，外部服务主要分为资源的可用性和接口的可用性，接下来咱们依次进行分析：

静态资源的可用性

对于前端工程师来讲，静态资源的不可用，主要分如下三种状况：

1. 资源加载问题：在一个临时的弱网环境下，文件加载失败，好比说电梯间或者一个封闭的过道。

2. 网络劫持问题：代码篡改的问题，静态资源在通过一些网络运营商时，被进行篡改或者注入广告。

3. 代码执行问题：多是兼容性问题，也多是代码语法或者逻辑出现问题。

针对第一个问题，由于静态资源主要分为CSS文件和JS文件，CSS文件与咱们的核心业务无依赖关系，因此加载失败的时候进行重试，保障页面样式可还原。

而JS文件涉及一些依赖的文件，因此咱们采用一个比较稳妥的方案：在判断核心的JS文件加载失败时，降级为一个MVP的版本，来保障交易的正常进行。以下图所示，在没有作静态资源降级以前，这个门店是正常的会员门店，会有促销的活动和信息。在CDN出现问题时，它会出现白屏问题。而在通过降级处理以后，咱们能够把整个页面回退成普通的门店，就不包含营销或者促销信息了。

整个方案有一个核心点，就是在CDN不可用时进行降级或者重试的过程当中，还会遇到不可用的状况，咱们最终要把资源回到源服务，至少保障在源服务上能够提供一个静态的页面提供给用户。这里也存在一个风险点，若是资源挂掉的话，源服务能不能承受CDN回源产生的额外流量？这个你们须要打一个问号，也须要特别注意。若是采用这样的方法，必定要评估好服务能不能承受这么大的压力。

第二个问题，你们都比较头疼。由于运营商是以省为单位运营的，因此在跨省的资源请求上会形成额外的流量，基于这个问题，每个省级运营商都会想办法节省流量，对于流量大的资源有可能会进行劫持甚至篡改。

首先是要预防，一个简单的方案，所有把域名所有升级为HTTPS，让劫持篡改失去了价值，这样能够下降一些风险。若是还支持HTTP访问，依然还会存在被劫持的风险。

其次，在发现劫持问题后，要快速帮助用户修复。美团运维有统一的120模式，这个模式会帮助咱们收集一些用户的环境信息，包括网络信息、手机版本号等等，从而快速定位这个问题，全力保障用户体验。

最后是监控，流量劫持都是以省级为单位的。因此在资源监控上，咱们要求至少要作到省级，最好可以作到市级，若是发现某一个市、某一个省静态资源发生问题，就第一时间启动修复。

还有一个隐性问题，就是在CDN回源的时，资源请求是否是应该使用HTTPS？在这个问题上，由于考虑到性能，回源请求会使用HTTP。因此广泛来说，CDN文件的请求会使用HTTPS，意味着咱们使用HTTPS来保证CDN不会被劫持，可是CDN回源会形成风险，至关于HTTPS预防这种方式，在理论上不能彻底解决这个问题。

最后，还有一个代码执行层面的问题。咱们会把报错信息，及时上报到平台上进行分析和处理，目前美团使用统一监控方案CAT，现已开源。

接口服务的可用性

不少前端开发同窗有一个很大的误区，接口不可用并非前端的问题。不少同窗会先定位这个问题属于本身仍是别人，若是是后端的问题，本身的心态就是“烧高香”。

但实际状况是，系统可用性须要前端和后端共同努力，若是后端不可用，前端怎么提高都是没有效果的，因此咱们须要改变本身的认识。若是发现接口有问题，第一时间帮助后端解决或者帮助定位，减小故障影响的时间，这也能提升前端的服务效率。美团对技术团队的要求是，提升监控和反馈的敏锐度。接下来就涉及到端到端监控和降级的方案。

端到端监控与降级

监控、报警的目的是为了快速的发现问题。若是定位到问题，第一时间不能靠人力进行解决，那么应该立刻进行故障自动处理或者降级。

可控的一些降级的方案在上文中已经提到。对于前端的监控，咱们使用了美团开源的CAT。CAT能够定义每一个页面覆盖资源的状况，能够细分到省、系统、网络、运营商等维度，从而帮更快的发现劫持和篡改的状况，而后及时进行修复。

故障演练的必要性

在实际工做中，咱们不少时候都缺乏执行力。好比上文提到的故障处理的方法和方案，在实际工做中有没有效果，或者能不能为业务作出价值和贡献，都须要要打个问号。固然，若是这些事情都没有实践，也至关于“纸上谈兵”。为了最终要达到目的，提升系统的可用性，就须要提升系统的检验标准，接下来就是要进行故障演练。

好比，咱们能够人为的让后端接口挂掉，看前端服务的表现；让静态资源挂掉，检查对服务有没有影响。如今美团的静态资源托管服务上运行着近千个项目，若是挂掉的话，会形成没法想象的后果。在这种状况下，托管CDN以后并不意味着会带来一些很好的效果，实际上它也会带来不少没法想象、没法预知的问题。因此为了系统的稳定性保障，最终落地点就是故障演练。

保障动做标准流程

最后总结几点，帮助你们作系统可用性的Review，主要分为事前、事中、过后：

1. 事前依赖流程与规范，包括代码规范、分支规范、测试规范、上线规范等。若是没有百分百的把握，不要上线。上线标准必定明确的，模棱两可的上线，大几率会出现问题。

2. 事中依赖监控与降级，能够设计一些监控和降级的方案。对于不可降级的要作好事前的预案，同时也依赖于演练的频率。演练的次数多了，就能够经过熟练的操做，下降服务受影响的时间，间接提升服务的可用性。

3. 过后依赖执行力，要作可落地的Case Study。不少同窗都是在过后复盘的时，说此次没有作好，代码写错了，没有太注意，这是别人的问题等等，草草就结束了。可是对下次事故来讲，并无预防的动做和可落地的执行方案。这就要求执行力，也看解决问题的决心。

总结

最后总结，影响前端服务可用性，其实就是两件事：

1. 流程规范的执行力

2. 工程化完整程度

不少前端的同窗并无关注监控和报警的状况，大部分精力仍是放在业务开发和功能覆盖上。可是，制定流程规范是工程师通用的能力，但愿你们在本身所负责的业务系统中，能够设定更多的流程制度，帮助保障前端服务的可用性和稳定性。

除此以外，咱们要多思考。好比认真思考一下，以前的工做存在什么潜在的问题。思考的频率如何，思考以后的结果和落地的执行力如何，这些都很是重要。

咱们发现不少前端同窗都把时间花在业务开发和功能覆盖上，对于本身的系统缺乏完整性的认知。因此建议你们能够先作一个通用的解决方案，覆盖从前端到后台，从研发、测试、上线的全流程。

目前，美团金融前端团队已经开始尝试构建一个符合公司前端标准研发体系的解决方案，还有一个线上协做研发平台，将集团的服务进行集成，同时把不少日常不注意的事情集中进行解决，减小重复性的工做，帮助你们把精力更多地投入在核心业务层面。

做者简介

田泱，2015年校招入职美团，前后参与过美团平台移动版多项垂直品类的前端研发工做，从0到1参与了智能支付应用层的前端建设工做，现负责美团金融服务平台前端基础服务研发团队。

招聘信息

 

若是你们对咱们所作的事情也有兴趣，想要和咱们一块儿共建大前端团队的话，欢迎发送简历至 tianyang02@meituan.com 。

 

也许你还想看

 

Android自动化页面测速在美团的实践

前端赶上Go: 静态资源增量更新的新实践

Android消息总线的演进之路：用LiveDataBus替代RxBus、EventBus