本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。
背景技术：
相关技术中，常采用沙箱环境保证业务处理过程中的文件安全，沙箱是一种通过安全策略限制程序行为的执行环境，为一些来源不可信、具有破坏力或无法判定程序意图的程序提供隔离环境。
一般沙箱包括基于虚拟化的沙箱和基于规则的沙箱，但这两类沙箱在使用过程中，都不能支持被隔离的文件自动进入沙箱，且其安全性有待提高。
技术实现要素：
本申请实施例提供一种业务处理方法及装置，用于至少提供一种提升业务处理过程的安全的方法。
本申请第一方面，提供一种业务处理方法，包括：
接收业务程序发送的业务处理指令，所述业务处理指令指示待调用的镜像，所述镜像包括对所述业务处理指令对应的业务请求进行处理的程序；
确定所述待调用的镜像对应的容器组pod的容器组访问微服务service，根据所述service提供的网络地址和端口访问所述pod，通过所述pod提供的容器调用所述待调用的镜像，其中，所述pod和service是按照如下方式预先创建的：
响应容器创建指令创建容器组pod，所述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问所述pod的service，所述service包括访问所述pod的网络地址和端口。
上述方法中，将业务处理过程中需要使用的程序(即镜像)放入容器组pod中，即在进行业务处理的过程中，限制业务处理过程使用的程序不能从本地计算机的其他文件中读取任何信息，也不能往本地计算机的其他文件中写入任何信息，避免了业务处理过程中使用的程序修改计算机中其他文件信息的情况，明显地提升了业务处理的安全。
在一种可能的实现方式中，所述通过所述pod提供的容器调用所述待调用的镜像之后，还包括：
响应容器删除指令，删除所述pod和所述service，所述容器删除指令是所述业务程序确定结束处理所述业务请求后发送的。
上述方法中，在结束处理业务请求后，可以删除该业务请求对应的pod和service，对pod的生命周期进行控制，进一步避免了处理完业务请求的pod中的镜像对计算机中其他文件篡改的情况，提升了隔离环境的安全。
在一种可能的实现方式中，所述响应容器创建指令创建容器组pod，包括：
从容器引擎中获取与所述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得所述pod，其中，一个容器对应一个镜像。
上述方法中，在创建pod时即拉取镜像，支持将文件自动拉入隔离环境pod中，且在一个容器中放入一个镜像，支持用不同的容器隔离不同的镜像，避免了不同的镜像的相互影响以及可能发生相互篡改的情况的出现。
在一种可能的实现方式中，所述service提供的网络地址和端口用于访问至少两个功能相同的pod；
所述根据所述service提供的网络地址和端口访问所述pod，包括：
根据所述service提供的网络地址和端口，随机访问所述至少两个功能相同的pod中任意一个pod。
上述方法中，支持同时运行多个功能相同的pod，在访问pod进行业务请求处理时，只需要访问其中一个即可，避免了只有一个pod时，该pod发生损坏而导致无法处理业务请求或者错误处理业务请求的情况。
在一种可能的实现方式中，所述应用于开源容器工具kubernetes或kubesphere或c2containerservice。
上述方法中，应用开源容器工具进行业务处理，应用开源容器工具的容器管理能力实现对文件进行隔离，减少了对用户的使用限制。
本申请第二方面，提供一种业务处理装置，包括指令接收单元和业务处理单元，其中：
所述指令接收单元被配置为执行接收业务程序发送的业务处理指令，所述业务处理指令指示待调用的镜像，所述镜像包括对所述业务处理指令对应的业务请求进行处理的程序；
所述业务处理单元被配置为执行确定所述待调用的镜像对应的容器组pod的容器组访问微服务service，根据所述service提供的网络地址和端口访问所述pod，通过所述pod提供的容器调用所述待调用的镜像，其中，所述pod和service是按照如下方式预先创建的：
响应容器创建指令创建容器组pod，所述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问所述pod的service，所述service包括访问所述pod的网络地址和端口。
在一种可能的实现方式中，所述业务处理单元还被配置执行：
通过所述pod提供的容器调用所述待调用的镜像之后，响应容器删除指令，删除所述pod和所述service，所述容器删除指令是所述业务程序确定结束处理所述业务请求后发送的。
在一种可能的实现方式中，所述pod是按照如下方式创建的：
从容器引擎中获取与所述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得所述pod，其中，一个容器对应一个镜像。
在一种可能的实现方式中，所述service提供的网络地址和端口用于访问至少两个功能相同的pod，所述业务处理单元具体被配置执行：
根据所述service提供的网络地址和端口，随机访问所述至少两个功能相同的pod中任意一个pod。
在一种可能的实现方式中，所述装置包括所述开源容器工具kubernetes装置或kubesphere装置或c2containerservice装置。
本申请第三方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面及任一种可能的实施方式中任一所述的方法。
本申请第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面及任一种可能的实施方式中任一所述的方法。
本申请第二方面至第四方面的有益效果可参见第一方面的描述，此处不再重复叙述。
附图说明
图1为本申请实施例提供的一种业务处理的过程示意图；
图2为本申请实施例提供的一种创建容器组pod的过程示意图；
图3为本申请实施例提供的一种业务处理的过程中业务程序和开源容器工具的交互示意图；
图4为本申请实施例提供的一种业务处理的过程中业务程序与开源容器融聚各单元的交互示意图；
图5为本申请实施例提供的一种业务处理装置的结构示意图；
图6为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为了更好的理解本申请实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。
下面对本申请的设计思想进行说明。
相关技术中，常采用沙箱环境保证业务处理过程中的文件安全，一般沙箱包括基于虚拟化的沙箱和基于规则的沙箱。
基于虚拟化的沙箱根据虚拟化层次的不同可分为两类，即系统级别的沙箱和容器级别的沙箱，系统级别的沙箱如虚拟机模拟完整的操作环境，让程序如运行在真实的硬件环境之上；容器级别的沙箱采用了更为轻量级的虚拟化技术，实现用户空间资源的虚拟化，在资源使用效率和资源管理上占有较大的优势。
基于规则的沙箱使用访问控制规则限制程序的行为，主要由访问控制规则引擎、程序监控器等部分组成；程序监控器监控程序行为，将监控到的行为经过转换提交给访问控制规则引擎，由访问控制规则引擎根据访问控制规则判断是否允许程序使用系统资源；基于规则的沙箱无需复制系统资源，方便了不同程序对资源的共享，降低了冗余资源对系统性能的影响。
但上述各类沙箱具有如下缺点：
1)处于沙箱中的文件仍可读取或篡改计算机本地中的其他文件的信息，进而影响文件安全。
2)对免费用户有诸多限制，如每次开机首次运行沙箱时会有数秒的暂停并提示用户进行付费注册，用户注册付费后才能使用沙箱。
3)不支持自动将文件拉入沙箱进行隔离，且不能同时运行多个沙箱等。
鉴于此，发明人设计了一种业务处理方法及装置，该方法包括接收业务程序发送的业务处理指令，上述业务处理指令指示待调用的镜像；确定上述待调用的镜像对应的容器组pod的容器组访问微服务service，根据上述service提供的网络地址和端口访问上述pod，通过上述pod提供的容器调用上述待调用的镜像。
其中，上述pod和service是按照如下方式预先创建的:
响应容器创建指令创建容器组pod，上述pod包括至少一个容器，每个容器对应一个镜像；创建用于访问上述pod的service，上述service包括访问上述pod的网络地址和端口。
以下结合附图对本申请的方案进行详细叙述。
请参见图1，本申请实施例提供一种业务处理方法，具体包括如下步骤：
步骤s101，接收业务程序发送的业务处理指令，该业务处理指令指示待调用的镜像，上述镜像包括对上述业务处理指令对应的业务请求进行处理的程序。
此处对业务请求和待调用的镜像的具体内容不做限定，本领域的技术人员可根据实际需求设置，如若业务处理指令的业务请求是压缩文件，则该业务处理指令指示有压缩文件使用的程序为待调用的镜像。
步骤s102，确定待调用的镜像对应的容器组pod的容器组访问微服务service，根据上述service提供的网络地址和端口访问上述pod，通过上述pod提供的容器调用上述待调用的镜像。
本步骤中，在通过pod提供的容器调用待调用的镜像，处理业务请求的过程中，可以调用待调用的镜像提供的程序接口对业务请求进行处理，如业务请求为压缩文件时，可以调用待调用的镜像提供的用于压缩文件的程序接口对待压缩的文件进行压缩。
作为一种实施例，上述方法可以但不局限于用于开源容器工具kubernetes或kubesphere或c2containerservice，即通过kubernetes或kubesphere或c2containerservice响应业务处理指令以及创建pod和service。
作为一种实施例，在步骤s102之后，还可以响应容器删除指令，删除上述pod和上述service，上述容器删除指令是上述业务程序确定结束处理上述业务请求后发送的。
对上述容器删除指令的形式不做限定，本领域的技术人员可根据实际需求设置，如开源容器工具为kubernetes，可以但不局限于将上述容器删除指令设置为kubectl指令或yaml文件等。
上述kubectl指令用于操作kubernetes集群的命令行接口，通过利用kubectl的各种命令可以实现各种功能，是在使用kubernetes中非常常用的工具。
上述yaml文件是一种通用的数据串行化格式，在kubernetes中用作配置文件。
响应容器创建指令创建容器组pod，上述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问上述pod的service，上述service包括访问上述pod的网络地址和端口。
对上述容器创建指令的形式不做限定，本领域的技术人员可根据实际需求设置，如可以但不局限于将上述容器创建指令设置为kubectl指令或yaml文件，在kubectl指令或yaml文件配置指示pod对应的一个或多个镜像。
pod创建完成后，每个pod都有自己的网络地址ip，而pod可能会被频繁地销毁和重建，因而pod的ip可能会发生变化，用pod的ip访问需要的pod容易出现错误，故而本申请中创建service，service定义了访问pod的方式，如service通过提供独立不变的网络地址和端口访问对应的pod。
可选地，可以按照如下方式响应容器创建指令创建容器组pod：
从容器引擎中获取与上述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得上述pod，其中，一个容器对应一个镜像。
开源容器工具中的镜像可以保存在容器引擎doocker镜像仓库中，在创建pod时，根据容器创建指令的指示从doocker镜像仓库拉取一个或多个镜像放入对应的容器即可得到pod。
进一步，由于一个pod可能被频繁地销毁和重启，在创建pod时还可以创建多个功能相同的pod，如此，当其中一个pod意外被销毁或出现其他错误时，还可以访问与其功能相同的其他的pod。
对应地，若创建了至少两个功能相同的pod，则可以将至少两个功能相同的pod看做一个集群，在创建访问pod使用的service时，service提供的网络地址和端口可以访问上述两个功能相同的pod中的任意一个。
基于此，在上述步骤s102中，若service提供的网络地址和端口用于访问至少两个功能相同的pod，则在根据上述service提供的网络地址和端口访问上述pod时，可以但不局限于根据上述service提供的网络地址和端口，随机访问上述至少两个功能相同的pod中任意一个pod。
作为一种实施例，若通过pod中的镜像处理业务请求的过程中需要使用一些数据或文件等资源，则业务程序预先将需要的资源推送或挂在到开源容器工具的网络文件系统中，以便在处理业务请求的过程中，不从业务系统中获取资源，且不操作业务系中的文件。
以下给出一种基于pod进行业务处理的具体示例。
该示例中以kubernetes作为上述开源容器工具，具体包括如下过程：
第一过程：创建pod和service
请参见图2，具体包括：
步骤s201，业务程序向开源容器工具发送容器创建指令。
步骤s202，开源容器工具响应容器创建指令，拉取与容器创建指令对应的至少一个镜像。
即kubernetes根据容器创建指令如kubectl指令yaml文件配置指示，从容器引擎docker镜像仓库中拉取至少一个镜像。
步骤s203，开源容器工具将拉取的至少一个镜像放入到对应的容器中得到pod。
该步骤中kubernetes在每个容器中放入一个镜像，进而得到pod，pod是k8s的最小工作单元，每个pod包含一个或多个容器，pod中的容器会作为一个整体被master调度到一个worker上运行。
上述master是kubernetes的管理者，负责管理以及调度kubernetes，worker则是kubernetes中实际运行服务的执行者。
进一步，在获取一个pod后，可以获取该pod的至少一个副本，进而得到至少两个功能相同的pod。
步骤s204，开源容器工具创建访问pod的service。
若步骤s203中获取了至少两个功能相同的pod，则此步骤创建的service提供的网络地址和端口可以访问上述至少两个功能相同的pod的任意一个。
至此，一个独立于业务程序的业务请求的处理环境就搭建好了，便可进行如下的业务处理过程。
应当说明的是上述kubernetes的各单元docker镜像仓库、master以及worker的功能可以由同一个服务器或不同的服务器实现。
第二过程：处理业务请求的过程
请参见图3，具体包括：
步骤s301，业务程序预先将处理业务请求需要的资源挂在至开源容器工具的网络文件系统。
即业务程序可以将需要的资源预先挂载到kubernetes的网络文件系统(networkfilesystem，nfs)中。
步骤s302，业务程序向开源容器工具发送业务处理指令，该业务处理指令指示待调用的镜像。
步骤s303，开源容器工具确定用于访问待调用的镜像对应的pod的service。
步骤s304，开源容器工具根据确定的service访问pod，通过访问的pod提供的容器调用待调用的镜像处理业务处理指令对应的业务请求。
可选地，在步骤s304之后，还可能包括：
步骤s3041，开源容器工具向业务程序返回业务请求的处理结果。
步骤s3042，业务程序确定结束处理上述业务请求，向开源容器工具发送容器删除指令。
步骤s3043，开源容器工具响应容器删除指令，删除对应的pod和service。
应当说明的是上述kubernetes的各功能以及nfs的功能可以由同一个服务器或不同的服务器实现。
上述第一过程和第二过程中业务程序和kubernetes各单元的信息交互可以参照图4给出的示意图，其中包括业务程序、网络文件系统nfs、docker镜像仓库、kubernetes的master(简称k8smaster)、kubernetes的worker(简称k8sworker)之间的交互。
本申请提供的方法中，一方面在进行业务处理的过程中，限制业务处理过程使用的程序不能读取或篡改其他文件的信息，提升了业务处理过程中文件的安全，且在创建pod时即拉取镜像，支持将文件自动拉入隔离环境pod中，支持用不同的容器隔离不同的镜像，避免了不同的镜像的相互影响以及可能发生相互篡改的情况的出现；以及可以对pod的生命周期进行控制，进一步避免了处理完业务请求的pod中的镜像对计算机中其他文件篡改的情况，提升了隔离环境的安全；另一方面本申请利用应用开源容器工具实现对业务请求的处理，减少了对用户的使用限制。
请参照图5，基于同一发明构思，本申请实施例提供一种业务处理装置500，包括指令接收单元501和业务处理单元502，其中：
指令接收单元501被配置为执行接收业务程序发送的业务处理指令，上述业务处理指令指示待调用的镜像，上述镜像包括对上述业务处理指令对应的业务请求进行处理的程序；
业务处理单元502被配置为执行确定上述待调用的镜像对应的容器组pod的容器组访问微服务service，根据上述service提供的网络地址和端口访问上述pod，通过上述pod提供的容器调用上述待调用的镜像，其中，上述pod和service是按照如下方式预先创建的:
响应容器创建指令创建容器组pod，上述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问上述pod的service，上述service包括访问上述pod的网络地址和端口。
可选地，业务处理单元502还被配置执行：
通过上述pod提供的容器调用上述待调用的镜像之后，响应容器删除指令，删除上述pod和上述service，上述容器删除指令是上述业务程序确定结束处理上述业务请求后发送的。
可选地，上述pod是按照如下方式创建的：
从容器引擎中获取与上述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得上述pod，其中，一个容器对应一个镜像。
可选地，上述service提供的网络地址和端口用于访问至少两个功能相同的pod，业务处理单元502具体被配置执行：
根据上述service提供的网络地址和端口，随机访问上述至少两个功能相同的pod中任意一个pod。
可选地，上述装置包括上述开源容器工具kubernetes装置或kubesphere装置或c2containerservice装置。
请参见图6，基于相同的发明构思，本公开实施例还提供一种电子设备600，包括处理器601、用于存储上述处理器可执行指令的存储器602；
其中，上述处理器601被配置为执行如下过程：
接收业务程序发送的业务处理指令，上述业务处理指令指示待调用的镜像，上述镜像包括对上述业务处理指令对应的业务请求进行处理的程序；
确定上述待调用的镜像对应的容器组pod的容器组访问微服务service，根据上述service提供的网络地址和端口访问上述pod，通过上述pod提供的容器调用上述待调用的镜像，其中，上述pod和service是按照如下方式预先创建的:
响应容器创建指令创建容器组pod，上述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问上述pod的service，上述service包括访问上述pod的网络地址和端口。
可选地，处理器601还被配置为执行：
过上述pod提供的容器调用上述待调用的镜像之后，响应容器删除指令，删除上述pod和上述service，上述容器删除指令是上述业务程序确定结束处理上述业务请求后发送的。
可选地，处理器601具体被配置为执行：
从容器引擎中获取与上述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得上述pod，其中，一个容器对应一个镜像。
可选地，上述service提供的网络地址和端口用于访问至少两个功能相同的pod；
处理器601具体被配置为执行根据上述service提供的网络地址和端口，随机访问上述至少两个功能相同的pod中任意一个pod。
基于同一技术构思，本申请实施例还一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，当上述计算机指令在计算机上运行时，使得计算机执行如前文论述的目标函数确定方法。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
1.一种业务处理方法，其特征在于，包括：
接收业务程序发送的业务处理指令，所述业务处理指令指示待调用的镜像，所述镜像包括对所述业务处理指令对应的业务请求进行处理的程序；
确定所述待调用的镜像对应的容器组pod的容器组访问微服务service，根据所述service提供的网络地址和端口访问所述pod，通过所述pod提供的容器调用所述待调用的镜像，其中，所述pod和service是按照如下方式预先创建的:
响应容器创建指令创建容器组pod，所述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问所述pod的service，所述service包括访问所述pod的网络地址和端口。
2.如权利要求1所述的方法，其特征在于，所述通过所述pod提供的容器调用所述待调用的镜像之后，还包括：
响应容器删除指令，删除所述pod和所述service，所述容器删除指令是所述业务程序确定结束处理所述业务请求后发送的。
3.如权利要求1所述的方法，其特征在于，所述响应容器创建指令创建容器组pod，包括：
从容器引擎中获取与所述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得所述pod，其中，一个容器对应一个镜像。
4.如权利要求1-3任一所述的方法，其特征在于，所述service提供的网络地址和端口用于访问至少两个功能相同的pod；
所述根据所述service提供的网络地址和端口访问所述pod，包括：
根据所述service提供的网络地址和端口，随机访问所述至少两个功能相同的pod中任意一个pod。
5.如权利要求1-3任一所述的方法，其特征在于，所述方法应用于开源容器工具kubernetes或kubesphere或c2containerservice。
6.一种业务处理装置，其特征在于，包括指令接收单元和业务处理单元，其中：
所述指令接收单元被配置为执行接收业务程序发送的业务处理指令，所述业务处理指令指示待调用的镜像，所述镜像包括对所述业务处理指令对应的业务请求进行处理的程序；
所述业务处理单元被配置为执行确定所述待调用的镜像对应的容器组pod的容器组访问微服务service，根据所述service提供的网络地址和端口访问所述pod，通过所述pod提供的容器调用所述待调用的镜像，其中，所述pod和service是按照如下方式预先创建的:
响应容器创建指令创建容器组pod，所述pod包括至少一个容器，每个容器对应一个镜像；
创建用于访问所述pod的service，所述service包括访问所述pod的网络地址和端口。
7.如权利要求6所述的装置，其特征在于，所述业务处理单元还被配置执行：
通过所述pod提供的容器调用所述待调用的镜像之后，响应容器删除指令，删除所述pod和所述service，所述容器删除指令是所述业务程序确定结束处理所述业务请求后发送的。
8.如权利要求6所述的装置，其特征在于，所述pod是按照如下方式创建的：
从容器引擎中获取与所述容器创建指令对应的至少一个镜像；
将获取的各镜像放入对应的容器获得所述pod，其中，一个容器对应一个镜像。
9.如权利要求6-8任一所述的装置，其特征在于，所述service提供的网络地址和端口用于访问至少两个功能相同的pod，所述业务处理单元具体被配置执行：
根据所述service提供的网络地址和端口，随机访问所述至少两个功能相同的pod中任意一个pod。
10.如权利要求6-8任一所述的装置，其特征在于，所述装置包括所述开源容器工具kubernetes装置或kubesphere装置或c2containerservice装置。
技术总结