基于“微服务架构”的油气田业务系统集成技术研究

基于“微服务架构”的油气田业务系统集成技术研究

韩光谱 ,任玉清 ,邓松 ,沈群 ,赵勇

中国石油西南油气田分公司重庆气矿，重庆，400021

摘要：文章从某国内天然气开发生产企业诸多业务应用系统面临的主要管理问题入手，主要研究“微服务”信息技术，并提出从用户认证、权限管理、流程服务、数据、业务功能等几个方面，对诸多应用系统的进行集成的优化策略。

关键词：微服务架构；用户认证；数据共享；应用集成

引言

在不同时期、不同信息技术条件下，该天然气开发生产企业配套建设了诸多业务应用系统，涵盖了地质、开发、管道、生产运行、QHSE、销售、分析化验等核心业务，在生产经营管理中发挥着重要作用，但在气田管理数字化转型和信息化技术飞速发展的今天，使用和运维上的问题凸显。尤其是用户认证管理、业务数据共享、各类应用集成这三个方面亟待改善。重新开发相应的系统，资金压力需求太大，因此需要从信息技术上另辟蹊径，实现应用系统的集约化管理。

1 信息系统管理亟待解决的问题

1.1用户认证管理

体现为多系统管理难度大、登录繁琐。形成原因：各业务部门按自身用户需求设计，缺少认证管理层面的总体规划。导致各系统自成体系，用户交叉重叠，基层单位用户要同时使用各部门的信息系统，需要多处登录，用户体验差，制约工作效率提升。

1.2业务数据共享

   体现为缺乏数据共享通道、同类数据不一致。形成原因：业务部门按自身业务需求设计，缺少数据管理层面的总体规划。导致各系统的数据独立建库和存储，数据模型缺乏全局性的统一数据标准；数据来源的入口、时间、周期不一致；无统一标准的数据接入、接出规范。这些问题导致了业务数据共享性差。

1.3应用集成

体现为业务应用分散、功能模块重复、更新维护难度大。形成原因：业务部门按自身业务需求设计，缺少业务管理层面的总体规划。各业务的管理需求不尽相同，但也有相同的部分，导致开发的应用分散在各系统中；内部业务审核流程重复性开发，用户需要多系统切换操作，应用效率低；各信息系统系统架构各异，开发标准体系新老并存，维护困难，升级困难大。

2 微服务架构技术应用的可行性分析

微服务架构模式（Microservices Architecture Pattern）区别于传统的软件架构，它是一种为了适应当前互联网后台服务的「三高需求：高并发、高性能、高可用」而产生的的软件架构。其目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以进行局部改良。具有反馈迅速、构建更快、可靠性更高等特点，可以将一个完整的服务进程分解为多个不同的独立服务[1]。微服务是由单一应用程序构成的小服务，拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

微服务架构均具备以下几个优点：

松耦合：微服务之间通过非具体实现的接口及非专有通信协议进行通信（比如REST），原接口不改变，对用户不会造成任何影响。

数据的有效控制：一个微服务对其数据结构和数据源拥有绝对的控制权，只有该服务才可以对数据做出修改，其他微服务只有通过该服务才能够访问数据。因此，该服务可以很方便地对所能提供的数据进行有效控制。

独立的更新维护：每个微服务都可以在不影响其他微服务的情况下进行编译、打包和部署，满足快速部署上线能力可以让用户需求尽早实现。这是单体架构应用所无法做到的。

应对用户需求的多样性：微服务架构可以轻松应对不同客户的特殊需求，通过定义良好的接口，让不同的微服务承担不同的职责。

更高可用性和弹性：微服务架构可以认为是一个去中心化的应用，每一个微服务都可以随时上线或下线。当某个微服务出现问题时只需要将其下线，由其他同类型的微服务承担其功能，对外仍旧可以提供服务，不会造成整个服务无法正常工作。

可见微服务架构技术优点与“认证+服务+数据+应用”的一体化的企业业务管理信息平台建设需求完全契合。

3油气田业务系统集成平台微服务架构

油气田业务系统集成平台应满足功能可灵活扩展、性能可弹性伸缩、系统可快速迭代发布的要求[2]。按照微服架构设计理念，需要对油气田各业务系统服务进行二次开发，构建认证、用户、权限、流程、数据等微服务。微服务作为原子级服务，用于建设平台的用户、权限、模块的管理体系。平台总体架构设计图见图1，微服务治理图见图2

图1 总体架构设计

4 微服务治理的内容及原则

微服务治理内容：进行充分调研后，在该企业相关应用系统的基础上，建立油气田业务系统集成平台，需要开展架构体系设计和微服务设计。

架构体系设计

微服务设计包含认证微服务、用户微服务、权限微服务、应用微服务、流程微服务、消息微服务、日志微服务、数据微服务，基于这些微服务实现系统集成平台的管理和集成功能。

治理的原则：

先少后多（微服务数量）、先粗后细(粒度)

基于业务逻辑进行拆分（用户群体、业务领域等模型）

基于可靠性（核心模块独立化、主次链路隔离）

基于性能拆分（独立拆分高性能场景）

接口需保证幂等

接口数据定义严禁内嵌，透传

规范化工程结构，符合微服务风格

不止对计算服务记性拆分，服务层 -> 缓存层 -> 数据层 的逐步拆解，才能发挥最大功效。

图2 微服务治理内容

5 主要微服务的实现策略

5.1认证服务

现有各业务系统都开发了专用登录模块，认证方式互不认可，各系统需要逐一手工登录，改造各业务系统认证服务，建立统一认证微服务，以用户均具备的统一身份信息作为认证为基础，采用OAuth2.0+SSO技术，基于开源IdentityServer进行构建，实现面向各层级用户的统一认证和单点登录服务。用户通过客户端调用认证微服务，获取访问令牌，实现用户统一身份认证。认证流程见图3

图3 认证流程

用户：使用已注册的客户端访问资源的人。

客户端：从server请求令牌的应用请求，既可以通过身份认证令牌来验证识别用户身份，又可以通过授权令牌来访问服务端的资源。客户端在申请令牌前需要在server服务中注册。

资源：通过访问要获取的信息，可以是用户的身份数据或者api资源。

身份令牌：对认证过程的描述，它至少标识某个用户的主身份信息、该用户的认证时间和认证方式。身份令牌还可以包含额外的身份数据。

访问令牌：允许客户端访问某个 API 资源。客户端请求到访问令牌，然后使用这个令牌来访问 API资源。

5.2用户服务

构建以用户、组织机构、岗位三位一体的联动机制，为其它微服务或三方应用提供用户、组织机构、岗位管理的 Restful接口，实现用户注册、调岗、查询、注销等功能。

Restful接口使用 http 协议和 url，利用 Client/Server模式对资源进行 增删改查，通过一套统一的接口为 Web，IOS 和 Android 提供用户服务。

5.3权限服务

基于角色的访问控制(RBAC)，是将系统访问限制为授权用户的一种方法，是围绕角色和特权定义的与策略无关的访问控制机制，RBAC的组件使执行用户分配变得很简单[3]。

因此需要基于角色的访问控制(RBAC)，建立统一的权限微服务。根据实际生产过程中的岗位责任制形式，开发“用户-岗位-角色-模块-数据”五位一体权限模型，形成分层授权、逐级传递的权限管理模式。

根据“用户-岗位-角色-模块-数据”五位一体权限模型，为企业内部的各种职务创建角色、权限的层级；通过职务在不同系统中的角色（一个或多个角色）来决定获取权限的层级。

角色的访问控制定义的三个主要规则：

1、角色分配：仅当对象已选择或分配了角色时，对象才能行使权限。

2、角色授权：必须为主体授权主体的活动角色。使用上面的规则1，此规则可确保用户只能承担获得其授权的角色。

3、权限授权：仅当对象的活动角色被授权时，对象才能行使权限。使用规则1和2，此规则可确保用户只能行使其被授权的权限。

5.4流程服务

建立油气田业务处理流程微服务，用户通过自定义配置，实现流程的自动化处理，为业务应用提供统一的流程消息推送、流程审批等相关服务。基于Activiti（开源）流程引擎，遵循BPMN2.0国际标准，利用springboot集成activiti，实现activiti的微服务化。

建立流程：

1、对springboot和activiti进行整合，引入指定pom索引，包括activiti的模型编辑插件activiti-moleder的整合和简单修改；

2、添加eureka-server和zuu，使用feign对activiti的API对外提供访问，实现流程流转，以Restful接口的方式对外提供，实现activiti的微服务化；

3、实现节点的自定义表单。

5.5日志服务

日志中心作为一套基础服务，基于ELK体系进行搭建，具有日志采集、日志存储、日志分析、数据输出等功能，实现对用户行为和数据使用情况的采集与分析功能，面向应用提供标准化的Restful风格的服务接口，同时面对不同开发语言提供相应的SDK，例如JS-SDK、Java-SDK。日志服务应满足以下三点要求：

1、业务应用故障定位溯源。基于日志埋点机制，详细记录日志数据，用于快速故障根源定位、调试信息查看、运行效率查看、实时监控IT环境运行状态，分钟级定位故障根源，提升IT管理人员工作效率。

2、全业务链运行态势洞悉。面向用户访问及操作的全周期，实时自动化日志采集与存储。根据对应记录数据，全方位分析用户使用的习惯，例如访问路径、查询条件、关注业务内容（模块、报表、曲线……），并构建维度化分析模型，从业务模块维度、用户访问维度、访问链路维度、业务垂直维度等多个维度，洞悉用户使用业务应用过程中的全业务链运行态势。

3、应用安全态势感知与监控。基于统一的环境变量体系，结合用户、应用、权限等中心，唯一化每条日志的出处，通过对应用日志数据进行统一处理分析，实现对网络攻击行为、数据安全事件等安全问题的发现和告警，打造安全可监控和威胁可感知的安全能力。

5.6消息服务

基于开源ActiveMQ消息中间件构建，具备消息的接收、存储、转发及管理能力，能够将各类消息以短信、邮件、APP通知等方式进行推送。消息服务应满足以下三点要求：

1、主题管理。对主题的基本信息维护及管理操作，主要包括主题创建、主题订阅、主题查看等功能，消息生产者与消息消费者通过消息中心管理网站平台订阅消息。

2、消息管控。通过搭建分布式、集群、微服务框架，基于请求调度、消息缓存等技术，实现消息高并发、高响应的能力，最终将应用消息以微信、短信、邮件、APP通知等方式推送到组织与用户的各个终端。

3、策略管理。为消息发送提供定时、定量、支持不同载体的策略制定规则，针对特定用户制定策略时，提供红名单规则，遵循红名单>功能>模块>应用的策略执行原则，满足不同应用在各种场景下的消息发送策略。

5.7数据服务

构建数据微服务，提升与数据库的交换能力，作为数据访问服务层，支撑其他微服务的数据应用。基于Mybatis框架，围绕业务应用对结构化数据的查询、回写等需求，开发Restful风格的数据接口，满足在线定制、集中管理、授权共享、安全访问以及调用操作日志记录等数据管理功能。

建立服务接口的动态注册和发布功能；建立接口授权机制，建立数据操作日志记录；建立针对数据缓存的数据接口配置机制，提高数据访问效率；建立数据操作的过滤和检测机制，避免sql注册攻击，确保数据安全。数据服务技术架构见图4

图4 数据服务技术架构

6结语

微服务架构的技术特点能够解决油气田业务信息系统管理和应用面临的三方面核心问题。利用该架构技术建立新的一体化业务管理信息平台，可以打破单体架构、垂直架构、分布式架构等不同架构业务系统间的壁垒，为用户提供一站式的认证、登录、授权及业务资源分配能力，打造高效、经济、实用的业务协同环境，形成“集中、集成、协同、共享”的信息化管理模式。

在开展业务信息系统集成前，应充分调研每个系统的用户群、业务模块、应用、服务、数据库，结合每个系统的原始开发文档，编制集成平台的用户群、角色、权限、业务需求、应用层、服务层、数据处理层的顶层设计和技术实现的详细设计；调集所有业务部门管理人员进行设计内容的完整度、可行性的审查。

参考文献：

[1] 克里斯·理查森 著,喻勇 译.微服务架构设计模式[M].机械工业出版社，出版年：2019起止页码．

[1] 冯志勇,徐砚伟,薛霄,陈世展.微服务技术发展的现状与展望[J].计算机研究与发展, 2020, 57(5): 1103-1122。

[2] 肖荣,高全亮.基于微服务架构的智慧景区平台关键技术研究与应用[J].计算机时代,2019(04):44-47。

[3] 余杨奎.基于角色的访问控制模型(RBAC)研究.计算机技术与发展,2019,1:98-201。

作者简介：

第一作者：韩光谱，男，1979年01月15日，汉，陕西长安，空军工程大学导弹学院计算机与技术专业，工程师，中国石油西南油气田分公司重庆气矿