CN116389221A - 基于OGC API-Processes的云原生空间信息处理服务方法及装置 - Google Patents

Abstract

本发明公开了一种基于OGC API‑Processes的云原生空间信息处理服务方法及装置，通过依托OGC API‑Processes标准进行概念设计、执行模式设计，拓展所述OGC API‑Processes标准的服务接口；构建符合OpenAPI规范的空间信息处理服务平台架构；根据云原生技术体系，完善所述空间信息处理服务平台架构。因此，本发明实施例能够以RESTful API的形式提供空间信息处理服务，并支持分布式云端自动化部署及管理，从而以一种更简洁、现代的方式支持地学处理模型的共享及互操作，以提升空间信息处理服务在复杂网络空间下的运维效率。

Description

基于OGC API-Processes的云原生空间信息处理服务方法及 装置

技术领域

本发明涉及地理信息服务技术领域，尤其涉及一种基于OGC API-Processes的云原生空间信息处理服务方法及装置。

背景技术

地学领域的扩展及海量空间数据的涌现，不断衍生出大量多源异构的空间信息处理算子或模型，而Web已成为其共享与集成的重要环境。开放地理信息联盟OGC已提出空间信息处理服务(WPS)标准，以规范化的形式在Web环境共享空间信息处理功能。WPS标准为网络服务中的执行过程提供了一个健壮、可互操作且通用的协议，针对该协议已有众多开发实现，但大多基于传统SOA架构，由于通信协议、数据编码等原因，该架构不断暴露出冗余弊端，已不足以应对日益开放的Web环境。基于此，OGC正在制定Processes API开放标准，致力于通过轻量化的接口和网络协议实现空间信息处理服务，但该标准正处于制定阶段，暂未大规模应用，且该标准制定的服务接口并不完善，缺乏定制化、可扩展的服务集成方案。

发明内容

本发明提供一种基于OGC API-Processes的云原生空间信息处理服务方法及装置，以解决现有技术中Processes API开放标准存在服务接口不完善，缺乏定制化、可扩展的服务集成的技术问题，通过云原生技术体系，完善OGC Processes API开放标准存在的技术问题，能够以RESTful API的形式提供空间信息处理服务，并支持分布式云端自动化部署及管理，从而提升空间信息处理服务在复杂网络空间下的运维效率。

为了实现上述目的，第一方面，本发明实施例提供了一种基于OGC API-Processes的云原生空间信息处理服务方法，包括：

依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；

构建符合OpenAPI规范的空间信息处理服务平台架构；

根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

作为上述方案的改进，所述根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率，具体包括：

将所述空间信息处理服务平台与容器进行虚拟化映射，通过容器编排实现所述空间信息处理服务平台的自动化部署与管理；

使所述空间信息处理服务平台的内核适配于微服务架构；

执行所述空间信息处理服务的过程采用DevOps风格，以实现快速部署和持续交付。

作为上述方案的改进，所述依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口，具体包括：

设计空间信息处理过程Process和所述空间信息处理实例化Job对象之间的关系，对所述Job对象进行管理与监控；

设计简单类型数据的值传输模式，以及复杂类型数据的引用传输模式；

将运行时间较短的处理过程设为同步模式服务执行序列；将运行时间较长的处理过程设为异步模式服务执行序列；

设计服务接口，以实现服务发现、服务描述、服务执行、服务管理；

拓展所述OGC API-Processes标准的服务接口，以供用户将本地处理算子自动化注册到服务目录；

其中，所有的服务接口均为RESTful接口，符合REST的约束条件与设计准则；所述OGC API-Processes标准的服务接口为定制化算子服务发布接口。

作为上述方案的改进，所述构建符合OpenAPI规范的空间信息处理服务平台架构，具体包括：

定义所述空间信息处理服务的标准化、与实现语言无关的接口描述，使所述空间信息处理服务符合OpenAPI规范；

制定数据层、算子库、Process Engine、Job管理中心和访问接口模块，完善空间信息处理服务平台架构。

作为上述方案的改进，所述将所述空间信息处理服务平台与容器进行虚拟化映射，通过容器编排实现所述空间信息处理服务平台的自动化部署与管理，具体包括：

将所述空间信息处理服务平台和地学算子的运行依赖环境均封装于容器的镜像中；

建立预定义文件，通过容器编排工具对容器运行的行为和交互方式进行干预，实现所述容器的镜像中所述空间信息处理服务平台的自动化部署与管理；

其中，所述容器包含完整运行时环境，以实现一次构建、任意部署。

作为上述方案的改进，所述使所述空间信息处理服务平台的内核适配于微服务架构，具体包括：

设置自动化注册组件，将所述空间信息处理服务平台注册到微服务架构的服务注册中心，作为服务提供者提供处理功能服务；

构建所述服务提供者、服务注册中心、服务消费者的核心模块，实现服务自动化注册与发现；

预置负载均衡策略，以实现服务消费过程中的客户端负载均衡。

作为上述方案的改进，所述执行所述空间信息处理服务的过程采用DevOps风格，以实现快速部署和持续交付，具体为：

所述空间信息处理服务平台开发实现全过程均采用DevOps风格，使开发、部署、运营维护流程高效自动化，能够支持快速部署和持续交付。

作为上述方案的改进，所述空间信息处理服务，具体为：

将多源异构的空间信息处理算子或地学处理模型，发布为Web处理服务；其中，所述空间信息处理算子或地学处理模型，包括单元算子和组合模型。

作为上述方案的改进，所述方法还包括：

建立所述空间信息处理服务的整体系统架构，进行所述空间信息处理服务的技术选型与开发实现。

第二方面，本发明实施例提供了一种基于OGC API-Processes的云原生空间信息处理服务装置，包括：

标准化制定模块，用于依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；

构建平台架构模块，用于构建符合OpenAPI规范的空间信息处理服务平台架构；

完善平台架构模块，用于根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

与现有技术相比，本发明实施例公开的一种基于OGC API-Processes的云原生空间信息处理服务方法及装置，通过依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；构建符合OpenAPI规范的空间信息处理服务平台架构；根据云原生技术体系，完善所述空间信息处理服务平台架构。因此，本发明实施例能够以RESTful API的形式提供空间信息处理服务，并支持分布式云端自动化部署及管理，从而以一种更简洁、现代的方式支持地学处理模型的共享及互操作，以提升空间信息处理服务在复杂网络空间下的运维效率。

附图说明

图1是本发明实施例提供的一种基于OGC API-Processes的云原生空间信息处理服务方法的流程示意图；

图2是本发明实施例提供的一种基于OGC API-Processes的云原生空间信息处理服务装置的结构示意图；

图3是同步执行模式序列图；

图4是异步执行模式序列图；

图5是定制化算子服务发布机制示意图；

图6是基于OGC API-Processes的云原生空间信息处理服务平台架构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，本发明的术语“包括”和“具体”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，云原生是一种构建和运行应用程序的风格，旨在从程序设计之初就考虑其云端部署特性，主要包含容器化、微服务、DevOps等要点。其中容器是一种操作系统级的虚拟化技术，可将应用程序打包至轻量化容器单元，实现一次构建、任意部署；微服务架构是将独立系统拆分为多个小型服务，从而实现灵活运维；DevOps则是指打通开发与运维之间壁垒，对产品进行迭代式开发，借助自动化工具实现快速部署、持续交付。由于轻量化、灵活性高、扩展性强等特点，云原生技术体系已成为各类应用云端部署的热门方案。

请参阅图1，图1是本发明实施例提供的一种基于OGC API-Processes的云原生空间信息处理服务方法的流程示意图，该基于OGC API-Processes的云原生空间信息处理服务方法，包括步骤S11至S13：

S11：依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGCAPI-Processes标准的服务接口；

S12：构建符合OpenAPI规范的空间信息处理服务平台架构；

S13：根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

作为一个优选实施例，上述S13步骤，具体包括：

S131：将所述空间信息处理服务平台与容器进行虚拟化映射，通过容器编排实现所述空间信息处理服务平台的自动化部署与管理；

S132：使所述空间信息处理服务平台的内核适配于微服务架构；

S133：执行所述空间信息处理服务的过程采用DevOps风格，以实现快速部署和持续交付。

作为一个优选实施例，上述S11步骤，具体包括：

设计空间信息处理过程Process和所述空间信息处理实例化Job对象之间的关系，对所述Job对象进行管理与监控；

设计简单类型数据的值传输模式，以及复杂类型数据的引用传输模式；

将运行时间较短的处理过程设为同步模式服务执行序列；将运行时间较长的处理过程设为异步模式服务执行序列；

设计服务接口，以实现服务发现、服务描述、服务执行、服务管理；

拓展所述OGC API-Processes标准的服务接口，以供用户将本地处理算子自动化注册到服务目录；

其中，所有的服务接口均为RESTful接口，符合REST的约束条件与设计准则；所述OGC API-Processes标准的服务接口为定制化算子服务发布接口。

在本实施例具体实施时，所述空间信息处理过程Process既包括GIS软件中常用的执行功能，也包括某些时空和仿真的专用模型，既可以是简单且快速执行的同步操作，也可以是复杂耗时的异步操作。

由于空间数据结构复杂、数据量通常较大，并且地学领域各学科分支众多、问题繁杂，导致空间信息处理过程通常结构各异且耗费资源，因此对其设计主要聚焦于执行过程的实现。所述Job对象是对特定处理过程的执行而创建的服务器端对象，它在不同的执行模式中具有不同的可见状态，比如在同步执行中是隐性，而在异步执行中则为显性。每个Job对象都具备唯一的ID值，用以实现在客户端对其监控和管理。

所述空间信息处理服务概念设计包括两方面：一是Process的发现和对其描述信息的请求，每个Process都由唯一标识符进行区分，并具备完整的描述信息，比如标题概述、详细描述、版本信息、支持的执行模式、输入输出数据描述等；二是通过服务接口实现对Job对象的管理和监控，每个Job对象均具有全局唯一标识符jobID，同步执行模式下该jobID为隐性存在，异步执行模式下可通过jobID实现服务执行状态及执行结果的查询。

在空间信息处理服务执行过程中，对于原子数据或其他简单类型数据，可以直接通过值来传输；而对于矢量、栅格或其他复杂类型数据，不便于直接在HTTP报文中直接传递，则通过引用来进行传输，引用模式的实现需要借助网络数据服务，在网络空间下数据通过统一资源定位符(Uniform Resource Locator，URL)定位，客户端与服务器之间仅传输URL值，源数据则通过请求URL获取。

所述同步模式服务执行序列是指对于简单处理过程，客户端与服务器之间建立持久连接，服务调用后，客户端向服务器提交执行请求，并持续监听其响应信息。与此同时，服务器隐式地创建Job对象，接着调用Process对应的执行算子或处理模型，从而执行Job对象，执行完成后将处理结果返回客户端，结束整个请求过程。具体执行模式序列图请参阅图3。

所述异步模式服务执行序列是指对于复杂耗时的处理过程，客户端与服务器之间并不需要建立持久连接，服务调用后，客户端向服务器发送执行请求，服务器显性地创建Job对象，并直接将jobID返回给客户端，后续客户端通过该jobID实现对Job对象的管理和监控。服务器创建Job对象之后开辟新线程用于算子或模型执行，此时客户端可通过jobID查询执行状态，待线程运行结束，Job对象更新结果数据并刷新执行状态，之后客户端可以通过jobID请求结果数据。在Job对象执行期间，用户或客户端也可以通过Dismiss操作终止其执行。具体执行模式序列图请参阅图4。

具体的，所述服务接口包含描述性接口、Process管理接口、Job管理接口和定制化发布接口四部分，共11个服务接口。

其中描述性接口包含LandingPage、APIDefinition和Conformance三个接口，用于获取服务平台描述信息，不涉及具体执行逻辑；Process管理接口包含ProcessCollection和Process两个接口，分别用于提供服务平台的功能目录和单个处理服务的描述信息；Job管理接口包含Execute、Status、Result、JobList和Dismiss共五个接口，Execute接口用于执行具体处理服务并创建Job对象，Status接口用于请求执行状态，Result接口负责请求执行结果，JobList接口用于请求某个Process已执行过的所有Job对象列表，Dismiss接口用于停止Job对象的执行或删除历史列表中该对象的相关信息。

所述定制化算子服务发布接口是指对OGC API-Processes标准所做的扩展，供用户将本地处理算子自动化注册到服务目录。

请参阅图5，在服务平台启动状态下，用户访问相对应算子类型的发布接口，按照参数模板提交算子基本信息并向服务器上传算子可执行文件，其中算子基本信息包含算子标识符、标题信息、算子简单描述、输入输出描述信息等，可执行文件包括执行脚本、已编译模型、动态链接库、应用软件包等。服务器依据用户提交的信息自动化生成配置文件，其中记录该处理算子所涉及的全部信息，包括算子可执行文件在服务器中存储的物理路径等，然后注册中心基于该配置文件向服务目录注册该算子服务。注册成功后，调用ProcessCollection接口即可在服务目录中看到该算子服务，并支持服务描述、服务执行等后续操作。

所述RESTful接口是指符合REST约束条件与设计准则的网络接口，它以资源为中心构建，将互联网中一切暴露给客户端的事物都视为资源，并通过URI唯一标识。一个完整的URI由以下几部分组成：协议、IP地址或域名、端口号、一段或多段文件路径以及查询字符串。本发明所述接口均设计为RESTful接口，通过URI进行访问。

作为一个优选实施例，上述S12步骤，具体包括：

定义所述空间信息处理服务的标准化、与实现语言无关的接口描述，使所述空间信息处理服务符合OpenAPI规范；

制定数据层、算子库、Process Engine、Job管理中心和访问接口模块，完善空间信息处理服务平台架构。

在本实施例具体实施时，所述接口描述是指在接口设计基础之上，依托于OpenAPI规范设计接口描述信息，使得用户或计算机更便捷地理解和发现接口，本发明主要提供JSON格式的接口描述文档。所述处理服务平台架构主要包含数据层、算子库、ProcessEngine、Job管理中心、访问接口五部分：数据层由三部分元素构成，其中业务数据库用于Job对象相关信息的持久化和查询，空间数据服务用于在服务执行过程中通过URL提供复杂类型数据，算子元数据库主要用于存储服务平台中处理算子的描述信息。算子库主要用于存储处理算子实体文件，包括源码或可执行文件等形式，分别按编程语言或应用领域分为不同类型。Process Engine是服务平台的核心模块，用于实际执行算子库中包含的空间信息处理算子，有同步运算和异步运算两种执行模式。Job管理中心主要负责对服务执行后创建的Job对象进行管理，此模块由五部分组成。其中创建Job由客户端请求算子服务执行后触发，创建后为每个Job对象定义唯一标识符jobID；Job状态用于异步模式的算子服务执行之后，查询该算子服务执行状态；Job结果用于请求Job对象的运算结果；Job删除具备两种功能，一是停止正在运行的处理算子，二是在业务数据库中删除Job对象相关信息；Job列表用于查询某一算子服务已执行过的所有Job对象的列表。访问接口负责整个服务平台对外暴露的接口，均为符合OpenAPI规范的RESTful接口。

作为一个优选实施例，上述S131步骤，具体包括：

将所述空间信息处理服务平台和地学算子的运行依赖环境均封装于容器的镜像中；

建立预定义文件，通过容器编排工具对容器运行的行为和交互方式进行干预，实现所述容器的镜像中所述空间信息处理服务平台的自动化部署与管理；

其中，所述容器包含完整运行时环境，以实现一次构建、任意部署。

在本实施例具体实施时，所述容器的镜像是指Docker容器及镜像具有轻量化特点。Docker是目前应用广泛的容器虚拟化技术，它可将整个操作系统及其安装的软件环境都打包到Docker镜像中，从而为应用程序提供隔离性高、安全灵活的运行空间和资源。由于Docker容器是操作系统级的虚拟化技术，与底层宿主机共享系统内核，因此相比虚拟机的方式性能更加优良。通过Docker镜像对空间信息处理服务平台进行部署，将空间信息处理服务平台和其中处理算子的依赖环境均打包到Docker镜像，便可快速发布在任何机器。系统开发及运维人员仅需维护一个轻量级Docker镜像，便可实现“一次构建、任意部署”的效果，极大地提升了空间信息处理服务平台部署效率及资源利用率。

所述容器编排工具是指Docker官方提供的Compose容器编排工具，在借助容器实现平台部署的基础上，设置容器名称、端口映射、文件路径映射、启动命令等针对容器的管理指令，形成预定义文件，从而实现自动化启动容器并完成预设配置。除此之外，编排工具也可对多个容器进行管理维护，依据容器当前状态做出相应处理。由于直接与底层DockerAPI交互，Compose可以与Docker无缝衔接，因此可以在任何支持Docker的平台上运行，这也保证了该方法的普适性。

需要注意的是，容器内部仅包含依赖环境等静态资源，而空间信息处理服务平台部署于容器外部，两者的映射关系则在预定义文件中进行设定，因此容器编排对灵活、低耦合的平台部署至关重要。

作为一个优选实施例，上述S132步骤，具体包括：

设置自动化注册组件，将所述空间信息处理服务平台注册到微服务架构的服务注册中心，作为服务提供者提供处理功能服务；

构建所述服务提供者、服务注册中心、服务消费者的核心模块，实现服务自动化注册与发现；

预置负载均衡策略，以实现服务消费过程中的客户端负载均衡。

需要说明的是，所述微服务架构是把应用程序功能性地分解为一组服务的架构风格，属于模块开发的一种形式。微服务架构的主旨是将原本独立的系统拆分为多个小型服务，每个服务本质上是一个麻雀虽小但五脏俱全的应用程序，相互之间松耦合并且在各自独立的进程中运行，服务之间通过基于HTTP的轻量协议进行通信。被拆分的每个服务都围绕着系统中某项耦合度较高的业务功能构建，可通过全自动部署机制独立部署，整个微服务架构通常采用去中心化的服务管理方式，保持高内聚、低耦合特性，并且每个服务都维护着自身的数据存储、业务开发和自动化测试案例。

在本实施例具体实施时，微服务架构中包含服务提供者、服务消费者和服务注册中心三个核心组件，用以完成服务注册与发现。服务提供者将自身注册到服务注册中心，注册中心构建服务列表并暴露出去，服务消费者在服务列表中发现服务，通过服务名称发送请求来实现服务消费，以此实现基本的服务治理。同时，微服务架构中还可以构建客户端负载均衡、容错保护、服务网关等功能模块，用以提升安全性及运维效率。

在与微服务架构适配过程中，设计所述空间信息处理服务平台内核，将其自身当作微服务单元，并注册到服务注册中心，供其他用户或应用程序消费空间信息处理服务。由于空间信息处理算子或模型类型多样、结构各异，且通常面向不同的应用场景或领域，比如地质演变、气象分析等，故依据算子的类别或应用需求可同时构建多个处理服务平台，共同注册到微服务架构体系中，分别对其管理并应用。

所述客户端负载均衡是指每个客户端节点都维护着自身可访问的服务清单，在消费服务时，依据已配置好的负载均衡策略，从中选择合适的服务端并直接调用。所述服务清单由服务注册中心提供，其中包含着众多服务端的详细信息，在实际应用中，客户端要与注册中心相配合，以心跳检测的方式来保证服务清单的实时性与可用性。

在本发明实例中，同一类别的空间信息处理服务存在多个实例，同时在服务注册中心完成注册。客户端从注册中心获取服务清单列表，并在负载均衡器中进行配置，用户在请求服务时，直接依据服务名称进行访问，负载均衡器依据事先设定的负载均衡策略从多个服务实例中选取合适的一个，并将调用指令转发给服务实例，完成服务消费过程。客户端负载均衡器是一个功能组件，不需要独立部署，通常也可添加至服务提供者中。一般的负载均衡策略有轮询法、权重访问法和流量访问法等，用户也可以在负载均衡器中自行定义负载均衡策略。

作为一个优选实施例，上述S13步骤，具体为：

所述空间信息处理服务平台开发实现全过程均采用DevOps风格，使开发、部署、运营维护流程高效自动化，能够支持快速部署和持续交付。

在本实施例具体实施时，所述DevOps风格是指Development和Operations相结合，打破开发、测试与运维之间的壁垒，高效地组织团队通过自动化工具协作和沟通，来完成软件的全生命周期管理，从而更快速、更高效地交付更稳定的软件。

需要说明的是，所述云原生是一种应用程序开发风格，主要有两方面含义，一是指应用部署并运行于云中，而不是传统的数据中心；二是表示程序设计之初即考虑了云的特性，原生为云设计并以最佳姿态在云上运行。云原生一般包括三个要点：容器化、微服务及DevOps，采用Docker等开源堆栈将应用容器化，通过微服务提供灵活性与可扩展性，DevOps是指开发、测试、运维一体化，可支持持续迭代及自动化运维，三者共同促进云原生平台实现弹性伸缩、动态调度、优化资源利用率等目标。

GitLab CI/CD是一个集成在GitLab中的工具，通过持续集成、持续交付、持续部署的方法进行软件开发。其中持续集成的原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中；持续交付和部署相当于更进一步的持续集成，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。基于此，可以在应用程序开发早期发现漏洞和问题，从而确保部署到生产环境中的所有代码都符合预设的代码标准。

Spring Cloud是一个拥有多个子项目的大型框架集合，可被看作是微服务架构解决方案的综合套件，随着其中组件的扩展，它也逐渐加深了对云原生开发的支持程度。它以Spring Boot框架为基础，其中各个功能组件均基于后者实现。Spring Boot是Pivotal团队推出的轻量级Java应用框架，它以“习惯优于配置”为理念，通过设计大量自动化配置的方式来简化开发过程，使得用户可以快速构建应用。Spring Boot能很好地融入Docker容器，自身内嵌了Tomcat、Jetty等Web服务器，也支持RESTful API的生成，具备自动化配置、快速开发、轻松部署等优点，非常适合用作微服务架构中各项具体服务单元的开发框架。

在实际应用中，Spring Boot一般用于应用开发或解决微服务中某个具体问题，而Spring Cloud则是将其整合起来，形成一个综合性解决框架集合，它利用Spring Boot的开发便利性，巧妙地简化了分布式系统中各种功能组件的实现方法，比如配置管理、服务治理、断路器、智能路由、控制总线、数据监控、分布式会话和集群状态管理等，这些都可以利用Spring Boot的开发风格实现一键启动和部署。同时，Spring Cloud将诸多被广泛实践及证明过的框架组合起来，集众家所长，并且屏蔽掉复杂的配置和实现原理，最终提供给用户一套简单易懂、易部署、易维护的微服务架构开发工具。

在本实施例具体实施时，以Spring Boot作为本发明空间信息处理服务平台开发基本框架，并采用多模块项目开发方法。将整个服务平台工程分为Processes、Engine和Job三大模块，分别负责一部分业务的实现。

其中Processes模块负责与客户端的交互，包括接口的设计、参数的解析以及返回结果的封装等，主要由Controller和Model两部分组件构成。Controller是Spring Boot框架中的业务控制层，负责前后端的交互，接收前端消息请求并调用后端执行方法，结束后将执行结果返回。该组件设计为Overview、Process Manager、Job Manager和CustomDeployment四个接口类，每个类都包含若干个调用方法，与其他模块相配合，共同完成服务接口所设计的功能。Model组件所包含的方法类比较多，主要负责数据格式的界定、接口URL设计、Job对象执行状态设定、输入输出数据的解析与封装等功能，Model组件主要是作为基础组件，为前后端的交互提供各类基础信息。

Engine模块是服务平台底层逻辑实现的核心，负责服务算子的执行、输入输出解析、算子描述的生成等，它主要包含三个组件。Core组件负责具体空间信息处理算子的执行，其中包含的方法类较多，包括本地算子库管理、Job对象生成与执行、输入输出数据传递、结果数据引用生成、Job对象存储等功能。Algorithm组件是服务平台的算子库，所有发布的空间信息处理算子都在这一组件中集成或管理，对算子的描述或调用均需要通过算子库中定义的方法来实现。

Job模块主要用于Job对象相关元数据的持久化和查询，与业务数据库相连，负责记录算子服务执行的历史信息，这一模块包含的组件与Spring Boot中数据访问所划分的层级保持一致。其中Dao组件是持久化层，负责与业务数据库交互，完成数据持久化及查询等功能。Mapper组件是数据库操作层，负责Dao组件中具体操作方法所对应的SQL语句。Entity组件是实体对象层，用于定义Job对象所包含的属性。Service组件是业务接口层，负责对工程中其他模块提供数据库访问方法，任何与业务数据库有关的操作都要通过该组件提供的方法来实现。

在本实施例具体实施时，上述所有接口均为RESTful API，而Spring Boot框架对REST提供了很好的支持，仅需在Controller组件的接口类中添加@RestController注解即可。在前端接口管理方面，Swagger是一个规范且完整的框架，它用于管理、描述、调用及可视化REST风格的Web服务，同时可自动生成符合OpenAPI规范的接口描述文档，从而使得用户或计算机在无需访问源代码及额外文档的情况下，发现和理解服务所提供的功能。

在本实施例具体实施时，采用Docker容器虚拟化技术实现服务平台的云端部署，并通过Docker Compose容器编排技术完成自动化部署及管理。

为最大限度地支持快速交付与持续集成，并降低服务平台与运行环境之间的耦合性，本发明仅将算子服务的运行环境(如操作系统、Java执行工具、Python库等)打包至Docker镜像，而服务平台本身则部署于镜像外部，通过配置文件与内部环境相映射。本发明选取官方提供的纯净Ubuntu版本Linux操作系统镜像为基础镜像，在其基础上安装JDK(Java Development Kit)、GDAL、QGIS、Python编译环境以及各种Python依赖库等，通过commit命令生成全新的Docker镜像。

Docker Compose的配置文件一般命名为docker-compose.yml，采用YAML格式语言记录使用版本、构建服务名称、文件路径映射、端口映射、容器内部启动命令等信息，对其信息进行配置，便可实现容器化应用的自动部署与管理。通过该配置文件中的一系列映射关系，Docker镜像内部环境与外部工程之间可相互协调，在降低耦合性的同时，提供完整的服务功能。Docker Compose工具也支持开机自启动功能，从而支持真正的自动化处理。

Spring Cloud Eureka是一个用于实现服务治理的组件，它在Netflix Eureka的基础上进行封装，为其添加Spring Boot风格的自动化配置，从而使得用户仅通过简单引入依赖和注解配置，便能实现服务自动化注册与发现。Eureka组件由服务端和客户端两部分组成，均采用Java语言编写，并提供了完备的RESTful API，主要适用于通过Java语言完成的分布式系统。Eureka的服务端即为服务注册中心，它支持高可用性，即在一个系统中维护多个注册中心，相互间共享服务清单列表。Eureka的客户端主要处理服务实例的注册与发现，它通过注解和参数配置的方式，嵌入在服务实例的程序中，在程序启动时，依据参数自动化地向注册中心注册自身服务，并以发送心跳的方式更新可用性；同时，它也可以从注册中心获取当前已注册的服务列表，将其缓存到本地并不断刷新服务状态。

Spring Cloud Ribbon是一个服务消费者组件，它在NetFlix Ribbon的基础上进一步封装，通过对客户端维护的服务列表进行轮询访问，来实现负载均衡的作用。在微服务架构中，服务提供者和消费者的角色并不完全互斥，某些服务实例既可以提供服务，也可以消费其他实例提供的服务，以此实现相互间的协同合作。因此，Ribbon组件在使用时需要将自身也注册到服务注册中心，并且它会发送一个REST请求，来获取注册中心已注册的服务清单。

在本实施例实施时，空间信息处理服务平台作为服务提供者，提供信息处理服务。采用Spring Cloud Eureka组件构建服务注册中心，此组件需要独立部署并搭建独立的Spring Boot工程，通过在application.properties配置文件中设置URL地址和其他所需要素来进行配置。采用Spring Cloud Ribbon组件构建服务消费者，在全局配置文件中设置注册中心的URL地址，并在启动类中添加@LoadBalanced注解，以此实现服务消费时的客户端负载均衡。

在本实施例具体实施时，通过GitLab CI/CD工具实现持续集成、持续交付与持续部署。在GitLab上托管本发明所述的应用开发代码，并在根目录的.gitlab-ci.yml文件中指定构建、测试和部署的脚本，这些脚本被分组到jobs，它们共同组成一个Pipeline流水线，由名为GitLab Runner的工具执行。在实际开发流程中，当提交推送到远程仓库的分支上时，为该项目设置的CI/CD管道即会被触发，首先运行自动化脚本代码并获得批准，在服务器上构建并测试应用程序，使用Review Apps预览每个合并请求的更改，获得批准后合并该分支到默认分支，同时自动将此次更改部署到生产环境，如果中途或后续出现问题，都可以轻松回滚溯源。

作为一个优选实施例，所述空间信息处理服务，具体为：

将多源异构的空间信息处理算子或地学处理模型，发布为Web处理服务；其中，所述空间信息处理算子或地学处理模型，包括单元算子和组合模型。

在具体实施当中，依托于OGC API-Processes标准进行Process与Job的概念设计、同步与异步的执行模式设计，设计其标准原有接口，并添加可用于注册本地算子的定制化发布接口，所有服务接口均为RESTful接口；

设计空间信息处理服务使其符合OpenAPI规范，基于数据层、算子库、ProcessEngine、Job管理中心、访问接口等模块设计处理服务整体平台框架；

将处理服务平台完整运行环境封装于轻量化的容器镜像中，实现一次构建、任意部署，并通过容器编排工具实现自动化部署及管理；

设置自动化注册组件，将处理服务平台适配于微服务架构，并构建服务提供者、服务注册中心、服务消费者等核心模块，实现微服务注册与发现；

对云原生空间信息处理服务平台进行技术选型与开发实现，全过程保持DevOps风格，支持快速部署，持续交付。

本实施例在具体实施时，可将多源异构空间信息处理算子或模型，发布为Web处理服务，并通过RESTful接口进行调用与管理。

其中，空间信息处理算子或模型是用于处理地理数据的运算过程，既包括GIS软件中常用的执行功能，也包括某些时空和仿真的专用模型，既可以是简单且快速执行的同步操作，也可以是复杂耗时的异步操作。由于空间数据结构复杂、数据量通常较大，并且地学领域各学科分支众多、问题繁杂，导致地学处理功能或模型通常结构各异且耗费资源，因此对其设计主要聚焦于执行过程的实现。

OGC API-Processes是OGC正在制定的新一代空间信息处理服务标准，它以WPS2.0规范为基础，遵循OpenAPI设计原则，以通过具有表述性状态转移(RepresentationalState Transfer，REST)风格的协议进行通信，并基于JSON编码在网络传输，旨在以一种轻量化、简洁易用的方式共享地学处理功能。

用于在Web端提供空间信息处理功能的网络服务，聚焦于执行过程的实现。

作为一个优选实施例，所述方法，还包括：

建立所述空间信息处理服务的整体系统架构，进行所述空间信息处理服务的技术选型与开发实现。

请参阅图6，空间信息处理服务平台是该架构中的主要内容，由算子库、ProcessEngine、业务数据库等组件构成，通过轻量化的HTTP协议提供RESTful API，用户除使用基础服务功能之外，也可以通过提交算子基本信息和可执行文件到算子注册中心，来实现定制化算子注册发布功能。

服务平台搭建完成之后，将其运行依赖环境均打包到Docker容器中，并对两者进一步整合，借助Compose容器编排技术实现自动化部署及管理。启动之后作为服务实例提供服务，同时可构建多个服务实例，将其注册到服务注册中心，与服务消费者共同构成基础的微服务架构。同时，整个系统的代码基于GitLab CI/CD工具进行托管与部署，实现持续集成、持续交付。

图2是本发明实施例提供的一种基于OGC API-Processes的云原生空间信息处理服务装置的结构示意图，该基于OGC API-Processes的云原生空间信息处理服务装置，包括：

标准化制定模块21，用于依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；

构建平台架构模块22，用于构建符合OpenAPI规范的空间信息处理服务平台架构；

完善平台架构模块23，用于根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

本发明实施例所提供的一种基于OGC API-Processes的云原生空间信息处理服务装置能够实现上述实施例的基于OGC API-Processes的云原生空间信息处理服务方法的所有流程，装置中的各个模块的作用以及实现的技术效果分别与上述实施例的基于OGC API-Processes的云原生空间信息处理服务方法的作用以及实现的技术效果对应相同，这里不再赘述。

综上所述，本发明实施例公开的一种基于OGC API-Processes的云原生空间信息处理服务方法及装置，通过依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；构建符合OpenAPI规范的空间信息处理服务平台架构；根据云原生技术体系，完善所述空间信息处理服务平台架构。因此，本发明实施例能够以RESTful API的形式提供空间信息处理服务，并支持分布式云端自动化部署及管理，从而以一种更简洁、现代的方式支持地学处理模型的共享及互操作，以提升空间信息处理服务在复杂网络空间下的运维效率。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims (10)

1.一种基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，包括：

依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；

构建符合OpenAPI规范的空间信息处理服务平台架构；

根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

2.如权利要求1所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率，具体包括：

将所述空间信息处理服务平台与容器进行虚拟化映射，通过容器编排实现所述空间信息处理服务平台的自动化部署与管理；

使所述空间信息处理服务平台的内核适配于微服务架构；

执行所述空间信息处理服务的过程采用DevOps风格，以实现快速部署和持续交付。

3.如权利要求1所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGCAPI-Processes标准的服务接口，具体包括：

设计空间信息处理过程Process和所述空间信息处理实例化Job对象之间的关系，对所述Job对象进行管理与监控；

设计简单类型数据的值传输模式，以及复杂类型数据的引用传输模式；

将运行时间较短的处理过程设为同步模式服务执行序列；将运行时间较长的处理过程设为异步模式服务执行序列；

设计服务接口，以实现服务发现、服务描述、服务执行、服务管理；

拓展所述OGC API-Processes标准的服务接口，以供用户将本地处理算子自动化注册到服务目录；

其中，所有的服务接口均为RESTful接口，符合REST的约束条件与设计准则；所述OGCAPI-Processes标准的服务接口为定制化算子服务发布接口。

4.如权利要求1所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述构建符合OpenAPI规范的空间信息处理服务平台架构，具体包括：

定义所述空间信息处理服务的标准化、与实现语言无关的接口描述，使所述空间信息处理服务符合OpenAPI规范；

制定数据层、算子库、Process Engine、Job管理中心和访问接口模块，完善空间信息处理服务平台架构。

5.如权利要求2所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述将所述空间信息处理服务平台与容器进行虚拟化映射，通过容器编排实现所述空间信息处理服务平台的自动化部署与管理，具体包括：

将所述空间信息处理服务平台和地学算子的运行依赖环境均封装于容器的镜像中；

建立预定义文件，通过容器编排工具对容器运行的行为和交互方式进行干预，实现所述容器的镜像中所述空间信息处理服务平台的自动化部署与管理；

其中，所述容器包含完整运行时环境，以实现一次构建、任意部署。

6.如权利要求2所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述使所述空间信息处理服务平台的内核适配于微服务架构，具体包括：

设置自动化注册组件，将所述空间信息处理服务平台注册到微服务架构的服务注册中心，作为服务提供者提供处理功能服务；

构建所述服务提供者、服务注册中心、服务消费者的核心模块，实现服务自动化注册与发现；

预置负载均衡策略，以实现服务消费过程中的客户端负载均衡。

7.如权利要求2所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述执行所述空间信息处理服务的过程采用DevOps风格，以实现快速部署和持续交付，具体为：

所述空间信息处理服务平台开发实现全过程均采用DevOps风格，使开发、部署、运营维护流程高效自动化，能够支持快速部署和持续交付。

8.如权利要求1所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，所述空间信息处理服务，具体为：

将多源异构的空间信息处理算子或地学处理模型，发布为Web处理服务；其中，所述空间信息处理算子或地学处理模型，包括单元算子和组合模型。

9.如权利要求1所述的基于OGC API-Processes的云原生空间信息处理服务方法，其特征在于，还包括：

建立所述空间信息处理服务的整体系统架构，进行所述空间信息处理服务的技术选型与开发实现。

10.一种基于OGC API-Processes的云原生空间信息处理服务装置，其特征在于，包括：

标准化制定模块，用于依托OGC API-Processes标准进行概念设计、执行模式设计，拓展所述OGC API-Processes标准的服务接口；

构建平台架构模块，用于构建符合OpenAPI规范的空间信息处理服务平台架构；

完善平台架构模块，用于根据云原生技术体系，完善所述空间信息处理服务平台架构，以提升空间信息处理服务在复杂网络空间下的运维效率。

Images