本发明提出了一种面向地球应用模型的云化集成系统及其方法，通过建立面向服务的模块化的地球应用模型持续集成链路，即通过资源标识、云化封装、资源组装、配置注入、部署发布五个环节，实现数字地球多源应用模型的流程化、标准化的快速集成发布。本发明简化了模型服务化流程，提升了模型持续交付的效率，也保证了实时交付的环境一致性。
1.一种面向地球应用模型的云化集成系统，其特征在于，包括：
资源标识模块，用于对模型服务、数据存储资源进行规范化的定义与描述，标识资源的服务能力，进而支撑组合方式的服务能力集成，首先，通过规范化的字符结构描述地球平台各类资源的业务能力，生成由领域类型、业务类型、资源类型和版本号组成的资源标识；然后，依据具体业务场景，通过资源标识建立地球应用模型与各类依赖资源之间的关联，构建资源依赖拓扑模型，所述资源依赖拓扑由模型服务节点和数据存储节点组成；
云化封装模块，用于细粒度解耦并封装应用模型实体和各类依赖资源为统一的云化软件包，以容器、微服务、DevOps为基础建立应用模型云化服务结构，首先，进行模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、计算资源、虚拟化运行环境的细粒度解耦，使得每个部分都能单独管控；其次，通过声明式模板语言将解耦后的内容描述为服务模板、数据模板和配置模板，采用虚拟化技术将地球应用模型可执行文件封装成轻量化的业务镜像文件，将操作系统、依赖库封装成虚拟化运行环境镜像文件，实现业务逻辑和运行环境分离；最后，将资源模板、轻量化业务镜像文件、虚拟化运行环境镜像文件封装为规范化的软件包结构，支撑地球应用模型快速集成发布；
资源组装模块，用于地球应用模型依赖资源的组装，即以云化软件包为持续集成对象，依据应用模型中的资源依赖关系，将模型服务实例和数据存储实例与地球应用模型建立关联；
配置注入模块，用于地球应用模型多场景配置管理，底层的容器化承载环境中使用ConfigMap作为配置的承载，基于ConfigMap的配置管理机制实现配置注入和更新，首先，通过配置模板提供多场景配置支持，依据业务场景按需激活相应场景配置；其次，通过字符地址进行配置映射替换，实现依赖资源真实访问地址动态注入；最后，使用Kubernetes ConfigMap进行云化配置托管，满足分布式模型服务配置需求；
部署发布模块，用于地球应用模型在云计算环境的部署运行并对外暴露访问地址，首先，通过基础参数配置和高级参数配置支撑地球模型服务的多模态运行，通过部署模板将服务模板、数据模板、配置模板，以及部署参数构建为能够被Kubernetes解析执行的脚本文件；然后，通过Kubernetes初始化容器（Init Container）技术实现运行时应用模型和运行环境的实时组装，同时，将依赖资源的访问地址以环境变量的方式注入到运行环境镜像容器，将多场景配置以Configmap存储卷的方式挂载到运行环境镜像容器；最后，在运行环境镜像容器中运行地球应用模型可执行文件以生成模型服务实例，对外暴露访问地址信息。
2.根据权利要求1所述的面向地球应用模型的云化集成系统，其特征在于，所述资源标识中，将领域类型和业务类型进行定义；资源类型对于服务资源，包含长时运行服务、有状态服务、批处理任务、定时任务、工作流任务，对于数据资源，包含关系型数据库MySQL、PostgreSQL、DM、非关系型数据库Hbase，以及分布式文件系统DFS；版本号的标识方式为S[整数]或D[整数]，S表示服务资源，D表示数据资源，版本号从1开始逐级上升。
3.根据权利要求1所述的面向地球应用模型的云化集成系统，其特征在于，所述服务模板是对地球应用模型信息的格式化封装，服务模板的字段信息包含模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、计算资源、虚拟化运行环境八个部分，其中：模型元信息字段包含资源标识（RID）、模型名称（ModeName）、开发者（Creator）、功能描述（Description）、访问端口（Port）、端口协议（Protocol）、访问域名（DomainName）、基础路径（BaseUrl）、测试路径（TestUrl）、检索关键字（Keywords）；
地球领域信息字段包含领域类型（DomainType）、业务类型（BusinessType）、时间信息（TemoralInfo）、参考系（ReferenceSystem）、空间位置（SpatialPosition）、空间经纬度（SpatialResolution）、数据类别（Category）、产品等级（ProductLevel）；
接口契约字段包含接口名称（InterfaceName）、接口类型（InterfaceType）；
服务配置（SvcCfg）字段由配置标识声明对配置资源的引用；
服务依赖（SvcDeps）字段由服务资源标识声明对服务资源的引用；
数据依赖（DataDeps）字段由数据资源标识声明对数据资源的引用；
计算资源（ComputSetting）字段由最小/最大申请量声明地球应用模型对计算资源的需求；
虚拟化运行环境（VEnv）字段由业务镜像标签和运行环境镜像标签声明对业务镜像和运行环境镜像的引用。
4.根据权利要求1所述的面向地球应用模型的云化集成系统，其特征在于，所述数据模板是对地球应用模型存储信息的格式化封装，数据模板的字段包含资源标识（RID）、存储名称（Database）、功能描述（Description）、存储容量（Capacity）、存储配置（Config），其中：存储配置字段包含存储地址（Host）、用户名（UserName）、密码（PassWord）、存储路径（Location）、挂载路径（MountPath）、ZK地址（ZKAddr）；
所述挂载路径字段是针对文件系统存储在应用模型容器内的挂载路径，所述ZK地址字段是针对Hbase存储的访问地址。
5.根据权利要求4所述的面向地球应用模型的云化集成系统，其特征在于，所述配置模板是对地球应用模型配置信息的格式化封装，配置模板的字段包含配置标识（CfgID）、功能描述（Description）、激活场景（Active）、配置信息（Config），其中：配置信息字段包含多组应用场景配置信息，每组应用场景配置信息包含场景名称
（Scene）、配置挂载路径（MountPath），以及多组配置文件信息（ConfigFiles），每组配置文件信息包含配置文件名称（FileName）和配置文件内容（FileContent）；
激活场景字段通过引用场景名称激活当前地球应用模型所使用的应用场景配置，配置文件内容包含由依赖资源标识和关键字组成的字符地址，支持运行时通过实际资源的访问地址替换字符地址生成可用配置文件，从而实现依赖资源信息的动态注入；
所述字符地址格式为“资源标识_关键字”，所述关键字包括访问地址（HOST）、访问域名（DOMAINNAME）、存储名称（DATABASE）、存储用户名（USERNAME）、存储密码（PASSWORD）、存储挂载路径（MOUNTPATH）、ZK地址（ZKADDR）。
6.根据权利要求1所述的面向地球应用模型的云化集成系统，其特征在于，所述资源组装模块提供基于需求匹配度优先排序、相对重要性优先排序的资源筛选方法，支持依赖资源实例优选，支持环境变量注入和配置文件注入两种方式的依赖加载使用。
7.根据权利要求1所述的面向地球应用模型的云化集成系统，其特征在于，所述部署参数分为基础参数和高级参数，其中：基础参数是模型服务运行必须的参数，包括部署名称、开发单位、功能描述、部署类型、访问域名、访问端口、端口协议、配置实例、CPU请求量、内存请求量、实例数量；
高级参数聚焦于服务性能，以满足数字地球模型服务多模态运行场景，包括运行模式、粘性会话、容器调试模式、存活探测、就绪性探测、定向部署、自动伸缩‑最小实例数、自动伸缩‑最大实例数。
8.一种面向地球应用模型的云化集成方法，其特征在于，基于权利要求1‑7任一项所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时，基于权利要求1‑7任一项所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
10.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，基于权利要求1‑7任一项所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
一种面向地球应用模型的云化集成系统及其方法
技术领域
[0001] 本发明涉及服务集成发布技术，具体涉及一种面向地球应用模型的云化集成系统及其方法。
背景技术
[0002] 数字地球应用模型是联系底层地球数据与上层科学研究、专家决策的关键纽带，是新一代数字地球信息服务体系中的一类重要资源，具有来源广泛、结构多样的特点。从来源方面看，不同研究领域在地球空间数据、科学数据、专题产品处理过程中积累了大量的应用模型，比如生成类、访问类、智能分析类、空间分析类；从结构方面看，这些海量多源的应用模型往往具有不同的开发语言、版本结构、设计风格、部署模式等。
[0003] 数字地球应用模型多源异构特点的存在，一方面促进了地球平台朝着多学科应用的方向发展，另一方面多源模型综合应用及学科交叉互补分析的需求趋势更加明显。比如，科研人员希望通过集成其他领域的专题应用模型进行科学研究，以拓宽地球空间数据的应用范畴；社会公众希望通过组合多种来源的数字地球应用模型构建专题数据处理工作流，以缩短专题应用产品的生产周期；政府工作人员希望查看各类地图检索类应用模型，以满足日常办公需要。随着数字地球应用领域的扩大以及应用功能需求的增多，需要通过建立开放的集成平台和标准的集成规范，完成多源异构专题应用模型规范化的持续集成管理，为数字地球平台提供稳定可靠的服务。
[0004] 目前现有数字地球平台在多源模型的持续接入与集成方面，面临一些新的问题和挑战。相比于传统的地理信息应用模型，数字地球则扩展到了三维空间的分析与计算，空间维度的提高，使数字地球应用模型总体上具有体量更多、来源更广、差异更大的特点。早期内嵌式、模块式和模型库的集成方式，都不能实现大规模应用模型的有效集成与信息融合。更重要的是基于数字地球平台的多学科交叉应用与智能决策的场景需要一种开放灵活、可持续、可复用的应用模型集成管理机制。另外，云计算工作模式的引入虽然优化了地球系统的资源配比，但对模型的精细化管理提出了更高的要求，综上所述，目前在相关领域内缺少地球应用模型的云化集成方法和系统的研究，即基于虚拟化、容器云等技术建立面向服务的地球应用模型持续集成链路。
发明内容
[0005] 本发明的目的在于提出一种面向地球应用模型的云化集成系统及其方法。
[0006] 实现本发明目的的技术解决方案为：一种面向地球应用模型的云化集成系统，通过建立面向服务的模块化的地球应用模型持续集成链路，即通过资源标识、云化封装、资源组装、配置注入、部署发布五个环节，实现数字地球多源应用模型的流程化、标准化的快速集成发布。
[0007] 资源标识模块，用于对模型服务、数据存储等资源按照数字地球平台的统一要求进行规范化的定义与描述，标识资源的服务能力，进而支撑组合方式的服务能力集成。资源标识依据地球大数据科学工程，以及地球应用模型处理业务的特点设计成点分四段结构，从左至右依次为领域类型、业务类型、资源类型和版本号，适应数字地球多学科交叉应用与智能决策的集成场景。
[0008] 云化封装模块，用于细粒度解耦并封装应用模型实体和各类依赖资源为统一的云化软件包，以容器、微服务、DevOps等云原生技术为基础建立应用模型云化服务结构，具备快速部署、按需伸缩、不停机交付等特点。首先，进行模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、计算资源、虚拟化运行环境等细粒度解耦，使得每个部分都能单独管控。其次，通过声明式模板语言将解耦后的内容描述为服务模板、数据模板和配置模板，采用虚拟化技术将地球应用模型可执行文件封装成轻量化的业务镜像文件(不含运行环境)，将操作系统、依赖库等封装成虚拟化运行环境镜像文件，实现业务逻辑和运行环境分离。最后，将资源模板、轻量级业务镜像文件、虚拟化运行环境镜像文件封装为规范化的软件包结构，支撑地球应用模型快速集成发布。
[0009] 资源组装模块，用于地球应用模型依赖资源的组装。即以云化软件包为持续集成对象，依据应用模型中的资源依赖关系，将满足要求的模型服务实例和数据存储实例与目标应用模型建立关联，进而对外形成服务合力。特别地，提供需求匹配度优先排序、相对重要性优先排序等多种资源筛选方法支持依赖资源实例优选，支持环境变量注入和配置文件注入两种方式的依赖加载使用。
[0010] 配置注入模块，用于地球应用模型多场景配置管理，底层的容器化承载环境中使用ConfigMap作为配置的承载，基于ConfigMap的配置管理机制实现配置注入和更新。首先，通过配置模板提供多场景配置支持，依据业务场景按需激活相应场景配置，场景配置之间可灵活切换。其次，通过“字符地址”进行配置映射替换实现依赖资源真实访问地址动态注入，地球应用模型使用原有的方式加载配置建立依赖资源连接，无需代码改造。最后，使用Kubernetes ConfigMap进行云化配置托管，满足分布式模型服务配置需求，保证配置注入的可靠性和时效性。
[0011] 部署发布模块，用于地球应用模型在云计算环境的部署运行并对外暴露访问地址。首先，通过基础参数配置和高级参数配置支撑地球模型服务的多模态运行，通过部署模板将服务模板、数据模板、配置模板，以及部署参数构建为能够被Kubernetes解析执行的脚本文件。然后，通过Kubernetes初始化容器(Init Container)技术实现运行时应用模型和运行环境的实时组装。同时，将依赖资源的访问地址以环境变量的方式注入到运行环境镜像容器，将多场景配置以Configmap存储卷的方式挂载到运行环境镜像容器。最后，在运行环境镜像容器中运行地球应用模型可执行文件以生成模型服务实例，对外暴露访问地址信息。
[0012] 一种面向地球应用模型的云化集成方法，基于所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
[0013] 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时，基于所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
[0014] 一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，基于所述的面向地球应用模型的云化集成系统，实现面向地球应用模型的云化集成。
[0015] 本发明与现有技术相比，其显著优点为：1)提出一种地球应用模型的云化集成与发布方法，深度融合了“云原生”的设计理念，将地球应用模型进行模块化分解与精细化表达，通过声明式模板简化了模型服务化流程。2)提出了可复用、可扩展的应用模型持续集成链路，改变了传统多源地理应用模型松散、低效的管理模式，尤其采用容器化的承载方式不仅提升了模型持续交付的效率，也保证了实时交付的环境一致性。
附图说明
[0016] 图1是本发明一种地球应用模型的云化集成系统的模块化持续集成链路。
[0017] 图2是地球应用模型资源标识结构图。
[0018] 图3是地球应用模型资源依赖拓扑模型。
[0019] 图4是地球应用模型云化服务结构图。
[0020] 图5是地球应用模型服务模板。
[0021] 图6是地球应用模型数据模板。
[0022] 图7是地球应用模型配置模板。
[0023] 图8是地球应用模型容器镜像文件和软件包动态装载原理图。
[0024] 图9是地球应用模型云化软件包结构图。
[0025] 图10是地球应用模型资源组装流程图。
[0026] 图11是地球应用模型配置注入流程图。
[0027] 图12是地球应用模型部署发布流程图。
[0028] 图13是地球应用模型云化部署模板。
具体实施方式
[0029] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
[0030] 本发明通过整合应用模型服务化技术、依赖资源动态组装技术、模型环境实时装载技术等，实现了云计算环境下地球应用模型的快速集成与发布过程，集成发布链路如图1所示。一种面向地球应用模型的云化集成系统及其方法，包含资源标识模块、云化封装模块、资源组装模块、配置注入模块、部署发布模块，地球应用模型集成发布流程包含：
[0031] a、资源标识模块，通过规范化的字符结构描述地球平台各类资源的业务能力，生成由领域类型、业务类型、资源类型和版本号组成的资源标识。依据具体业务场景，通过资源标识建立地球应用模型与各类依赖资源之间的关联，构建“资源依赖拓扑模型”。所述资源依赖拓扑由模型服务节点和数据存储节点组成，是地球应用模型资源集成的重要依据。
[0032] b、云化封装模块，首先设计地球应用模型云化服务结构，解耦地球应用模型实体和各类依赖资源，使得每个部分都能单独管控，从而适应云计算环境的高弹性和高可扩展性的特点。所述云化服务结构包含模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、虚拟运行环境八个部分。然后，通过声明式模板语言将解耦后的内容描述为服务模板、数据模板和配置模板，采用虚拟化技术将地球应用模型可执行文件封装成轻量化的业务镜像文件(不含运行环境)，将操作系统、依赖库等封装成虚拟化运行环境镜像文件，实现业务逻辑和运行环境分离。最后，将资源模板、轻量级业务镜像文件、虚拟化运行环境镜像文件封装为规范化的软件包结构，支撑地球应用模型快速集成发布。
[0033] c、资源组装模块，以云化封装模块输出的软件包为持续集成对象，依据资源标识模块中定义的“资源依赖拓扑模型”，将满足要求的依赖模型服务实例、依赖数据存储实例与目标应用模型建立关联。特别地，提供需求匹配度优先排序、相对重要性优先排序等多种资源筛选方法支持依赖资源实例优选，支持环境变量注入和配置文件注入两种方式的依赖加载使用。
[0034] d、配置注入模块，首先通过配置模板提供多场景配置支持，依据业务场景按需激活相应场景配置。其次，通过优选依赖资源的真实访问地址替换配置模板中用于占位的依赖资源“字符地址”，实现依赖资源动态注入。最后，基于Kubernetes ConfigMap实现云化配置的注入和更新过程。
[0035] e、部署发布模块，将服务模板、数据模板、配置模板，以及部署参数构建为能够被Kubernetes解析执行的脚本文件，通过基于Kubernetes初始化容器(Init Container)的软件包动态装载技术实现运行时应用模型和运行环境的实时组装，通过在运行环境镜像容器中运行地球应用模型可执行文件创建模型服务实例，完成模型服务访问地址信息的暴露。
[0036] 下面结合附图2‑13对各模块的组成和功能进行详细说明。
[0037] 所述资源标识模块用于对模型服务、数据存储等资源按照数字地球平台的统一要求进行规范化的定义与描述，标识资源的服务能力，进而支撑组合方式的服务能力集成。参照图2所示的地球应用模型资源标识结构图，图3所示的资源依赖拓扑图，具体实施步骤如下：
[0038] (1)资源标识定义
[0039] 参照图2，所述资源标识设计成点分四段结构，从左至右依次为领域类型、业务类型、资源类型和版本号。其中，领域类型按照地球大数据科学工程的特点进行定义。业务类型按照地球应用模型处理业务的特点进行定义。资源类型对于服务资源，包含长时运行服务、有状态服务、批处理任务、定时任务、工作流任务等。对于数据资源，包含关系型数据库MySQL、PostgreSQL、DM(达梦)等，非关系型数据库Hbase，以及分布式文件系统DFS等。版本号的标识方式为S[整数]或D[整数]，S表示服务资源，D表示数据资源，版本号从1开始逐级上升。例如，对地观测卫星领域(DDGCWX)的影像校正类业务(YXJZ)，其批处理任务(PCLRW)的资源标识定义为DDGCWX.YXJZ.PCLRW.S1。资源标识作为建立地球应用模型资源依赖关系的重要依据，需要结合领域知识进行严格定义。
[0040] (2)资源标识关联
[0041] 参照图3，依据业务场景描述，通过资源标识建立地球应用模型与各类资源之间的依赖关联，构建“资源依赖拓扑模型”用于支撑组合方式的服务能力集成。所述资源依赖拓扑模型是基于微服务技术建立的地球应用模型的服务能力依赖关系网络，由服务资源节点、数据资源节点，以及资源依赖关系组成，所述资源依赖关系通过线条箭头表示，线条箭头指向为资源的依赖方向(如图3中服务资源B依赖服务资源A，服务资源A依赖数据资源E)。
[0042] 所述云化封装模块用于细粒度解耦并封装应用模型实体和各类依赖资源，使得每个部分都能单独管控，从而适应云计算环境的高弹性和高可扩展性的特点。
[0043] 参照图4‑图9，具体实施步骤如下：
[0044] (1)资源依赖解耦
[0045] 参照图4，提出地球应用模型“云化服务结构”，并根据所述云化服务结构对地球应用模型进行解耦。所述云化服务结构包含模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、计算资源、虚拟化运行环境八个部分。其中，模型元信息是对地球应用模型基本信息的描述。地球领域信息是对地球领域应用模型的特征信息、专家经验等进一步抽取、整合，生成满足系统需求的领域知识，包含应用模型的领域类型、业务类型，时间信息(如地球空间数据以及专题产品的生产时间)、空间信息(如空间坐标系、空间分辨率、经纬度等)、属性信息(如地球空间数据类别、产品等级)等。接口契约是面向服务的接口协议或约束规范，包含标准的OpenGIS规范(如WMS、WMTS、WFS、WCS等)和通用的传输接口协议(如RESTful、WebService、RPC等)。服务配置是独立于程序的只读变量，支持通过不同的配置来改变应用模型的运行方式和业务输出，满足不同的平台环境和应用场景需求。服务依赖和数据依赖是地球应用模型依赖的服务资源和数据资源，资源之间的依赖关系由资源标识模块中的“资源依赖拓扑模型”进行定义。计算资源是地球应用模型运行时所需的CPU资源、内存资源、硬盘资源、网络资源等。虚拟化运行环境是对操作系统、程序依赖库等运行时的统一封装为容器镜像文件，发布到任何支持镜像运行的环境中使用，不用担心版本和配置环境出现不兼容问题，从而保证交付的一致性。
[0046] (2)模型云化封装
[0047] 参照图5‑图9，首先将步骤(1)中解耦的内容通过声明式模板语言描述为资源模板，所述资源模板包含服务模板、数据模板和配置模板。然后，采用虚拟化技术将地球应用模型可执行文件封装成轻量化的业务镜像文件(不含运行环境)，将操作系统、依赖库等封装成虚拟化运行环境镜像文件，实现业务逻辑和运行环境分离。最后，将资源模板文件、轻量级业务镜像文件、虚拟化运行环境镜像文件封装为规范化的软件包结构(参照图9)，支撑地球应用模型快速集成发布过程。
[0048] 进一步地，所述服务模板是对地球应用模型“云化服务结构”信息的格式化封装，语法格式可以采用JSON、XML、YAML。参照图5，所述服务模板的字段信息与“云化服务结构”对应，包含模型元信息、地球领域信息、接口契约、服务配置、服务依赖、数据依赖、计算资源、虚拟化运行环境八个部分。其中，模型元信息字段包含资源标识(RID)、模型名称(ModeName)、开发者(Creator)、功能描述(Description)、访问端口(Port)、端口协议(Protocol)、访问域名(DomainName)、基础路径(BaseUrl)、测试路径(TestUrl)、检索关键字(Keywords)；地球领域信息字段包含领域类型(DomainType)、业务类型(BusinessType)、时间信息(TemoralInfo)、参考系(ReferenceSystem)、空间位置(SpatialPosition)、空间经纬度(SpatialResolution)、数据类别(Category)、产品等级(ProductLevel)；接口契约字段包含接口名称(InterfaceName)、接口类型(InterfaceType)；服务配置(SvcCfg)字段由配置标识声明对配置资源的引用；服务依赖(SvcDeps)字段由服务资源标识声明对服务资源的引用；数据依赖(DataDeps)字段由数据资源标识声明对数据资源的引用；计算资源(ComputSetting)字段由最小/最大申请量声明地球应用模型对计算资源的需求；虚拟运行环境(VEnv)字段由业务镜像标签和运行环境镜像标签声明对业务镜像和运行环境镜像的引用。
[0049] 进一步地，所述数据模板是对地球应用模型存储信息的格式化封装，语法格式可以采用JSON、XML、YAML等。参照图6，所述数据模板的字段包含资源标识(RID)、存储名称(Database)、功能描述(Description)、存储容量(Capacity)、存储配置(Config)。其中，存储配置包含存储地址(Host)、用户名(UserName)、密码(PassWord)、存储路径(Location)、挂载路径(MountPath)、ZK地址(ZKAddr)。特别地，MountPath字段是针对文件系统存储在应用模型容器内的挂载路径，ZKAddr字段是针对Hbase存储的访问地址。
[0050] 进一步地，所述配置模板是对地球应用模型配置信息的格式化封装。语法格式可以采用JSON、XML、YAML等。参照图7，所述配置模板的字段包含配置标识(CfgID)、功能描述(Description)、激活场景(Active)、配置信息(Config)。其中，Config字段包含多组应用场景配置信息，每组应用场景配置信息包含场景名称(Scene)、配置挂载路径(MountPath)，以及多组配置文件信息(ConfigFiles)。每组配置文件信息包含配置文件名称(FileName)和配置文件内容(FileContent)。特别地，Active字段通过引用场景名称激活当前地球应用模型所使用的应用场景配置，配置文件内容可以包含由依赖资源标识和关键字组成的“字符地址”，支持运行时通过实际资源的访问地址替换字符地址生成可用配置文件，从而实现依赖资源信息的动态注入。所述字符地址格式为“资源标识_关键字”，所述关键字包括访问地址(HOST)、访问域名(DOMAINNAME)、存储名称(DATABASE)、存储用户名(USERNAME)、存储密码(PASSWORD)、存储挂载路径(MOUNTPATH)、ZK地址(ZKADDR)。其中，关键字HOST可表示服务资源和数据资源的访问地址(IP:Port)，二者通过资源标识进行区分。例如，字符地址DDGCWX.YXJZ.PCLRW.S1_HOST表示依赖服务资源的访问地址，DDGCWX.YXJZ.DFS.D1_HOST表示依赖数据资源的访问地址。
[0051] 进一步地，所述轻量级业务镜像文件和虚拟化运行环境镜像文件通过软件包动态装载实现运行时应用模型与运行环境的实时组装，不仅可以提高运行环境的复用能力，而且还可以改善地球应用模型持续集成发布的效率。参照图8，业务镜像文件包含轻量级操作系统文件(如Alpine)和地球应用模型可执行文件(AppModel)，所述轻量级操作系统文件占用存储体积小，只提供一些Linux常用操作命令(如cp)的使用，并不能支撑地球应用模型的实际运行。所述环境镜像文件包含全量级操作系统文件(如CentOS)和地球应用模型运行依赖库(如GDAL、JAVA等)，能够支撑地球应用模型的实际运行。通过软件包动态装载技术实现运行时应用模型与运行环境的实时组装，即在运行时通过使用Linux的cp命令，动态将地球应用模型可执行文件从业务镜像容器复制到环境镜像容器，并在环境镜像容器运行地球应用模型可执行文件，从而生成可对外提供服务能力应用模型容器。
[0052] 所述资源组装模块用于地球应用模型依赖资源的组装。即依据资源标识模块中定义的“资源依赖拓扑模型”，将满足要求的模型服务实例和数据存储实例与目标地球应用模型建立关联，进而对外形成服务合力。包含依赖优选和依赖加载两个阶段。
[0053] (1)依赖资源优选
[0054] 依赖资源优选是指从海量的候选资源实例集合中过滤出满足需求的模型服务资源实例和数据存储资源实例的过程。参照图10，具体实施步骤如下：
[0055] ①资源实例召回
[0056] 递归资源依赖拓扑模型，从地球平台过滤出与依赖资源标识相同的所有已部署资源实例，形成候选资源实例集合 其中， 表示与第n个依赖资源标识(RID)相同的资源实例集合，n表示地球应用模型依赖总数(包括服务依赖和数据依赖)。
[0057] ②资源实例排序
[0058] 遍历候选资源实例集合，确定资源实例的优先顺序并过滤出优质资源实例，形成优选资源实例集合 其中， 表示对候选资源实例集合 进行优先排序，并将排名靠前的K项资源实例作为优选资源实例。集成多种优先排序方法供用户选择，包括需求匹配度优先排序、相对重要性优先排序等。其中，需求匹配度优先排序通过分析地球应用模型对依赖资源的需求指标与候选资源实例实际指标的匹配度，匹配度越大排名越靠前。例如，依据用户给出的数据存储容量和存储读写性能指标需求，通过余弦相似度或皮尔逊相似度计算所有候选资源实例的数据存储容量和存储读写性能指标与用户需求指标之间的匹配度。相对重要性优先排序通过对资源实例之间多个维度的评价指标进行相对优劣的比较，从而确定资源实例的综合排名。例如，选取服务资源实例的响应时间、服务吞吐量、服务错误率作为评价指标，使用多准则决策方法计算资源实例的相对优劣性。
[0059] (2)依赖资源加载
[0060] 依赖加载是将依赖优选的结果即服务(存储)实例的连接信息注入模型服务容器，进而支撑依赖资源的使用过程。提供两种依赖注入方式支持地球应用模型获取依赖资源实例的连接信息。一是环境变量注入：结合容器虚拟化技术，将依赖实例连接信息以环境变量的方式注入模型服务容器，模型服务通过读取环境变量的方式使用。二是配置文件注入：将依赖实例的连接信息注入配置模板，替换由依赖资源标识和关键字组成的“字符地址”，然后模型服务采用原有的方式加载配置进行使用。为了保证两种方式的统一，所述环境变量注入方式下环境变量的键(Key)采用配置模板中“字符地址”的定义方式。
[0061] 所述配置注入模块用于地球应用模型的多场景配置管理，首先依据应用场景需求激活相应的配置文件，然后将资源组装模块优选的资源实例的真实地址替换所述激活配置文件中的“字符地址”以生成可用配置文件，实现依赖资源真实访问地址的动态注入，最后在底层的容器化承载环境中使用Kubernetes ConfigMap作为配置的承载，基于ConfigMap的配置管理机制实现配置注入和更新过程。
[0062] 参照图11，具体实施步骤如下：
[0063] (1)生成配置
[0064] 依据配置模板中的激活场景(Active)字段，获取相应场景下的配置文件(包含字符地址)。获取资源组装模块优选的模型服务资源和数据存储资源实例的真实地址，通过配置映射替换所述激活配置文件中的“字符地址”以生成地球应用模型可用的配置文件，实现依赖资源真实访问地址的动态注入。
[0065] (2)注入配置
[0066] 将配置实例创建为ConfigMap对象，ConfigMap的数据包含多个Key‑Value字符串，每个字符串对应一个配置文件。通过Kubernetes存储卷挂载的方式将ConfigMap挂载到模型容器的原始配置路径，应用模型即可通过原有的方式加载配置。
[0067] (3)更新配置
[0068] 更新激活场景生成新的配置文件，并与当前ConfigMap所承载的配置内容进行对比，若不同则用新生成的配置实例更新ConfigMap内容，否者不进行任何操作。ConfigMap内容的更新即同步完成模型服务配置的升级或回滚。
[0069] 所述部署发布模块用于地球应用模型在云计算环境的部署运行并对外暴露访问地址。通过基础参数配置和高级参数配置支撑地球模型服务的多模态运行。通过存储卷挂载实现模型服务多场景配置和依赖资源访问地址的容器环境注入，通过软件包动态装载实现运行时应用模型和运行环境的实时组装。参照图12，具体实施步骤如下：
[0070] (1)配置部署参数
[0071] 基于Kubernetes云计算环境，提供大量部署参数支撑地球模型服务的多模态运行，分为基础参数和高级参数。其中，基础参数是模型服务运行必须的参数。这些参数部分可以通过服务模板字段进行自动填充，比如部署名称、开发单位、功能描述、部署类型、访问域名、访问端口、端口协议、配置实例等，部分是通过在线计算进行最佳分配，比如CPU请求量、内存请求量、实例数量等。高级参数聚焦于服务性能，满足数字地球模型服务多模态运行场景，包括运行模式、粘性会话、容器调试模式、存活探测、就绪性探测、定向部署、自动伸缩‑最小实例数、自动伸缩‑最大实例数等。
[0072] (2)创建部署模板
[0073] 根据部署类型是普通还是工作流，创建不同的部署模板。其中，工作流部署创建Argo部署模板(参照图13)，普通部署创建原生Kubernetes部署模板(包括deployment、service、ingress等)。所述部署模板将服务模板、数据模板、配置模板，以及部署参数构建为能够被Kubernetes解析执行的脚本文件。
[0074] (3)生成模型服务实例
[0075] 首先，基于Kubernetes初始化容器(Init Container)技术，将业务镜像以初始化容器的方式启动，执行复制文件命令，将应用模型可执行文件装载到运行环境镜像容器。然后，将依赖资源的访问地址以环境变量的方式注入到运行环境镜像容器，同时将配置注入模块创建的Configmap存储卷挂载到运行环境镜像容器。最后，在运行环境镜像容器中运行地球应用模型可执行文件以生成模型服务实例，对外暴露访问地址信息。
[0076] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0077] 以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。
