作者简介
Harry，携程资深后端开发工程师，负责直连平台建设，关注系统高可用、数据驱动等领域。
一、前言
携程门票活动供应商直连平台（以下简称“直连平台”）通过API对接多个供应商的订单和商品系统，实现自动化信息同步和状态流转。
随着业务的高速发展，供应商的对接需求与日俱增，这不仅对直连平台接入供应商的上线效率提出更高的要求，同时供应商系统的物理网络限制、稳定性参差不齐等情况也给直连平台带来不小的挑战。
本文将从提高供应商接入效率和增强系统稳定性两个方面分享直连平台的实践经验。
二、背景
2.1 系统介绍
直连平台作为供应商与携程内部系统的适配层，主要支持两条通路：一是同步供应商的商品信息到商品系统，如价格、库存、内容等；二是同步订单信息，如订单状态、凭证信息等。直连平台针对不同供应商提供对应的适配逻辑，以匹配订单系统和商品系统的接口。开放平台为供应商提供方便快速接入的OpenApi和沙箱工具。
图1 直连平台系统介绍
2.2 挑战
随着供应商接入需求越来越多，不同供应商系统之间的差异也愈加明显，在供应商上线效率和系统稳定性上带来新的挑战。
2.2.1 效率
大量供应商通过OpenApi接入平台。每家供应商在上线前，平台需要投入约2人日的联调和验收。当接入中的供应商数量越来越多时，直连平台需要排期对供应商进行逐个处理，延长了供应商的上线周期，影响上线效率。
2.2.2 稳定性
不同供应商系统的物理网络、系统软件之间往往存在差异，承载能力不一。当直连平台的订单流量超过供应商系统的承载能力时，会造成其系统不稳定，甚至引起长时间系统故障，影响平台出票。对于已有限流策略的供应商，如果直连平台的QPS过大时，请求也会被其直接拦截，故需要平台适配不同供应商的承载能力。
当供应商系统出现停机升级、宕机或网络异常等情况，平台会产生大量异常或超时的订单，造成大量客人支付后退订，严重影响下单的对接成功率。供应商系统异常后，由人工介入处理，虽能在一定程度缓解该问题，但仍会出现费力度高和介入不及时等问题。
由于各供应商返回的错误信息不一致，平台难以根据失败原因进行预警或系统干预。
三、实践
直连平台学习借鉴行业通用方案，并结合平台实际情况，在提升效率和提高稳定性方面做了如下实践。
3.1 提升效率
供应商和直连平台均对OpenApi的测试环节有提升效率和降低成本的诉求，直连平台希望提供一个方便供应商自测，且能保证测试质量的工具。
3.1.1 方案
沙箱能对供应商提供自助测试的支持，可以节省人力和提高供应商上线效率，同时也能保护直连平台正式环境不受干扰，所以是开放平台的首选。
在网络安全方面，沙箱指在隔离环境中，用以测试不受信任的文件或应用程序等行为的工具。不明程序让它在沙箱内运行，程序无权修改沙箱外的程序及系统设置，保障了系统不会遭到恶意软件及病毒的篡改和入侵。
一般开放平台中的沙箱，仅能测试单个接口和显示接口日志。和同行业的其他沙箱相比，本文介绍的沙箱（以下简称“平台沙箱”）还支持测试业务场景、自动验收上线等功能，在提高上线效率的同时，还能提高对接质量。
图2 平台沙箱 vs 其他沙箱
3.1.2 平台沙箱简介
为了给供应商提供灵活易用的自助测试工具，平台沙箱支持供应商根据自身系统参数和业务类型进行相关配置。供应商在提交测试任务后，平台沙箱结合供应商配置和测试用例的匹配策略，从测试用例池中匹配所需的测试用例。测试用例的处理支持自动化，即便对于需要供应商主动推送通知的用例，平台沙箱也支持断点执行。平台沙箱接收到供应商推送的正确报文后继续完成后续测试任务，整个过程无需平台人工干预。全部用例执行成功后，即达到平台沙箱验收标准，系统将自动上线。
图3 平台沙箱处理流程
为了实现平台沙箱的全自动化，直连平台需要重点考虑以下4个核心环节：
图4 平台沙箱核心环节
3.1.3 用例定义
人工联调测试时，测试人员需要依据供应商接口类型及业务场景编写不同测试用例，用例类型常包含功能测试、异常测试、边界测试等。这种基于业务场景的测试用例可以保证测试质量。平台经调研其他公司的沙箱后发现，绝大多数的沙箱仅能给用户提供单接口测试的页面，有的页面虽然能组装报文或查看接口日志，但由于没有约束业务场景和校验点，故测试的质量高低不一，为上线后的对接质量带来隐患。
而平台沙箱通过把一个或多个接口组织在一个有明确测试目的的场景中，让供应商的测试流程更清晰，也更容易把握校验点。
图5 单接口测试 vs 场景化测试
3.1.4 用例匹配
不同供应商的产品形态、接口处理方式会有不同，故所需的测试用例集合也不同。为了实现供应商与测试用例的自动匹配，平台在维护测试用例时会为每个测试用例设置不同的匹配规则。匹配规则包含供应商是否接入指定接口、指定接口是同步或异步处理以及具体业务参数，如：是否检验底价、是否校验库存、是否需要证件等。
图6 用例匹配过程
3.1.5 用例执行
匹配得到测试用例集合之后，平台沙箱会自动执行每一个测试用例。每个测试用例包含的多个接口，可能是平台调用供应商的接口（如下单接口），也可能是供应商调用平台的接口（如下单确认通知接口）。以“用例定义”章节中的case#1和case#3为例，分别介绍普通执行流程和断点执行流程，如下图：
图7 用例执行流程（普通执行流程、断点执行流程）
3.1.6 自动验收
每个测试用例都是独立的、可重复执行的，所以允许供应商进行重复测试，直至执行成功。平台沙箱自动统计测试用例的结果。测试用例涵盖了几乎全部的业务场景，全部测试用例都执行成功，则认为供应商根据直连平台OpenApi开发的对接系统达到验收标准。达标后，供应商需要在平台沙箱上主动通知直连平台。平台将自动为供应商做上线配置，完成从平台沙箱测试到验收上线的全部流程。
3.1.7 成果
平台沙箱上线后，供应商测试和验收不再受制于平台人力，对接OpenApi的供应商每月平均上线数量相较于上线前提高了8倍以上，供应商平均接入总耗时从平均23人日下降到6人日。
图8 沙箱上线前后比较
3.2 提高稳定性
系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。在节假日或营销活动期间，订单量会是平常的几倍或几十倍，这会给供应商系统的稳定性带来很大风险。直连平台需要控制流量，提高供应商系统的稳定性。
3.2.1 方案
对于承载能力低于直连平台的供应商系统，直连平台需要控制流向供应商的请求速度，一般会通过限流机制来实现。限流的作用是控制在单位时间向提交不超过一定阈值的请求量，即使用削峰填谷的思路，解决突发流量的问题，保证直连平台整体的出票成功率。
图9 限流策略（削峰填谷）
当供应商系统的指标连续出现异常时，为了减少或阻断持续的影响，常见的做法是采用熔断机制。若系统检测到熔断发生，一般会采取降级处理。在直连平台中，熔断分系统熔断和业务熔断。系统熔断是当直连平台检测到供应商系统持续异常时会通过一定时间的禁售等降级操作来减少出票失败量；而业务熔断则是通过分析并标准化供应商接口返回的错误信息，并进行相应降级操作。
图10 熔断降级
3.2.2 限流
- 常见限流算法
常见的限流算法有计数器算法、令牌桶算法和漏桶算法。
计数器算法是限流算法里最简单、最容易实现的一种算法，通过控制一段时间的总请求数实现限流；令牌桶算法则是使用一个存放固定容量令牌的桶，并按照固定速率向桶中添加令牌，请求是否被处理需要看桶中令牌是否足够；漏桶算法是始终按照固定速率处理请求。
计数器算法和令牌桶算法控制处理请求的平均速度，会存在一定程度的突发流量，而漏桶算法是固定速度，所以直连平台采用漏桶算法来解决不同供应商的限流需求。
- 漏桶限流
用户订单产生后，直连平台需要从队列中批量读取数据，向供应商批量分发，常常会出现瞬时流量影响对方系统的稳定性。通过漏桶限流方案，实现匀速分发，保证供应商系统的平稳处理。
图11 漏桶限流前后对比
具体步骤：根据限流策略，从数据队列中获取指定数量的订单，根据间隔时间计算提交时刻，最后执行分时提交。
图12 漏桶限流实现逻辑
平台的订单对接供应商有几千家。在配置限流策略时，无需为每一家配置限流策略。平台的做法是对于有限流诉求的供应商、订单量较大的供应商和临时有营销活动的供应商配置即可，而其他供应商可以使用一个公共的限速适中的限流策略即可。这样可以保证重点供应商系统的稳定性，又可以减少维护限流策略的费力度。
- 效果展示
下图为限流后的流量请求结果。从图中可明显看出，支持限流后的直连平台可以很平稳的控制处理请求的速度。
图13 限流效果
3.2.3 系统熔断
- 熔断监控
系统熔断的监控采用30分钟长监控和5分钟短监控结合的方式。长监控用于计算熔断时长，而短监控的目的是为了补充长监控的不足，防止把系统已经恢复的供应商再次进行熔断。
- 熔断时长
熔断时长在基础时间的基础上，综合考虑了异常或超时率和连续熔断次数。在对供应商历史异常时长的统计后得到异常均值时长在30分钟左右，故平台设置熔断单次时长最长不超过60分钟。计算熔断时长的公式为：
t：基础时间（5分钟）。
p: 过去30分钟内的异常或超时率。
L(p)：由p计算出的熔断时长等级。异常或超时率越高，则熔断时长等级越高。
n：连续熔断次数，首次熔断n=1。资源上线超过24小时，则n重置为0。
3.2.4 业务熔断
- 错误信息多样性
直连平台对接的供应商非常多且不同供应商接口契约、对接流程和错误描述也不尽相同。对于因“库存不足”而失败的下单响应报文，直连平台可能是根据供应商返回的不同code区分的，也有可能是需要通过错误描述来区分的，如“库存数量不足”、“余票不足”、“没有库存”、“还剩0张”、“已售罄”等等。
图14 库存不足”对应的供应商错误信息
接口的错误信息有很多用途，如监控供应商系统的稳定性、归纳对客失败话术、反映商品设置错误、反映用户错误输入、提醒补库存、关闭班期或下线资源等。基于供应商接口错误信息的分析和处理对于商品力、系统监控、用户体验等方面都有非常重要作用。
- 错误分类
直连平台把业务错误分为6个大类，分别是系统问题、游客信息问题、限购问题、库存问题、产品设置问题和账户余额问题。每个大类有分为若子类，在子类上可以配置通知接收人、通知方式、资源操作方式、对客话术code等。比如对于下单接口，只需要把不同供应商下单接口错误信息中的关键词关联到相应的二级分类上，平台即可基于分类进行统一的操作。
图15 错误分类演示
为了关键词更加精确地识别指定供应商的错误信息，关键词的配置工作必须要人工进行。相同的错误描述对于不同供应商可能有着不同的含义，如：“处理错误”或某个具体的错误码等。
直连平台会监控关键词匹配率，并每日拉取增量的未匹配关键词的供应商错误信息，由运营进行补充到供应商的关键词策略中。
- 降级方式
目前降级方式仅支持禁售，禁售包括关闭班期和下线资源。供应商返回“库存不足”、“日期不可售”等错误时，平台将会对资源操作关闭班期，供应商返回“预存款不足”、“价格设置错误”等错误时，平台将下线资源。
3.2.5 成果
通过系统熔断和业务熔断，有效的规避了因供应商系统异常、库存不足、账户余额不足等等问题造成出票失败的问题，异常或超时失败率从0.34%下降到0.05%。
图16 系统熔断效果
四、结语
引入沙箱后，接入OpenApi的供应商不再受制于直连平台的人力，上线效率明显提升，但由于目前沙箱文档中对沙箱页面使用流程和常见问题的介绍仍不够详尽，还需要平台人力为供应商解答诸多类似问题，故需要进一步完善。
熔断监控能有效减少出票失败率，但熔断监控只依赖下单接口的状态，由于部分供应商已接入可定检查或预下单等实时接口，所以增加监控更多接口数据能更加有效地提高监控的实时性。而且除了禁售，熔断策略还可以补充其他操作，如变更确认方式等。
此外，随着供应商数量和业务逻辑复杂度的增加，现有监控和预警机制有待进一步完善。当前预警手段还比较依赖邮件，而告警邮件数量增多，会增加告警触达率低和响应不及时的风险。故需要基于平台现有逻辑埋点，通过公司成熟且完善的一系列组件对监控和预警做进一步升级。
最后，希望本文中提到的解决方案能给大家带来帮助和启发。
【推荐阅读】
- 每分钟写入6亿条数据，携程监控系统Dashboard存储升级实践
- 携程海外MySQL数据复制实践
- 支持10X增长，携程机票订单库Sharding实践
- 携程基于BookKeeper的延迟消息架构落地实践
“携程技术”公众号
分享，交流，成长
