顾丹鹏 张业星 唐松强 周浩 张浩洋 何栓康

摘要： 在工程领域，工程数据管理平台是实现全生命周期管理和数字化移交的关键，选用传统单体化应用技术构建平台面临很大的挑战。研究了构建工程数据管理平台的主要设计思路、设计原则以及服务拆分等关键技术与方法。采用云原生微服务Spring Cloud框架进行设计与实现，使平台具备资源按需分配和弹性伸缩以及自动化部署和管理的能力。

关键词： 云原生; 微服务; 数据; 管理; Spring Cloud

中图分类号：TP311          文献标识码：A     文章编号：1006-8228（2021）10-49-05

Research on engineering data management platform based on Cloud Native technology

Gu Danpeng1，2， Zhang Yexing1，2，3， Tang Songqiang1，2， Zhou Hao1，2， Zhang Haoyang1，2， He Shuankang1，2

（1. PowerchinaHuadong Engineering Corporation Limited， Zhejiang， Hangzhou 311100， China; 2. Zhejiang Huadong Engineering Digital Technology Co. Ltd; 3. Zhejiang Engineering Digital Technology Research Center）

Abstract： In the field of engineering， the engineering data management platform is the key to realize full life cycle management and digital handover， and the monolithic application technologies are facing great challenge to construct the platform. The main design ideas， design principles and key technologies and methods of building engineering data management platform are studied. The Spring Cloud framework of Cloud Native microservice is adopted to design and implement， so that the platform has the abilities of resource on-demand allocation and elastic scaling， and the abilities of automatic deployment and automatic management.

Key words： Cloud Native; microservice; data; management; Spring Cloud

0 引言

為了推进企业数字化发展，提升水电站建设及其运行维护过程中的工作效率和质量，建设覆盖工程全过程的工程数据管理平台[1]具有重大意义。

近年来，基于云原生技术进行应用[2]的构建逐渐成为了一种趋势。本文基于云原生技术，采用微服务架构，遵循微服务最佳设计原则，实现一套面向工程领域的工程数据管理系统，该系统具备数据自定义、数据存储以及数据服务能力，覆盖全工程项目范围。本文从系统整体设计、服务拆分以及监控与运维共三个个方面，详细阐述系统设计，以及相关技术难点。整个系统具备高可用、易于扩展特性，可持续交付和持续集成，并且易于监测和运维。

1 相关研究

根据Pivotal和云原生计算基金会（CNCF，Cloud Native Computing Foundation）对云原生的定义，云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于扩展、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁、可预测的重大变更。

云原生应用通常采用微服务[3-4]架构，微服务架构的核心理念是将复杂的应用系统以独立业务单元的形式分解为多个服务，每个服务可以采用不同的实现技术，以轻量级、更灵活的模式进行独立设计、开发、部署，运行于独立的进程中，形成高度内聚的自治单元。微服务架构具有非常多的优势。其一，使大型的复杂应用可以持续交付和持续部署，软件部署到生产环境时将面临更少的问题和故障;其二，每个服务都相对较小、功能相对单一并且容易维护，易于调试、快速部署;其三，服务可以独立部署，服务之间采用轻量的通信协议，耦合度低，利于快速迭代;其四，微服务架构可以使每个团队专注于自己的服务，实现服务自治;其五，更易实验和采纳新的技术，由于微服务依靠服务注册和发现机制，服务之间采用轻量级通信协议，各服务可以使用不同的技术方案实现服务，这样非常方便服务尝试新的技术。此外，微服务架构还具备更好的容错性，微服务架构通常需要设计故障隔离机制，例如，某个服务中的内存泄露不会影响其他服务，其他服务仍旧可以正常地响应请求。

2 系统设计

2.1 架构设计

工程数据管理平台建立在云平台之上，系统总体架构如图1所示，具备虚拟化、容器化、资源调度等能力，支持计算资源、存储资源、网络资源的配置化调整，以应对业务上需求的增长。针对涉及到的结构化、非结构化、半结构化数据，以及BIM模型空间数据，采用多种数据库混合存储方案。采用业内成熟键值对内存数据库Redis缓存数据，文档、图片等选用开源MinIO[5]及云平台提供的对象存储服务（Object Storage Service，OSS），业务存储采用关系型数据库MySQL，考虑到工程数据复杂的关联关系，采用具备图数据库[6]特性的ArangoDB数据库，同时具备文档数据数据库特性。针对BIM空间数据，选用PostgreSQL+PostGIS以支持空间几何数据的存储。

服务层划分基础服务和应用服务，基础服务实现微服务架构基础组件，包括服务注册与发现组件、集中配置组件、消息队列等。应用服务主要实现业务功能，根据业务需求，工程数据管理平台具备项目管理、标准、主数据存储和管理能力，同时，可以将这些标准、数据发布成数据服务对外提供数据交换接口，提供数据服务能力。平台具备BIM三维服务能力，BIM模型文件的存储和转换为在线服务的能力，支持多种数据类型（Rvt、Dgn等）。其中，系统管理指是系统层级的管理功能，包括用户、组织机构、菜单、角色、权限、安全等方面。

各层服务经过统一的网关对外提供能力，同时，在网关层对访问的流量进行控制，安全控制。应用层，系统可以应用于桌面端，如Bentley、Revit等BIM软件进行数据生产和录入。同时，系统提供基于浏览器的Web端可视化管理平台，具备标准、项目、数据、服务的管理能力，以及系统层级的运维管控能力。

2.2 服务拆分

服务拆分需要遵守一些原则，原则一是定义类的职责时，应该遵循单一职责原则（Single Responsibility Principle，SRP），即设计小的、内聚的、仅仅含有单一职责的服务，以提升服务的稳定性。原则二是把类组成包时，应该遵循闭包元组（Common Closure Principle，CCP），如果由于某些原因，两个类的修改必须耦合先后发生，那么就应该把它们放到同一个包内。

根据上述原则，将系统划分为八个主要的微服务（如表1所示）。

按照上述服务划分，各微服务之间拓扑关系如图2所示，外层为微服务基础服务组件，包括认证服务注册与发现服务以及API网关;内部为九个核心的业务服务。每个微服务使用各自独立的数据库。

⑴ 服务间通信

工程数据管理平台各微服务之间通信方式，选用同步和异步相结合的通信方式，如图2所示，采用基于HTTP协议的REST API进行同步通信，以及基于消息队列的消息事件处理器（消息发布、消息接收）进行异步通信。针对服务之间业务复杂度低，特别是一般的数据查询操作的业务场景，使用同步通信机制以JSON格式进行，例如，实例数据服务需要获取元数据服务中定义的数据模型结构、字段等信息。针对耗时较多的处理，如果使用同步方式，容易造成阻塞或超时，这种情况一般使用异步通信机制，选用消息队列进行消息的分发，例如，将项目切换为发布状态时，需要通知数据服务，生成项目下对应的服务实例。

针对客户端与服务器之间一对多交互的业务场景，仍然采用基于消息队列的异步通信机制，由事件生产方发送消息，各响应方订阅该消息，并执行相关操作。

⑵ 微服务数据聚合

微服务架构相对传统架构而言，业务对象数据通常会分散到各个微服务中，一个次数据请求可能跨越多个服务，数据经过多个服务返回后聚合成最后的结果。例如，项目与服务之间的关系，数据服务中每条服务信息包括所属的项目名称，由于只在数据服务的数据库中存储了项目唯一标识Project ID，每次查询服务信息需要调用项目服务获取项目名称，才能获取Project ID对应的详细信息，响应存在延迟，并且不利于分页查询。为了聚合分散的数据，提升系统的响应性能，有两种方案：①微服务之间通过关联的唯一ID进行数据关联，并且冗余一些项目的部分基础信息;②在调用项目服务后对数据进行本地缓存，服务直接对缓存的数据进行读取提升服务性能。

经过分析后，考虑到这类数据更新频率不会太高，故选用第一种方案，在数据服务的数据库设计上冗余项目基本信息。然而，这种方案存在项目信息更新后，数据服务中数据库数据不一致的问题。为了避免数据不一致的问题，采用消息队列，当项目服务需要对项目基本信息进行更新的时候发一个更新消息，数据服务订阅这个主题消费，并更新相关数据，从而避免数据错误，使数据最终一致。

⑶ 分布式事务

在微服务架构下每个服务使用独立的数据库，一次事务可能涉及到多个服务之间的数据库操作。根据CAP理论，在现实的网络环境下，服务之间通信存在时间差，数据会出现不一致的情况。为了达到分布式环境下数据库的一致性，有一些常见的分布式事务[7]方法，主要分五种：XA分布式事务、2PC（2PC，two-phase commit）、基于事务补偿的TCC（Try、Confirm、Cancel）、基于消息队列以及Saga。相比其他的事务方法，Saga更适合管理微服务架构下的事务，它由一连串的本地事务组成，每个本地事务负责更新它所在服务的私有数据库，这些操作仍旧依赖于ACID事务框架和函数，然而，Saga缺少ACID事务中的隔离性，此外，由于每个本地事务都提交了其更改，因此需要采用补偿事务回滚Saga。

在工程数据管理平台系统中，采用基于消息队列（RocketMQ）的事务消息（Transaction Message）和Saga相结合的事务机制。对于一般类型的数据交互，我们使用事务消息确保各个服务之间的数据一致，对应关键性数据场景，选用Saga进行事务操作，为解决Saga的事务缺少隔离机制，需要在业务层采取对策（语义锁定对策[8]），确保执行事务中的数据不可见或不可操作。

2.3 监控与运维

微服务架构网络层次多、技术复杂，这导致追踪业务请求、排查错误相比单体应用复杂度急剧上升。分布式调用链监控工具，可以监控那些横跨不同应用、不同服务器之间的关联动作，进而快速定位与解决故障[9]。

工程数据管理平台考虑到当前微服务数量，以及后续扩展，选用Spring Cloud Sleuth进行调用链数据记录，并使用分布式跟踪系统[10]ZipKin可視化系统调用链情况。其中，每个客户端请求会带上用户基本信息，包括用户ID，以及操作的项目ID。为了监控服务之间的调用性能，选用SkyWalking进行链路性能监控，通过其JVM代理非侵入式获取服务之间的拓扑结构，并监控每个外层请求的调用链，获取每个接口的响应时间。根据这些监控信息对系统进行优化与调整。

微服务架构下，每个服务独立开发演进，为了提升系统开发效率，快速集成至开发环境。采用Jenkins进行自动化部署[11]，持续向开发环境和测试环境集成，采用基于Kubernetes的容器管理平台Rancher，具备企业级多集群管理能力，方便服务资源调整、扩容和升级，提升微服务的部署效率。为了获取更详细的监控各服务之间的运行状态，选用Prometheus拉取每个服务的JVM信息以及请求的调用次数等指标数据，同时，设置健康检查与告警設置，当系统出现故障时，第一时间以邮件或短信的方式，通知运维人员排查问题。

3 研究成果

3.1 主数据管理

工程数据管理平台中，数据管理界面展示的是某个建管类项目引用建管标准后，对应生成的51个数据模型，包括主表和枚举表，如图3所示。

可以清晰预览每张数据模型的数据，如图4所示建管类项目下“方案信息”表对应的数据记录。

该建管项目对应的项目信息如图5所示，展示了项目的行业、类型以及状态等基本信息，同时，也统计出来项目下包含的数据模型数量、文件类型，即数据量的分布图。

3.2 监控与运维

工程数据管理平台微服务采用Rancher进行集中管理，如图6所示，每一个服务对应一个Deployment，其中，根据服务的访问量，扩充不同数量Pod，以提供系统的响应性能。

为了实时获取并监控服务的运行状态，采用Prometheus结合Grafana可视化的监控工具，监控每个服务在最近6个小时内的调用次数变化情况。

4 结束语

为了建设覆盖工程全过程的工程数据管理平台，本系统基于云平台，采用微服务架构，服务遵循单一职责原则、独立部署和轻量级通信等设计原则，本文从云平台、存储层、服务层到应用层对系统进行具体说明。针对服务拆分中涉及到的服务通信、数据聚合以及分布式事务等问题，着重说明了理论基础与解决方案。同时，在系统监控和运维层面提供可行方案。最终完成工程数据管理平台的实现与应用，经过实际生产实践，整个系统具备高可用、易于扩展的特性，可持续交付和持续集成，并易于监测和运维。

参考文献（References）：

[1] 王金锋，张业星，陈健等.水电全生命周期工程数据中心及其关键技术[J].水力发电，2014.40（8）：21-24

[2] Kratzke N， Quint P. Understanding cloud-native applications after 10 years of cloud computing-A systematic mapping study[J]. Journal of Systems and Software，2017.126：1-16

[3] 冯志勇，徐砚伟，薛霄等.微服务技术发展的现状与展望[J].计算机研究与发展，2020.57（5）：1103-1122

[4] 吴化尧，邓文俊.面向微服务软件开发方法研究进展[J].计算机研究与发展，2020.57（3）：525-541

[5] MinIO; MinIO， a Leader in High Performance Object Storage， Launches the MinIO Subscription Network Globally[J]. Computer Technology Journal. 2020.

[6] 于戈，谷峪，鲍玉斌等.云计算环境下的大规模图数据处理技术[J].计算机学报，2011.34（10）：1753-1767

[7] 方意，朱永强，宫学庆.微服务架构下的分布式事务处理[J].计算机应用与软件，2019.36（1）：152-158

[8] Frank L， Zahle T U. Semantic ACID properties in multidatabases using remote procedure calls and update propagations[J].Software-Practice and Experience，1998.28（1）：77-98

[9] 李文海，彭鑫，丁丹等.基于日志可视化分析的微服务系统调试方法[J].计算机科学，2019.46（11）：145-155

[10] Sigelman B H， Barroso L A， Burrows M， et al. Dapper， a Large-Scale Distributed Systems Tracing Infrastructure[Z]，2010.

[11] 蔡永健，路云菲，邬远祥等.基于Jenkins和Docker容器技术在数字化电站项目自动化部署的研究及应用[J].计算机时代，2020.2：77-80