基于微服务架构的水资源数据接口设计与实现

樊启萌，姚华明，汤正阳，杨 旭，张玉柱，赵牧晨

(1.三峡水利枢纽梯级调度通信中心，湖北 宜昌 443002； 2.智慧长江与水电科学湖北省重点实验室，湖北 宜昌 443002)

随着梯级调度业务持续发展，三峡水利枢纽梯级调度通信中心积累了气象、水调、电调等多业务系统，各系统相对独立，数据也较为分散。受建设时期、业务模式等因素制约，整体缺乏统一的设计标准，开发平台、开发语言各有差异，信息交互共享困难。为满足水资源研究、展示数据需要，实现信息共享与交互，加之配合长江电力公司Paas云平台化建设，基于微服务架构形成一个通用的水资源数据接口服务，具有重要意义。

1 系统架构

应用系统架构经过近10 a发展沉淀，逐渐由单一发展至分布式发展，由功能化至服务化，经历了从单一应用架构(ORM)到垂直应用架构(MVC)、分布式服务架构(RPC)、流动计算架构(SOA)及微服务架构(MSA)的演化历程(图1)。

图1 系统架构演化示意Fig.1 System architecture evolution

1.1 系统架构演化历程

早期系统以单体应用为主，即所有功能集中部署的高内聚版本。随着业务的复杂化，单体应用逐步被MVC架构替代，业务被拆分成视图层、控制层、逻辑层、数据访问层、数据存储层。MVC架构解决了前后端、界面、控制逻辑和业务逻辑分层问题，系统具有模块化的特点，便于二次开发与维护，但是仍存在不同应用之间的通信与交互问题。进一步考虑将核心和公共业务抽取形成单独服务，以解决模块之间跨进程通信的问题。结合公司开放能力云平台建设，系统架构随业务需求迭代演化，最终实现了统一服务生命周期管控及较好的服务治理。综上所述，推出了全面支持微服务的开发框架[1]，采用微服务架构和平台轻量级容器技术(Docker)、云计算资源相结合，可将高度耦合的功能分解到各个离散的微服务中以实现对应用系统的解耦[2]，是更好提升系统持续集成和扩展能力的解决方案。

1.2 基于容器云的MSA架构

微服务是一种软件架构的设计风格，整个软件服务架构由多个微服务构成[3]，微服务架构实际上是SOA架构样式的变体，提倡将单一应用程序划分为若干单独的服务，每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制。每个微服务可以独立编译、部署、运行。微服务是在信息技术下完成分散大系统的建构，运行过程中为高度相对独立状态，也能够有效实现自治[4]。微服务架构理念为敏捷开发, 在微服务架构的基础上研究电力服务平台, 可以最大限度地简化服务, 同时能够对现有的电力业务不产生任何影响[5]。在微服务运行过程中，微服务性能受运行环境影响，云计算平台的出现和发展为微服务提供了方便快捷的运行环境。在云计算平台下，所有的软硬件资源(包括网络、服务器、存储、应用软件、服务)统一在资源池中，用户按需取用，大大减少了资源管理工作开销。常见云服务模式有3层，分别是IaaS(基础设施即服务)层、PaaS(平台即服务)层和SaaS(软件即服务)层。IaaS层为用户提供计算、存储、网络等基础资源；PaaS层为用户提供应用程序部署和管理服务；SaaS层提供用户使用的软件系统。近年来，容器化技术广泛应用到云计算中，容器云以容器作为资源分割和调度的基本单位，进行软件开发和部署，最后将容器制作成镜像交付用户，用户无需关注开发和部署过程，就能具有更好的性能、更快的部署和发布速度。

容器镜像类似于文件系统的分层机构，而从镜像运行容器会在该镜像顶部加载一个可读写、初始值为空的文件系统，称为容器层[6]。利用云计算提供的微服务环境构建软件的开发、部署和运行环境，同时利用先进 Web 技术实现软件的 Web 化将是云计算环境下软件的发展方向和趋势[7]。Docker是一种常用的容器技术，因其轻量化、高性能、跨平台等优点而被广泛运用，Kubernetes是一个基于Docker实现的容器编排系统。Docker和Kubernetes是构建开放平台基础设施的核心技术。基于容器云的开放平台基础设施可以实现基础资源的复用，一体化部署及统一的服务治理，优化微服务程序的部署方法，同时也可以实现更灵活的云资源弹性扩展和回收。

2 数据接口功能设计与实现

目前，水资源研究业务涉及数据主要来源于梯调水库调度数据库，在此基础上，先后开发过移动查询、可视化、决策支持等系统，系统多采取单体应用或垂直业务架构，各系统之间独立，数据无法共享。现考虑将前期各系统数据接口整理、分类、重构为微服务架构的接口服务。

2.1 业务系统微服务架构改造

整体改造方案对各业务系统进行松耦合及拆分，提取公用数据服务并进行分类实现。业务系统微服务架构改造设计见图2。

图2 系统微服务架构改造设计Fig.2 System microservice architecture rebuilding design

2.2 接口功能设计

按业务需求，接口服务可划分为管理数据接口、水文业务接口、基础数据处理接口三大类。① 管理数据接口主要包括登录验证等功能；② 水文业务接口主要包括实时数据、小时数据、日数据、旬数据、月数据、年数据、计划数据、预报数据、决策系统模拟计算水位、流量结果数据、水库模拟仿真计算数据、规则模型参数数据等；③ 基础数值计算接口提供拟合、插值、曲线查询等功能。水资源数据接口功能总体设计见图3。

图3 水资源数据接口功能总体设计Fig.3 Overall design of water resource data interface function

其中，实时数据接口，包括通用实时数据查询、通过电站编号获取电站实时机组出力信息、实时水位数据查询、实时流量数据查询、实时出力数据查询等获取实时数据。计划数据接口，通过点号和电站号获得最新计划出力信息。小时、日、月、旬、年等数据接口，涵盖水文、电力、气象等各时段数据信息。预报数据接口，包括流量预报信息、演进后预报信息、气象雨量预报信息。基础数值计算接口，包括多项式拟合、常量拟合、带截断的线性拟合、一般线性拟合、线性内插、三次多项式插值、三次样条插值以及曲线查询、水文频率查询等方法。

2.3 技术路线

资源数据接口服务程序采用微服务+容器云的技术路线。微服务单独部署并在注册中心进行注册，网关中心为微服务提供入口，实现路由和过滤功能。数据层采用Mybatis Plus框架，实现数据库的持久化操作以及查询、统计、计算等操作。数据服务层采用Spring Boot框架，Spring Boot可用于多层架构体系的模型业务层, 对于上层其可以有效地屏蔽底层数据库操作, 提高低层模块与高层模块之间的内聚, 降低多层模块间的耦合性, 具有分层模块化架构应用业务系统的优势[8]。通过业务需求逻辑对数据进行加工处理，形成最终业务数据，定义并发布1套标准的数据调用方式和接口。数据封装采用JSON数据格式。系统技术架构图如图4所示。

图4 水资源数据接口系统架构Fig.4 Water resource data interface system architecture

接口安全验证采用基于HMAC的验证方式。其主要设计是在请求头中使用两个字段：access-key和Date(或Timestamp)，在API授权时为调用者生成access-key和access-secret，前者暴露在网络中，后者安全保存。当客户端调用API时，把自己的access-key填入Authorization头中，用自己的access-secret按照要求对request的headers/body计算HMAC加密后的secret。服务器拿到头信息后从数据库(或者缓存)中取出access-key对应的secret，按照相同方式计算HMAC，如果其与Authorization header一致，则请求合法；否则不合法。

基于HMAC加密的安全验证时序图见图5。接口开发完成后通过Yapi接口管理平台提供管理测试等功能。接口管理列表见图6。业务功能改造前后对比见图7。

图5 基于HMAC加密的安全验证时序Fig.5 Security verification sequence based on HMAC encryption

图6 接口管理列表Fig.6 Interface management list

图7 改造前后对比Fig.7 Comparison before and after improvement

3 服务治理

3.1 DevOps

3.1.1 持续集成

依托微服务平台持续集成功能，实现接口服务程序的一体化部署。本地调试完成后的交付jar包，在平台创建部署流水线，配置自定义项并生成容器配置文件，根据配置文件自动创建容器镜像，实现一键发布。

同时，此次发布构建的应用镜像发布到镜像仓库，实现了应用的统一管理。应用镜像发布后存储于镜像仓库中，满足应用一次构建、多次运行的需求。同时应用部署日志可查看，搜索及管理。通过配置域名管理，接口服务程序以域名对外提供访问。

3.1.2 镜像管理

发布的应用服务通过容器镜像的方式进行管理。微服务平台提供公有和私有两种方式镜像发布。公有镜像仓库集成了JavaWeb、Python、Nginx等常见应用环境；私有方式需要自定义Docker，发布到镜像仓库。

3.2 监控与链路管理

(1) 集群监控。包括集群的总体资源监控(包括CPU、内存、磁盘以及集群内建立的NS的资源使用情况)。

(2) 主机监控。包括主机的总体资源监控(包括CPU、内存、磁盘的资源使用情况)。

(3) 应用监控。应用成功发布后，PaaS监控大盘提供运行应用的监控数据。包括实时及历史24 h内，应用占用的CPU、内存、网络曲线。通过监控曲线，掌握应用资源占用情况。

(4) 变更大盘。PaaS变更大盘提供用户操作记录。用户操作生成变更单详细记录。变更单包括所有应用的变更，通过变更单可查看历史变动，同时根据变更回滚至相应版本。

(5) 链路管理。基于zipkin的服务间调用链路监控，展示调用延时、调用结果等信息。通过系统上下游的自定义埋点，可以监控整体系统链路的业务全貌。

3.3 配置中心

通过统一的配置中心实现了对分布式应用配置文件的统一管理以及对不同环境配置文件的管理及更新。通过配置中心，可以查看保持同步的实例的地址信息，在线维护配置文件。配置中心的配置文件与各环境镜像中客户端的配置文件保持同步。

4 结 论

本文提出了基于微服务架构的水资源数据接口服务的设计及实现方法，是解决通过网络传输数据和数据访问的重要方法之一，解决了现有系统之间数据无法共享、功能冗余的问题，实现了从单体应用到微服务架构、从传统部署到容器化持续集成的演变。

(1) 在业务功能方面。水资源接口服务涵盖水资源研究、展示所需大部分数据，并具备扩展性，对比改造前，各系统后台数据通过微服务统一管理，业务人员查看及调用更加便捷。

(2) 在服务治理方面，通过整合PaaS平台，系统具备持续集成、统一配置、完整链路监控日志的完善体系，具有较高的自动化运维水平和较低的运维成本，对比改造前，系统异常处理及日常运维效率有较大提升。

随着后期业务功能发展，在现有的设计方法和技术路线的基础上，系统功能还将有较大的改造和优化空间。