马蜂窝火车票系统服务化改造初探

图 2-火车票系统 V1.0 技术架构

如图所示，对外展现功能主要分为两大块，一块是 C 端 App 和 H5，另外是运营后台。二者分别经过外网 Nginx 和内网 Nginx 统一打到 php train 应用上。程序内部主要有四个入口，分别是：

1. 供其他二方系统调用的 facade 模块

2. 运营后台调用的 admin 模块

3. 处理 App 和 H5 请求的 train 核心模块

4. 处理外部供应商回调模块

四个入口会依赖于下层 modules 模块实现各自功能。对外调用上分两种情况，一种是调用二方系统的 facade 模块满足其公司内部依赖；一种是调用外部供应商。基础设施上依赖于搜索、消息中间件、数据库、缓存等。

这是典型的单体架构模式，部署简单，分层结构清晰，容易快速实现，可以满足初期产品快速迭代的要求，而且建立在公司已经比较成熟的 PHP 技术基础之上，不必过多担心稳定性和可靠性的问题。

该架构支撑火车票业务发展了将近一年的时间，简单、易维护的架构为火车票业务的快速发展做出了很大的贡献。然而随着业务的推进，单体架构的缺陷逐渐暴露出来：

• 所有功能聚合在一起，代码修改和重构成本增大

• 研发团队规模逐渐扩大，一个系统多人开发协作难度增加

• 交付效率低，变动范围难以评估。在自动化测试机制不完善的情况下，易导致「修复越多，缺陷越多」的恶性循环

• 伸缩性差，只能横向扩展，无法按模块垂直扩展

• 可靠性差，一个 Bug 可能引起系统崩溃

• 阻碍技术创新，升级困难，牵一发而动全身

为了解决单体架构所带来的一系列问题，我们开始尝试向微服务架构演进，并将其作为后续系统建设的方向。

图3-大交通基础组件

如上图所示，整体开发框架与组件从下到上分为四层。这里主要介绍最上层大交通业务场景下的封装框架和组件层：

• mlang：大交通内部 工具 包

• mes-client-starter：大交通 MES 技术埋点采集上报

• dubbo-filter：对 Dubbo 调用的 tracing 追踪

• mratelimit：API 限流保护组件

• deploy-starter：部署流量摘除工具

• tul：统一登录组件

• cat-client：对 CAT 调用增强封装的统一组件

服务化的实施离不开基础设施体系的支持。在公司已有基础之上，我们陆续建设了：

• 敏捷基础设施：基于 Kubernetes 和 Docker

• 基础设施监控告警：Zabbix，Prometheus，Grafana

• 业务告警：基于 ES 日志，MES 埋点 + TAlarm

• 日志系统 ：ELK

• CI/CD 系统：基于 Gitlab+Jekins+Docker+Kubernetes

• 配置中心：Apollo

• 服务化支撑 ：Springboot2.x+Dubbo

• 服务治理：Dubbo-admin，

• 灰度控制

• TOMPS ：大交通应用管理平台

• MPC 消息中心：基于 RocketMQ

• 定时任务：基于 Elastic-Job

• APM 系统 ：PinPoint，CAT

• PHP 和 Java 双向互通支持

如上所述，初步构筑了较为完整的 DevOps + 微服务开发体系。整体架构如下：

图4-大交通基础设施体系

从上至下依次分为：

• 访问层——目前有 App，H5 和微信小程序；

• 接入层——走公司公共的 Nginx，OpenResty；

• 业务层的应用——包括无线 API，Dubbo 服务，消

• 消息中心和定时任务——部署在 Kubernetes+Docker 中

• 中间件层——包括 ElasticSearch，RocketMQ 等

• 存储层——MySQL，Redis，FastDFS，HBase 等

此外，外围支撑系统包括 CI/CD、服务治理与配置、APM 系统、日志系统、监控告警系统。

• CI 基于 Sonar + Maven(依赖检查，版本检查，编译打包) + Jekins

• CD 基于 Jekins+Docker+Kubernetes

我们目前还没有放开 Prod 的 OPS 权限给开发，计划在新版 CD 系统中会逐步开放。

我们选择 Dubbo 作为分布式微服务框架，主要有以下因素考虑：

1. 成熟的高性能分布式框架。目前很多公司都在使用，已经经受住各方面性能考验，比较稳定；

2. 可以和 Spring 框架无缝集成。我们的架构正是基于 Spring 搭建，并且接入 Dubbo 时可以做到代码无侵入，接入也非常方便；

3. 具备服务注册、发现、路由、负载均衡、服务降级、权重调节等能力；

4. 代码开源。可以根据需求进行个性化定制，扩展功能，进行自研发

图 6-Dubbo 架构

除了保持和 Dubbo 官方以及社区的密切联系外，我们也在不断对 Dubbo 进行增强与改进，比如基于 dubbo-fitler 的日志追踪，基于大交通统一应用管理中心的 Dubbo 统一配置管理、服务治理体系建设等。

图7-抢票功能划分

也就是说，用户下抢票单支付成功，待抢票占座成功后，后续出票的事情我们会交给 PHP 电子票系统去完成。同理，在抢票的逆向方面，只需实现「未抢到票全额退」以及「抢到票的差额退」功能，已出票的线上退和线下退票都由 PHP 系统完成，这就在很大程度上减少了抢票的开发任务。

图8-抢票服务设计

• 正向交易服务：包括用户下抢票单、支付、取消、出票、查询、通知等功能

• 逆向交易服务：包括逆向订单、退票、退款、查询、通知等

• 供应侧：去请求资源方完成对应业务操作、下抢票单、取消、占座、出票等

• 活动服务：包括日常活动、分享、活动排名统计等

2. 从系统层级分为前端 H5 层前后分离、API 接入层、RPC 服务层，和 PHP 之间的桥接层、异步消息处理、定时任务、供应商对外调用和推送网关。

图9-抢票系统分层

• 展示层：H5 和小程序，前后端分离

• API 层：对 H5 和小程序提供的统一 API 入口网关，负责对后台服务的聚合，以 HTTP REST 风格对外暴露

• 服务层：包括上节所提到的业务服务，对外提供 RPC 服务

• 桥接层：包括调用 PHP 的代理服务，对 Java 侧提供 Dubbo RPC 服务，以 HTTP 形式调用统一的 PHP 内部网关；对 PHP 提供的统一 GW，PHP 以 HTTP 形式通过 GW 来调用 Java 服务

• 消息层：异步的消息处理程序，包括订单状态变更通知，优惠券等处理

• 定时任务层：提供各种补偿任务，或者业务轮询处理

对于交易系统而言，不管是用何种语言，何种架构，要考虑的最核心部分终归是数据。数据结构基本反应了业务模型，也左右着程序的设计、开发、扩展与升级维护。我们简单梳理一下抢票系统所涉及的核心数据表：

1. 创单环节：用户选择车次进入填单页以后，要选择乘车人、添加联系人，所以首先会涉及到乘车人表，这块复用的 PHP 电子票功能

2. 用户提交创单申请后，将会涉及到以下数据表：

• 订单快照表——首先将用户的创单请求要素存储起来

• 抢票订单表 (order)：为用户创建抢票单

• 区段表（segment）：用于一个订单中可能存在的连续乘车而产生的多个车次情况 (类似机票航段)

• 乘车人表 (passenger)：抢票单中包含乘车人信息

• 活动表 (activity)：反映订单中可能包含的活动信息

• 物品表 (item)：反映包含的车票，保险等信息

• 履约表：用户购买车票、保险后，最终会做票号回填，我们也叫票号信息表

3. 产生占座结果后：用户占座失败涉及全额退款，占座成功可能涉及差额退款，因此我们会有退票订单表 (refund_order)；虽然只涉及到退款，但同样会有 refund_item 表来记录退款明细。

图10-抢票订单状态流转

我们将状态分为订单状态和支付状态，通过事件机制来推进状态的流转。到达目标态有两个前提：一是原状态，二是触发事件。状态按照预设的条件和路线进行流转，将业务逻辑的执行和事件触发与状态流转拆分开，达到解耦和便于扩展维护的目的。

所谓幂等性，是指对一个接口进行一次调用和多次调用，产生的结果应该是一致的。幂等性是系统设计中高可用和容错性的一个有效保证，并不只存在于分布式系统中。我们知道，在 HTTP 中，GET 接口是天生幂等的，多次执行一个 GEI 操作，并不会对系统数据产生不一致的影响，但是 POST，PUT，DELETE 如果重复调用，就可能产生不一致的结果。

具体到我们的订单状态来说，前面提到状态机的流转是需要事件触发的，目前抢票正向的触发事件有：下单成功、支付成功、占座成功、关闭订单、关闭支付单等等。我们的事件一般由用户操作或者异步消息推送触发，其中任意一种都无法避免产生重复请求的可能。以占座成功事件来说，除了修改自身表状态，还要向订单中心同步状态，向 PHP 电子票同步订单信息，如果不做幂等性控制，后果是非常严重的。

保证幂等性的方法有很多，以占座消息为例，我们有两个措施来保证幂等：

1. 占座消息都带有协议约束的唯一 serialNo，推送服务可以判断该消息是否已被正常处理。

2. 业务侧的修改实现 CAS(Compare And Swap)，简单来说就是数据库乐观锁，如 update order set order_status = 2 where order_id = 『1234' and order_status = 1 and pay_status = 2 。

抢票系统建设的完成，代表我们迈出了一小步，也只是迈出了一小步，毕竟抢票是周期性的业务。更多的时间里，电子票是我们业务量的主要支撑。在新老系统的并行期，主要有以下痛点：

1. 原有电子票系统由于当时因素影响，与特定供应商绑定紧密，受供应商制约较大；

2. 由于和抢票系统及大交通其他系统之间的兼容成本较高，导致我们统一链路追踪、环境隔离、监控告警等工作实施难度很大；

3. PHP 和 Java 桥接层承接太多业务，性能无法保证

因此，卸下历史包袱，尽快完成旧系统的服务化迁移，统一技术栈，使主要业务得到更加有力的系统支撑，是我们接下来的目标。

我们希望通过对电子票流程的改造，重塑之前应急模式下建立的火车票项目，最终实现以下几个目标：

1. 建立马蜂窝火车票的业务规则，改变之前业务功能和流程上受制于供应侧规则的局面；

2. 完善用户体验和功能，增加在线选座功能，优化搜索下单流程，优化退款速度，提升用户体验；

3. 提升数据指标和稳定性，引入新的供应侧服务，提高可靠性；供应商分单体系，提升占座成功率和出票率；

4. 技术上完成到 Java 服务化的迁移，为后续业务打下基础

我们要完成的不仅是技术上的重构，而是结合新的业务诉求，去不断丰富新的系统，力求达到业务和技术的目标一致性，因此我们将服务化迁移和业务系统建设结合在一起推进。下图是电子票流程改造后火车票整体架构：

图11-电子票改造后的火车票架构

图中浅蓝色部分为抢票期间已经建好的功能，深蓝色模块为电子票流程改造新加入的部分。除了和抢票系统类似的供应商接入、正向交易、逆向交易以外，还包括搜索与基础数据系统，在供应侧也增加了电子票的业务功能。同时我们新的运营后台也已经建立，保证了运营支撑的延续性。

项目实施过程中，除了抢票所说的一些问题之外，也着重解决以下几个问题。

图12-站站查询调用流程

请求先到 twl api 层，再到 tsearch 查询服务，tsearch 到 tjs 接入服务再到供应侧，整个调用链路还是比较长的，如果每次调用都是全链路调用，那么结果是不太乐观的。因此 tsearch 对于查询结果有 redis 缓存，缓存也是缩短链路、提高性能的关键。站站查询要缓存有几个难点：

1. 对于数据实时性要求很高。核心是余票数量，如果数据不实时，那么用户再下单占座成功率会很低

2. 数据比较分散。比如出发站，到达站，出发日期，缓存命中率不高

3. 供应侧接口不稳定。平均在 1000ms 以上

综合以上因素考虑，我们设计 tsearch 站站搜索流程如下：

图13-搜索设计流程

如图所示，首先对于一个查询条件，我们会缓存多个渠道的结果，一方面是因为要去对比哪个渠道结果更加准确，另一方面可以增加系统可靠性和缓存命中率。

我们将 Redis 的过期时间设为 10min，对缓存结果定义的有效期为 10s，首先取有效；如果有效为空，则取失效；如果失效也为空，则同步限时 3s 去调用渠道获取，同时将失效和不存在的缓存渠道交给异步任务去更新。需要注意通过分布式锁来防止并发更新一个渠道结果。最终的缓存结果如下：

我们有大量业务是通过异步消息方式来处理的，比如订单状态变更消息、占座通知消息、支付消息等。除了正常的消息消费以外，还有一些特殊的场景，如顺序消费、事务消费、重复消费等，主要基于 RocketMQ 来实现。

顺序消费

主要应用于对消息有先后依赖的场景，比如创单消息必须先于占座消息被处理。RocketMQ 本身支持消息顺序消费，我们基于它来实现这种业务场景。从原理上来说也很简单，RocketMQ 限定生产者只能将消息发往一个队列，同时限定消费端只能有一个线程来读取，这样全局单队列，单消费者就保证了消息的顺序消费。

重复消费

RocketMQ 保障的是 At Least Once，并不能保证 Exactly Only Once，前面抢票我们也提过，一是通过要求业务侧保持幂等性，另外通过数据库表 message_produce_record 和 message_consume_record 来保证精准一次投递和消费结果确认。

事务消费

基于 RocketMQ 的事务消息功能。它支持二阶段提交，会先发送一条预处理消息，然后回调执行本地事务，最终提交或者回滚，帮助保证修改数据库的信息和发送异步消息的一致。

歼十战机的总设计师曾说过一句话：「造一架飞机不是最难的，难的是让它上天」，对我们来说同样如此。3 月是春游季的高峰，业务量与日俱增，在此期间完成系统重大切换，我们需要完备的方案来保障业务的顺利切换。

方案设计

灰度分为白名单部分和百分比灰度部分，我们首先在内部进禾禾土白名单进行灰度，稳定后进入 20% 流量灰度期。

灰度的核心是入口问题，由于本次前端也进行了完整改版，因此我们从站站搜索入口将用户引入到不同的页面，用户分别会在新旧系统中完成业务。

相关推荐

状态机在机票订单交易系统中的应用与优化

关注马蜂窝技术，找到更多你想要的内容