CN111984269B - 提供应用构建服务的方法及应用构建平台 - Google Patents

Abstract

提供了一种提供应用构建服务的方法及应用构建平台，所述方法包括：提供至少一个工作负载和至少一个运维能力，其中，每个工作负载封装了基础设施集群中的多种服务相关资源以用于执行对应的服务，每个运维能力封装了所述基础设施集群中的多种运维相关资源以用于执行对应的运维；提供每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源；提供API模块，其中，所述API模块用于使用户通过API模块配置工作负载和运维能力以执行应用的构建。

Description

提供应用构建服务的方法及应用构建平台

技术领域

本公开涉及云平台应用开发领域，更具体地说，涉及一种提供应用构建服务的方法及应用构建平台。

背景技术

云原生时代，以kubernetes为底座的PaaS(平台即服务)平台逐步成为共识，Kubernetes提供了各种原生的资源模型,比如deployment、statefulset、configmap、service等等，PaaS维护人员通过组合一种或多种资源模型，来构成一个服务，每个平台都可以拥有一个自己的组合方式。

例如，图1是示出现有的PaaS平台的架构示意图。如图1所示，PaaS平台分为内置服务和在线服务两个部分。对于内置服务部分，通过devops工具将例如监控指标数据(Promethus)、鉴权(Authorization)、监控(Monitor)、日志(Log)等服务渲染为kubernetesyaml文件，然后通过kubectl把内置应用部署到kubernetes集群。对于在线服务部分，通过PAS来将Tensorflow-Serving、GDBT、Flink Task、H2O、定制化实时预估(Customize Real-Time Estimates)、PMML等服务部署到kubernetes集群，PAS内部维护了kubernetes原生资源的模板(例如，Deployment Template、Service Template、Configmap Template等)，然后组合各个模板来完成资源部署。

现有的PaaS平台存在以下问题：(1)devops和pas是两套独立的技术栈，虽然本质上是相同的，都在将服务部署到kubernetes集群，但彼此沉淀的技术不能共享，通过两种不同的方式来部署和管理，维护两套技术方案，好的方案思路彼此不能复用。(2)devops维护大量的yaml模板，模式固定，扩展能力较差，遇到复杂需求业务接入成本高昂。(3)PAS通过维护资源模板的方式来完成服务部署，模板也是固定的kubernetes原生资源的json模板，扩展性较差，复用性不高。(4)现有模板方式难于形成沉淀技术和抽象业务模型的标准。

发明内容

本公开的示例性实施例可至少解决上述问题，也可不解决上述问题。

根据本公开的一方面，一种提供应用构建服务的方法，包括：提供至少一个工作负载和至少一个运维能力，其中，每个工作负载封装了基础设施集群中的多种服务相关资源以用于执行对应的服务，每个运维能力封装了所述基础设施集群中的多种运维相关资源以用于执行对应的运维；提供每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源；提供API模块，其中，所述API模块用于使用户通过API模块配置工作负载和运维能力以执行应用的构建。

可选地，所述至少一个工作负载可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。

可选地，所述基础设施集群可包括kubernetes集群；第一工作负载可封装kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap原生资源。

可选地，第一工作负载还可封装非kubernetes原生资源。

可选地，所述基础设施集群可包括kubernetes集群；第二工作负载可封装kubernetes集群中的job、cronjob和configmap原生资源。

可选地，第二工作负载还可封装非kubernetes原生资源。

可选地，所述至少一个运维能力可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。

可选地，所述基础设施集群可包括kubernetes集群；自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数；负载均衡运维能力可封装kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力；自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小；持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、Persistent Volume Claim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求；发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

根据本公开的另一方面，提供一种应用构建平台，包括：工作负载库，包括至少一个工作负载，其中，每个工作负载封装了所述应用构建平台所依托的基础设施集群中的多种服务相关资源以用于执行对应的服务；运维能力库，包括至少一个运维能力，其中，每个运维能力封装了所述基础设施集群中的多种运维相关资源以用于执行对应的运维；控制器库，包括每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源；API模块，用于使用户通过API模块配置工作负载和运维能力以执行应用的构建。

可选地，所述至少一个工作负载可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。

可选地，所述基础设施集群可包括kubernetes集群；第一工作负载可封装了kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap原生资源。

可选地，第一工作负载还可封装非kubernetes原生资源。

可选地，所述基础设施集群可包括kubernetes集群；第二工作负载可封装kubernetes集群中的job、cronjob和configmap原生资源。

可选地，第二工作负载还可封装非kubernetes原生资源。

可选地，所述至少一个运维能力可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。

可选地，所述基础设施集群可包括kubernetes集群；自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数；负载均衡运维能力可封装kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力；自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小；持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、Persistent Volume Claim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求；发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

根据本公开的另一方面，提供一种存储指令的计算机可读存储介质，其中，当所述指令被至少一个计算装置运行时，促使所述至少一个计算装置执行本公开的提供应用构建服务的方法。

根据本公开的另一方面，提供一种包括至少一个计算装置和至少一个存储指令的存储装置的系统，其中，所述指令在被所述至少一个计算装置运行时，促使所述至少一个计算装置执行本公开的提供应用构建服务的方法。

根据本公开的提供应用构建服务的方法和应用构建平台，通过工作负载来对平台所依托的基础设施集群的多种服务资源进行组织、封装和管理，通过运维能力来对平台所依托的基础设施集群的多种运维资源进行组织、封装和管理，从而可提供上层开发应用所需要的全部产品功能，这不仅能够提供更丰富的业务需求，且所有行为可控，同时满足社区标准和生态，便于后续和社区的融合，还能够使应用开发者仅需专注于与业务相关的开发工作，而不必关注或开发底层架构和运维细节。

此外，根据本公开的提供应用构建服务的方法和应用构建平台，应用的管理全部围绕对工作负载和运维能力的管理。随着产品的迭代升级及探索，能够不断强化和稳定工作负载和运维能力，上层应用开发者只需通过声明使用即可。

此外，根据本公开的提供应用构建服务的方法和应用构建平台，由于组件信息可包括组件名称和组件版本号，因此，应用升级时，可新增版本号，这不会影响已有服务，只需要在应用配置文件中声明新的版本号即可。

此外，根据本公开的提供应用构建服务的方法和应用构建平台，应用的交付围绕着组件的形式交付,这样可以按单个应用或者指定应用交付即可。由于从大量的yaml文件转移到工作负载和运维能力的组合声明上，原来需要全量渲染template模板，现在只需要升级对应的组件或者应用配置文件即可，而工作负载和运维能力是kubernetes的运维，可充分利用kubernetes提供的扩展机制及其自身机制的稳定性，现在的交付指定升级的应用的镜像，对组件中工作负载使用的镜像进行升级即可，不用通过离线包这种繁重交付方式，并且有了工作负载和运维能力这套标准，开发、运维、交付在标准中进行协作，大大减少了沟通成本。

附图说明

通过结合附图，从实施例的下面描述中，本公开这些和/或其它方面及优点将会变得清楚，并且更易于理解，其中：

图1是示出现有的PaaS平台的架构示意图。

图2是示出根据本公开的示例性实施例的用户执行应用部署的示意图。

图3是示出根据本公开的示例性实施例的应用构建平台的框图。

图4是示出根据本公开的示例性实施例的提供应用构建服务的方法的流程图。

图5是示出根据本公开的示例性实施例的应用部署系统的框图。

图6是示出根据本公开的示例性实施例的应用部署方法的流程图。

具体实施方式

提供参照附图的以下描述以帮助对由权利要求及其等同物限定的本公开的实施例的全面理解。包括各种特定细节以帮助理解，但这些细节仅被视为是示例性的。因此，本领域的普通技术人员将认识到在不脱离本公开的范围和精神的情况下，可对描述于此的实施例进行各种改变和修改。此外，为了清楚和简洁，省略对公知的功能和结构的描述。

在此需要说明的是，在本公开中出现的“若干项之中的至少一项”均表示包含“该若干项中的任意一项”、“该若干项中的任意多项的组合”、“该若干项的全体”这三类并列的情况。例如“包括A和B之中的至少一个”即包括如下三种并列的情况：(1)包括A；(2)包括B；(3)包括A和B。又例如“执行步骤一和步骤二之中的至少一个”，即表示如下三种并列的情况：(1)执行步骤一；(2)执行步骤二；(3)执行步骤一和步骤二。

根据现有的PaaS平台的管理模式和运维方式，难于提供APP概念的抽象，然而，PaaS平台的服务通过APP的形式呈现，用户不会感知底层服务如何维护的，像OS呈现给用户的就是一个一个进程，PaaS平台提供给用户的就是一个一个APP。因此，为了解决现有的问题，本公开提出一种以APP为中心的升级方式，聚焦于基于APP的应用管理。具体地说，可将内置服务和在线服务全部抽象为工作负载(workload)和运维能力(trait)，例如，充分利用kubernetes平台提供的CRD+controller(自定义资源定义+控制器)机制，将kubernetes集群的各种资源抽象并封装为工作负载和运维能力的CRD，并开始各自对应的控制器，通过工作负载和运维能力的组合来实现应用的整个生命周期的管理。所有跑在基础设施集群(例如，基础设施集群可包括kubernetes集群、Hadoop集群、存储集群等)上的应用可以注册为组件(component)，APP就是一个或多个组件构成，然后通过trait提供的各种运维能力，完成一个APP完整功能的提供。为了提高适应不同场景(例如，在线、离线、PaaS Service、PaaSBuild-in Service、有状态、无状态等多种业务场景)的能力，组件可通过内嵌工作负载的方式来注册组件，并支持扩展工作负载(例如，kubernetes集群的CRD)，即，支持自定义的工作负载(workload CRDs)，也就是说，统一的组件方便平台统一管理，组件可通过内嵌不同的工作负载以满足平台自身业务特点。此外，APP的部署可通过声明应用配置文件(Application Configuration)的方式来实现，即，通过一个应用配置文件将组件和运维能力组织起来，基于这个应用配置文件，可满足APP所有的元信息，组件中包括的工作负载对应的控制器(workload controller)和运维能力对应的控制器(trait controller)可根据对应的元信息及预期的逻辑在基础设施集群(例如，kubernetes集群)上创建各种对应的资源以完成一个APP的完整部署。此外，对于抽象出的工作负载和运维能力，可随着需求的迭代，不断沉淀和打磨，不断扩展和完善，成为平台服务APP标准，且有社区、有生态。此外，上述部署APP的方式不仅可用于在平台所依托的作为基础架构的kubernetes集群上部署APP，还可用于在任何可使用上述部署APP的方式的基础设施集群上部署APP，例如，但不限于，ECS、FaaS、Mesos等。

下面，对应用构建平台涉及的相关词汇进行解释。

工作负载(workload)：通过应用构建平台的研发人员对应用构建平台所依托的基础设施集群(例如，kubernetes集群)提供的资源进行抽象而封装了与提供的服务相应的一种或多种资源。

根据本公开的示例性实施例，工作负载可包括与在线服务应用对应的第一工作负载(ServerWorkload)和与离线服务应用对应的第二工作负载(TaskWorkload)中的至少一个。

根据本公开的示例性实施例，当应用构建平台所依托的基础设施集群为kubernetes集群时，第一工作负载可封装的kubernetes集群中的原生资源可包括，但不限于，deployment、statefulset、daemonset、pod、service和configmap等，以满足长期运行(long running)业务特点及期望。这里，deployment是kubernetes的一种原生资源，主要满足多个副本的无状态服务；statefulset是kubernetes的一种原生资源，满足有状态服务，可以提供稳定的持久化存储，稳定的网络标识，有序部署，有序收缩等；daemonset是kubernetes的一种原生资源，确保一个Pod在全部节点或部分节点运行一个Pod；Pod是kubernetes最小的调度单位，Pod由一个或几个容器组成，有独立的网络IP；service是kubernetes的一种原生资源，由于第一工作负载对应在线服务应用，因此，第一工作负载可默认创建service服务，供后续内部负载均衡等能力使用；configmap是kubernetes的一种原生资源，用来保存键值对(key-value pair)配置数据，这个数据可以在pods里使用，或者被用来为像控制器(controller)一样的系统组件存储配置数据，可以把它理解为Linux系统中的/etc目录，专门用来存储配置文件的目录。

根据本公开的示例性实施例，当应用构建平台所依托的基础设施集群为kubernetes集群时，第一工作负载还可封装非kubernetes原生资源，例如，自研的非kubernetes原生资源、kubernetes社区的一些成熟的可用资源(诸如，OpenKruise的CloneSet等)。具体地说，可根据业务需求或者AI应用特点自研或引入非kubernetes原生资源以封装在第一工作负载中。例如，在某些场景如果重新调度会来带不必要的调度开销，同时多容器的Pod，升级sidecar容器导致主容器重启，通常是不可接受的，此时，可引入支持原地升级的Advanced StatefulSet非kubernetes原生资源。

根据本公开的示例性实施例，当应用构建平台所依托的基础设施集群为kubernetes集群时，第二工作负载可封装的kubernetes集群中的原生资源可包括，但不限于，job、cronjob和configmap等原生资源。这里，job是kubernetes的一种原生资源，负责批处理任务，即仅执行一次的任务，保证批处理任务的一个或多个Pod成功结束。cronjob是kubernetes的一种原生资源，负责定时任务，可定时拉起job。

根据本公开的示例性实施例，当应用构建平台所依托的基础设施集群为kubernetes集群时，第二工作负载还可封装非kubernetes原生资源，例如，自研的非kubernetes原生资源、kubernetes社区的一些成熟的可用资源。具体地说，可根据业务需求或者AI应用特点自研或引入非kubernetes原生资源以封装在第二工作负载中。例如，与原生资源DaemonSet类似的Broadcast Job非kubernetes原生资源，可以像daemonset一样在所有节点运行，但是这提供了一个job的能力。

业务相关参数(parameters)：工作负载对外开放的参数，可提供修改工作负载元信息的能力。在部署APP时，可指定与业务相关的各种参数，并将参数传入到工作负载实例中，从而提供给对应的工作负载控制器根据这些元信息产生不同的行为。

根据本公开的示例性实施例，业务相关参数可包括用于获取将使用的镜像的地址的镜像标识、用于指定将使用的模型的地址的环境变量、用于指定将使用的配置文件的参数、镜像启动命令及参数、组件的名称及版本号、服务健康检查探针、服务对外开放的环境变量中的至少一个。这些业务相关参数都是在基础设施集群运行容器的一些基本参数，根据工作负载的不同，具体的业务相关参数也不同。例如，对于第一工作负载来说，业务相关参数可包括用于指示在线服务应用是有状态服务还是无状态服务的第一参数(workloadsubtype字段)，该参数决定后续第一工作负载的控制器拉起基础设施集群原生的服务能力。再例如，对于第二工作负载来说，业务相关参数可用于指示离线服务应用是一次性服务还是定时服务的第二参数(schedule字段)，该参数表示启动离线任务的定时规则，类似操作系统的crontab。

工作负载控制器(Workload Controller)，负责管理对应的工作负载相关的资源。具体地说，工作负载控制器可根据与工作负载实例中的参数对应的元信息，选择创建应对的基础设施集群中的资源。例如，在kubernetes集群的情况下，工作负载控制器可创建一个或者一组deployment、stateful、service、configmap等资源来让APP服务收敛在期望的状态。此外，工作负载控制器可监控对应的资源的变化，让资源的状态收敛在期望的状态里面。此外，当对应的APP被删除时，工作负载控制器自动完成相关资源的回收。

根据本公开的示例性实施例，当用户声明使用与在线服务应用对应的第一工作负载并声明了第一参数时，第一工作负载的控制器根据声明的第一参数的元信息创建deployment、statefulset、daemonset、pod、service和configmap中的一个或多个资源。例如，当第一参数指示在线服务应用为有状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建statefulset、service、configmap等资源，当第一参数指示在线服务应用为无状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建deployment或daemonset资源。

根据本公开的示例性实施例，当用户声明使用与离线服务应用对应的第二工作负载并声明了第二参数，且第二参数指示离线服务应用是一次性服务时，第二工作负载的控制器根据声明的第二参数的元信息创建job资源。当用户声明使用与离线服务应用对应的第二工作负载并声明了第二参数，且第二参数指示离线服务应用是定时服务时，第二工作负载的控制器根据声明的第二参数的元信息创建cronjob或job资源。

运维能力(trait)：通过应用构建平台的研发人员对应用构建平台所依托的基础设施集群(例如，kubernetes集群)提供的资源进行抽象而封装了与提供的运维能力相应的一种或多种资源。例如，每种运维能力为了完成某些特定的运维能力，需要提供对应的信息(例如，参数)，信息的定义可通过CRD元信息来传递。

根据本公开的示例性实施例，运维能力可包括，但不限于，自动弹性扩缩容运维能力(AutoScalerTrait)、负载均衡运维能力(IngressTrait)、自定义服务副本数运维能力(ManualscalerTrait)、持久化管理运维能力(VolumeMounterTrait)和发布策略运维能力(FlaggerTrait)中的至少一个。

下面，以应用构建平台所依托的基础设施集群为kubernetes集群为例，分别具体介绍上述运维能力的特点。

根据本公开的示例性实施例，自动弹性扩缩容运维能力(AutoScalerTrait)可用于提供Pod水平扩缩容的能力，可根据Pod的CPU负载情况和内存使用情况等动态调整服务Pod副本数。自动弹性扩缩容运维能力封装的资源可包括，但不限于，kubernetes集群中的Horizontal Pod Autoscaler、Promethus原生资源。自动弹性扩缩容运维能力对外开放的参数可包括，但不限于，CPU大小(CPU)、存储器大小(memory)、最小副本数(minReplica)和最大副本数(maxReplica)。

根据本公开的示例性实施例，负载均衡运维能力(IngressTrait)可利用kubernetes Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡的能力。负载均衡运维能力封装的资源可包括，但不限于，kubernetes集群中的Service、Ingress原生资源。负载均衡运维能力对外开放的参数可包括，但不限于，请求的路径(Path)、请求的域名(Host)和请求的服务端口(ServicePort)。

根据本公开的示例性实施例，自定义服务副本数运维能力(ManualscalerTrait)可提供自定义服务副本数的能力，指定后副本数将收敛在该期望数值，同时可修改对应工作负载(例如，用户选择和/或配置的工作负载)的副本资源的大小。自定义服务副本数运维能力可根据对应工作负载拉起的对应资源(例如，statefulset、deployment等)，将服务副本数更新到期望值。也就是说，自定义服务副本数运维能力可将对应工作负载拉起的资源进行更新(patch)，自定义服务副本数运维能力能够知道自己被应用于哪个工作负载上，从而能够知道对具体哪些资源(例如，哪个statefulset或哪个deployment等)进行更新(patch)。自定义服务副本数运维能力对外开放的参数可包括，但不限于，副本数(Replica)、可设置的副本的资源(Resource)。例如，可设置的副本的资源可包括CPU大小、存储器大小和GPU大小等。

根据本公开的示例性实施例，持久化管理运维能力(VolumeMounterTrait)可提供业务持久化需求，在部署服务时，声明已经支持的存储类型及挂载路径等信息即可实现服务数据持久化的需求。负载均衡运维能力封装的资源可包括，但不限于，kubernetes集群中的Persistent Volumes、Persistent Volume Claim、StorageClass原生资源以及各种开源的provider资源(例如，OpenEBS等)。持久化管理运维能力对外开放的参数可包括，但不限于，存储卷资源(VolumeResource)、存储类型(StorageType)。其中，存储卷资源可包括使用磁盘的大小(即，存储大小)和挂载路径，存储类型可包括kubernetes集群的多种云原生存储。

根据本公开的示例性实施例，发布策略运维能力(FlaggerTrait)可通过利用开源部署插件Flagger已经支持的发布策略(例如，金丝雀、蓝绿及A/B Testing等)结合运维能力模式，用户简单声明必要策略信息即可使用多种发布策略。发布策略运维能力封装了开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。发布策略运维能力对外开放的参数可包括，但不限于，发布策略参数(Analysis)、发布策略(Policy)。

当然，本公开的运维能力不限于上述提及的运维能力，还可包括其它可能的运维能力，例如，日志运维能力、监控运维能力等。

运维能力控制器(trait controller)：负责管理对应的运维能力相关的资源。具体地说，运维能力控制器可根据与运维能力实例中的参数对应的元信息，选择创建应对的基础设施集群中的资源。

根据本公开的示例性实施例，自动弹性扩缩容运维能力的控制器可通过自动弹性扩缩容运维能力控制kubernetes的HPA，使得HPA根据设置的参数实时监控对应工作负载拉起资源(例如，CPU、memory)的状态信息，根据自动弹性扩缩容运维能力定义的期望负载及期望副本数对对应工作负载的Pod实例数量执行弹性扩缩。

根据本公开的示例性实施例，负载均衡运维能力的控制器可根据与请求的路径、请求的域名和请求的服务端口对应的元信息，创建对应的负载均衡规则。

根据本公开的示例性实施例，自定义服务副本数运维能力的控制器可控制对应工作负载(例如，与在线服务应用对应的第一工作负载)拉起资源的副本数，使得服务实例的副本数在设置的数值内。

根据本公开的示例性实施例，持久化管理运维能力的控制器可根据与存储类型、存储大小和挂载路径对应的元信息，创建对应的持久化存储卷声明(PVC)以及存储类型(StorageClass)并将存储卷挂载到pod内部指定的路径。

根据本公开的示例性实施例，发布策略运维能力的控制器可根据与设置的发布策略参数和设置的发布策略对应的元信息，创建对应的发布策略。

组件(component)：组件是组成一个应用的组成部分，可包括应用所依赖的服务，例如，MySQL数据库、应用服务本身(例如，拥有多个副本的PHP服务器)。例如，所有跑在kubernetes集群上的pod都可声明为组件，包括一些基础的信息，包括镜像、启动参数、健康检测探针、资源等。也就是说，一个应用可由一个或多个组件，有了组件的概念，应用构建平台的架构师可将应用分解成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全、高可扩展性应用的最佳实践：它通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。考虑到应用构建平台的业务复杂程度，可通过内嵌工作负载的方式来注册组件，统一的组件方便统一管理，而内嵌不同的工作负载可开放给平台的维护者，这样可基于平台业务特点来开发不同的工作负载。当应用开发者通过平台将他们写的代码“打包”成一个组件，然后通过编写配置文件来描述该组件与服务之间的关系以及运维能力需求，使得应用开发者能够更专注于与业务相关的开发工作，而不必关注或开发底层架构和运维细节。

应用配置文件(Application Configuration)：为了将声明的组件以及运维能力组织起来，变成一个真正运行起来的应用，可通过编写应用配置文件来实例化这个待运行的应用。应用开发者可利用平台提供的API模块来编写应用配置文件，使得平台能够根据应用开发者提交的应用配置文件，实例化出对应的、真正运行起来的应用，并在平台所依托的基础设施集群上创建对应的资源以完成一个应用的完整部署。

下面将参照图2至图6具体描述根据本公开的示例性实施例的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统。

图2是示出根据本公开的示例性实施例的用户执行应用部署的示意图。

参照图2，用户执行应用部署可包括两个步骤，即，注册组件和部署应用。

注册组件需要声明组件所使用的工作负载及其对外开放的业务相关参数。例如，根据本公开的示例性实施例的工作负载可包括与在线服务应用对应的第一工作负载(ServerWorkload)和与离线服务应用对应的第二工作负载(TaskWorkload)。用户在注册组件时需要声明使用第一工作负载或者第二工作负载或者第一工作负载和第二工作负载两者，此外，还需要声明与声明使用的工作负载对应的业务相关参数(parameters)。当然，根据本公开的示例性实施例的工作负载除了可包括第一工作负载和第二工作负载之外，还可包括其他任何可能的工作负载。

部署应用需要声明使用哪个或哪些组件及其相关信息(例如，名称、版本号等)、使用哪个或哪些运维能力及其参数以及注册组件时所声明的工作负载对外开放的业务相关参数。例如，根据本公开的示例性实施例的运维能力可包括自动弹性扩缩容运维能力(AutoScalerTrait)、负载均衡运维能力(IngressTrait)、自定义服务副本数运维能力(ManualscalerTrait)、持久化管理运维能力(VolumeMounterTrait)和发布策略运维能力(FlaggerTrait)。用户在部署应用时需要声明使用上述运维能力中的哪个或哪些运维能力及其对外开放的参数。当然，根据本公开的示例性实施例的运维能力除了可包括上述运维能力之外，还可包括其他任何可能的运维能力。

图3是示出根据本公开的示例性实施例的应用构建平台的框图。

参照图3，根据本公开的示例性实施例的应用构建平台300(下面，可简称为平台300)可包括工作负载库310、运维能力库320、控制器库330、API模块340。

工作负载库310可包括至少一个工作负载，其中，每个工作负载封装了平台300所依托的基础设施集群中的多种服务相关资源以用于执行对应的服务。

根据本公开的示例性实施例，工作负载库310可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。当然，工作负载库310不限于此，还可包括其它可能的工作负载，例如，与在线离线混合业务应用对应的工作负载等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，第一工作负载可封装kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap等原生资源。此外，第一工作负载还可封装非kubernetes原生资源。第二工作负载可封装了kubernetes集群中的job、cronjob和configmap等原生资源。此外，第二工作负载还可封装非kubernetes原生资源。

运维能力库320可包括至少一个运维能力，其中，每个运维能力封装了平台300所依托的基础设施集群中的多种运维相关资源以用于执行对应的运维。

根据本公开的示例性实施例，运维能力库320可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。当然，运维能力库310不限于此，还可包括其它可能的运维能力，例如，日志运维能力、监控运维能力等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数。负载均衡运维能力可封装kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力。自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小。持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、Persistent VolumeClaim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求。发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

控制器库330可包括每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源。例如，工作负载控制器可根据对应工作负载中的参数来选择创建对应的kubernetes的资源(例如，原生资源或非原生资源)，让APP服务收敛在期望的状态，还可监控对应的资源的变化，让资源的状态收敛在期望的状态里面，此外，当对应的APP被删除时，工作负载控制器可自动完成相关资源的回收。再例如，运维能力控制器可根据对应运维能力中的参数来选择创建对应的kubernetes的资源或者对对应工作负载拉起的资源进行更新(patch)，以满足对应APP的运维需求。

API模块340可用于供用户(例如，应用开发者)配置工作负载和运维能力(例如，包括声明使用哪些工作负载和运维能力及与它们相关的参数)来执行应用的构建。

图4是示出根据本公开的示例性实施例的提供应用构建服务的方法的流程图。

参照图4，在步骤401，可提供至少一个工作负载和至少一个运维能力。其中，每个工作负载封装了平台300所依托的基础设施集群中的多种服务相关资源以用于执行对应的服务，每个运维能力封装了平台300所依托的基础设施集群中的多种运维相关资源以用于执行对应的运维。

根据本公开的示例性实施例，所述至少一个工作负载可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。当然，工作负载不限于此，还可包括其它可能的工作负载，例如，与在线离线混合业务应用对应的工作负载等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，第一工作负载可封装kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap等原生资源。此外，第一工作负载还可封装非kubernetes原生资源。第二工作负载可封装了kubernetes集群中的job、cronjob和configmap等原生资源。此外，第二工作负载还可封装非kubernetes原生资源。

根据本公开的示例性实施例，所述至少一个运维能力可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。当然，运维能力不限于此，还可包括其它可能的运维能力，例如，日志运维能力、监控运维能力等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数。负载均衡运维能力可封装kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力。自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小。持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、Persistent VolumeClaim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求。发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

在步骤402，提供每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源。例如，工作负载控制器可根据对应工作负载中的参数来选择创建对应的kubernetes的资源(例如，原生资源或非原生资源)，让APP服务收敛在期望的状态，还可监控对应的资源的变化，让资源的状态收敛在期望的状态里面，此外，当对应的APP被删除时，工作负载控制器可自动完成相关资源的回收。再例如，运维能力控制器可根据对应运维能力中的参数来选择创建对应的kubernetes的资源或者对对应工作负载拉起的资源进行更新(patch)，以满足对应APP的运维需求。

在步骤403，提供API模块，以供用户(例如，应用开发者)配置工作负载和运维能力(例如，包括声明使用哪些工作负载和运维能力及与它们相关的参数)来执行应用的构建。

当然，本公开对上述步骤401-403的顺序不作限作，上述步骤401-403可按任意顺序或同时执行。

图5是示出根据本公开的示例性实施例的应用部署系统的框图。

参照图5，应用部署系统500可包括业务层模块510和底层模块520两个部分。业务层模块510可包括API模块511、注册组件模块512和部署应用模块513。底层模块520可包括用于管理工作负载和运维能力的控制器库模块，包括至少一个工作负载控制器521和至少一个运维能力控制器522。API模块511可对外提供restfulapi服务，注册组件模块512可定义组件的协议标准并执行组件注册，部署应用模块513可定义应用部署的协议标准并执行应用部署。此外，业务层模块510还可包括适配模块(未示出)，用于在操作系统和控制器库模块之间做一层适配，有了这层适配，业务可以不感知控制器库模块的存在，控制器库模块不耦合业务，仅专注于工作负载和运维能力的维护。

具体地说，API模块511可接收用户(例如，应用开发者)用于注册组件的第一信息。这里，第一信息可包括用于声明所述组件使用的至少一个工作负载和一组业务相关参数(即，对应工作负载对外开放的参数)的信息。这里，用户可按照平台300提供的标准协议(标准配置文件)来声明第一信息。

根据本公开的示例性实施例，所述至少一个工作负载可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。当然，所述至少一个工作负载不限于此，还可包括其它可能的工作负载，例如，与在线离线混合业务应用对应的工作负载等。例如，当平台300所基础设施集群为kubernetes集群时，第一工作负载可封装kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap等原生资源。此外，第一工作负载还可封装非kubernetes原生资源。第二工作负载可封装了kubernetes集群中的job、cronjob和configmap等原生资源。此外，第二工作负载还可封装非kubernetes原生资源。

根据本公开的示例性实施例，所述一组业务相关参数可包括：用于获取将使用的镜像的地址的镜像标识、用于指定将使用的模型的地址的环境变量、用于指定将使用的配置文件的参数、镜像启动命令及参数、所述组件的名称及版本号、服务健康检查探针、服务对外开放的环境变量中的至少一个。

随后，注册组件模块512可根据第一信息创建所述组件以将所述组件注册到平台300所依托的基础设施集群。所述组件内嵌用户声明使用的至少一个工作负载和一组业务相关参数。

随后，API模块511可接收用户(例如，应用开发者)用于部署应用的第二信息。这里，第二信息可包括用于声明所述组件及其相关信息(例如，所述组件的名称、版本号等)、使用的至少一个运维能力及其参数和注册组件时声明的一组业务相关参数的信息。这里，用户可按照平台300提供的标准协议(标准配置文件)来声明第二信息。

根据本公开的示例性实施例，所述至少一个运维能力可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。当然，所述至少一个运维能力不限于此，还可包括其它可能的运维能力，例如，日志运维能力、监控运维能力等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus等资源，用于动态调整服务pod副本数。负载均衡运维能力可封装kubernetes集群中的Service、Ingress等资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力。自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小。持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、PersistentVolume Claim、StorageClass等资源以及多种开源的provider资源，用于提供服务数据持久化需求。发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

根据本公开的示例性实施例，自动弹性扩缩容运维能力的参数可包括，但不限于，CPU大小、存储器大小、最小副本数和最大副本数。负载均衡运维能力的参数可包括，但不限于，请求的路径、请求的域名和请求的服务端口。自定义服务副本数运维能力的参数可包括，但不限于，副本数以及副本的CPU大小、存储器大小和GPU大小。持久化管理运维能力的参数可包括，但不限于，存储类型、存储大小和挂载路径。发布策略运维能力的参数可包括，但不限于，发布策略参数和发布策略。

随后，部署应用模块513可根据第二信息创建应用部署配置文件以将所述应用部署配置文件创建到300所依托的基础设施集群。所述应用部署配置文件包括声明的组件及其相关信息、使用的至少一个运维能力及其参数和注册组件时声明的一组业务相关参数的信息。

随后，所述至少一个工作负载和所述至少一个运维能力可被实例化。例如，可通过平台300所安装的解释器渲染出所述至少一个工作负载的实例，和所述至少一个运维能力的实例。

随后，所述至少一个工作负载和所述至少一个运维能力中的每个工作负载和每个运维能力各自的控制器521、522在监控到对应的工作负载或运维能力被实例化后，根据对应的元信息以创建对应的资源以完成应用的部署。例如，元信息可通过适配模块在执行适配时基于工作负载、运维能力、业务相关参数和运维能力参数而产生的。

根据本公开的示例性实施例，当所述至少一个工作负载包括与在线服务应用对应的第一工作负载时，所述一组业务相关参数可包括指示在线服务应用是有状态服务还是无状态服务的第一参数，第一工作负载的控制器可根据声明的第一参数的元信息创建deployment、statefulset、daemonset、pod、service和configmap中的一个或多个资源。例如，当第一参数指示在线服务应用为有状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建statefulset、service、configmap等资源，当第一参数指示在线服务应用为无状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建deployment或daemonset资源。

根据本公开的示例性实施例，当所述至少一个工作负载包括与离线服务应用对应的第二工作负载时，所述一组业务相关参数可包括指示离线服务应用是一次性服务还是定时服务的第二参数，第二工作负载的控制器可根据声明的第二参数的元信息创建job、cronjob和configmap中的一个或多个资源。例如，当第二参数指示离线服务应用是一次性服务时，第二工作负载的控制器可根据声明的第二参数的元信息创建job资源。当第二参数指示离线服务应用是定时服务时，第二工作负载的控制器可根据声明的第二参数的元信息创建cronjob或job资源。

根据本公开的示例性实施例，当所述至少一个运维能力包括自动弹性扩缩容运维能力时，自动弹性扩缩容运维能力的控制器可通过自动弹性扩缩容运维能力控制kubernetes的HPA，使得HPA根据设置的参数实时监控所述至少一个工作负载拉起资源的状态信息，并可根据自动弹性扩缩容运维能力定义的期望负载及期望副本数对所述至少一个工作负载的Pod实例数量执行弹性扩缩。

当所述至少一个运维能力包括负载均衡运维能力时，负载均衡运维能力的控制器可根据与请求的路径、请求的域名和请求的服务端口对应的元信息，创建对应的负载均衡规则。

当所述至少一个运维能力包括自定义服务副本数运维能力时，自定义服务副本数运维能力的控制器可控制所述至少一个工作负载拉起资源的副本数，使得服务实例的副本数在设置的数值内。

当所述至少一个运维能力包括持久化管理运维能力时，持久化管理运维能力的控制器可根据与存储类型、存储大小和挂载路径对应的元信息，创建对应的持久化存储卷声明以及存储类型并将存储卷挂载到pod内部指定的路径。

当所述至少一个运维能力包括发布策略运维能力时，发布策略运维能力的控制器可根据与设置的发布策略参数和设置的发布策略对应的元信息，创建对应的发布策略。

图6是示出根据本公开的示例性实施例的应用部署方法的流程图。

参照图6，在步骤601，可通过API模块511接收用户(例如，应用开发者)用于注册组件的第一信息。这里，第一信息可包括用于声明所述组件使用的至少一个工作负载和一组业务相关参数(即，对应工作负载对外开放的参数)的信息。这里，用户可按照平台300提供的标准协议(标准配置文件)来声明第一信息。

根据本公开的示例性实施例，所述至少一个工作负载可包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。当然，所述至少一个工作负载不限于此，还可包括其它可能的工作负载，例如，与在线离线混合业务应用对应的工作负载等。例如，当平台300所基础设施集群为kubernetes集群时，第一工作负载可封装kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap等原生资源。此外，第一工作负载还可封装非kubernetes原生资源。第二工作负载可封装了kubernetes集群中的job、cronjob和configmap等原生资源。此外，第二工作负载还可封装非kubernetes原生资源。

根据本公开的示例性实施例，所述一组业务相关参数可包括：用于获取将使用的镜像的地址的镜像标识、用于指定将使用的模型的地址的环境变量、用于指定将使用的配置文件的参数、镜像启动命令及参数、所述组件的名称及版本号、服务健康检查探针、服务对外开放的环境变量中的至少一个。

在步骤602，可通过注册组件模块512根据第一信息创建所述组件以将所述组件注册到平台300所依托的基础设施集群。所述组件内嵌用户声明使用的至少一个工作负载和一组业务相关参数。

在步骤603，可通过API模块511接收用户(例如，应用开发者)用于部署应用的第二信息。这里，第二信息可包括用于声明所述组件及其相关信息(例如，所述组件的名称、版本号等)、使用的至少一个运维能力及其参数和注册组件时声明的一组业务相关参数的信息。这里，用户可按照平台300提供的标准协议(标准配置文件)来声明第二信息。

根据本公开的示例性实施例，所述至少一个运维能力可包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个。当然，所述至少一个运维能力不限于此，还可包括其它可能的运维能力，例如，日志运维能力、监控运维能力等。

根据本公开的示例性实施例，当平台300所基础设施集群为kubernetes集群时，自动弹性扩缩容运维能力可封装kubernetes集群中的Horizontal Pod Autoscaler、Promethus等资源，用于动态调整服务pod副本数。负载均衡运维能力可封装kubernetes集群中的Service、Ingress等资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力。自定义服务副本数运维能力可根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小。持久化管理运维能力可封装kubernetes集群中的Persistent Volumes、PersistentVolume Claim、StorageClass等资源以及多种开源的provider资源，用于提供服务数据持久化需求。发布策略运维能力可封装开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

根据本公开的示例性实施例，自动弹性扩缩容运维能力的参数可包括，但不限于，CPU大小、存储器大小、最小副本数和最大副本数。负载均衡运维能力的参数可包括，但不限于，请求的路径、请求的域名和请求的服务端口。自定义服务副本数运维能力的参数可包括，但不限于，副本数以及副本的CPU大小、存储器大小和GPU大小。持久化管理运维能力的参数可包括，但不限于，存储类型、存储大小和挂载路径。发布策略运维能力的参数可包括，但不限于，发布策略参数和发布策略。

在步骤604，可通过部署应用模块513根据第二信息创建应用部署配置文件以将所述应用部署配置文件创建到平台300所依托的基础设施集群。所述应用部署配置文件包括声明的组件及其相关信息、使用的至少一个运维能力及其参数和注册组件时声明的一组业务相关参数的信息。

在步骤605，所述至少一个工作负载和所述至少一个运维能力可被实例化。例如，可通过平台300所安装的解释器渲染出所述至少一个工作负载的实例，和所述至少一个运维能力的实例。

在步骤606，可通过所述至少一个工作负载和所述至少一个运维能力中的每个工作负载和每个运维能力各自的控制器521、522在监控到对应的工作负载或运维能力被实例化后，根据对应的元信息以创建对应的资源以完成应用的部署。例如，元信息可通过适配模块在执行适配时基于工作负载、运维能力、业务相关参数和运维能力参数而产生的。

根据本公开的示例性实施例，当所述至少一个工作负载包括与在线服务应用对应的第一工作负载时，所述一组业务相关参数可包括指示在线服务应用是有状态服务还是无状态服务的第一参数，第一工作负载的控制器可根据声明的第一参数的元信息创建deployment、statefulset、daemonset、pod、service和configmap中的一个或多个资源。例如，当第一参数指示在线服务应用为有状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建statefulset资源，当第一参数指示在线服务应用为无状态服务时，第一工作负载的控制器根据声明的第一参数的元信息创建deployment资源。

根据本公开的示例性实施例，当所述至少一个工作负载包括与离线服务应用对应的第二工作负载时，所述一组业务相关参数可包括指示离线服务应用是一次性服务还是定时服务的第二参数，第二工作负载的控制器可根据声明的第二参数的元信息创建job、cronjob和configmap中的一个或多个资源。例如，当第二参数指示离线服务应用是一次性服务时，第二工作负载的控制器可根据声明的第二参数的元信息创建job资源。当第二参数指示离线服务应用是定时服务时，第二工作负载的控制器可根据声明的第二参数的元信息创建cronjob资源。

根据本公开的示例性实施例，当所述至少一个运维能力包括自动弹性扩缩容运维能力时，自动弹性扩缩容运维能力的控制器可通过自动弹性扩缩容运维能力控制kubernetes的HPA，使得HPA根据设置的参数实时监控所述至少一个工作负载拉起资源的状态信息，并可根据自动弹性扩缩容运维能力定义的期望负载及期望副本数对所述至少一个工作负载的Pod实例数量执行弹性扩缩。

当所述至少一个运维能力包括负载均衡运维能力时，负载均衡运维能力的控制器可根据与请求的路径、请求的域名和请求的服务端口对应的元信息，创建对应的负载均衡规则。

当所述至少一个运维能力包括自定义服务副本数运维能力时，自定义服务副本数运维能力的控制器可控制所述至少一个工作负载拉起资源的副本数，使得服务实例的副本数在设置的数值内。

当所述至少一个运维能力包括持久化管理运维能力时，持久化管理运维能力的控制器可根据与存储类型、存储大小和挂载路径对应的元信息，创建对应的持久化存储卷声明以及存储类型并将存储卷挂载到pod内部指定的路径。

当所述至少一个运维能力包括发布策略运维能力时，发布策略运维能力的控制器可根据与设置的发布策略参数和设置的发布策略对应的元信息，创建对应的发布策略。

下面，将详细介绍将根据本公开的示例性实施例的通过应用构建平台部署应用的方法应用于一个推荐服务应用的场景。

场景描述：推荐服务应用输入为用户标识信息、用户访问的物料及待推荐的物料列表，推荐服务应用输出为推荐物料列表的排名，并将排名靠前的物料推荐给用户。

服务要求：推荐服务应用提供对外访问的能力，接收用户请求，并提供A/BTesting的能力以判断不同模型对用户点击率(CTR)的影响。

部署步骤：

1、声明组件(如已声明组件，则跳过此步骤)。声明组件可通过编写标准协议来完成。声明组件需要声明的信息及对外开放的参数可包括：通过第一参数(workloadsubtype字段)指定推荐服务为在线服务且无状态服务；推荐服务的镜像标识，根据该标识可以拉取到镜像地址；推荐服务使用的模型地址，可通过环境变量指定；推荐服务使用的配置文件，可通过config字段指定；启动服务默认资源(例如，CPU和memory)、组件的名字和版本(例如，sage-rec-svc,1.0.0)；服务健康检查探针(例如，liveness和readiness)；指定服务对外开放的环境变量，部署服务时可传入。

2、按照标准协议填写完成后，可通过restfulapi将组件注册到基础设施集群。

3、部署应用。部署应用可通过编写标准协议来完成。部署应用需要指定如下信息：指定使用推荐服务的组件(可通过组件名称来指定)及其版本号；部署应用时使用的应用名称；声明使用的运维能力；声明在声明组件时所声明的对外开放的参数。

这里，根据上述服务要求，需要声明三个运维能力，即，负载均衡运维能力、自定义服务副本数运维能力(提供手动改副本资源的能力)、发布策略运维能力(提供A/B Testing的能力)。

4、通过restfulapi将部署应用的元信息创建到基础设施集群。

5、部署应用的元信息到基础设施集群后，平台安装的解释器会渲染出与在线服务应用对应的第一工作负载实例和上述三个运维能力实例。

6、当在线服务应用对应的第一工作负载的控制器和上述三个运维能力的控制器监控到对应工作负载和运维能力实例的创建后，根据元信息创建预估服务。

7、负载均衡运维能力根据已创建Service创建Ingress规则,对外提供预估服务。

8、由于需要A/B Testing的能力，因此可组件sage-rec-svc:1.0.0升级到sage-rec-svc:1.0.1，主要更新第一工作负载中镜像。

9、对已经部署应用进行升级，将组件的版本号信息从1.0.0升级到1.0.1，然后配置A/B Testing规则。

10、通过restfulapi将更新信息提交到基础设施集群，更新生效后，用户(例如，应用使用者)可以根据配置的规则及负载均衡能力访问服务。

根据本公开的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统，通过工作负载来对平台所依托的基础设施集群的多种服务资源进行组织、封装和管理，通过运维能力来对平台所依托的基础设施集群的多种运维资源进行组织、封装和管理，从而可提供上层开发应用所需要的全部产品功能，这不仅能够提供更丰富的业务需求，且所有行为可控，同时满足社区标准和生态，便于后续和社区的融合，还能够使应用开发者仅需专注于与业务相关的开发工作，而不必关注或开发底层架构和运维细节。

此外，根据本公开的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统，应用的管理全部围绕对工作负载和运维能力的管理。随着产品的迭代升级及探索，能够不断强化和稳定工作负载和运维能力，上层应用开发者只需通过声明使用即可。

此外，根据本公开的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统，由于组件信息可包括组件名称和组件版本号，因此，应用升级时，可新增版本号，这不会影响已有服务，只需要在应用配置文件中声明新的版本号即可。

此外，根据本公开的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统，应用的交付围绕着组件的形式交付,这样可以按单个应用或者指定应用交付即可。由于从大量的yaml文件转移到工作负载和运维能力的组合声明上，原来需要全量渲染template模板，现在只需要升级对应的组件或者应用配置文件即可，而工作负载和运维能力是kubernetes的运维，可充分利用kubernetes提供的扩展机制及其自身机制的稳定性，现在的交付指定升级的应用的镜像，对组件中工作负载使用的镜像进行升级即可，不用通过离线包这种繁重交付方式，并且有了工作负载和运维能力这套标准，开发、运维、交付在标准中进行协作，大大减少了沟通成本。

以上已参照图2至图6描述了根据本公开示例性实施例的提供应用构建服务的方法和应用构建平台以及应用部署方法和系统。

图3所示出的应用构建平台和图5所示出的通过应用构建平台应用部署系统中的各个模块可被配置为执行特定功能的软件、硬件、固件或上述项的任意组合。例如，各个模块可对应于专用的集成电路，也可对应于纯粹的软件代码，还可对应于软件与硬件相结合的模块。此外，各个模块所实现的一个或多个功能也可由物理实体设备(例如，处理器、客户端或服务器等)中的组件来统一执行。

此外，参照图4所描述的提供应用构建服务的方法和图6所描述的应用部署方法可通过记录在计算机可读存储介质上的程序(或指令)来实现。例如，根据本公开的示例性实施例，可提供存储指令的计算机可读存储介质，其中，当所述指令被至少一个计算装置运行时，促使所述至少一个计算装置执行根据本公开的提供应用构建服务的方法和/或应用部署方法。

上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，应注意，计算机程序还可用于执行除了上述步骤以外的附加步骤或者在执行上述步骤时执行更为具体的处理，这些附加步骤和进一步处理的内容已经在参照图4和图6进行相关方法的描述过程中提及，因此这里为了避免重复将不再进行赘述。

应注意，根据本公开示例性实施例的应用构建平台和应用部署系统中的各个模块可完全依赖计算机程序的运行来实现相应的功能，即，各个模块在计算机程序的功能架构中与各步骤相应，使得整个系统通过专门的软件包(例如，lib库)而被调用，以实现相应的功能。

另一方面，图3和图5所示的各个模块也可以通过硬件、软件、固件、中间件、微代码或其任意组合来实现。当以软件、固件、中间件或微代码实现时，用于执行相应操作的程序代码或者代码段可以存储在诸如存储介质的计算机可读介质中，使得处理器可通过读取并运行相应的程序代码或者代码段来执行相应的操作。

例如，本公开的示例性实施例还可以实现为计算装置，该计算装置包括存储部件和处理器，存储部件中存储有计算机可执行指令集合，当计算机可执行指令集合被处理器执行时，执行根据本公开的示例性实施例的提供应用构建服务的方法和/或应用部署的方法。

具体说来，计算装置可以部署在服务器或客户端中，也可以部署在分布式网络环境中的节点装置上。此外，计算装置可以是PC计算机、平板装置、个人数字助理、智能手机、web应用或其他能够执行上述指令集合的装置。

这里，计算装置并非必须是单个的计算装置，还可以是任何能够单独或联合执行上述指令(或指令集)的装置或电路的集合体。计算装置还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程(例如，经由无线传输)以接口互联的便携式电子装置。

在计算装置中，处理器可包括中央处理器(CPU)、图形处理器(GPU)、可编程逻辑装置、专用处理器系统、微控制器或微处理器。作为示例而非限制，处理器还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。

根据本公开示例性实施例的提供应用构建服务的方法和/或应用部署方法中所描述的某些操作可通过软件方式来实现，某些操作可通过硬件方式来实现，此外，还可通过软硬件结合的方式来实现这些操作。

处理器可运行存储在存储部件之一中的指令或代码，其中，存储部件还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。

存储部件可与处理器集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储部件可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储部件和处理器可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器能够读取存储在存储部件中的文件。

此外，计算装置还可包括视频显示器(诸如，液晶显示器)和用户交互接口(诸如，键盘、鼠标、触摸输入装置等)。计算装置的所有组件可经由总线和/或网络而彼此连接。

根据本公开示例性实施例的提供应用构建服务的方法和/或应用部署方法可被描述为各种互联或耦合的功能块或功能示图。然而，这些功能块或功能示图可被均等地集成为单个的逻辑装置或按照非确切的边界进行操作。

因此，参照图4所描述的提供应用构建服务的方法和参照图6所描述的应用部署方法可通过包括至少一个计算装置和至少一个存储指令的存储装置的系统来实现。

根据本公开的示例性实施例，至少一个计算装置是根据本公开示例性实施例的用于提供应用构建服务的方法和/或通应用部署方法的计算装置，存储装置中存储有计算机可执行指令集合，当计算机可执行指令集合被至少一个计算装置执行时，执行参照图4所描述的提供应用构建服务的方法和/或参照图6所描述的应用部署方法。

以上描述了本公开的各示例性实施例，应理解，上述描述仅是示例性的，并非穷尽性的，本公开不限于所披露的各示例性实施例。在不偏离本公开的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。因此，本公开的保护范围应该以权利要求的范围为准。

Claims (14)

1.一种提供应用构建服务的方法，包括：

提供至少一个工作负载和至少一个运维能力，其中，每个工作负载封装了基础设施集群中的多种资源相关服务用于执行对应的服务，每个运维能力封装了所述基础设施集群中的多种运维相关资源以用于执行对应的运维；

提供每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源；

提供API模块，其中，所述API模块用于使用户通过API模块配置工作负载和运维能力以执行应用的构建；

其中，所述至少一个运维能力包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个，所述基础设施集群包括kubernetes集群，所述自动弹性扩缩容运维能力封装了kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数；

负载均衡运维能力封装了kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力；

自定义服务副本数运维能力根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小；

持久化管理运维能力封装了kubernetes集群中的Persistent Volumes、PersistentVolume Claim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求；

发布策略运维能力封装了开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

2.如权利要求1所述的方法，其中，所述至少一个工作负载包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。

3.如权利要求2所述的方法，其中，第一工作负载封装了kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap原生资源。

4.如权利要求3所述的方法，其中，第一工作负载还封装了非kubernetes原生资源。

5.如权利要求2所述的方法，其中，第二工作负载封装了kubernetes集群中的job、cronjob和configmap原生资源。

6.如权利要求5所述的方法，其中，第二工作负载还封装了非kubernetes原生资源。

7.一种应用构建平台，包括：

工作负载库，包括至少一个工作负载，其中，每个工作负载封装了所述应用构建平台所依托的基础设施集群中的多种服务相关资源以用于执行对应的服务；

运维能力库，包括至少一个运维能力，其中，每个运维能力封装了所述基础设施集群中的多种运维相关资源以用于执行对应的运维；

控制器库，包括每个工作负载和每个运维能力各自的控制器，其中，每个控制器用于管理对应的工作负载或运维能力相关的资源；

API模块，用于使用户通过API模块配置工作负载和运维能力以执行应用的构建；

其中，所述至少一个运维能力包括自动弹性扩缩容运维能力、负载均衡运维能力、自定义服务副本数运维能力、持久化管理运维能力和发布策略运维能力中的至少一个，所述基础设施集群包括kubernetes集群，所述自动弹性扩缩容运维能力封装了kubernetes集群中的Horizontal Pod Autoscaler、Promethus资源，用于动态调整服务pod副本数；

负载均衡运维能力封装了kubernetes集群中的Service、Ingress资源，用于利用kubernetes集群中的Ingress已有的负载均衡能力结合用户配置的工作负载所创建的服务提供负载均衡能力；

自定义服务副本数运维能力根据用户配置的工作负载拉起的对应资源，将服务副本数更新到期望值，用于将服务副本数收敛在自定义的服务副本数的数值内和/或修改用户配置的工作负载的副本资源大小；

持久化管理运维能力封装了kubernetes集群中的Persistent Volumes、PersistentVolume Claim、StorageClass资源以及多种开源的provider资源，用于提供服务数据持久化需求；

发布策略运维能力封装了开源的发布策略Flagger资源，控制Flagger的行为以使Flagger来控制工作负载拉起的资源，用于支持用户配置发布策略。

8.如权利要求7所述的应用构建平台，其中，所述至少一个工作负载包括与在线服务应用对应的第一工作负载和与离线服务应用对应的第二工作负载中的至少一个。

9.如权利要求8所述的应用构建平台，其中，第一工作负载封装了kubernetes集群中的deployment、statefulset、daemonset、pod、service和configmap原生资源。

10.如权利要求9所述的应用构建平台，其中，第一工作负载还封装了非kubernetes原生资源。

11.如权利要求8所述的应用构建平台，其中，第二工作负载封装了kubernetes集群中的job、cronjob和configmap原生资源。

12.如权利要求11所述的应用构建平台，其中，第二工作负载还封装了非kubernetes原生资源。

13.一种存储指令的计算机可读存储介质，其中，当所述指令被至少一个计算装置运行时，促使所述至少一个计算装置执行如权利要求1至6中的任一权利要求所述的提供应用构建服务的方法。

14.一种包括至少一个计算装置和至少一个存储指令的存储装置的系统，其中，所述指令在被所述至少一个计算装置运行时，促使所述至少一个计算装置执行如权利要求1至6中的任一权利要求所述的提供应用构建服务的方法。