基于去边车的单核操作系统在无服务器框架的部署方法及装置

技术领域

本发明属于微服务技术领域，特别涉及基于去边车的单核操作系统在无服务器框架的部署方法及装置。

背景技术

无服务器(Serverless)框架例如Knative，允许部署的服务实例Pod根据流量负载情况自适应扩缩。边车(Sidecar)架构是指通过额外启动一个组件来补充本身服务不具备的功能，使其兼容部署在特定框架下的需求。辅助的边车(Sidecar)容器与服务容器在一个实例中启动，使得服务容器无需关心接入无服务器框架的细节。然而边车容器本身作为一种重量级组件，对无服务器框架内的服务通信以及启动性能都造成了较大的影响。

单核操作系统(Unikernel)是一种轻量级、高性能的操作系统。它只保留系统必要功能，内存大小远小于容器运行时，且省去了用户-内核态切换的开销，服务处理性能强于容器。适合为每一个函数服务开发一个定制化的操作系统作为运行时来部署。然而，重量级组件边车容器的存在使得Unikernel作为服务运行时的优势无法体现。

Kubernetes是一种容器编排技术方案，能够为容器提供部署运行、资源调度、服务发现和动态伸缩等一系列功能，提高了大规模容器集群管理的便捷性。Knative作为K8s(Kubernetes)环境的扩展，将服务作为实例部署时，需要服务容器和边车容器运行时一致。以Unikernel作为运行时部署无服务器服务需要开发一个Unikernel版本的边车，工程实现量巨大。

而现有的去边车化轻量级无服务器部署主要是基于扩展的伯克利包过滤器(extended Berkeley Packet Filter，eBPF)在容器通信场景实现，代表工作有SPRIGHT[QiS,Monis L,Zeng Z,et al.SPRIGHT:extracting the server from serverlesscomputing！high-performance eBPF-based event-driven,shared-memoryprocessing[C]//Proceedings of the ACM SIGCOMM 2022Conference.2022:780-794.]和Cilium[Cilium:eBPF-based Networking,Observability,Security.https://cilium.io.]。eBPF通信是通过对系统内核内嵌字节码和共享内存的方式来实现服务间的远程调用。它的优势在于保证边车功能的同时，可以绕过网络通信间繁重的序列化、用户态切换、上下文切换开销。然而eBPF的功能并不支持在Unikernel中使用。另外eBPF的一个主要收益源自用户态切换开销，而单内核操作系统Unikernel本身只有一个用户态，无法完全享受eBPF的收益。

因此，目前现阶段无服务器部署去边车实现轻量化的工作不能应用于Unikernel，是本领域亟需解决的技术问题。

发明内容

本发明的目的在于提供基于去边车的单核操作系统在无服务器框架的部署方法及装置，该方法通过设计边车库避免了边车的重量级，降低服务实例占用内存，规避了边车容器流量转发带来的性能损失，同时外部库集成到系统内核中，对应用部署不造成侵入式的影响。

本发明提供如下技术方案：

基于去边车的单核操作系统在无服务器框架的部署方法，所述部署方法为：

将边车容器的功能集成到单核操作系统中的外部扩展库，作为边车库Lib-Sidecar，所述边车库Lib-Sidecar包括三个服务器：用于流量转发的主服务器，检测并发量并用于扩缩容的依据的性能指标服务器，用于函数容器生命健康检测的健康检测服务器；

配置Kubernetes的实例部署文件，以单核操作系统Unikernel运行时部署虚拟机，无服务器框架Knative识别部署实例为Unikernel，不再注入边车容器并启动Pod实例；

完成上述配置后，单核操作系统Unikernel进入启动阶段，边车库Lib-Sidecar在外部库初始化阶段启动，确保Unikernel运行时能在Knative框架中兼容。

针对现阶段无服务器部署去边车实现轻量化的工作不能应用于Unikernel的特点，本发明基于Unikernel的可扩展性，将边车容器的功能以外部扩展库的形式集成到Unikernel中，即，通过设计边车库(Lib-Sidecar)来实现Unikernel部署在无服务器场景下的部署优化。解决了现有方案不能适配Unikernel，以及无服务器通信框架本身存在的问题。且边车库避免了边车的重量级，降低服务实例占用内存，规避了边车容器流量转发带来的性能损失。同时外部库集成到系统内核中，对应用部署不造成侵入式的影响。

Pod配置文件需要添加注解字段告知Kubernetes部署对象为单核操作系统Unikernel，具体方法为：Knative通过维护一个版本管理组件管理创建Pod服务的模板，并检查注解中的字段，该字段存在时会在实例模板部署时，不为其注入边车容器。

所述版本管理组件将边车容器相关的上下文信息写入到单核操作系统Unikernel运行时的上下文中，用于在Knative环境下运行。

所述部署方法还包括：开发者在主函数中注册业务处理函数和业务服务函数，用于在接收外部网络请求时执行业务逻辑。

即，用户定义一个handle_request函数(业务处理函数)，用于处理到达网关、其它微服务发来的请求，并在handle_service函数(业务服务函数)中定义实际的执行逻辑。

在本发明中，无服务器框架管理微服务的运行，单核操作系统是微服务运行时的承载工具，边车库是单核操作系统的组件，它使得单核操作系统能在无服务器框架下运行。但是边车库本身只是一个壳，用户需要在引入边车库后，用户即开发者，因此需要在handle_request里实现具体的网络包处理逻辑，handle_service是实现业务逻辑。

当网关以及其它微服务发送的请求在边车库Lib-sidecar预处理后到达业务处理函数，业务处理函数对到达的请求头进行分析和处理，然后调用业务服务函数执行网关及其它微服务的实际逻辑，执行完成后返回，业务处理函数最后决定网络包的响应状态。

具体地，边车库Lib-sidecar预处理的方法为：

所述边车库Lib-sidecar中的主服务器负责接收到达的请求，并执行后续的实际业务。

Knative中的性能指标会定期向边车库Lib-sidecar的性能指标服务器发送请求，获取当前服务的并发量，并作为依据发送给Knative的自动扩缩容实例Autoscaler来实现服务实例的扩缩容。

所述边车库Lib-sidecar中的健康检测服务器负责接收来自Knative的健康状态检查，以维护Knative下实例的生命周期。

具体可以为：

handle_request主要是根据到达的请求的数据包头以及不同的状态决定不同的处理逻辑，而handle_service用于执行实际的业务。由于虚拟机间可以通过例如虚拟机函数(vmfunc)的内存共享协议进行通信，这种情况的通信不需要经过网络发包，而是直接调用对方虚拟机的函数逻辑执行。

无服务器框架下部署的应用一般是微服务，而微服务本质上是一个HTTP服务器，在接收外部网络请求时执行业务逻辑。Unikernel(单核操作系统)作为服务的运行时运行具体的微服务，Lib-Sidecar是构建Unikernel的一个组件，负责启动一个HTTP服务器，并接收来自网关的请求进行预处理，例如统计网络吞吐量以及系统健康状况等。但是Lib-sidecar本身不包含业务函数信息。网络请求在Lib-sidecar预处理后到达业务处理函数handle_request，该函数需要用户即开发者在主函数中注册。handle_request需要对到达的请求头进行分析和处理。调用handle_service执行微服务的实际逻辑，执行完成后返回，handle_request最后决定网络包的响应状态。

具体来说，Handle_request是用来处理网络包的状态，例如200表示请求OK，而404表示请求非法。handle_service是实际的业务函数，比如期望网络包到达后，将网络包的数据存放到数据库里。handle_service根据执行结果，告知handle_request返回200还是404。

本发明还提供了一种基于去边车的单核操作系统在无服务器框架的部署装置，包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现上述基于去边车的单核操作系统在无服务器框架的部署方法。

本发明还提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时，用于实现上述基于去边车的单核操作系统在无服务器框架的部署方法。

与现有技术相比，本发明具有以下优异效果：

Unikraft为代表的Unikernel允许以外部扩展库的方式扩充系统所需的功能，因此可以针对无服务器部署的边车容器所需要的功能，以外部库Lib-sidecar的方式集成到Unikernel中。由于Unikernel服务本身具备了部署在无服务器框架下所需的功能，不再需要专门启动一个边车容器，这意味着不再需要专门实现Unikernel运行时的边车。

在无服务器框架下的微服务都是以超文本传输协议(Hyper Text TransferProtocol，HTTP)服务器的形式部署的，Lib-sidecar本质上也是HTTP服务器。因此对一个本身具备微服务性能的Unikernel，它需要自带C语言扩展库以及网络库。为服务函数的Unikernel增加Lib-sidecar不需要额外引入大型第三方库，只需要基于现有扩展库撰写执行逻辑。因此Lib-sidecar的引入不会对镜像大小以及启动时间造成影响。

Lib-sidecar的存在使得网关以及其它服务发送的流量请求不再需要通过主服务器的转发到达函数Unikernel，提升整体系统吞吐量。

Unikraft本身支持外部库执行逻辑在系统启动阶段注册启动，因此将Lib-sidecar以外部库引入的形式对函数本身执行逻辑是非侵入式的。

附图说明

图1为实施例中部署方法的流程图。

图2为Lib-sidecar架构和通信过程的示意图。

具体实施方式

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

需要说明的是，在不冲突的情况下，下述的实施例及实施方式中的特征可以相互组合。

如图1和图2所示，本实施例提供的基于去边车的单核操作系统在无服务器框架的部署方法具体为：

S1、将边车容器的功能集成到单核操作系统中的外部扩展库，作为边车库Lib-Sidecar，所述边车库Lib-Sidecar包括三个服务器：用于流量转发的主服务器，检测并发量并用于扩缩容的依据的性能指标服务器，用于函数容器生命健康检测的健康检测服务器。

由于Knative的边车容器由Go语言实现，主要逻辑是通过3个协程启动主服务器(MainServer)、性能指标服务器(MetricServer)、健康检测服务器(AdminServer)，分别用于流量转发、检测并发量并用于扩缩容的依据以及函数容器生命健康检测。因此，将边车容器的功能集成到单核操作系统中的外部扩展库形成的边车库库Lib-Sidecar也需要具备上述边车容器的功能。

S2、配置Kubernetes的实例部署文件，以Unikernel运行时部署虚拟机，无服务器框架Knative识别部署实例为Unikernel，不再注入边车容器并启动Pod实例。

具体操作方法为：Pod配置文件需要添加注解字段Unikernel＝true告知Kubernetes部署对象为Unikernel。Knative通过维护一个版本管理组件(Revision)管理创建Pod服务的模板，它会检查注解中的Unikernel字段，该字段存在时会在实例模板部署时，不为其注入边车容器。版本管理组件会将边车容器相关的上下文信息，例如安全上下文、健康探针等写入Unikernel运行时的上下文中，用于在Knative环境下运行。

S3、完成上述配置后，单核操作系统Unikernel进入启动阶段，边车库Lib-Sidecar成在外部库初始化阶段启动，确保Unikernel运行时能在Knative框架中兼容。

S4、开发者在主函数中注册业务处理函数和业务服务函数，用于在接收外部网络请求时执行业务逻辑。

S4的具体操作方法为：

开发者定义一个handle_request函数，用于处理到达网关、其它微服务发来的请求，并在handle_service中定义实际的执行逻辑。handle_request主要是根据到达的请求的数据包头以及不同的状态决定不同的处理逻辑，而handle_service用于执行实际的业务。由于虚拟机间可以通过例如虚拟机函数(vmfunc)的内存共享协议进行通信，这种情况的通信不需要经过网络发包，而是直接调用对方虚拟机的函数逻辑执行。

边车库中的三个服务器在Unikernel虚拟机的开机阶段启动。Lib-sidecar中启动3个线程维护3个HTTP服务器，分别对应主服务器，性能指标服务器以及健康检测服务器，并在8012，8022以及9090端口进行监听。

所有由网关、服务发送的流量都会到达边车库中对应的3个服务器。主服务器负责接收到达的HTTP请求，并执行后续的实际业务。性能指标服务器用于统计当前服务接收的并发量，Knative中的性能指标会定期向Lib-sidecar的性能指标服务器发送请求，获取当前服务的并发量，并作为依据发送给Knative的自动扩缩容实例(Autoscaler)来实现服务实例的扩缩容。健康检测服务器负责接收来自Knative的健康状态检查，以维护Knative下实例的生命周期。

本实施例以查询用户信息的程序为例，开发者以Unikernel运行时和Lib-sidecar的方式将应用部署在Knative中。Handle_request接收Lib-sidecar预处理过的请求包，并对handle_service进行封装。handle_service根据请求中的用户信息对数据库进行查询。如果用户信息存在，那么返回用户信息，handle_request将请求头状态设置为200，表示正确请求。如果请求不存在，handle_service抛出错误结果标志，handle_request将返回结果请求头设置为404表示用户不存在。当请求量上升时，Lib-sidecar根据统计的并发量信息，及时通知Autoscaler，Knative对Pod实例进行扩容。同理请求量下降时进行缩容。在没有请求时，完成运行实例的销毁。

在本实施例中，Unikraft允许将自定义的函数库在操作系统的不同启动阶段注册，作为第三方库边车库放在库函数(Lib)阶段启动。对于需要使用边车库功能的服务提供者，只需要引用边车库头文件并实现handle_request和handle_service，不需要定义主函数。边车库作为Unikernel的功能组件，因此有了Lib-sidecar，Unikernel就能接入Serverless框架运行。

综上所述，本实施例提供的基于去边车的单核操作系统在无服务器框架的部署方法通过设计边车库避免了边车的重量级，降低服务实例占用内存，规避了边车容器流量转发带来的性能损失，同时外部库集成到系统内核中，对应用部署不造成侵入式的影响。

本发明实施例还提供了一种基于去边车的单核操作系统在无服务器框架的部署装置，包括一个或多个处理器，存储器中存储有可执行代码，处理器执行可执行代码时，用于实现上述实施例中的基于去边车的单核操作系统在无服务器框架的部署方法。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在任意具备数据处理能力的设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的从硬件层面而言，除处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的任意具备数据处理能力的设备通常根据该任意具备数据处理能力的设备的实际功能，还可以包括其它硬件，对此不再赘述。

本发明实施例还提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时，实现上述实施例中的基于去边车的单核操作系统在无服务器框架的部署方法：计算机可读存储介质可以是前述任一实施例所述的任意具备数据处理能力的设备的内部存储单元，例如硬盘或内存。所述计算机可读存储介质也可以是任意具备数据处理能力的设备，例如所述设备上配备的插接式硬盘、智能存储卡(Smart Media Card,SMC)、SD卡、闪存卡(Flash8 Card)等。进一步的，所述计算机可读存储介质还可以既包括任意具备数据处理能力的设备的内部存储单元也包括外部存储设备。所述计算机可读存储介质用于存储所述计算机程序以及所述任意具备数据处理能力的设备所需的其它程序和数据，还可以用于暂时地存储已经输出或者将要输出的数据。

以上所述仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。