基于微服务架构的行李全流程跟踪系统设计与实现

［李剑彬 张文娟］

1 引言

行李全流程跟踪作为建设四型机场的重要组成部分，可以有效提高行李运行安全、降低行李差错率。2019 年，民航局提出“三步走”战略，2021 年底全国千万级机场间国内航线将实现行李全流程跟踪，2025 年年底将实现国内航线全覆盖和国际航线有突破。2020 年1 月，北京召开的全国民航工作会议，工作任务明确要求，“推广RFID行李跟踪系统广泛使用、连接成网，逐步建成覆盖全国的民航行李跟踪系统”。

行李全流程跟踪系统，需要接入不同的系统或设备的节点数据，若采用传统的架构进行设计实现，可能会面临跨系统、跨平台数据接入问题，不能很好的接入外部数据源。另外，随着系统数据量的增长，以及行李全流程追踪外延的扩大，对系统的高可用性和拓展性要求越来越高，需要对业务逻辑进行分离，以适应高并发以及异构系统的交互要求，降低系统业务模块的耦合度。为了更好的适应行李全流程系统机场端、集团版和支线机场SASS 服务的发展需要，满足民航局建设行李全流程跟踪系统的指示精神，以及国际航协753 号决议中对行李的追踪和信息监控要求，本文将采用基于微服务架构来设计和实现行李全流程跟踪系统。

2 微服务架构

微服务架构作为近几年的技术热点，是一种遵循高内聚、低耦合的软件开发架构，可以将系统的不同业务功能、业务需求，拆分为若干个支持独立部署和拓展的服务组件，这些服务可以通过不同的语言（Java、C#、Python 或Go等）完成开发，服务之间可以采用轻量化通信机制暴露接口来实现通信，支持多种通信协议（RPC、HTTP REST或AMQP 等），完成跨平台服务调用。

与传统单体架构比较，微服务架构的优点主要有。

（1）每个服务专注于特定的功能或业务需求，服务粒度可以很小；

（2）不同服务可以采用不同的编程语言进行服务实现；

（3）不同服务支持独立开发、独立部署；

（4）微服务架构易于进行需求拓展；

（5）微服务架构易于进行流程编排。

3 需求分析

根据《关于加快推进千万级机场旅客行李全流程跟踪系统机场端建设的通知》的相关要求，千万级机场的行李全流程跟踪系统，需要满足值机、安检、分拣、装车/箱、装机、中转、到达等7 个基本节点的数据采集要求。

为提高机场行李处理效率、降低行李托运异常问题而出现的成本损耗，行李全流程跟踪系统主要基于行李全过程管控为出发点，采取多源异构数据采集解析等技术，结合行李托运过程中多种多样的监控设备，并通过数据采集/整合/监控/分析，达成旅客托运行李全方位追踪、业务高效运行的目的，从而实现机场行李托运业务降本增效的最终目标。

4 系统设计与实现

本文将结合行李全流程跟踪系统的实际需求以及未来发展趋势，利用微服务架构组件化、独立部署、复杂度低、技术多元化等优势，充分考虑系统的高可用性和拓展性，结合高内聚、低耦合思想，对系统的总体架构、系统服务划分与功能设计等内容进行设计实现。

4.1 系统总体架构

本文设计实现的行李全流程跟踪系统采用五层架构设计，包含应用展示层、数据服务层、运维资源层、网络通信层和数据采集层，系统总体架构如图1 所示。

图1 系统总体架构图

系统采用基于Java 的微服务架构实现，前后端分离，充分考虑当前主流技术发展趋势和实际业务应用需要，选用Spring Cloud和Spring Cloud Alibaba中较为适合的微服务应用框架，完成整体技术选型和总体架构搭建。后台基于 Spring Boot 进行开发，为PC 端、移动端和小程序等提供接口服务；前端采用H5+CSS 实现，可根据需要适配Vue、Element UI 等前端框架。

（1）应用展示层：系统采用前后端分离技术实现，可以通过对后台服务的组合调用，实现系统业务应用与交互需求。本系统页面功能及系统外部调用，均可以根据服务接口进行前端定制化开发，降低接口代码开发量，提高代码复用率及系统可拓展性。

（2）数据服务层：包含微服务网关、各服务组件、服务治理与配置、服务监控和DevOps 等内容。微服务网关采用Spring Clound Gateway 框架实现，提供统一接入、协议适配、流量管理与容错、以及安全防护等功能，Web前端或其它应用，访问系统服务组件时，会通过访问API网关进行数据传递，结合JWT 鉴权和Ribbon 负载均衡等框架，保障服务接口的可靠性和安全性；各服务组件为系统前端、应用及对外提供服务支撑，支持集群拓展，内部整合Swagger UI 框架，便于接口调用、调试；服务监控、服务治理与配置，包含服务注册、服务发现、服务治理、熔断防护、链路追踪等内容，选用Nacos、Sentinel、Zipkin 等微服务框架，保证数据及服务组件的监控、管理；DevOps 包含构建工具Maven、代码仓库Git/SVN、持续集成与部署Jenkins、K8S 等开发运维一体化相关内容，用于实现系统持续集成、持续交付、持续部署。

（3）运行资源层：包含系统运行所需的计算资源、存储资源、操作系统和配套软件及设施等内容，用于满足本系统正常运行所需结构化和非结构化数据存储、使用等要求。

（4）网络通信层：为系统提供网络通信所需资源。

（5）数据采集层：主要包含两类数据来源，即外部系统和采集设备。用于实现航班、行李和行李状态等系统基础和应用数据的采集，为行李全流程跟踪系统提供原始数据支持，是系统最为重要的内容之一。

4.2 系统服务划分与功能设计

行李全流程跟踪系统采用微服务架构设计实现，系统基于高内聚，低耦合的设计思想垂直切分几个独立的业务服务，包括行李追踪服务、用户权限服务、基础配置服务、设备管理服务、日志服务、消息服务、数据推送服务和数据采集服务等，系统环境如图2 所示。

图2 系统环境图

（1）行李追踪服务，作为行李全流程跟踪系统的核心服务模块，主要功能模块包括航班保障、行李保障、旅客保障、不正常行李查询、综合监控、数据统计等，通过数据抽取、数据清洗、数据转换、数据存储和分析，实现数据的多样性展示，展示形式包括图表、大屏、可视化看板、3D 看板等。

（2）用户权限服务，主要用于控制各服务组件、功能模块、系统操作等内容的权限，涉及功能模块包括用户管理、权限管理、角色管理、服务授权及微服务网关接口控制等。

（3）基础配置服务，主要用于管理系统基础数据信息管理，功能包括机场管理、航司管理、航站楼管理、机型管理、舱位管理、标记管理、系统管理、参数配置等。

（4）设备管理服务，主要用于行李全流程跟踪系统所涉及的节点数据采集前端设备的管理，包含设备的台账、监控、记录、状态等功能模块。

（5）日志服务，系统运行过程中，会产生多种类型的日志数据，例如操作日志、异常日志、接口日志、通信日志、数据交互日志和系统其它日志记录，在本系统中，统一通过日志服务进行管理，功能包括日志展示、日志检索、日志清理、日志审计、日志溯源等。

（6）消息服务，行李全流程跟踪过程中，会经过多个跟踪节点，涉及的工作场所多、范围大，需要具备统一的消息传递机制，本服务主要用于系统内外部的消息的传递、展示和管理，支持系统角色、系统用户之间的消息收发，涵盖PC 端、手持智能终端，消息内容包含通知消息、任务、预警、告警、系统消息等内容。

（7）数据推送服务，作为系统对外进行数据交互的服务组件，主要用于系统整体数据推送控制，包括推送规则定义、推送机制、推送频率、转发、接收等功能内容，是系统可增值服务模块。

（8）数据采集服务，行李全流程跟踪系统涉及的航班、行李、行李状态等数据，主要来源于外部系统或采集设备，涉及系统对接、通信方式、通信协议差异性较大的问题，本系统设计通过统一的数据采集服务进行实现，支持通信方式、通信协议自定义，确保数据接入的便利性，并提供数据原始报文记录，便于进行问题排查、定位和处理。

为了更好地确保各个微服务的独立性，本文划分的各个微服务模块，与应用层以及微服务之间的交互都是使用RESTFUL 风格，通过HTTP 协议进行的。并且，服务之间仅保留必需的调用，前端调用接口过程中，涉及服务之间业务关联的内容，前端能处理的，均由前端处理，例如，PC 端发送消息给具体的用户，由前端分别调用消息服务和用户权限服务，实现消息发送给具体用户；后台数据处理过程中，服务之间业务关联的内容，通过其它方式能处理的，均不进行服务之间的调用，例如，行李追踪服务产生消息给指定的角色，会先把消息写入数据表，由消息服务调用消息规则引擎，发送此类消息给指定角色。

4.3 跟踪流程实现

行李全流程跟踪系统实现旅客行李全流程跟踪，主要涉及行李出港和进港两个核心业务流程。

如图3 所示，行李出港流程中，本系统需完成值机、安检、分拣、装车/箱、装机等环节的行李采集。

图3 行李出港流程图

如图4 所示，行李进港流程中，进港行李可分为中转和非中转行李，中转行李可使用手持或穿戴终端等方式完成信息采集；非中转行李可以通过固定式等设备完成行李信息采集。

图4 行李进港流程图

针对不同的机场，每个环节可以进一步细分为一个或多个小节点，例如安检节点，可以细分为开始安检、完成安检等。本系统充分考虑跟踪节点细分问题，支持各环节多节点行李数据的跟踪。

4.4 多源异构实现

行李全流程跟踪系统实现旅客行李的全流程跟踪，满足值机、安检、分拣、装车/箱、装机、中转、到达等7个基本节点数据采集要求，依赖于外部源数据的提供，包括航班、行李的基础数据和各跟踪节点采集到的行李状态数据等。

不同机场的数据来源方式、采集节点要求都存在一定差异，本文以常见的对接系统进行描述，包括信息集成系统、离港控制系统、安检信息系统、行李处理系统和航易行，以及手持式、穿戴式和固定式的行李识别数据采集设备，数据流向如图5 所示。

图5 数据流向图

来源于不同系统或设备的原始数据，会统一经过数据采集服务进行处理，数据采集服务根据不同的数据来源及相应的接口协议，通过内部集成的规则引擎，对原始数据进行采集、解析、计算和存储等处理，形成结构化和非结构化数据，提供给其它微服务组件进行应用或二次加工，最终完成旅客行李全流程跟踪的应用需求，如图6 所示。

图6 规则引擎流程图

4.5 总体数据库实现

系统总体数据库主要基于各个微服务使用需要，进行分库设计实现，主要划分为行李追踪、基础配置、消息、日志、用户权限和设备管理等数据库，如图7 所示。

图7 数据库设计图

系统数据库可兼容多种不同关系型数据库，例如Mysql、SQL Server。此处以Mysql8.0 为例说明，数据库可采用一主一从或一主两从进行高可用设计，可根据现场实际环境需求，再次进行数据库水平拓展、垂直拓展，例如：数据库集群、分库分表等。数据库访问缓存使用Redis，支持集群，如图8 所示。

图8 数据库部署图

4.6 系统部署实现

本系统支持实体机、虚拟机及云平台等部署方式，兼容Windows、CentOS 等操作系统，可以根据投运机场的大小、服务器资源、业务规模等因素，灵活部署。服务器资源充足的情况下，可参考图9 所示的高可用部署方式。

图9 系统部署图

（1）前端页面采用Nginx 集群部署，运用反向代理、负载均衡技术，确保前端的高可用性、高可靠性。

（2）API 网关、Nacos 和业务服务集群，结合Ribbon负载均衡、Sentinel 熔断防护、Zipkin 链路追踪等框架，自动根据系统运行情况进行熔断、限流、降级等处理，方便进行链路追踪、问题定位；优化访问请求在服务器组之间的分配，提高系统的响应速度和总体性能；监控服务的运行状态，避免单服务故障导致服务无法正常使用的问题，提高服务组件的安全性、可靠性和稳定性。

（3）Redis 缓存集群部署，进一步提高系统访问性能，降低服务器访问压力；MQ 集群，避免数据量激增时造成数据积压的问题，确保数据处理的高效、准确。

（4）数据库采用读写分离、主备热切的部署方式，让系统访问和数据安全得到进一步保障，服务性能得到全面提升，系统安全性、可靠性、可用性等得到进一步加强、完善。

相对于采用单体、非微服务架构实现的行李全流程跟踪系统，局限于机场端或单机场应用，本文描述的基于微服务架构的行李全流程跟踪系统设计实现，打破了传统应用的局限，聚焦行李全流程跟踪系统实际使用需求，兼容单机场、机场集团和不同机场集团的多个中小机场使用场景，结合高内聚、低耦合思想，通过服务粒度的拆分，进一步实现系统的高可靠性和高可用性，有效避免系统数据量增长过快导致系统响应速度过慢或无法使用的情况。

采用微服务架构进行行李全流程跟踪系统实现，服务模块组件化，可以很好地适配机场系统多、接入复杂的问题，后续接入其它系统应用时，能够很好地降低对本系统的影响，只需通过增加新的服务组件，即可实现应用拓展需求；另外，本系统业务耦合度极低，便于采用集群等高可用部署方式，可以通过集团机场部署本系统，为支线机场提供服务应用，降低支线机场的行李全流程跟踪系统建设成本，高效完成民航旅客托运行李跟踪大闭环，解决旅客痛点，全面提升国内机场托运行李服务质量要求这也是本文的目的和意义之一。

5 结束语

本文针对民航局对行李全流程跟踪系统的建设需要，结合微服务技术最新发展趋势，通过对实际项目实施过程中相关经验的归纳总结，设计并实现出了一套基于微服务架构的行李全流程跟踪系统。系统采用了多项关键技术，包括基于Spring Clound 微服务架构、Spring Clound Gateway 网关、Nginx 集群、JWT 鉴权、Ribbon 负载均衡、Sentinel熔断保护、Nacos服务治理和DevOps可发运维一体化相关内容等，解决了行李全流程跟踪系统在实际应用过程中数据来源多、数据量大和并发量多等问题，具备高拓展性、高可用性、高性能、高可靠性、高可维护性等特点。采用此架构设计和实现的行李全流程跟踪系统，将有效辅助提高行李分拣效率，降低行李运输差错率，提高旅客满意度，提升机场服务品质及公众形象，具备良好的推广价值。