出行APP收银台承接机票、酒店、火车票、度假等业务的订单支付，是连接业务订单、移动客户端与公共支付平台的关键环节，服务年处理交易量超10亿笔的业务规模。
项目的主要复杂度来自多业务、多支付方式的交叉组合：不同业务对订单有效期、支付验价、风控信息和商户主体有不同要求，同时需要支持微信、支付宝、银行卡及礼品卡组合支付等方式。新增业务或支付方式时，既要复用公共能力，又要准确处理各自的交易规则，避免影响已有支付链路。
原收银台采用C#开发，经过多年迭代，业务逻辑耦合、历史分支繁多，维护和接入成本较高，与APP平台的Java技术栈也不一致。因此，项目在持续承接线上交易的前提下推进重构，将分散的支付流程整合为可复用、可扩展的公共能力，缩短业务接入周期，并提升异常发现与故障隔离能力。
1.统一收银与支付选择： 为不同业务提供统一支付入口，展示订单金额、商品信息和支付倒计时；根据业务支持范围、用户历史支付方式及配置规则，确定可用支付方式及展示顺序，减少用户选择成本。
2.多渠道与组合支付： 对接微信、支付宝、银行卡、Apple Pay等支付方式，支持礼品卡、旅游卡等虚拟资产支付，以及余额不足时的组合支付，满足单一支付渠道之外的资金使用需求。
3.支付前业务校验： 在发起支付前，向业务系统核验订单状态、应付金额和支付条件，并获取风控所需信息；针对不同业务执行必要的订单信息补充与推送，使公共支付流程能够适配机票、酒店等业务的差异。
4.业务接入与配置管理： 统一管理项目支持的支付方式、支付前处理动作和相关服务配置，支持新增业务、扩展支付方式及商户主体调整，减少重复开发和接入遗漏。
5.支付追踪与运行监控： 提供支付日志、支付统计及通知衔接能力，从业务项目和支付方式两个维度观察支付情况，结合系统资源指标定位异常，为接入验证、线上排障和持续优化提供依据。
在保障线上支付稳定的前提下完成重构。 原系统经过多年迭代，各业务规则与支付逻辑交织，直接重写容易遗漏历史场景。我先梳理存量支付流程和业务差异，明确系统边界，再分阶段推进迁移与验证，在统一Java技术栈的同时保留必要的兼容能力。重构一期覆盖98%的支付调用量，保障业务平稳过渡。
解决业务项目与支付方式交叉扩展的问题。 机票、酒店等业务都有各自的验价、风控和订单处理要求，如果每接入一种支付方式就重复实现这些规则，开发和维护成本会持续增加。我将支付流程拆分为校验、业务前置处理、支付执行和后续处理，使业务规则与支付方式分别扩展、按需组合；配合接入规范和代码生成工具，降低60%的重复开发成本。2023年Q1完成三期支付方式100%接入，项目接入率达87%。
降低外部服务异常对整体支付的影响。 收银台依赖多个业务系统和公共支付服务，单个接口变慢可能占满共享资源，拖累其他支付请求。我按命令处理、业务项目和支付服务划分线程池，隔离不同依赖的资源使用；同时将监控从CPU、内存、JVM延伸到项目及支付方式维度，帮助定位异常环节。通过日常巡检识别10余项优化点，落地6项优化，系统可用性提升至99.99%。
推进复杂支付场景落地。 负责礼品卡组合支付、虚拟资产支付及银行卡去PCI合规改造，协调业务方、客户端和公共支付团队，处理不同业务规则与存量接口的兼容问题。最终支撑机票、酒店、度假等多业务线接入，服务年处理交易量超10亿笔的业务规模。
评论