许关飞：美团●大众点评高级技术专家，酒店后台研发组eHome团队负责人。新美大高级技术专家。 2012年加入美团，主导了新美大酒店业务从通用团购模式到专业酒店预订的技术转型；负责过美团酒店预订业务系统，平台系统，目前带领酒店孵化业务技术团队。
导读：新美大以团购作为切入点，为了更好的连接用户与商户，从2012年开始在酒店、外卖、电影等垂直领域深耕细作。到2016年，美团酒店交易额单日破亿，间夜量行业第一。
在酒店业务的转型和高速发展过程中，不同的阶段对系统结构也提出来不同的要求，本次分享会通过对几个阶段的系统整体情况的分析、演化，和大家一起整理业务的不同阶段给系统带来的挑战和机遇，希望可以为处于文中某个阶段的同学提供一些思路上的参考。
一、 案例背景
美团酒店从2012年开始，以团购为基础，着手酒店业务的精细化发展；
2012年~2016年期间，探索并完成了团购业务到预订业务的升级，预订业务占比90%以上；
期间酒店业务快速发展，2016年消费额单日破1.5亿，单日入住间夜量突破80W，行业第一；
在业务转型升级、快速发展的整个过程中，不同的阶段对系统架构的设计带来了不同的挑战。
二、案例解读
我们将从开始酒店精耕细作到现阶段，把酒店系统的整个发展过程分为4个大阶段：决策、落地、支撑、优化，如图1。
决策阶段是指我们需要去思考、确定以后酒店系统应该如何去发展、才能够更好的去支撑、推动业务的发展。
落地阶段是指在做好决定之后，需要将决定的内容逐步落地、实现。
支撑阶段是指在系统需要能够很好的支撑业务迅猛的发展。
优化阶段是指在系统的支撑、发展过程，我们需要通过不断的优化业务、系统，以更好的推动业务发展。
图1 酒店系统发展历程
●2.1 决策阶段
首先我们进入决策阶段（图2）。
图2 决策阶段
在当时的阶段中，伴随着团购业务的发展，已经形成一套完整的团购系统体系，包含全套的供给、数据、售卖流程，包含toB、toE、toC的全套功能，并搭配着相关的基础设施，如DB、Cache、RPC等，而这一套系统同时支撑着餐饮、电影、酒店、旅游等20多个大品类。如图3所示。
图3 团购系统体系
酒店业务的精细化发展需要我们在供给、产品、促销、交易等环节进行进一步的扩充、升级。如图4。
图4 酒店业务的精细化发展要求
摆在面前的是一系列非常常见的问题：老系统支撑难、新系统成本高、业务可行性不确认。
老系统支撑难：原有团购系统是全品类系统架构，通用性强，修改、订制较难，系统历史“包袱”较重；
新系统成本高：如果新建一套系统链路长，涉及面广，改动量大，周期长；
业务可行性不确认：无论采取何种方式来看，成本都不会低，而此时我们对于这个业务方向是否是真正满足用户需求还存在一定的不确认性。
这是非常常见的场景，也是非常难做的决定。对于很难决定的事情，我们需要收集更多的信息：
首先，低成本验证业务可行性。
采取和现有流程较为松耦合的方式实现简易版业务（图5），以保证可以确认用户对此类需求的使用情况，同时尽量保持低成本。经验证，业务方向OK。
图5 简易版业务流程
第二，典型需求验证“支撑难”。
通过典型的“价格计划”需求（图6），验证团购系统进行定制化开发的成本。经过实际验证，一个典型的需求持续2个月左右，影响方非常多，而以后类似需求还会有很多。所以，成本基本不可接受。
图6 “计划价格”需求
第三，MVP需求验证“成本高”。
通过酒店集团接入打造酒店系统MVP版本（图7），以第三方为供给来源，PC版做出口，实现最简版逻辑，以确认新建系统范围、成本。经过实际验证，周期在2个月左右，成本不小，但基本可控。
图7 酒店系统MVP版本
经过三方面的验证得出结论：业务方向OK、复用成本过高，新建成本基本可控。依此得出方案：构建酒店系统（造个轮子），如图8。
图8 解决方案
●2.2 落地阶段
方向确定后，我们进入落地阶段（图9）。
图9 落地阶段
落地过程中主要关注三个方面：
哪些轮子需要自己造（自建 or 复用）：全链路中涉及非常多的系统，全部重建成本高，且有部分是可以重用的，如何取舍。
轮子造多大（分 与 合）：服务化粒度问题，业务初期需求变动频繁，小服务协调成本高，大服务稳定性、隔离性差。
车不停，怎么把轮子搞上去（保证业务发展）：整个服务构建需要周期，期间会对业务造成较大影响，如何降低影响，保证业务发展。
应对：“自建” or “复用”→掐头去尾，保核心竞争力
构建酒店系统并不意味着所有的轮子都要重造一遍，过程中遵循几个原则（如图10）：
掐头：基础设施如缓存、RPC框架等复用，保证基础设施稳定性；基础服务如用户、支付、风控等复用，保证以后不同业务之间的协作。
去尾：对外的统一出口如主搜、推荐、订单等复用，保证对下游用户体验的统一性、简单性。
保核心竞争力：中间业务逻辑部分，关注和业务核心竞争力最核心相关部分。非核心部分“随缘”，多业务核心部分“要结果”，只酒店核心部分“自己搞”。
图10 “自建”or“复用”
应对：“分”与“合”→对内分，对外合
对于分与合的问题，服务化是趋势，但我们要尽量降低业务前期频繁的变动和大需求扎堆的情况对系统带来的影响，采取对内分、对外合的方式（如图11）：
对内分：对内保留业务逻辑扩展性，如产品内部服务会根据后续业务发展方向拆分销售规则、价格、库存等服务，保证可扩展性。
对外合：对外保证服务逻辑完整性：如产品服务对外提供的接口，可以完成对产品的完整操作和信息获取，以避免服务扩散太细，带来的高协作成本。
图11 “分”与“合”
应对：保证业务发展→分阶段落地，区分优先级，保证每阶段收益
系统的整个构建涉及面较广，如果一次性完成周期较长，同时也不利于快速验证和优化，所以将整个项目进行分步，分步的要求有两个：
优先解决业务痛点；
必须有阶段性产出。
首先，识别项目的核心目标：高效的供给→良好的用户体验。
然后，确认核心目标的优先级：
用户体验依赖于高效供给产生的丰富、高质量产品，并且供给系统建设完成之后需要一定的积累周期；
所以：优先解决供给问题，然后完善用户体验。
最后，明确每个阶段的业务收益：
供给阶段：效率提升
用户体验阶段：退款率
步骤一：解决效率问题
通过对于供给系统、产品系统的建设，使供给效率达到300%的提升，同时在这个过程中，完成了酒店系统的前半部分建设：供给到产品（如图12）。
图12 供给到产品
步骤二：解决体验问题
通过对于预付系统的建设，进行业务升级，用户退款率降低60%，同时在这个过程中，完成了酒店系统的后部分建设：售卖到交易（如图13）。
图13 售卖到交易
步骤三：系统融合
将团购系统中的酒店业务和酒店系统进行融合，保证各个业务形态共享效率、体验的红利，同时统一酒店的所有系统。（如图14）
图14 系统融合
经过以上的几步，完成了酒店系统的初步建设。
图15中，灰色部分为去尾的基础组件部分，桃红色部分是去尾的基础服务部分，绿色部分是未掐头的统一出口部分，而其余的大片深青色部分，则是酒店业务核心相关的系统部分。
图15 酒店系统
●2.3 支撑阶段：支撑业务需求、业务量的快速增长
酒店系统建设完成后，就需要承担起原有团购业务量，再加上用户爆发的需求，系统需要进一步的改进以更好的支撑业务。（图16）
图16 支撑阶段
支撑阶段我们主要从以下几个方面来看：
质量：轮子总坏，坏一次修半天；一天N个故障，一直在处理线上问题。
稳定性：调整各内部的小轮子，整个车都跪了；一个小需求上线，导致整个系统瘫痪。
性能：车太重，轮子hold不住了；业务量越来越大，系统相应越来越慢，逐渐hold不住了。
服务化：小轮子变大轮子；原本的一个小服务，随着业务的发展，越来越大，很多人都不敢动了。
应对：质量
一谈到质量，可以很快想到需要从需求、设计、开发、上线、维护等各个环节严格把关，才能保证最终的质量。
一个通用的理论是：在越前置的环节发现问题，造成的影响越小，恢复成本越低。
但伴随着这个理论的同时，还有另一个维度的问题：在越前置的环节想要发现问题，需要投入的成本通常也越高。当每天都在忙于救火时，如果我们直接硬抓单测覆盖率，精力方面不太允许，所以我们在对于这些质量控制措施的优先级有适当的调整（当然各方面的事情都需要同时做）。
抓线上监控、问题处理：保证问题快速发现、快速解决
监控层面：完善基础监控、服务监控、业务监控，查缺补漏，保证全流程监控，以快速发现问题。
排查层面：通过系统调用trace和业务trace维度，保证可以根据问题情况，迅速定位原因。
处理层面：内部问题通过处理工具、数据修复工具快速处理，外部问题通过降级、限流等措施快速响应。
图17 线上监控问题处理
如图17，当把线上的监控、排查、处理方面做的差不多的时候，我们终于可以从救火中抽出一些精力来，继续向前走。
抓上线流程：保证问题影响范围尽量小（图18）
内网环境：内网线上环境，内部验证。
灰度环境：灰度部分用户环境，小流量用户验证。
全量环境：全量用户环境，上线。
图18 上线环境
抓主流程自动化测试：保证问题的严重程度尽量低（图19）
通过MockServer进行外部服务mock，保证测试环境稳定性；
对业务功能进行分级；
按业务功能优先级覆盖自动化测试，保关键流程不失。
图19 流程自动化测试
抓设计、开发、自测：保证问题尽早避免、尽早发现
设计阶段：提供标准的设计范例，保证设计产出的质量；通过设计Review的方式，保证设计结果；
开发阶段：通过最佳实践的参照，避免重复的学习和填坑成本；通过静态扫描规则的定制，排除常见的问题；通过需求代码Review和代码定期走读，对代码精益求精；
自测阶段：提供单元测试规范，设定覆盖度目标，持续集成长期检查。
图20 设计开发自测阶段监控
应对：稳定性
系统稳定性方面可以有很多个维度进行考虑，这里我们核心讨论隔离问题。
分层：变与不变分离
对服务进行分层：数据层、服务层、应用层、API层，稳定性依次降低，将变化的逻辑尽量控制在上层区域，避免底层修改。（图21）
图21 服务分层
瘦身：核心流程与分支流程分离
主线逻辑梳理，剥离无用逻辑、非主线逻辑，保证核心流程的稳定清晰，如图22。
图22 核心流程与分支流程分离
隔离：内部与外部分离
交互部分进行检测，发现问题后Fail Fast，避免因为一个点的问题拖坏整个系统。如图23。
图23 内外部隔离
应对：性能
搞性能最重要的事情：数据。任何的优化请用数据说话，不然都是瞎搞。
常用的优化性能的几个思路（基础组件、网络等层面优化不在这里讨论）：简化、异步、并行、就近（如图24）。
简化：是不是有那么复杂
异步：是不是有那么着急
并行：是不是必须等着别人
图24 简化、异步、并行
就近：扩机房慢了，能不能本地机房；网络访问慢了，能不能用本地数据等，如图25所示。
图25 就近
应对：服务化
随着业务的发展，原本的小服务越来越大，需要考虑服务化问题。一般服务拆分有以下几个思考维度：
业务层面：独立性、完整性、原子性等
服务层面：轻重、快慢、读写等
组织层面：组织划分决定系统架构
另外，对于可以多业务公用的部分，可以按平台方式构建，如客服系统、结算系统等，如图26。
图26 平台构建
经过一段时间的折腾，系统变成了如图27所示的情况：
最下面一层的基础设施、基础业务服务，支撑着公司各个事业群的业务；
倒数第二层的平台层，提供酒旅场景下的平台业务服务，支撑着酒店、门票、交通等业务形态；
中间的产品、交易层面，作为业务的服务层，保持基本稳定；
第二层的搜索、交易等作为应用层，更贴近业务，更轻量的发生变化，保持灵活性。
图27 优化后的系统架构
而在这个阶段中，我们系统跑的越来越顺畅，优化效果如图28所示。
图28 优化效果
●2.4 优化阶段：技术优化，推动业务进一步发展
随着业务、系统的进一步发展，系统进入优化阶段（图29），在这个阶段提出了另一个话题：如何通过技术优化进一步推动业务发展。
图29 优化阶段
核心原则两个：
抓住痛点：保持思考，搞清楚想要的到底是什么；
数据说话：和性能部分一样，没有数据就是瞎搞。
抓住痛点
如图30，原有的营销流程是：运营同学人工收集N方的数据，然后根据自己的经验设定营销策略，投放，然后再去收集数据验证结果。
图30 原有营销流程
这个时候我们可能会听到运营同学反馈：“唉，每天太累了，想休两天假，还没人能替我”。
从正常需求路线来看，我们需要优化给运营同学获取数据的工具，优化运营同学设定策略的系统的用户体验。
但我们还应该往深层次想：
为什么很累：在整个环节中，运营是核心环节，需要从多方获取信息、整合、制定决策、投放，角色较重。
为什么没人能替：在策略设定的过程中，过于依赖运营的能力，经验对结果产生巨大的影响，而且同时经验是不易传授、不易积累的。
针对这个情况，我们对于营销系统进行了进一步的优化（图31）：
经验积累：将运营的规则设定作为经验输入到分析引擎，做到有积累。
角色轻化：数据整合、分析的主要工作由机器替代，运营更多起到审核、观察的角色。
图31 优化营销系统
数据说话
如图32所示，直连的一个典型场景是：从酒店集团或第三方获取库存、价格信息，然后通过MT售卖。而在这个过程中，数据的实时性对于业务的影响非常大。
图32 直连的典型场景
需要考虑的内容包括：
问题触发点：支付转化率较低
缩小范围：分析各个环节数据，确认房态部分影响
明确指标：房态准确率
具体步骤（如图33）：
第一：分析用户的订单预订时间，确认未来N天数据的覆盖度，针对距离当前时间的天数设定不同的同步策略，准确率上升10%；
第二：分析实际数据不实时引起问题的情况，确定通过发生验证、交易等触发，进行数据的同步处理，准确率上升5%；
第三：分析用户的行为数据，预测出热点数据，提高同步频率，准确率上升8%。
图33 步骤
小结（图34）
图34 演进进程
三、案例启示
决策阶段：一切没有足够信息的决定都叫“拍脑袋”；
落地阶段：策略与场景、阶段密切相关；不要指望一口吃成胖子；
优化阶段：优先级很重要；全链路思考，短板一定会漏水；
支撑阶段：保持思考；一起没有数据支撑的优化都是“瞎搞”。
11月9-12日，北京国家会议中心，第六届TOP100全球软件案例研究峰会，美团外卖算法架构师郝井华将分享《美团配送智能调度系统演进》；美团点评酒旅质量团队工具链负责人王鹏将分享《微服务架构下的自动化测试和持续集成工具链实践》。
TOP100全球软件案例研究峰会已举办六届，甄选全球软件研发优秀案例，每年参会者达2000人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场，现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。
