【交易架构day7】美团预订交易的演进之路——美团方法论落地

2020-04-01 15:16 277人阅读评论(0)

导读：新美大以团购作为切入点，为了更好的连接用户与商户，从2012年开始在酒店、外卖、电影等垂直领域深耕细作。到2016年，美团酒店交易额单日破亿，间夜量行业第一。

在酒店业务的转型和高速发展过程中，不同的阶段对系统结构也提出来不同的要求，本次分享会通过对几个阶段的系统整体情况的分析、演化，和大家一起整理业务的不同阶段给系统带来的挑战和机遇，希望可以为处于文中某个阶段的同学提供一些思路上的参考。

1､案例背景

美团酒店从2012年开始，以团购为基础，着手酒店业务的精细化发展；
2012年~2016年期间，探索并完成了团购业务到预订业务的升级，预订业务占比90%以上；
期间酒店业务快速发展，2016年消费额单日破1.5亿，单日入住间夜量突破80W，行业第一；
在业务转型升级、快速发展的整个过程中，不同的阶段对系统架构的设计带来了不同的挑战。

2､案例解读

我们将从开始酒店精耕细作到现阶段，把酒店系统的整个发展过程分为4个大阶段：决策、落地、支撑、优化，如图1。

决策阶段是指我们需要去思考、确定以后酒店系统应该如何去发展、才能够更好的去支撑、推动业务的发展。
落地阶段是指在做好决定之后，需要将决定的内容逐步落地、实现。
支撑阶段是指在系统需要能够很好的支撑业务迅猛的发展。
优化阶段是指在系统的支撑、发展过程，我们需要通过不断的优化业务、系统，以更好的推动业务发展。

● 2.1 决策阶段

首先我们进入决策阶段。在当时的阶段中，伴随着团购业务的发展，已经形成一套完整的团购系统体系，包含全套的供给、数据、售卖流程，包含toB、toE、toC的全套功能，并搭配着相关的基础设施，如DB、Cache、RPC等，而这一套系统同时支撑着餐饮、电影、酒店、旅游等20多个大品类。如图3所示。

酒店业务的精细化发展需要我们在供给、产品、促销、交易等环节进行进一步的扩充、升级。如图4。

摆在面前的是一系列非常常见的问题：老系统支撑难、新系统成本高、业务可行性不确认。

老系统支撑难：原有团购系统是全品类系统架构，通用性强，修改、订制较难，系统历史“包袱”较重；
新系统成本高：如果新建一套系统链路长，涉及面广，改动量大，周期长；
业务可行性不确认：无论采取何种方式来看，成本都不会低，而此时我们对于这个业务方向是否是真正满足用户需求还存在一定的不确认性。

这是非常常见的场景，也是非常难做的决定。对于很难决定的事情，我们需要收集更多的信息：

首先，低成本验证业务可行性。

采取和现有流程较为松耦合的方式实现简易版业务（图5），以保证可以确认用户对此类需求的使用情况，同时尽量保持低成本。经验证，业务方向OK。

第二，典型需求验证“支撑难”。

通过典型的“价格计划”需求（图6），验证团购系统进行定制化开发的成本。经过实际验证，一个典型的需求持续2个月左右，影响方非常多，而以后类似需求还会有很多。所以，成本基本不可接受。

第三，MVP需求验证“成本高”。

通过酒店集团接入打造酒店系统MVP版本（图7），以第三方为供给来源，PC版做出口，实现最简版逻辑，以确认新建系统范围、成本。经过实际验证，周期在2个月左右，成本不小，但基本可控。

经过三方面的验证得出结论：业务方向OK、复用成本过高，新建成本基本可控。依此得出方案：构建酒店系统（造个轮子），如图8。

● 2.2 落地阶段

方向确定后，我们进入落地阶段。落地过程中主要关注三个方面：

哪些轮子需要自己造（自建 or 复用）：全链路中涉及非常多的系统，全部重建成本高，且有部分是可以重用的，如何取舍。
轮子造多大（分与合）：服务化粒度问题，业务初期需求变动频繁，小服务协调成本高，大服务稳定性、隔离性差。
车不停，怎么把轮子搞上去（保证业务发展）：整个服务构建需要周期，期间会对业务造成较大影响，如何降低影响，保证业务发展。

应对：“自建” or “复用”→掐头去尾，保核心竞争力

构建酒店系统并不意味着所有的轮子都要重造一遍，过程中遵循几个原则（如图10）：

掐头：基础设施如缓存、RPC框架等复用，保证基础设施稳定性；基础服务如用户、支付、风控等复用，保证以后不同业务之间的协作。
去尾：对外的统一出口如主搜、推荐、订单等复用，保证对下游用户体验的统一性、简单性。
保核心竞争力：中间业务逻辑部分，关注和业务核心竞争力最核心相关部分。非核心部分“随缘”，多业务核心部分“要结果”，只酒店核心部分“自己搞”。

应对：“分”与“合”→对内分，对外合

对于分与合的问题，服务化是趋势，但我们要尽量降低业务前期频繁的变动和大需求扎堆的情况对系统带来的影响，采取对内分、对外合的方式（如图11）：

对内分：对内保留业务逻辑扩展性，如产品内部服务会根据后续业务发展方向拆分销售规则、价格、库存等服务，保证可扩展性。
对外合：对外保证服务逻辑完整性：如产品服务对外提供的接口，可以完成对产品的完整操作和信息获取，以避免服务扩散太细，带来的高协作成本。

应对：保证业务发展→分阶段落地，区分优先级，保证每阶段收益

系统的整个构建涉及面较广，如果一次性完成周期较长，同时也不利于快速验证和优化，所以将整个项目进行分步，分步的要求有两个：

优先解决业务痛点；
必须有阶段性产出。

首先，识别项目的核心目标：高效的供给→良好的用户体验。

然后，确认核心目标的优先级：

用户体验依赖于高效供给产生的丰富、高质量产品，并且供给系统建设完成之后需要一定的积累周期；
所以：优先解决供给问题，然后完善用户体验。
最后，明确每个阶段的业务收益：
供给阶段：效率提升
用户体验阶段：退款率

步骤一：解决效率问题

通过对于供给系统、产品系统的建设，使供给效率达到300%的提升，同时在这个过程中，完成了酒店系统的前半部分建设：供给到产品（如图12）。

步骤二：解决体验问题

通过对于预付系统的建设，进行业务升级，用户退款率降低60%，同时在这个过程中，完成了酒店系统的后部分建设：售卖到交易（如图13）。

步骤三：系统融合

将团购系统中的酒店业务和酒店系统进行融合，保证各个业务形态共享效率、体验的红利，同时统一酒店的所有系统。（如图14）

经过以上的几步，完成了酒店系统的初步建设。

图15中，灰色部分为去尾的基础组件部分，桃红色部分是去尾的基础服务部分，绿色部分是未掐头的统一出口部分，而其余的大片深青色部分，则是酒店业务核心相关的系统部分。

● 2.3 支撑阶段：支撑业务需求、业务量的快速增长

酒店系统建设完成后，就需要承担起原有团购业务量，再加上用户爆发的需求，系统需要进一步的改进以更好的支撑业务。

支撑阶段我们主要从以下几个方面来看：

质量：轮子总坏，坏一次修半天；一天N个故障，一直在处理线上问题。
稳定性：调整各内部的小轮子，整个车都跪了；一个小需求上线，导致整个系统瘫痪。
性能：车太重，轮子hold不住了；业务量越来越大，系统相应越来越慢，逐渐hold不住了。
服务化：小轮子变大轮子；原本的一个小服务，随着业务的发展，越来越大，很多人都不敢动了。

应对：质量

一谈到质量，可以很快想到需要从需求、设计、开发、上线、维护等各个环节严格把关，才能保证最终的质量。

一个通用的理论是：在越前置的环节发现问题，造成的影响越小，恢复成本越低。

但伴随着这个理论的同时，还有另一个维度的问题：在越前置的环节想要发现问题，需要投入的成本通常也越高。当每天都在忙于救火时，如果我们直接硬抓单测覆盖率，精力方面不太允许，所以我们在对于这些质量控制措施的优先级有适当的调整（当然各方面的事情都需要同时做）。

抓线上监控、问题处理：保证问题快速发现、快速解决

监控层面：完善基础监控、服务监控、业务监控，查缺补漏，保证全流程监控，以快速发现问题。
排查层面：通过系统调用trace和业务trace维度，保证可以根据问题情况，迅速定位原因。
处理层面：内部问题通过处理工具、数据修复工具快速处理，外部问题通过降级、限流等措施快速响应。

如图17，当把线上的监控、排查、处理方面做的差不多的时候，我们终于可以从救火中抽出一些精力来，继续向前走。

抓上线流程：保证问题影响范围尽量小（图18）

内网环境：内网线上环境，内部验证。
灰度环境：灰度部分用户环境，小流量用户验证。
全量环境：全量用户环境，上线。

抓主流程自动化测试：保证问题的严重程度尽量低（图19）

通过MockServer进行外部服务mock，保证测试环境稳定性；
对业务功能进行分级；
按业务功能优先级覆盖自动化测试，保关键流程不失。

抓设计、开发、自测：保证问题尽早避免、尽早发现

设计阶段：提供标准的设计范例，保证设计产出的质量；通过设计Review的方式，保证设计结果；
开发阶段：通过最佳实践的参照，避免重复的学习和填坑成本；通过静态扫描规则的定制，排除常见的问题；通过需求代码Review和代码定期走读，对代码精益求精；
自测阶段：提供单元测试规范，设定覆盖度目标，持续集成长期检查。