本文根据美团高级工程师田泱在美团技术沙龙第31期《线下支付千万级订单服务——前后端架构实践》的演讲内容整理而成。
导读
不管是在面试过程中与候选人讨论，还是在团队内和前端小伙伴进行讨论，都能发现很多同学有一个共同点：对所做的工作缺乏判断。如何评判工作交付的质量，如何评判产品与客户之间的触达率等等，这些问题其实比“埋头敲代码”重要很多。
业务介绍
近几年，随着移动支付的普及，衍生出来聚合支付产品逐渐成为了大家进行移动支付第一选择。而对美团金融平台而言，支付这件事的意义和挑战就完全不一样，我们把它定义为“搭载火箭的冰山式服务”。
之所以称之为“火箭”，是因为我们在过去一年中，迅速成为公司最新一个日订单千万级的业务，整个业务是火箭式的发展速度。为什么叫“冰山式的服务”？这是因为，通过我们平台的一个二维码、一个页面就可以实现扫码支付，虽然操作比较简单，但是其背后却涉及很多商家系统、供应链系统，而且还需要很多平台系统的支撑，对技术和系统稳定性的要求非常之高。但对用户来说，他们只是看到了“冰山一角”。
比如金融最大的问题要合规，这就导致很多业务设计上，必须强制做很多功能节点，随着业务发展过程中节点越来越多，这必然导致服务的可用性越来越差，可能实际情况比下面这张图更复杂：
当我们把产品串起来之后，发现有很多端，每个端同时又有很多的逻辑线互相交叉。这就造成了整个产品和前端服务在快速发展过程中缺乏设计性，同时也缺乏可靠性、稳定性的保证。
很多同学天真的认为，前端服务应该像奥尼尔一样稳定、强壮。但是实际情况，更可能像下了班后“葛优躺”的那种状态。今天我们讲的目标就是：如何提高自己对所负责业务服务的信心？
第一，如何定义前端可用性。
第二，影响前端可用性的关键因素是什么。
第三，解决这些关键问题的处理方式，端到端监控与降级处理方案。
第四，总结一下标准的前端保障工作流程，希望能对大家有所启发。
扫码付前端可用性定义
大家对于“系统可用性”这个概念都不陌生，其定义也比较简单，比较好理解。业界通用的计算公式是：
%availability=（TotalElapsedTime－SumofInoperativeTimes）/TotalElapsedTime
但是，前端和后端对这个可用性的认知并不一样。因为对于后端服务的可用性来说，执行环境较为可控，基本上不会存在中间的状态。而前端服务却大为不同，前端会面临各式各样不确定的用户使用场景。比如我们使用iPhone访问没有问题，测试的同学使用小米6也没有问题，但是老板用的华为P10就有问题了。
所以，前端服务的可用性无法像后端一样，有准确的数字指标，或者有精确的定义公式。这也是前端可用性提升面临的问题，因为我们无法将最终的工作归结在一个衡量指标上。这里给大家留一个思考题：如果你负责的业务提高了万分之一的可用性，对整个业务能够产生多大大价值？
在美团金融，我们团队粗略算过，如果业务的可用性提高万分之一，对业务部门的价值提升，至少在五位数以上。不积跬步，无以至千里。可以说在前端领域，任何一点微小的进步或者提升，都值得我们付出百分之一百的努力。
影响可用性的关键因素
我们把2017年前端发生的故障分为四种类型：
代码优化、服务迁移后遗症：代码优化和改造，这点也不可避免。因为技术在更新代码的过程中，很难兼顾到所有的细节问题，容易造成线上事故。
外部依赖服务故障：这是比较典型的问题，对于前端来说，最常见的就是接口服务或者依赖的基础服务组件出现故障，这些都会导致前端业务的不可用。
研发流程执行不彻底：其实代码优化层面的问题，可以通过流程或者标准化的动作进行规避。但实际过程中，很多问题是因为投入的精力有限，或者着急上线等因素，导致研发执行的不彻底或者不规范。
虽然看起来很复杂，但是归根结底可以概括成两大类：第一类问题，就是我们自身的问题，可以比喻成“我撞在猪身上了”；第二类问题就是别人的问题，可以理解成“猪撞我身上了”，我们经常说这样一句话，“不怕神一样的对手，就怕猪一样的队友”，在前端开发问题上，这个道理一样适用。
内部节点可用性
流程规范：很多的前端事故的主要原因就是流程不规范，所以建议整个研发流程要用SOP来规避一些问题。比如上线的准入标准，服务必须达到一定的标准才能上线，在没有明确之前不准上线等等。
代码规范：一般而言，很少有前端代码写的不规范，但是可以在流程和制度层面进行额外的要求。很多时候，前端的语法要求不是特别严格，但是服务可用性有额外的要求，代码规范，可以帮助规避简单的问题。
外部链路的可用性
对技术同学来说，在做任何一个服务的时候，我们经常喊的口号都是“简单可依赖”。但是在现实中，“简单可依赖”几乎是不存在的，没有任何一个人敢说自己负责的服务能够达到简单可依赖，这只是愿景而不是现实。
我们使用外部服务的时，怎么保证它的可用性呢？对于前端开发者来说，外部服务主要分为资源的可用性和接口的可用性，接下来我们依次进行分析：
静态资源的可用性
对于前端工程师来说，静态资源的不可用，主要分以下三种情况：
资源加载问题：在一个临时的弱网环境下，文件加载失败，比如说电梯间或者一个封闭的过道。
代码执行问题：可能是兼容性问题，也可能是代码语法或者逻辑出现问题。
针对第一个问题，因为静态资源主要分为CSS文件和JS文件，CSS文件与我们的核心业务无依赖关系，所以加载失败的时候进行重试，保障页面样式可还原。
而JS文件涉及一些依赖的文件，所以我们采用一个比较稳妥的方案：在判断核心的JS文件加载失败时，降级为一个MVP的版本，来保障交易的正常进行。如下图所示，在没有做静态资源降级之前，这个门店是正常的会员门店，会有促销的活动和信息。在CDN出现问题时，它会出现白屏问题。而在经过降级处理之后，我们可以把整个页面回退成普通的门店，就不包含营销或者促销信息了。
整个方案有一个核心点，就是在CDN不可用时进行降级或者重试的过程中，还会遇到不可用的情况，我们最终要把资源回到源服务，至少保障在源服务上可以提供一个静态的页面提供给用户。这里也存在一个风险点，如果资源挂掉的话，源服务能不能承受CDN回源产生的额外流量？这个大家需要打一个问号，也需要特别注意。如果采用这样的方法，一定要评估好服务能不能承受这么大的压力。
第二个问题，大家都比较头疼。因为运营商是以省为单位运营的，所以在跨省的资源请求上会造成额外的流量，基于这个问题，每一个省级运营商都会想办法节省流量，对于流量大的资源有可能会进行劫持甚至篡改。
首先是要预防，一个简单的方案，全部把域名全部升级为HTTPS，让劫持篡改失去了价值，这样可以降低一些风险。如果还支持HTTP访问，依然还会存在被劫持的风险。
其次，在发现劫持问题后，要快速帮助用户修复。美团运维有统一的120模式，这个模式会帮助我们收集一些用户的环境信息，包括网络信息、手机版本号等等，从而快速定位这个问题，全力保障用户体验。
还有一个隐性问题，就是在CDN回源的时，资源请求是不是应该使用HTTPS？在这个问题上，因为考虑到性能，回源请求会使用HTTP。所以普遍来讲，CDN文件的请求会使用HTTPS，意味着我们使用HTTPS来保证CDN不会被劫持，但是CDN回源会造成风险，相当于HTTPS预防这种方式，在理论上不能完全解决这个问题。
接口服务的可用性
很多前端开发同学有一个很大的误区，接口不可用并不是前端的问题。很多同学会先定位这个问题属于自己还是别人，如果是后端的问题，自己的心态就是“烧高香”。
端到端监控与降级
故障演练的必要性
在实际工作中，我们很多时候都缺少执行力。比如上文提到的故障处理的方法和方案，在实际工作中有没有效果，或者能不能为业务做出价值和贡献，都需要要打个问号。当然，如果这些事情都没有实践，也相当于“纸上谈兵”。为了最终要达到目的，提高系统的可用性，就需要提高系统的检验标准，接下来就是要进行故障演练。
比如，我们可以人为的让后端接口挂掉，看前端服务的表现；让静态资源挂掉，检查对服务有没有影响。现在美团的静态资源托管服务上运行着近千个项目，如果挂掉的话，会造成无法想象的后果。在这种情况下，托管CDN之后并不意味着会带来一些很好的效果，实际上它也会带来很多无法想象、无法预知的问题。所以为了系统的稳定性保障，最终落地点就是故障演练。
保障动作标准流程
最后总结几点，帮助大家做系统可用性的Review，主要分为事前、事中、事后：
事前依赖流程与规范，包括代码规范、分支规范、测试规范、上线规范等。如果没有百分百的把握，不要上线。上线标准一定明确的，模棱两可的上线，大概率会出现问题。
事后依赖执行力，要做可落地的CaseStudy。很多同学都是在事后复盘的时，说这次没有做好，代码写错了，没有太注意，这是别人的问题等等，草草就结束了。但是对下次事故来说，并没有预防的动作和可落地的执行方案。这就要求执行力，也看解决问题的决心。
总结
最后总结，影响前端服务可用性，其实就是两件事：
流程规范的执行力
工程化完整程度
除此之外，我们要多思考。比如认真思考一下，之前的工作存在什么潜在的问题。思考的频率如何，思考之后的结果和落地的执行力如何，这些都非常重要。
目前，美团金融前端团队已经开始尝试构建一个符合公司前端标准研发体系的解决方案，还有一个线上协作研发平台，将集团的服务进行集成，同时把很多平常不注意的事情集中进行解决，减少重复性的工作，帮助大家把精力更多地投入在核心业务层面。
作者简介
田泱，2015年校招入职美团，先后参与过美团平台移动版多项垂直品类的前端研发工作，从0到1参与了智能支付应用层的前端建设工作，现负责美团金融服务平台前端基础服务研发团队。
招聘信息
如果大家对我们所做的事情也有兴趣，想要和我们一起共建大前端团队的话，欢迎发送简历至tianyang02@meituan.com。