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

交通方式是用户旅行前要考虑的核心要素之一。为了帮助用户更好地完成消费决策闭环，马蜂窝上线了大交通业务。现在，用户在马蜂窝也可以完成购买机票、火车票等操作。

与大多数业务系统相同，我们一样经历着从无到有，再到快速发展的过程。本文将以火车票业务系统为例，主要从技术的角度，和大家分享在一个新兴业务发展的不同阶段背后，系统建设与架构演变方面的一些经验。

第一阶段：从无到有

在这个阶段，快速支撑起业务，填补业务空白是第一目标。基于这样的考虑，当时的火车票业务从模式上选择的是供应商代购;从技术的角度需要优先实现用户在马蜂窝 App 查询车次余票信息、购票、支付，以及取消、退票退款等核心功能的开发。

图1-核心功能与流程

技术架构

综合考虑项目目标、时间、成本、人力等因素，当时网站服务架构我们选择的是 LNMP(Linux 系统下 Nginx+MySQL+PHP)。整个系统从物理层划分为访问层 ( App，H5，PC 运营后台)，接入层 (Nginx)，应用层 (PHP 程序)，中间件层 (MQ，ElasticSearch)，存储层 (MySQL，Redis)。

对外部系统依赖主要包括公司内部支付、对账、订单中心等二方系统，和外部供应商系统。

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

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

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

运营后台调用的 admin 模块

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

处理外部供应商回调模块

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

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

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

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

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

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

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

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

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

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

第二阶段：架构转变及服务化初探

从 2018 年开始，整个大交通业务开始从 LNMP 架构向服务化演变。

架构转变——从单体应用到服务化

「工欲善其事，必先利其器」，首先简单介绍一下大交通在实施服务化过程中积累的一些核心设施和组件。

我们最主要的转变是将开发语言从 PHP 转为 Java，因此技术选型主要围绕 Java 生态圈来展开。

开发框架与组件

图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/CD 系统

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

CD 基于 Jekins+Docker+Kubernetes

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

图5-CI/CD 体系

服务化框架 Dubbo

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

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

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

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

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

图 6-Dubbo 架构