铁路站车Wi-Fi运营服务平台微服务架构设计

翁湦元，单杏花，阎志远，王雪峰

（中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 100081）

铁路站车Wi-Fi运营服务平台上线以来，先后增加了设备状态监控、运营数据监控、用户行为分析以及手机App接入服务等功能。随着系统功能的日益增加，系统应用的数量不断增多，原有应用的体积不断增长，应用部署和维护的难度也随之增长[1]。为实现业务的快速迭代，减少研发、部署和维护的复杂性，利用微服务架构对现有系统进行改造[2]。在微服务系统架构中，独立部署在不同进程中的服务之间通过HTTP 等通信机制实现相互调用，从而实现系统的灵活部署和扩展[3]。本文阐述了铁路站车Wi-Fi运营服务平台进行微服务化改造的架构设计、关键问题和实施效果。

1 微服务架构设计改造方案

1.1 原系统架构概述

原铁路站车Wi-Fi运营服务平台根据不同的业务需求垂直划分为相互独立的模块，模块均是单体应用的形式，通过部署多个副本并借助Nginx负载均衡实现应用服务能力的扩展。单体应用内部功能集中，代码和数据中心化，运行在同一个进程中。随着业务系统功能的增多，一旦出现缺陷，原因难以定位。修复系统需要花费较长的时间，项目构建和部署的时间也会相应加长。

1.2 服务拆分和架构设计

通过引入微服务架构模式，将应用程序分解为一系列较小的互连服务，从而避免大而臃肿的单体应用架构。根据既有系统业务进行梳理，对平台进行服务拆分，拆分结果如表1所示。

表1 平台服务列表

铁路站车Wi-Fi运营服务平台可划分为接入层、业务层、基础资源层和数据层[4]，微服务架构设计如图1所示。

图1 微服务架构设计图

（1）接入层面向用户和外部软件以Web页面或API接口的方式提供服务，根据业务模块垂直划分，通过整合业务层内各业务微服务的能力来为外部用户和软件提供最终的服务，灵活地对服务进行编排、组合，以实现快速迭代，满足多变的外部需求。

（2）业务层由经过拆分的相互独立且松散耦合的服务组成，各服务专注于自身负责的模块业务[5]，可快速水平扩展，同时服务的升级也不会影响平台整体业务的正常运行。

（3）基础资源层由与业务无关的组件组成，为微服务应用提供必要的运行支撑。

（4）数据层部署的是各业务服务所需的数据库实例，并且可以针对各业务的需求特性单独配置数据复制和数据拆分等优化策略。

2 微服务改造关键问题

微服务架构相对于单体架构而言更为复杂，以下针对微服务化改造中的若干关键问题和应对措施进行阐述。

2.1 应用配置统一管理

微服务架构中应用的数量比单体架构要多出许多，各应用配置均不相同，配置的维护和管理难度变大。为此引入配置中心，将应用的配置信息统一存储在配置中心内。各应用只要注册并加入微服务体系中，即可根据自身的服务名称获取相应的配置信息，有效减少了配置出错的可能性。

图2 微服务配置调用示意图

如图2所示，应用通过注册找到配置中心服务，读取自己的配置信息并完成启动流程，还可通过消息队列监听配置信息的变化，完成配置的及时刷新。

2.2 日志监控与链路追踪

微服务架构是分布式的，服务都被部署在不同的节点中，而用户的一次操作可能涉及多个服务处理。对于研发人员而言，调试过程中如何通过日志检查各服务的运行状态，分析用户一次操作请求的处理过程将变得极为困难[6]。通过建立ELK（Elastic Search, Logstash, Kibana）[7]实现日志的集中采集和快速搜索服务，并通过Zipkin实现服务调用链路的追踪服务，可解决日志查询和调用过程的追踪问题。日志采集与链路追踪系统部署结构示意图，如图3所示。

图3 日志采集与链路追踪示意图

服务在运行过程中的日志被Logstash采集组件搜集并通过Kafka消息队列投送到Elastic Search集群中被索引以便快速检索。服务之间的调用过程信息通过RabbitMq队列投送至Zipkin链路追踪服务中，Zipkin服务将信息保存至Elastic Search集群以供链路追踪分析。

2.3 接入层服务安全性

与传统的单体程序不同，微服务架构下用户使用的每一功能都有可能涉及多个服务。若将用户身份认证整合进每一个微服务应用，会使得代码出现大量冗余，增加代码维护工作量。并且反复处理用户认证信息也是对计算资源的一种浪费。为解决上述问题，引入JWT（Json Web Tokens）[8]身份认证机制，并将JWT的认证与API网关相结合，JWT认证流程如图4所示。

图4 JWT认证机制示意图

通过网关对用户操作的统一拦截与处理，对于免验证的接口请求直接放行，对于需要用户身份认证的接口请求，则解析并验证JWT信息是否有效，若JWT信息有效，往下转发用户请求，同时将用户信息附加在请求头中；若JWT信息无效，则拒绝用户的请求。通过网关控制和JWT认证统一全平台的用户权限控制机制，实现单点登陆，减少代码冗余。

2.4 服务调用规范

在微服务架构内，应用之间通过HTTP方式进行交互[9]，相比于单体应用体系，微服务体系服务之间的依赖更加复杂，若按照以往的开发方式常常出现由于缺乏接口文档或者接口文档更新不及时导致开发人员使用错误的方式调用服务接口的情况，研发人员不得不频繁针对接口问题进行沟通和代码调整，增加了开发和沟通成本。为避免以上问题，将服务接口定义体现在interface中，并将这些接口独立建立为API项目。服务提供方按照interface[10]中的定义实现Controller，服务调用方在Http客户端中继承对应的interface，从而保证了双方通信接口定义的统一。部分项目代码如下。

（1）在api项目中编写接口约定interface

api项目中仅编写interface代码，约定接口的Http调用地址和参数等信息。

（2）在服务提供方的Controller中编写接口实现

服务提供方中用于接收和处理请求的Controller必须实现api项目中的interface，以保证接口按照interface的约定提供服务。

（3）在服务调用方按照interface的约定进行调用

在调用方项目中，我们利用Spring Cloud组件中的Feign Client来进行Http调用。Feign Client通过继承api项目中的interface即可按照interface约定的地址和参数进行调用。

综上，通过公用interface代码，保证了接口提供方和调用方对于某接口定义的一致性，从而避免了不必要的接口文档编写和沟通成本。

3 实施效果

改造后的铁路站车Wi-Fi运营服务平台充分利用了微服务架构的优势，能够快速响应需求变化，稳定运行的同时也可以实时监控平台各服务的运行状态，应用后的具体效果体现如下。

3.1 服务快速整合

平台运行期间，在两个月内迅速地完成交易服务的研发，并通过整合原有的内容管理与展示服务，成功上线小说收费阅读的功能，实现对原有的小说阅读功能的平滑升级。如图5所示，通过服务整合，内容、用户、交易3大服务模块共同支撑内容管理平台的运行。

图5 服务整合实例图

3.2 高效的研发调试工具

图6展示了微服务平台的全景调用关系图、服务调用链时序图、接口状态监测以及全局日志检索功能。以上工具为研发人员快速调试、系统调优提供了有力的支持。

图6 研发调试工具实例图

4 结束语

本文对微服务架构进行了简单介绍，阐述了铁路站车Wi-Fi运营服务平台的原架构设计的不足之处，提出了基于Spring Cloud的微服务架构设计与改造方案，列举了实施架构改造的关键问题，并举例说明了微服务化改造后的实施效果。微服务架构的引入，使平台得以快速响应需求的变化，同时通过服务的拆分和解耦降低了研发人员的研发难度，监控工具的引入也降低了研发人员的运维成本。当前架构设计仍然存在不足，如对于Spring Cloud组件的依赖性强，不利于引入多样化的开发语言等。