云服务实现方法及装置与流程

1.本公开涉及云计算技术领域，尤其涉及一种云服务实现方法及装置。


背景技术：

2.云计算时代出现了大量xaas形式的概念，从基础设施即服务(infrastructure as a service，iaas)、平台即服务(platform as a service，paas)、软件即服务(software as a service，saas)等等，它们都在试着将各种软、硬件资源等抽象为一种服务提供给开发者使用，让开发者们更加专注于业务逻辑，无需关注基础设施。
3.其中，函数即服务(function-as-a-service，faas)，它基于无服务器运算(serverless computing，serverless)的理念进行塑造，是目前较为先进的云计算产品。faas为云中运行的应用程序提供了一种全新的系统体系结构，faas通过部署用户提供函数代码，再通过事件机制触发函数代码执行。
4.然而，如何推进目前的faas产品进一步向serverless方向演进，优化faas服务架构是当前亟待解决的问题。


技术实现要素：

5.为了解决上述技术问题，本公开提供了一种云服务实现方法及装置。
6.第一方面，本公开实施例提供了一种云服务实现方法，其特征在于，包括：
7.响应客户端发送的业务请求，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务；
8.在所述应用实例中根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中；
9.在所述应用实例中基于相应的应用镜像创建应用容器，并从所述共享目录盘读取所述二进制执行文件注入到所述应用容器中；所述应用镜像是基于用户上传至云计算系统中的原生应用得到；所述原生应用包括所述目标服务对应的函数代码以及所述目标服务对应的配置项的配置信息；
10.运行所述应用容器中的所述二进制执行文件以启动运行时代理进程；以及，调用所述运行时代理进程控制所述应用实例中的运行时进程执行所述应用镜像中的文件以处理所述业务请求。
11.在一些实施例中，所述响应客户端发送的业务请求，生成目标服务对应的应用实例，包括：
12.在所述业务请求冷启动时，从冷启动资源池维护的多个空闲应用实例中调度一个空闲应用实例作所述目标服务对应的应用实例，所述多个空闲示例基于第二预设镜像创建；
13.在所述应用实例中基于相应的应用镜像创建应用容器，包括：
14.将所述空闲应用实例对应的业务容器中的第二基础镜像替换为所述应用镜像，并
重启以得到所述应用容器。
15.在一些实施例中，所述在所述应用实例中基于相应的应用镜像创建应用容器，包括：
16.从镜像仓库中拉取所述应用镜像的元信息；
17.基于所述应用镜像的元信息创建所述应用容器。
18.在一些实施例中，所述目标服务对应的配置项包括：监听端口、启动命令、健康检查接口以及函数生命周期中一项或多项。
19.在一些实施例中，所述在所述应用实例中根据第一基础镜像创建初始化容器之前，所述方法还包括：
20.调用所述云计算系统中的流量调用端口将所述业务请求对应的流量调度至所述应用实例；
21.调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例。
22.在一些实施例中，所述调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例，包括：
23.从各正在运行的应用实例分别对应的数据请求端口中，调用所述业务请求对应的应用实例对应的目标数据请求端口将所述业务请求转发给所述应用实例，所述目标数据请求端口支持的通信协议与所述业务请求采用的通信协议一致。
24.在一些实施例中，所述调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例之前，所述方法还包括：
25.对所述业务请求采用的通信协议进行识别得到识别结果，基于识别结果控制所述业务请求传输至多个网关中与所述业务请求的通信协议一致的网关，通过所述网关将所述业务请求转发至相应的数据请求端口；其中，所述多个网关分别用于转发不同通信协议的业务请求。
26.在一些实施例中，所述通过所述网关将所述业务请求转发至相应的数据请求端口，包括：
27.通过所述网关对所述业务请求的请求头进行解析得到服务的元信息，基于所述服务的元信息从相连接的多个数据请求端口中确定目标数据请求端口；以及，将所述业务请求转发至所述目标数据请求端口。
28.在一些实施例中，所述对所述业务请求采用的通信协议进行识别得到识别结果，基于识别结果控制所述业务请求传输至多个网关中与所述业务请求的通信协议一致的网关之前，所述方法还包括：
29.识别到所述客户端发送的所述业务请求采用第一指定通信协议时，将所述第一指定通信协议的业务请求转换为第二指定通信协议的业务请求。
30.在一些实施例中，所述响应客户端发送的业务请求，生成目标服务对应的应用实例之前，还包括：
31.接收所述客户端发送的所述业务请求，并从多种接口定义语言中确定与所述业务请求所采用的通信协议对应的目标接口定义语言；
32.基于所述目标接口定义语言生成所述业务请求对应的事件对象，以及，将所述业务请求对应的事件对象发送至所述目标服务，以触发所述目标服务响应所述业务请求生成
所述应用实例。
33.第二方面，本公开提供了一种云服务实现装置，包括：
34.实例生成模块，用于响应客户端发送的业务请求，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务；
35.第一处理模块，用于在所述应用实例中根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中；
36.第二处理模块，用于在所述应用实例中基于相应的应用镜像创建应用容器，并从所述共享目录盘读取所述二进制执行文件注入到所述应用容器中；所述应用镜像是基于用户上传至云计算系统中的原生应用得到；所述原生应用包括所述目标服务对应的函数代码以及所述目标服务对应的配置项的配置信息；
37.运行模块，用于运行所述应用容器中的所述二进制执行文件以启动运行时代理进程；以及，调用所述运行时代理进程控制所述应用实例中的运行时进程执行所述应用镜像中的文件以处理所述业务请求。
38.第三方面，本公开提供了一种电子设备，存储器和处理器；
39.所述存储器被配置为存储计算机程序指令；
40.所述处理器被配置为执行所述计算机程序指令，使得所述电子设备实现如第一方面及第一方面任一项所述的云服务实现方法。
41.第四方面，本公开提供了一种可读存储介质，包括：计算机程序指令；电子设备的至少一个处理器执行所述计算机程序指令，使得所述电子设备实现如第一方面及第一方面任一项所述的云服务实现方法。
42.第五方面，本公开提供一种计算机程序产品，电子设备执行所述计算机程序产品，使得所述电子设备实现如第一方面以及第一方面任一项所述的云服务实现方法。
43.本公开实施例提供一种云服务实现方法及装置，其中，本公开提供的方法通过采用用户自定义的应用镜像实现了云计算系统对于原生应用的支持，其中，应用镜像是基于用户上传至云计算系统中的原生应用得到；原生应用包括服务对应的函数代码以及服务对应的配置项的配置信息；且通过初始化容器的方式为基于应用镜像创建的应用容器注入所需依赖，解决了用户自定义镜像发布带来的运行时代理的二进制注入问题，保证用户开发的云计算服务对应的应用实例能够正常启动，进而保证客户端发送的业务请求能够被执行；从而实现了支持用户将多种不同类型的原生应用迁移至云计算系统，实现低成本无服务器化。此外，本公开提供的方法对用户的原有镜像不做构建阶段的侵入性修改。且本公开提供的方法能够支持各种语言开发的原生应用，也不会增加用户的学习开发成本。
附图说明
44.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
45.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
46.图1为本公开实施例提供的云计算系统的整体架构图；
47.图2为本公开一实施例提供的云服务实现方法的流程示意图；
48.图3为本公开提供的应用实例内各容器的启动顺序示意图；
49.图4为本公开一实施例提供的现有的faas支持用户应用的框架与本公开中faas支持用户应用的区别示意图；
50.图5为本公开实施例提供的数据调用链路和流量调用链路的示意图；
51.图6为本公开实施例提供的数据调用链路和流量调用链路解耦后的整体框架示意图；
52.图7为本公开一实施例提供的支持多协议的云计算系统的架构示意图；
53.图8a为本公开一实施例提供的基于图7所示的云服务实现方法的流程示意图；
54.图8b为本公开另一实施例提供的基于图7所示的云服务实现方法的流程示意图；
55.图9为本公开实施例提供的http协议的数据包结构示意图；
56.图10为本公开实施例提供的http协议的多链路复用结构示意图；
57.图11为本公开实施例提供的faas中数据调用链路对于http请求的框架图；
58.图12为本公开实施例提供的faas中数据调用链路对于http请求以及grpc请求的框架图；
59.图13为本公开实施例提供的thrift框架灵活的分层实现示意图；
60.图14为本公开实施例提供的第二指定通信协议的数据包结构示意图；
61.图15为本公开实施例提供的faas中数据调用链路同时处理http请求、grpc请求以及thrift请求的框架图；
62.图16为本公开实施例提供的对业务请求进行协议转换的框架示意图；
63.图17为本公开实施例提供的faas中事件触发器组件的结构示意图；
64.图18为本公开提供的一种云服务实现装置的结构示意图；
65.图19为本公开提供的一种电子设备的结构示意图。
具体实施方式
66.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
67.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
68.示例性地，以云计算系统为faas为例，目前的faas无法满足以下业务需求：
69.1、改造成本较高：在服务开发过程中，事件类型faas函数需要用户针对faas的不同语言的运行时(runtime)进行适配，将原有的业务逻辑抽象成faas的异步消息处理(handler)，对于业务团队，没有动力做应用迁移。
70.2、多语言支持不到位：faas的运行时限定了用户的语言选择，对于一些使用量少的语言场景无法覆盖，导致faas对于多语言支持不够。
71.3、用户学习成本较高：faas为用户提供函数handler接口的本意是希望减少用户
开发迭代成本，然而，在faas服务开发过程中用户需要学习faas为用户提供的handler接口使用方法，使得faas服务开发增加了用户的学习成本。
72.4、与内部服务治理体系难以对齐：框架本身为用户提供了脚手架代码生成和服务治理、监控、日志、运维等一系列能力。faas平台提供的一部分能力和框架与服务网格(mesh)架构的服务治理体系之间存在重叠，无法做到对齐。使用户运行在faas上的应用无法与服务监控治理体系(即mesh)结合。
73.5、rpc协议支持：基于http触发器faas能够较好地覆盖大多数http在线服务的场景，开发前端服务和后端rsetful api。然而，从后端服务视角来看，无法满足rpc协议传递的后端流量，因此，长期来看，在serverless/faas场景下对于多协议的支持也必须有所突破。
74.基于以上分析，为此确定faas支持微服务方向的目标以及要解决的技术问题：
75.1、如何实现支持用户将多种不同类型的原生应用(如http框架、rpc协议和框架、具有负载依赖的业务)迁移，实现业务的低成本serverless化。
76.2、在原生应用serverless化的基础上，实现将已有的事件源(消息队列、定时器、数据库binlog等等)进行与业务进行对接，提供额外的功能优势。
77.3、基于统一的faas架构进行迭代，和事件类型的faas函数一样，提供完整的冷启动、自动扩缩容能力，为业务方节省业务及资源成本，进一步降本增效。
78.为了解决上述问题，本公开提供一种云服务实现方法、装置及云计算系统，其中，云计算系统通过采用用户自定义的应用镜像实现了云计算系统对于原生应用的支持；且通过初始化容器方式为应用镜像注入所需依赖，解决了用户自定义镜像发布带来的运行时代理的二进制注入问题，保证用户开发的云计算服务对应的应用实例能够正常启动；此外，本公开提供的云计算系统对用户的原有应用镜像不做构建阶段的侵入性修改。通过云计算系统对原生应用的支持，用户可以在各种开发框架中进行应用开发，无需限制开发语言和开发环境，用户无需学习云计算系统提供的handler接口，大幅降低了用户的学习成本。且该方式能够完整保留冷启动能力以及自动扩缩容能力。
79.此外，本公开通过将数据调用链路与流量调用链路进行解耦，解耦之后可以将多协议的适配改造收敛在数据调用链路中，完成云计算系统对于多协议的支持。本公开还通过对指定通信协议的业务请求进行协议转换，使其能够满足云计算系统指定的通信协议要求，从而完成存量业务迁移。本公开还通过对触发器组件进行改造，使其满足多协议业务请求的事件触发，保证多协议的业务请求能够被正确响应。通过增加端口、协议转换适配以及对触发器组件的改造，实现了云计算系统对于多协议的支持，极大满足用户需求。且与已有事件源对接，
80.下面将通过以下具体实施例对本公开提供的云计算系统以及云服务实现方法进行详细介绍。
81.图1为本公开提供的云计算系统的整体架构示意图。请参阅图1所示，图1所示的云计算系统可以但不限为faas，此处以faas为例进行举例。假设，针对某个区域部署的faas可以包括一个或者多个中心机房，每个中心机房可以有一个或多个函数服务集群，函数服务集群可以包括一个或多个服务节点，各服务节点分别用于提供一种或多种云计算服务，因此，服务节点也可以理解为计算节点；客户端可以发送业务请求调用部署在云计算系统中
的云计算服务，其中，不同中心机房的服务结构可以基本保持一致，按照相应的接入层流量比例共同分担计算、存储、网络等负载，不同的中心机房也可以形成互备的容灾体系。
82.其中，从数据接入以及数据源来角度，可以包括以下几类触发：
83.1、负载均衡器(load balance)的在线流量，比如前端调用，内部工具api调用等等。
84.2、服务网格(mesh)调用流量，一般承载微服务之间的调用流量。
85.3、消息队列调用流量，承载faas内部在线，离线消息队列的消息处理流量，同时也作为底层通道承载数据库二进制日志(binlog)，对象存储事件等消息处理。
86.4、定时器(timer)调用流量，负责基于faas构建的定时器相关的调用流量。
87.因此，在本实施例提供的faas中，包括触发器组件，触发器组件包括：负载均衡处理器、消息队列触发器、定时触发器等等。
88.此外，由于faas是承载应用的平台，因此，还包含了构建、发布组件，同时基于日志(logging)、指标(metrics)、调用链(trace)等建设了可观性工具和面板，即服务网格(mesh)。从流量调度方面，faas中还拥有网关(gateway)和分发器(dispatcher)针对流量和并发进行精细的计算和调度。
89.一些实施例中，faas的整体架构可以构建在kubernetes框架之上，分场景使用不同的轻量化运行时来承载用户的应用实体。kubernetes节点上有一个伴生进程(hostagent)，应用实例(pod)内有一个伴生进程(runtimeagent)，负责管理函数的生命周期，代理函数请求等等。在kubernetes周边为了满足冷启动低延时和高可靠的需求，打造了独立的服务发现组件(discovery)、冷启动池组件(workermanager)来保证服务的稳定性和高可用性。此外，faas是一个自动扩缩的系统，因此，还打造了独立的指标聚合存储组件(metrics aggregation server，mas)和自动扩缩容组件(autoscaler)构建指标体系和扩缩容体系的高内聚系统。
90.示例性地，通过图2至图4所示实施例，并结合图1所示实施例中云计算系统的架构，以faas为例对云计算系统实现原生应用支持进行详细介绍。
91.本公开通过对云计算系统进行改造，使其具有支持用户自动定义镜像的能力，从而实现faas对原生应用的支持。具体地，目前的faas提供的运行时每个runtime对应一个基础镜像，通过镜像代码分离的方式对冷启动进行了一系列的优化，但同时也存在不少限制，其中之一就是很多用户服务的特定依赖需求无法得到满足。为此本公开提供的云计算系统引入自定义镜像的方案来满足用户自定义依赖的需求，其中，自定义镜像就是用户自己定制应用镜像，然后提交给faas进行部署，faas会采用用户提供的应用镜像启动容器。
92.由于用户自定义镜像中不包含runtimeagent的二进制执行文件，而runtimeagent是不可或缺的进程，因此，本公开通过在函数服务集群生态上使用初始化容器的方式为用户自定义镜像注入启动runtimeagent的二进制执行文件。
93.图2为本公开一实施例提供的云服务实现方法的流程示意图。请参阅图2所示，本实施例的方法包括：
94.s201、响应客户端发送的业务请求，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务。
95.其中，客户端可以为但不限于为其他云计算服务节点，业务请求用于请求调用云
计算系统中的目标服务，结合图1所示，目标服务可以预先部署在云计算系统某个函数服务集群所包括的目标服务节点中。客户端发送的业务请求可以经过触发器组件、网关以及分发器等组件传递到相应函数服务集群时，可以通过调用函数服务集群中的目标服务节点响应客户端发送的业务请求实时创建应用实例作为响应业务请求的应用实例或者从冷启动池组件所维护的空闲应用实例中调度一个作为响应业务请求的应用实例。
96.结合前述图1所示框架的介绍可知，业务请求可以通过事件触发的方式通知目标服务节点创建或调度业务请求对应的应用实例。
97.s202、在所述应用实例中根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中。
98.s203、在所述应用实例中基于相应的应用镜像创建应用容器，并从所述共享目录盘读取所述二进制执行文件注入到所述应用容器中。
99.如图3所示，初始化容器(init容器)是一种特殊的容器，在应用实例pod的应用容器启动之前运行。init容器中可以包括一些应用镜像中不存在的常见工具和安装脚本，应用实例中可以有多个应用容器，用户上传部署的应用/服务运行在这些应用容器中，同时应用实例可以有一个或多个先于应用容器启动的init容器。
100.init容器与普通的容器类似，但有以下两点区别：1、总是运行直到结束；2、每个都必须在下一个启动之前成功完成。
101.通过在应用实例中加入init容器的配置，采用预先设置的第一基础镜像启动init容器，并且在init容器启动命令中将第一基础镜像中的runtimeagent的二进制执行文件复制到应用实例对应的共享目录盘中，这样便可以实现在应用容器中获取到二进制执行文件，保证在应用容器中能够启动runtimeagent进程。
102.其中，若响应业务请求的应用实例是从冷启动池组件中调度的，由于冷启动池中维护的空闲应用实例包含预启动好的、不包含任何函数信息的空跑的业务容器，在业务请求对应的函数(即服务)需要冷启动时，可以从冷启动池中获取一个未被使用过的空闲应用实例，再从镜像仓库中拉取并装载所需应用镜像完成冷启动，以此来优化容器调度以及创建的时间。在自定义镜像场景，由于业务请求对应的冷启动请求未达到之前，无法确定采用哪个镜像，只能在冷启动请求到达时才能确定，为了减小实时调度以及创建容器的时间，所以同样基于warming pool方案，本公开通过采用预设的第二基础镜像预先创建一些空跑的业务容器，并且采用初始化容器机制将runtimeagent的二进制执行文件注入到共享目录盘中，冷启动请求到达时，将所调度的空闲应用实例中的业务容器中的第二基础镜像替换为应用镜像，并且通过重启的方式，将空闲的业务容器转换为能够正常运行的应用容器。
103.需要说明的是，本公开中的应用镜像是基于用户上传至云计算系统中的原生应用得到的，原生应用是一个完整的应用，其中包含目标服务对应的函数代码和目标服务对应的配置项的配置信息。
104.原生应用可以是用于基于任意框架开发的，本公开对此不作限定。
105.s204、运行所述应用容器中的所述二进制执行文件以启动运行时代理进程；调用所述运行时代理进程控制所述应用实例中的运行时进程执行所述应用镜像中的文件以处理所述业务请求。
106.如前所述在faas中runtimeagent进程负责管理函数的生命周期以及代理函数请
求等等，通过运行注入到应用容器中的二进制执行文件可以以启动runtimeagent进程，再通过runtimeagent进程控制启动运行时进程(即runtime)，再将业务请求的信息作为应用镜像所定义的函数的输入，经过计算可以得到业务请求的处理结果。
107.本实施例，通过采用用户自定义的应用镜像实现了云计算系统对于原生应用的支持；且通过初始化容器方式为应用镜像注入所需依赖，解决了用户自定义镜像发布带来的运行时代理的二进制注入问题，保证用户开发的云计算服务对应的应用实例能够正常启动；此外，本实施例的方法对用户的原有镜像不做构建阶段的侵入性修改。
108.在图2所示实施例的基础上，直接采用用户提供的镜像会引入冷启动慢的问题，oci(open container initiative)镜像拉取通常耗时在秒级以上，遇到镜像体积较大的可能耗时在几十秒，因此，本公开还需要在自定义镜像功能的基础上尽量避免冷启动时间过长的问题。
109.容器主要是由镜像和隔离以及安全技术组成，当需要启动一个容器时，通常需要先将完整的镜像拉取到本地，然后解压，再启动容器。在整个容器生命周期，镜像拉取是最耗时的步骤之一，然而，容器启动所需的数据一般只占镜像的一小部分，因此，本公开可以通过在容器启动时按需加载需要的数据，而不是提前下载完整的镜像，从而加速容器启动。这种方式可以称为懒加载(lazy load)方式。且懒加载的方式不仅适用于冷启动，还可以适用于实时创建的应用实例中应用容器的启动。
110.在一些实施例中，目标服务节点可以从镜像仓库中拉取应用镜像的元信息，将应用镜像的元信息装载至实时创建的应用容器或者利用应用镜像的元信息替换从冷启动池组件中调度的空闲应用实例的业务容器的第二基础镜像，从而得到应用容器。
111.此外，在应用容器启动过程中，目标服务节点还可以调用后台线程将所有的应用镜像的数据拉取到本地缓存，避免应用容器执行过程中因为网络抖动而受到影响。
112.综上，通过懒加载的方式能够加速应用容器的启动，且后台线程拉取所有的应用镜像的数据，能够保证应用容器在执行过程中的可靠性。
113.此外，结合图2所示实施例的描述，用户上传并部署在云服务系统中的原生应用(也可以理解为应用镜像)包含目标服务对应的配置项的配置信息，配置项可以但不限于包括以下一项或多项：
114.1、监听端口：用户需要通过指定端口监听，在与宿主机共享的host模式下，端口号通过环境变量动态注入。在一些实施例中，每个应用可以监听预设数量的端口，例如，可以包括：数据端口(接收用户请求)和调试端口(可选)。
115.2、启动命令：用户可以自定义启动命令，用户上传的代码包需要时可以直接执行的最终构建产物。
116.3、健康检查：用户可以自定义健康检查接口，供云计算系统检测服务健康状态。
117.4、函数生命周期：用户业务逻辑需要接受云计算系统自动弹性伸缩带来的影响，业务逻辑本身不强依赖本地运行环境的状态。
118.因此，在服务开发的过程中，用户需要遵守以上一项或多项开发规范，以保证应用镜像的完整性，且能够保证开发环境与运行环境的一致性。需要说明的是，开发规范所规定的服务对应的配置项可以随着云计算系统的不断改进发生变化。例如，随着云计算系统功能的不断完善，出现新增的配置项。或者一些配置项可以通用的情况下，可以在云计算系统
中部署通用配置项的文件，当关联的应用部署在云计算系统中时，获取通用通用配置项的文件，进行相关的配置即可。
119.示例性地，请参阅图4所示，以golang类型的faas函数为例，目前已有的faas中，golang语言的faas运行时是平台提供的sdk，用户编码服务对应的函数代码，上传二进制构建产物到faas平台，实际golang的sdk为用户提供一个http server(以及预先定义好的接口规范)，用户编码的函数代码上传之后，需要由faas进行各配置项的配置以及监听等等，已有的faas中，golang的faas函数相当于是一个http服务。而采用本公开所示的开发规范进行服务开发，用户上传的是完整的http应用(如图4中靠右侧图所示)，完整的http应用中包含函数代码以及用户自定义配置的监听端口、启动命令、健康检查以及函数生命周期等各配置项的配置信息，faas通过简单的适配便可实现原生http应用运行在faas上。
120.结合图2至图4所示实施例的技术方案，云计算系统能够实现支持用户基于各种http框架(如hertz)以及rpc框架(如kitex、euler、gulu、archon等)开发的原生应用，从而解决了前述提及的云计算系统改造成本高、多语言支持不够以及用户学习成本高的问题。
121.以faas为例，在faas支持各种协议的原生应用的基础上，也需要对多协议的业务请求进行支持。示例性地，通过图5至图17示实施例对faas实现多协议支持进行详细介绍。其中，目前已有的faas能够较好地支持http协议的业务请求，但目前无法支持多种rpc协议的业务请求。
122.目前已有faas支持http协议，通过分析可知，http协议能够为faas带来至少以下的好处：
123.1、多用户请求识别：基于http协议头传递服务元信息，方便统一的入流量网关管理。
124.2、无需对实际请求体内容进行解析：转发请求时，无需解析和感知业务请求体。作为7层http代理，可以实现请求级别的细粒度的流量控制和并发控制。
125.3、长链接保持、多路链接复用(针对http/2协议)，为7层代理节省资源开销。
126.基于上述分析，对于任意应用层的网络通信协议，能够具备以上特征，便可以被faas化。
127.进一步地，对faas对流量和资源的调度进行分析，可以将整套数据面架构拆分为数据调用链路和流量调用链路两部分；其中，数据调用链路为业务请求的实际转发路径；流量调用链路为是基于并发的流量调度、冷启动等faa内部组件的调用，其不涉及业务请求的转发。
128.示例性地，请参阅图5所示，图5中的实线箭头方向表示业务请求的转发以及透传路径，虚线部分代表流量调度和冷启动过程中涉及的系统组件内部调用链路。为了实现多协议支持，本公开通过对实线链路做多协议的适配，而虚线链路的架构可以保持不变，针对不同协议的应用，共享底层流量调度资源池。
129.其中，目前已有的faas的应用实例通常向用户提供一个端口，数据面流量代理和控制面信令通过统一的端口进入。请参阅图6所示，为了支持多协议，也为了进一步将用户数据流量和faas控制信令拆分，本方案为应用实例增加端口，从而将数据调用和流量调用解耦，且在runtimeagent内部将数据请求、控制信令的逻辑进行了解耦，以适配前端解耦的数据调用端口和流量调用端口。解耦之后，便可以将多协议的适配改造收敛在数据调用链
路中，底层完全复用faas统一的流量调度能力。
130.本公开提供的云计算系统通过将数据调用链路和流量调用链路解耦，向用户呈现支持不同协议的数据请求端口以及共享的流量调用端口，使得在支持多协议应用方面可以统一runtime，sidecar架构，同时可以共享一套流量调用系统。其中，sidecar架构表示业务进程附属的旁路进程，也可以理解为旁路插件。
131.结合前述分析，本公开通过在以下几个方面进行改造实现云计算系统的架构，实现支持多协议：
132.1、将数据调用链路和流量调用链路进行解耦，在数据调用链路中为多协议分别配置对应的数据请求端口，通过多个数据请求端口将相应通信协议的业务请求传递至相应通信协议的应用实例。
133.2、对网关进行改造，基于不同通信协议开发并部署各通信协议分别对应的网关。其中，一个网关可以对应一种或多种通信协议，本公开不作限定。其中，本公开可以通过服务网格对上游客户端发送的业务请求所采用的通信协议进行识别感知，确定业务请求所对应的通信协议一致的目标网关，并控制业务请求被发送至确定的目标网关。
134.3、网关对接收到业务请求的请求头进行分析，确定业务请求转发路径，即确定业务请求要被传递至哪个数据请求端口。
135.4、服务网格识别到业务请求为第一指定通信协议的请求时，将第一指定通信协议的业务请求转换为第二指定通信协议的业务请求，之后再控制第二指定通信协议的业务请求传输至对应的网关。其中，本公开对于第一指定通信协议和第二指定通信协议不作限定，第一指定通信协议对应的数据包结构可以不包含请求头，第二指定通信协议对应的数据包结构可以包括请求头以及请求帧，协议转换能够保证传递至网关以及应用实例的业务请求是满足云计算系统要求的。通过协议转换，能够实现存量业务迁移，也能够满足用户基于第二指定通信协议开发新的服务功能的需求。
136.5、云计算系统基于事件触发机制触发函数运行，为了支持多协议，本公开通过在事件触发器中配置多种不同通信协议的接口定义语言，以实现对多协议的业务请求的事件触发支持。
137.示例性地，图7为本公开一实施例提供的支持多协议的云计算系统的架构示意图。请参阅图7所示，本实施例提供的云计算系统在图1所示实施例提供的云计算系统的基础上，还针对事件触发器组件、网关以及数据流量调用端口进行了改进。
138.其中，本实施例提供的云计算系统包括事件触发器组件，事件触发器组件包括多种不同的事件触发器，如，负载均衡触发器、定时触发器、消息队列触发器。各类型的事件触发器包括多种不同通信协议的接口定义语言，通过接口定义语言中的函数生成业务请求的事件对象，并将业务请求对应的事件对象发送给云计算系统中的目标服务节点，以触发目标服务节点响应业务请求对应的事件对象，生成目标服务对应的应用实例。例如图7中示例性示出定时触发器和消息队列触发器中分别包括idl1和idl2，idl1用于对通信协议1的业务请求生成第一类型的事件对象，idl2用于对通信协议2的业务请求生成第二类型的事件对象。需要说明的是，根据业务需求可以设定部分或者全部类型的事件触发器支持多协议，且各类型的事件触发器所支持的多协议可以不完全相同，这些都可以灵活配置。
139.云计算系统还包括多个网关和服务网格节点，各网关分别支持相应的一种或多种
通信协议，例如，网关1支持通信协议1和通信协议2、网关2支持通信协议3、网关3支持通信协议4，依次类推，可根据实际需求设置网关的数量以及网关与通信协议之间的对应关系。
140.其中，服务网格节点能够对云计算系统进行入流量控制。具体地，服务网格节点可以对客户端发送的业务请求所采用的通信协议进行识别得到识别结果，并基于识别结果控制业务请求传递至与业务请求所采用的通信协议一致的目标网关。
141.此外，云计算系统中各应用实例对应解耦后的流量调用端口以及数据请求端口。
142.其中，流量调用端口可以处理云计算系统包括的各函数服务集群并发的流量调度以及冷启动等内部组件的调用。本实施例中，通过流量调用端口可以将业务请求所需的流量调度至后端相连接的目标服务节点，以将业务请求所需的流量调度至目标服务节点中与业务请求对应的应用实例。类似地，流量调用通过虚线表示，流量调用过程可以参照图5以及图6实施例所示。
143.数据请求端口用于将接收到的业务请求转发给相连接的目标服务节点，以将业务请求转发至目标服务节点中与业务请求对应的应用实例。其中，各应用实例所对应的数据请求端口所支持的通信协议与相应的服务所采用的通信协议一致。例如，节点1中应用实例1对应数据请求端口1和流量调用端口，节点1中应用实例2对应数据请求端口2和流量调用端口。若有更多应用实例，则这些更多应用实例分别对应的数据请求端口可以与前端相应通信协议的网关连接，接收并转发网关发送的业务请求。
144.如前所述，支持多协议的网关可以通过对业务请求的请求头进行解析，得到请求头中包含的服务的元信息，基于服务的元信息，从相连接的多个应用实例分别对应的数据请求端口中确定业务请求对应的目标数据请求端口，并控制业务请求被发送至确定的目标数据请求端口。
145.图8a为采用图7所示的云服务实现方法的流程示意图。请参阅图8所示，本实施例的方法包括：
146.s801、响应客户端发送的业务请求，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务。
147.s802、调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例。
148.其中，若目标网关单元支持接收以及转发多种不同通信协议的业务请求，则目标网关单元对接收到业务请求的请求头进行解析得到目标函数服务的元信息，基于目标函数服务的元信息从目标网关相连接的多个数据请求端口中确定目标数据请求端口；以及，将业务请求转发至所述目标数据请求端口。
149.s803、调用所述云计算系统中的流量调用端口将所述业务请求对应的流量调度至所述应用实例。
150.例如，调用业务请求对应的目标函数服务从镜像仓库中分别拉取第一基础镜像以及应用镜像至本地缓存，以便创建初始化容器以及应用容器。
151.s804、在应用实例中，根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中。
152.s805、在应用实例中基于应用镜像创建应用容器，并从共享目录盘读取二进制执行文件注入到应用容器中。
153.s806、运行应用容器中的二进制执行文件以启动运行时代理进程；以及，调用运行时代理进程控制应用实例中的运行时进程执行应用镜像中的文件以处理业务请求。
154.本实施例中步骤s804至步骤s806与图2所示实施例步骤s201至步骤s203类似，可参照图2所示各步骤的详细描述，简明起见，此处不再赘述。
155.本实施例通过将数据请求端口与流量调用端口进行解耦，为将多协议支持收敛在数据调用链路中提供了基础，且解耦之后，也可以降低端口开发复杂度，且有利于降低端口维护、升级的难度。
156.图8b为本公开另一实施例提供的云服务实现方法的流程图。请参阅图8b所示，本实施例的方法包括：
157.s901、接收客户端发送的业务请求，并从多种接口定义语言中确定与业务请求所采用的通信协议对应的目标接口定义语言。
158.s902、基于目标接口定义语言生成业务请求对应的事件对象，以及，将业务请求对应的事件对象发送至目标服务，以触发目标服务响应业务请求生成应用实例。
159.云计算系统是通过事件触发机制触发应用镜像执行，结合前述图7所示，云计算系统中包括各种类型的事件触发器，事件触发器接收到客户端发送的业务请求之后，可以从其包括的多种接口定义语言中选择相匹配的目标接口定义语言用于生成业务请求对应的事件对象，通过将生成的事件对象发送至目标服务节点，以通知目标服务节点响应客户端发起的业务请求。
160.需要说明的是，不同通信协议对应的接口定义语言可以生成不同类型的事件对象，本公开对此不做限定。
161.s903、响应业务请求对应的事件对象，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务。
162.本步骤与图2所示实施例步骤s201类似，可参照步骤s201的详细描述。
163.s904、通过调用服务网格对业务请求采用的通信协议进行识别得到识别结果。
164.s905、基于识别结果控制业务请求传递至与业务请求的通信协议一致的目标网关单元。
165.结合图7所示实施例，服务网格可以通过其包括的流量代理节点对业务请求进行流量代理，用于识别业务请求所采用的通信协议以及进行流量控制。
166.s906、通过目标网关将业务请求传递至相应的数据请求端口。
167.目标网关通过对业务请求的请求头进行解析，得到服务的元信息，根据服务的元信息可以确定业务请求所采用的通信协议的类型，进而可以确定将业务请求传递至哪个数据请求端口。
168.在一些实施例中，客户端所采用的通信协议可能不满足云计算系统的要求，例如，一些通信协议生成的业务请求的数据包结构不包括请求体，则支持网关对于业务请求的解析，也无法满足后端服务节点执行业务请求对于输入数据的要求，因此，需要对客户端进行改造，但这部分改造通过服务网格进行协议转换实现。具体地，服务网格检测到业务请求为第一指定通信协议的业务请求时，则对业务请求进行协议转换得到第二指定通信协议的业务请求，第二指定通信协议的业务请求的数据包结构满足云计算系统的要求。本公开对于实现协议转换的具体方式不做限定。通过协议转换能够实现前端存量远程调用服务的迁
移，满足前端客户端的服务需求，且不会对前端客户端产生任何影响。
169.s907、调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例。
170.s908、调用所述云计算系统中的流量调用端口将所述业务请求对应的流量调度至所述应用实例。
171.s909、在应用实例中，根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中。
172.s910、在应用实例中基于应用镜像创建应用容器，并从共享目录盘读取二进制执行文件注入到应用容器中。
173.s911、运行所述应用容器中的所述二进制执行文件以启动运行时代理进程；以及，调用所述运行时代理进程控制所述应用实例中的运行时进程执行所述应用镜像中的文件以处理所述业务请求。
174.步骤s907至步骤s911与图8a所示实施例中步骤s802至步骤s806类似，可参照图8a所示实施例的详细描述。
175.综上所述，通过在云计算系统的各类型事件触发器中分别增加多种通信协议的接口定义语言、部署多种不同通信协议的网关以及配置多种不同通信协议的数据请求端口，将多协议的支持收敛在数据调用链路中，实现了云计算系统具有支持多协议的能力，能够处理各种通信协议的业务请求，推动了云计算系统向serverless化演进。
176.下面示例性地以云计算系统为faas，faas支持http协议、grpc协议以及thrift协议为例举例说明如何实现云计算系统支持多协议。
177.一、http协议(http/2协议)
178.目前已有的一些faas通常是基于http/1.1协议，随着业务量增长，一些问题逐渐显露：高速增长的高并发请求数据造成数据调用链路连接数爆炸。tcp连接数过多，不仅会导致文件描述符过多，也会导致内存消耗过大。例如，golang的net/http框架会为每一个链接分配一个内存缓冲区，高并发场景下，内存消耗过大甚至会出现内存溢出(oom)导致系统进程退出的问题。
179.相比于http/1.1，http/2采用了二进制协议格式，并且支持多路链接复用，可以进一步减小高并发请求带来的系统开销。
180.请参阅图9所示，http/2协议将数据分为更小的帧，帧数据传输分为头帧(即请求头)和数据帧(即请求体)。其中，http协议的首部header信息会封装入头帧，请求体body作为数据帧传输。每一帧内部采用二进制编码。
181.请参阅图10所示，将数据区分为更小的帧之后，http/2可以在同一个tcp连接中同时传送多个请求，每一次请求响应的数据交互对应一个http/2的数据流(stream)，不同请求的不同帧通过帧数据中的streamid进行区分。图10示例性地示出了http/2客户端和服务端通过同一个tcp连接同时传输4个并发请求的场景。
182.在对于faas的改进中，因为http/2与http/1.1是向后兼容的，将faas的数据调用链路代理(gateway，runtimeagent)升级到http/2，为了避免tls引入的额外开销，数据调用链路内部采用去除了安全传输层协议(transport layer security，tls)的http/2协议，即h2c协议，将数据以明文格式传输。因此，本公开提供的faas中数据调用链路对于http/2的
传输如图11所示。
183.需要说明的是，一些函数(即服务)运行时并不支持h2c协议(也可以由于语言的标准库本身不提供h2c协议的支持，或者，用户开发时使用了较早版本的sdk无法及时升级)，针对这种情况，本公开进一步通过协议探测，使得应用实例内能够灵活兼容不同版本的http协议。
184.二、grpc协议
185.grpc协议是一种开源的rpc协议，http/2的支持，优化了faas系统内部数据调用链路。另一方面，它为grpc协议的支持也做了准备，grpc协议是一种开源的rpc框架项目，通信协议transfer protocol基于http/2，而序列化协议可以灵活选择protocol buffers、josn、xml等多种格式。
186.faas希望能够实现在不感知protocol buffers请求的接口定义语言(idl)的前提下，无需解析用户请求体，获取服务的元信息，基于http/2作为通信协议的grpc满足该要求：一个grpc请求本身可以看做是一个特殊的http/2请求，服务的元信息可以通过请求头传递，网关可以无需感知用户的请求体便可获得服务的元信息，实现对请求的流量控制。
187.grpc请求与http/2相比，增加了额外的grpc相关字段。需要说明的是，请求响应包含gprc-status(状态码)，根据grpc规范，grpc请求响应的状态以及状态码依赖gprc-status字段表达，和http的状态码无关。同时，gprc-status在请求体传递完成之后，通过http请求的trailer header传递给客户端。
188.为了实现数据调用链路对grpc请求的适配，本公开通过下述方式实现：1、数据调用链路faasgateway和runtimeagent针对grpc协议进行判断，根据响应的grpc错误码判断用户业务逻辑的执行结果，监控打点；在faas允许的最大超时时间内(例如15分钟)，支持了grpc流式传输；改造完成后，同一套数据调用链路，可以同时支持http和grpc协议。2、冷启动资源池为grpc协议单独预留部分资源，基于这些改进，faas支持了原生的grpc协议，并且也支持一些faas内部的grpc框架。
189.示例性地，数据调用链路同时处理http请求和grpc请求的框架如图12所示，针对不同协议的应用实例与不同通信协议的数据请求端口绑定，faasgateway将不同通信协议的业务请求分发给相应通信协议的数据请求端口，进而通过数据请求端口将业务请求转发至应用实例的runtimeagent。
190.三、thrift协议
191.thrift是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务。它被当作一个远程过程调用(rpc)框架来使用，因此，也可以理解为是一种特殊的rpc协议。
192.一些情况下，faas后端微服务体系可以是基于内部研发的协议框架构建，内部协议框架可以是通过对某指定开源的通信协议(本文以开源的thrift协议进行介绍)进行改进得到。为了支持未改进之前的指定通信协议，需要解决以下问题：
193.1、thrift协议非常灵活，传输层协议和序列化反序列协议分层组合可能有多种不同的可能性，通常faas很难做到支持全部的组合。示例性地可参照图13所示的thrift框架灵活的分层实现。
194.2、原生的thrift传输协议没有类似http这样的请求头结构用于传输请求服务的
元信息。
195.3、无法像grpc一样，复用http请求的数据调用链路，需要开发新得网关代理和容器内数据流量代理。
196.4、存量业务迁移：除了服务端就的代码改造，对存量业务同时也需要考虑上游的客户端的迁移成本。
197.基于thrift协议的灵活性，可以将thrift协议请求转换为faas内部统一的传输协议，使转换得到的业务请求的请求体包含请求头，可以作为faas传递服务的元信息(如函数id)的载体。其中，faas内部统一的传输协议可以但不限于基于thrift协议框架进行改造生成。
198.示例性地，faas内部统一的传输协议(即第二指定通信协议)的数据包的结构可以示例性地如图14所示，其支持可变长度的header内容用于存储faas所需的函数/服务元信息。图14中示例性地以header内容长度为16bit为例，但可以理解的是，并不限于16bit，可根据需求设置长度。需要说明的是，图14中省略号
“……”
表示第二指定通信协议所规定一些字段，本公开对于省略号部分所限定的字段不做限定。
199.针对thrift协议的rpc请求，通过开发和适配faas内部统一的传输协议的gateway(也可以称为faasthriftgateway)和runtimeagent内部的thriftrpc代理。部署完成之后，便可以支持的thriftrpc框架。
200.示例性地，数据调用链路同时处理http请求、grpc请求以及thrift协议的框架如图15所示，针对不同协议的应用实例与不同通信协议的数据请求端口绑定，上层调用控制业务请求到达相应通信协议的faasgateway，faasgateway再将接收到的业务请求转发给相应通信协议的数据请求端口，进而通过数据请求端口将业务请求转发至应用实例的runtimeagent。例如图16中，http请求和grpc请求将会通过faashttpgateway传递给http对应的数据请求端口1或者grpc对应的数据请求端口2。thrift请求将会通过faasthriftgateway传递给thrift对应的数据请求端口3。
201.需要说明的是，业务请求如何被传递至相应通信协议的faasgateway可以由服务网格控制，服务网格可以感知上游客户端传递的业务请求，确定各业务请求对应的网关，进而控制业务请求的传递路径。对于支持多通信协议的网关，可以通过识别业务请求的请求头，得到函数的元信息，再将业务请求传递给相应的数据请求端口。例如，faashttpgateway可以通过识别grpc协议的业务请求的请求头进行逻辑判断，确定业务请求是否应该分发至grpc对应的数据请求端口2，若符合grpc协议请求头的规范，则确定业务请求分发至http对应的数据请求端口1。
202.通过上述方案，faas便可以实现对多协议的支持，用户可以基于faas开发不同协议的rpc服务。在此基础上，还需要面临的问题是客户端流量接入问题，示例如下：
203.1、存量服务迁移/客户端改造问题：上游客户端支持的框架或协议与下游服务端所支持的框架或者协议不一致，例如，faas支持的统一的内部协议与上游客户端支持的thrift协议不一致，这样的情况会对下游服务端迁移造成阻碍。
204.2、多协议场景事件触发器支持：在传统事件类型faas函数场景下，用户对于事件触发器接入是强需求。对于rpc协议类型应用，具有同时处理在线微服务流量和异步事件的需求。
205.faas的微服务治理体系即mesh能够针对大部分在线微服务的客户端的出流量进行出流量代理劫持，代理帮助用户完成下游服务发现、监控打点、限流熔断等操作。针对上述第1点，本公开通过faas的微服务治理体系即mesh，为访问下游服务端的rpc进行协议转换。具体可以参照图16所示的方式实现：
206.1、上游客户端通过mesh流量代理访问下游faas服务。
207.2、mesh流量代理可以根据业务请求中包含的下游服务信息，识别下游服务的类型(faas或者paas)。
208.3、针对下是faas的thrift请求，对请求进行协议转换，得到与faas内部统一的传输协议一致的业务请求。
209.需要说明的是，一些情况下faas内部统一的传输协议是对开源的指定通信协议(如开源的thrift协议)的一层额外包装，也是一些rpc客户端与mesh流量代理之间默认的通信协议，因此，协议转换并不会引入过多的开销。
210.本公开为实现对于各种rpc协议应用的支持，通过协议转换的方式实现在不感知用户idl、不解析用户实际请求的情况下实现faas对于rpc协议的支持。
211.针对上述第2点，在http协议场景下，假设faas使用了cloudevent事件类型作为http请求统一的编解码方式，为了对rpc协议添加事件触发器支持，faas针对rpc定义了单独的事件触发器idl，希望接入事件触发器的用户能够按照faas规范编写rpc代码，保证不同协议的业务请求能够正确触发事件类型，进而保证业务请求被正确传递。
212.示例性地，参照图17所示，以定时触发器和消息队列触发器为例，在定时触发器和消息队列触发器中分别包含http客户端和rpc客户端。其中，接入定时触发器的http请求能够通过http客户端生成相应的httpcloudevent，并传递http应用；接入定时触发器的rpc请求能够通过http客户端生成相应的rpc请求对象，并传递给rpc应用。类似地，接入消息队列触发器的http请求能够通过其中的http客户端生成相应的httpcloudevent，并传递http应用；接入消息队列触发器的rpc请求能够通过其中的http客户端生成相应的rpc请求对象，并传递给rpc应用。
213.基于上述可知，本公开提供的云计算系统支持用户采用自定义镜像，且通过初始化容器(init容器)的方式向用户自定义镜像中注入runtimeagent进程的二进制执行文件，保证应用容器的runtime能够被正常启动。此外，在业务请求采用冷启动时，通过原地替换镜像以及触发重启的方式，保留了冷启动池的功能性；此外，还使用了懒加载的方式，加速应用容器启动速度。在此基础上，实现了云计算系统对于原生应用的支持。
214.此外，本公开通过将数据调用链路和流量调用链路解耦，针对不同通信协议开发适配不同的数据请求端口、网关单元以及在事件触发器中配置不同通信协议对应的idl，保证各种通信协议的业务请求能够被传递至相应通信协议的应用实例中，从而实现faas对多协议的支持。
215.示例性地，本公开还提供一种云服务实现装置。
216.图18为本公开一实施例提供的云服务实现装置的结构示意图。请参照图18所示，本实施例提供的装置1800包括：
217.实例生成模块1801，用于响应客户端发送的业务请求，生成目标服务对应的应用实例；所述目标服务为所述业务请求所请求的云计算服务。
218.第一处理模块1802，用于在所述应用实例中根据第一基础镜像创建初始化容器，再启动所述初始化容器，将所述第一基础镜像中的二进制执行文件写入所述应用实例对应的共享目录盘中。
219.第二处理模块1803，用于在所述应用实例中基于相应的应用镜像创建应用容器，并从所述共享目录盘读取所述二进制执行文件注入到所述应用容器中；所述应用镜像是基于用户上传至云计算系统中的原生应用得到；所述原生应用包括所述目标服务对应的函数代码以及所述目标服务对应的配置项的配置信息。
220.运行模块1804，用于运行所述应用容器中的所述二进制执行文件以启动运行时代理进程；以及，调用所述运行时代理进程控制所述应用实例中的运行时进程执行所述应用镜像中的文件以处理所述业务请求。
221.在一些实施例中，实例生成模块1801，具体用于在所述业务请求冷启动时，从冷启动资源池维护的多个空闲应用实例中调度一个空闲应用实例作所述目标服务对应的应用实例，所述多个空闲示例基于第二预设镜像创建。
222.相应地，第二处理模块1803，具体用于将所述空闲应用实例对应的业务容器中的第二基础镜像替换为所述应用镜像，并重启以得到所述应用容器。
223.在一些实施例中，第二处理模块1803，具体用于从镜像仓库中拉取所述应用镜像的元信息；基于所述应用镜像的元信息创建所述应用容器。
224.在一些实施例中，所述目标服务对应的配置项包括：监听端口、启动命令、健康检查接口以及函数生命周期中一项或多项。
225.在一些实施例中，还包括：流量调度模块1805和数据调度模块1806；其中，流量调度模块1805，用于调用所述云计算系统中的流量调用端口将所述业务请求对应的流量调度至所述应用实例；数据调度模块1806，用于调用所述云计算系统中的数据请求端口将所述业务请求转发给所述应用实例。
226.在一些实施例中，数据调度模块1806，具体用于从各正在运行的应用实例分别对应的数据请求端口中，调用所述业务请求对应的应用实例对应的目标数据请求端口将所述业务请求转发给所述应用实例，所述目标数据请求端口支持的通信协议与所述业务请求采用的通信协议一致。
227.在一些实施例中，还包括：请求获取模块1807，用于对所述业务请求采用的通信协议进行识别得到识别结果，基于识别结果控制所述业务请求传输至多个网关中与所述业务请求的通信协议一致的网关，通过所述网关将所述业务请求转发至相应的数据请求端口；其中，所述多个网关分别用于转发不同通信协议的业务请求。
228.在一些实施例中，请求获取模块1807，具体用于通过调用所述网关对所述业务请求的请求头进行解析得到服务的元信息，基于所述服务的元信息从相连接的多个数据请求端口中确定目标数据请求端口；以及，将所述业务请求转发至所述目标数据请求端口。
229.在一些实施例中，还包括协议转换模块1808，用于识别到所述客户端发送的所述业务请求采用第一指定通信协议时，将所述第一指定通信协议的业务请求转换为第二指定通信协议的业务请求。
230.相应地，请求获取模块1807，具体用于对第二指定通信协议的业务请求的请求头进行解析得到服务的元信息，基于服务的元信息从相连接的多个数据请求端口中确定目标
数据请求端口；以及，将所述业务请求转发至所述目标数据请求端口。
231.在一些实施例中，还包括：触发模块1809，用于接收客户端发送的业务请求，并从多种接口定义语言中确定与所述业务请求所采用的通信协议对应的目标接口定义语言；基于所述目标接口定义语言生成所述业务请求对应的事件对象，以及，将所述业务请求对应的事件对象发送至所述目标服务，以触发所述目标服务响应所述业务请求生成所述应用实例。
232.本实施例提供的装置可以用于实现前述任一方法实施例的技术方案，其实现原理以及技术效果类似，可参照前述方法实施例的详细描述，简明起见，此处不再赘述。
233.图19为本公开一实施例提供的电子设备的结构示意图。请参照图19所示，本实施例提供的电子设备1900包括：存储器1901和处理器1902。
234.其中，存储器1901可以是独立的物理单元，与处理器1902可以通过总线1903连接。存储器1901、处理器1902也可以集成在一起，通过硬件实现等。
235.存储器1901用于存储程序指令，处理器1902调用该程序指令，执行以上任一方法实施例提供的云服务实现方法。
236.可选地，当上述实施例的方法中的部分或全部通过软件实现时，上述电子设备1900也可以只包括处理器1902。用于存储程序的存储器1901位于电子设备1900之外，处理器1902通过电路/电线与存储器连接，用于读取并执行存储器中存储的程序。
237.处理器1902可以是中央处理器(central processing unit，cpu)，网络处理器(network processor，np)或者cpu和np的组合。
238.处理器1902还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，asic)，可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)，现场可编程逻辑门阵列(field-programmable gate array，fpga)，通用阵列逻辑(generic array logic，gal)或其任意组合。
239.存储器1901可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，ram)；存储器也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；存储器还可以包括上述种类的存储器的组合。
240.本公开还提供一种可读存储介质，包括：计算机程序指令，所述计算机程序指令被电子设备的至少一个处理器执行时，使得所述电子设备实现如上任一方法实施例提供的云服务实现方法。
241.本公开还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机实现如上任一方法实施例提供的云服务实现方法。
242.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除
在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
243.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。