CN110007980A

CN110007980A - 多业务服务端的实现方法和装置

Info

Publication number: CN110007980A
Application number: CN201910087285.XA
Authority: CN
Inventors: 徐曾
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2019-01-29
Filing date: 2019-01-29
Publication date: 2019-07-12
Anticipated expiration: 2039-01-29
Also published as: CN110007980B

Abstract

本说明书提供一种多业务服务端的实现方法，应用于所述服务端运行的宿主主机上，所述方法包括：获取业务插件的安装包，所述业务插件安装包包括至少一项业务的业务逻辑实现、以及在宿主主机上运行所述业务逻辑时依赖的软件资源；以独立的上下文加载所述业务插件；启动运行加载完毕的所述业务插件，由运行的业务插件对所述至少一项业务的请求进行响应。

Description

多业务服务端的实现方法和装置

技术领域

本说明书涉及网络通信技术领域，尤其涉及一种多业务服务端的实现方法和装置。

背景技术

手机、平板电脑等移动设备由于其优异的便捷性和爆炸式的增长速度，让App(应用软件)也同时拥有了极强的渗透能力。人们通过App完成沟通、购物、支付等事务，使得移动应用逐渐覆盖了工作生活的方方面面。为了满足用户的多样化需求，同一个App通常向用户提供多种业务服务。

作为客户端，App内的每种业务都需要通过与服务端的交互来进行。多业务服务端可以采用一个服务集群的方式来构建，在集群中运行用多个业务功能模块分别实现不同的业务服务。这些业务功能模块共用代码，相互耦合，一个业务功能模块的修改往往会影响到其他业务功能模块的运行，甚至严重影响整个服务端的系统稳定性，难以满足业务发展过程中快速多变的实际需求。

发明内容

有鉴于此，本说明书提供一种多业务服务端的实现方法，应用于所述服务端运行的宿主主机上，所述方法包括：

获取业务插件的安装包，所述业务插件安装包包括至少一项业务的业务逻辑实现、以及在宿主主机上运行所述业务逻辑时依赖的软件资源；

以独立的上下文加载所述业务插件；

启动运行加载完毕的所述业务插件，由运行的业务插件对所述至少一项业务的请求进行响应。

本说明书还提供了一种多业务服务端的实现装置，应用于所述服务端运行的宿主主机上，所述装置包括：

安装包获取单元，用于获取业务插件的安装包，所述业务插件安装包包括至少一项业务的业务逻辑实现、以及在宿主主机上运行所述业务逻辑时依赖的软件资源；

插件加载单元，用于以独立的上下文加载所述业务插件；

插件运行单元，用于启动运行加载完毕的所述业务插件，由运行的业务插件对所述至少一项业务的请求进行响应。

本说明书提供的一种计算机设备，包括：存储器和处理器；所述存储器上存储有可由处理器运行的计算机程序；所述处理器运行所述计算机程序时，执行上述多业务服务端的实现方法所述的步骤。

本说明书还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时，执行上述多业务服务端的实现方法所述的步骤。

由以上技术方案可见，本说明书的实施例中，在业务插件安装包中封装业务逻辑实现以及所依赖的软件资源，在加载业务插件时采用独立的上下文，使得每个业务插件与其他业务插件解耦合，每个业务插件的升级、故障等均不会影响其他业务插件的运行，增加了业务插件的开发独立性，降低了开发人员的工作量和工作难度，提高了业务插件升级时服务端的系统稳定性。

附图说明

图1是本说明书实施例应用场景的一种网络结构图；

图2是本说明书实施例中一种应用于宿主主机上的多业务服务端的实现方法的流程图；

图3是本说明书应用示例中一种宿主主机上软件系统的结构示意图；

图4是运行本说明书实施例的设备的一种硬件结构图；

图5是本说明书实施例中一种应用于宿主主机上的多业务服务端的实现装置的逻辑结构图。

具体实施方式

本说明书的实施例提出一种新的多业务服务端的实现方法，业务服务以插件的形式在宿主主机上加载后运行，业务插件的安装包中封装有至少一项业务的业务逻辑实现以及运行该业务逻辑时依赖的软件资源，在以独立的上下文加载业务插件并启动运行后即可由其提供业务服务，这样每个业务插件与其他业务插件相互独立，降低了开发人员在开发业务插件时的工作量和工作难度，并且一个业务插件的升级、故障等不会影响其他业务插件的服务，极大的提高了服务端的系统稳定性。

图1所示是本说明书实施例应用场景的一种网络结构示例，用户在其终端(如个人电脑或手机)上利用浏览器或App来进行各种业务，终端上的浏览器或App通过通信网络访问提供这些业务的服务端。服务端可以运行在一台宿主主机上(图1中未示出)，也可以以集群的形式运行在两个到多个宿主主机上。在服务端采用集群的形式时，每台宿主主机上运行若干个业务插件，每个业务插件用来实现一项到多项业务的服务端业务逻辑，不同的业务插件实现不同业务的业务逻辑。由终端发起的某项业务的请求，将由服务端负责该项业务的业务插件来进行响应。如图1中，宿主主机1上运行业务插件P1，宿主主机2上运行业务插件P2，宿主主机3上运行业务插件P1和P2。

其中，用户的终端一般是手机、平板电脑、PC(Personal Computer，个人电脑)、笔记本等设备；服务端运行的宿主主机可以是一个物理或逻辑设备，也可以是由两个或两个以上分担不同职责的物理或逻辑设备、相互协同来实现本说明书实施例中宿主主机的各项功能。另外，本说明书实施例对通信网络的类型、协议等均不做限定。

本说明书的实施例中，如前所述，在服务端由安装和运行在服务端宿主主机上的业务插件来向用户侧的客户端(如App)或浏览器提供各项业务的服务，每个业务插件可以负责一项到多项业务的服务，每项业务由同一个业务插件来负责。例如，服务端提供3种业务服务：业务A、业务B和业务C，可以由3个对应的业务插件分别实现业务A、业务B和业务C的服务端业务逻辑；也可以由一个业务插件P1实现业务A和业务B的服务端业务逻辑，由另一个业务插件P2实现业务C的服务端业务逻辑。

在开发业务插件时，开发人员按照属于该业务插件的各项业务的业务逻辑编写该业务插件的业务代码，以业务代码为基础生成该业务插件的业务逻辑实现，将业务逻辑实现和在宿主主机上运行该业务逻辑时依赖的软件资源封装到该业务插件的安装包中。

其中，业务逻辑实现用来完成当浏览器或客户端请求该业务插件负责的各项业务时，服务端对这些业务的各种处理流程；运行业务逻辑时依赖的软件资源包括在宿主主机上能够独立于其他业务插件来运行这些业务的业务逻辑(即该业务插件的运行只依赖于宿主主机的运行而不依赖于其他业务插件的运行)时所需要的各种软件资源，如需要调用的子程序或函数、字体、图片素材等等。

在一些应用场景中，服务端的多个业务插件会用到一些相同的功能，如通信功能、多语言支持等。这些功能可以由宿主主机上的公共服务来提供，即在宿主主机上运行一项到多项的公共服务，每项公共服务实现一种到多种可以被本宿主主机上业务插件使用的功能。公共服务可以提供对应于功能的调用接口，供本机上运行的业务插件来调用，以实现相应的功能。

根据实际应用场景中宿主主机的操作系统、开发人员所使用的开发环境等因素，业务逻辑实现、或运行业务逻辑时所依赖的软件资源可以是各种不同的文件形式，也可以采用各种不同的实现方式，本说明书的实施例不做限定。例如，业务插件安装包中的业务逻辑实现可以是开发人员编写的业务代码，也可以是对业务代码进行编译后生成的编译文件。

再如，在一种实现方式中，可以将业务逻辑中可能需要进行调整的参数作为配置参数，使用配置参数来编写用于实现业务逻辑的业务代码，在业务插件安装包中封装业务代码、业务配置和在宿主主机上运行该业务逻辑时所需软件资源。其中，业务配置用来确定业务代码中可调整参数(即配置参数)的值。将业务配置应用于业务代码后，可以确定业务代码中所有配置参数的值，具有确定配置参数值的业务代码即可用来生成可以加载并运行的业务插件。

本说明书的实施例中，多业务服务端的实现方法的流程如图2所示，该方法应用于服务端运行的宿主主机上。

步骤210，获取业务插件的安装包；业务插件安装包包括至少一项业务的业务逻辑实现、以及在宿主主机上运行该业务逻辑时依赖的软件资源；

在生成一个业务插件的安装包后，根据实际应用场景的具体情况，宿主主机可以采用各种方式获得业务插件的安装包，不做限定。例如，可以由开发人员直接在宿主主机上生成安装包并启动安装过程；可以由宿主主机定期查询某个预定网络存储位置，看是否有新版本的业务插件安装包或尚未安装的业务插件安装包，如果有则从该存储位置下载或读取后直接安装。

需要说明的是，业务插件安装包的安装过程，即是使用安装包加载该业务插件的过程。另外，业务插件安装包中还可以包括安装和运行该业务插件所需的其他软件资源、包括版本信息的描述文件等其他资源。

在一些应用场景中，可以由插件发布系统来向各个宿主主机推送业务插件的安装包，宿主主机收到插件系统分发的新版本业务插件的安装包或将要安装在本机上的新的业务插件的安装包之后，等待插件发布系统的安装指令，在收到安装指令后，再启动新版本业务插件或新业务插件的安装。

步骤220，以独立的上下文加载该业务插件。

一个业务插件的上下文提供了该业务插件的运行环境，独立的上下文指的是在同一个宿主主机上，一个业务插件的运行环境与其他业务插件的运行环境解耦和，相互之间没有依赖关系。根据实际应用场景中宿主主机的操作系统、业务插件所使用的开发语言和/或开发工具等因素，可以采用匹配于上述因素的具体方式来为某个业务插件构建独立的上下文，并使用该业务插件的安装包以构建的上下文来加载该业务插件，本说明书的实施例不做限定。

在一个例子中，可以基于宿主主机的容器创建独立的加载器来初始化业务插件的上下文，并且采用该加载器和该业务插件的上下文来加载安装包中的业务逻辑实现以及安装包中的其他软件资源(包括运行该业务逻辑时依赖的软件资源)。

将上述例子进一步具体到使用Java开发业务插件的情况，业务逻辑通常采用Java类来实现，业务插件的安装包中会包括实现用于业务逻辑的所有Java类、以及这些Java类所依赖的所有jar(Java Archive，Java归档文件)包。在加载业务插件时，以宿主主机上运行的Java容器的根上下文作为业务插件的父上下文(parent context)，创建独立的类加载器来初始化业务插件的上下文，并加载业务插件安装包中用于实现业务逻辑的Java类、及其所依赖jar包中的类、以及其他需要的资源。

具体而言，宿主主机上的Java容器在启动后会初始化一个启动上下文，这个上下文被称为根上下文；每个业务插件在加载时会先从Java容器中获取其根上下文作为自己上下文的父上下文，再基于父上下文创建独立的ClassLoader(类加载器)以初始化自己的上下文，这样每个业务插件就拥有了独立的ClassLoader和独立的上下文。再采用独立的ClassLoader和独立的上下文完成业务插件的加载，即可使得该业务插件拥有独立于其他业务插件的软件运行环境。

在一些应用场景中，可以为每个业务插件的上下文分配独立的物理资源，如CPU(Central Process Unit，中央处理器)时间片、内存等，使得各个业务插件在运行时在物理资源层面也相互隔离，从而进一步减少某项业务变更时对其他业务可能造成的影响。为业务插件的上下文分配独立物理资源的具体方式可以根据宿主主机的硬件平台、操作系统、业务插件所使用的开发语言和/或开发工具等因素来确定，本说明书的实施例不做限定。

对上述例子，可以在基于宿主主机的容器创建独立的加载器、并通过加载器初始化业务插件的上下文后，为业务插件的上下文分配独立的物理资源，再采用该加载器和该上下文加载该业务插件，这样业务插件的加载过程和运行过程都将使用为其分配的物理资源，而这些物理资源不会被其他业务插件使用。

具体到使用Java开发业务插件的情况，可以采用支持CGroup(Control Group，控制群组)技术的JVM(Java Virtual Machine，Java虚拟机)来作为宿主主机上Java容器的底层(即Java容器运行在支持CGroup技术的JVM上)。由于CGroup技术支持为每个独立的上下文分配独立的内存及CPU时间片，Java容器可以将上述隔离能力通过JVM参数暴露给业务插件，这样每个业务插件基于CGroup技术即可获得宿主主机上独立的内存和独立的CPU时间片。

步骤230，启动运行加载完毕的该业务插件，由运行的业务插件对至少一项业务的请求进行响应。

在某个业务插件加载完毕后，即可启动运行。当宿主主机收到来自用户终端的对某项业务的请求，如果该项业务由该业务插件负责，则由运行中的该业务插件来对该项业务的请求进行响应。

在由宿主主机向其上运行的各个业务插件提供公共服务的应用场景中，业务插件可能需要通过调用宿主主机提供的公共服务接口，来使用所需的一项到多项功能，以完成对业务请求的响应。

本说明书的实施例中，宿主主机所获取的业务插件安装包，既可以是新的业务插件安装包(即该业务插件负责的一项到多项业务，不同于宿主主机上已有的业务插件所负责的业务)，也可以是已有业务插件的新版本安装包。当所获取的安装包是新版本业务插件安装包时，可以在新版本业务插件启动运行前，仍旧由对应于新版本业务插件的老版本业务插件对所负责的业务请求进行响应；而在新版本业务插件加载完毕启动运行后，再将流量切换至新版本业务插件，即由新版本业务插件来对所负责的业务请求进行响应；从而使得宿主主机无需停机即可实现新老版本业务插件的平滑升级。在所负责业务的流量切换至新版本业务插件后，可以在宿主主机上注销老版本业务插件的各项服务，关闭老版本业务插件的上下文，释放老版本业务插件的上下文占用的物理资源。

可见，本说明书的实施例中，在业务插件安装包中封装业务逻辑实现以及所依赖的软件资源，以独立的上下文加载业务插件并启动运行后即可由其提供业务服务，使得每个业务插件与其他业务插件解耦合，降低了开发人员在开发业务插件时的工作量和工作难度，并且一个业务插件的升级、故障等不会影响其他业务插件的服务，提高了服务端的系统稳定性。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书的一个应用示例中，用户在智能手机上安装一个移动互联服务商的App后，可以通过该App使用该移动互联服务商提供多项业务功能。该App的服务端运行在由多个宿主主机组成的一个集群上，每项业务由一个业务插件来实现，每项业务的业务插件运行在至少一台宿主主机上。

对每个业务插件，开发人员编写业务代码和业务配置，来实现该项业务的服务端业务逻辑。开发人员将经过测试的业务代码和业务配置、以及业务代码中所有Java类所依赖的各项jar包，打包后生成该业务插件的安装包，并将业务插件安装包提交至动态发布系统(一种插件发布系统)，并设置该业务插件安装包的发布规划(如灰度、全量等)。

动态发布系统按照发布规划，将该业务插件安装包推送给集群中的至少一台宿主主机。宿主主机保存接收到的安装包。动态发布系统向接收安装包的宿主主机发出该安装包的安装指令。

宿主主机上运行支持Docker CGroup技术的JVM，来作为Java容器的底层，Java容器在启动后会初始化一个启动上下文作为根上下文。在收到动态发布系统的安装指令后，宿主主机将安装包中的业务配置应用于业务代码，然后开始采用业务代码来加载业务插件。宿主主机先将Java容器的根上下文作为自己上下文的父上下文，再基于父上下文创建独立的ClassLoader来初始化自己的上下文，从而该业务插件可以拥有独立于其他业务插件的上下文。采用Java容器通过JVM参数暴露的CGroup隔离能力，可以为该业务插件的上下文分配独立的内存和独立的CPU时间片，从而得到与其他业务插件相隔离的物理资源。

本应用示例中，宿主主机上运行有多项公共服务，各个业务插件可以通过调用公共服务提供的接口来实现对应的公共服务功能。在业务插件安装完成后，宿主主机上的软件系统的结构如图3所示。对安装完毕的业务插件进行安全检查，在通过安全检查后启动运行该业务插件，该业务插件即可对其所负责业务的请求进行响应。在响应业务请求时，该业务插件可以调用宿主主机上的公共服务所提供的功能。

可见，宿主主机上的各个业务插件之间上下文、物理资源相互隔离，业务插件与宿主系统之间上下文、物理资源也相互隔离。

本应用示例中，通过动态发布系统发布的业务插件安装包可以是某个业务插件的新版本安装包。在新版本业务插件启动运行前(包括新版本业务插件的安装过程进行时)，在宿主主机上可以继续由该新版本业务插件对应的老版本业务插件处理其负责业务的请求，在新版本插件启动运行后，再将所负责业务的流量切换到新版本业务插件上。在流量切换完成后，宿主主机注销老版本插件的各项服务，关闭老版本插件的上下文，并清理老版本插件占用的物理资源，完成老版本插件的卸载。

与上述流程实现对应，本说明书的实施例还提供了一种多业务服务端的实现装置。该装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为逻辑意义上的装置，是通过所在设备的CPU将对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，除了图4所示的CPU 420、内存440以及存储器430之外，多业务服务端的实现装置所在的设备400通常还包括其他硬件410，如用于进行无线信号收发的芯片、和/或用于实现网络通信功能的板卡等。

图5所示为本说明书实施例提供的一种多业务服务端的实现装置500，应用于所述服务端运行的宿主主机上，所述装置包括安装包获取单元510、插件加载单元520和插件运行单元530，其中：安装包获取单元510用于获取业务插件的安装包，所述业务插件安装包包括至少一项业务的业务逻辑实现、以及在宿主主机上运行所述业务逻辑时依赖的软件资源；插件加载单元520用于以独立的上下文加载所述业务插件；插件运行单元530用于启动运行加载完毕的所述业务插件，由运行的业务插件对所述至少一项业务的请求进行响应。

可选的，所述插件加载单元520具体用于：创建独立的加载器初始化所述业务插件的上下文，为所述业务插件的上下文分配独立的物理资源，基于所述加载器和业务插件的上下文加载所述业务插件。

可选的，所述插件运行单元530由运行的业务插件对所述至少一项业务的请求进行响应，包括：由运行的业务插件通过调用宿主主机提供的公共服务，对所述至少一项业务的请求进行响应；所述公共服务为运行在所述宿主主机上的所有业务插件提供调用接口。

可选的，所述业务插件安装包包括：业务代码和业务配置，所述业务代码用于实现业务逻辑，所述业务配置用于确定业务代码中可调整参数的值；所述插件加载单元520具体用于：将业务配置应用于业务代码后，以独立的上下文加载由所述业务代码生成的业务插件。

一个例子中，所述安装包获取单元510具体用于：接收插件发布系统分发的新版本业务插件的安装包；所述插件加载单元520具体用于：在收到插件发布系统的安装所述新版本业务插件的指令后，以独立的上下文加载所述业务插件；所述插件运行单元530具体用于：在新版本业务插件加载完毕启动运行后，由新版本业务插件对所述至少一项业务的请求进行响应。

上述例子中，所述装置还可以包括老版本卸载单元，用于在新版本业务插件加载完毕启动运行后，注销对应于所述新版本业务插件的老版本业务插件的各项服务，关闭所述老版本业务插件的上下文，释放所述老版本业务插件的上下文占用的物理资源。

一种实现方式中，所述业务插件安装包包括实现所述业务逻辑的所有Java类、以及所依赖的所有Java归档文件jar包；所述插件加载单元520具体用于：以宿主主机上运行的Java容器的根上下文作为业务插件的父上下文，创建独立的类加载器初始化业务插件的上下文，并加载业务插件安装包中的Java类。

上述实现方式中，所述宿主主机上Java容器运行在支持控制群组CGroup技术的Java虚拟机JVM上，所述业务插件基于CGroup技术获得宿主主机上独立的内存和中央处理器CPU时间片。

本说明书的实施例提供了一种计算机设备，该计算机设备包括存储器和处理器。其中，存储器上存储有能够由处理器运行的计算机程序；处理器在运行存储的计算机程序时，执行本说明书实施例中多业务服务端的实现方法的各个步骤。对多业务服务端的实现方法的各个步骤的详细描述请参见之前的内容，不再重复。

本说明书的实施例提供了一种计算机可读存储介质，该存储介质上存储有计算机程序，这些计算机程序在被处理器运行时，执行本说明书实施例中多业务服务端的实现方法的各个步骤。对多业务服务端的实现方法的各个步骤的详细描述请参见之前的内容，不再重复。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书的实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书的实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims

1.一种多业务服务端的实现方法，应用于所述服务端运行的宿主主机上，所述方法包括：

以独立的上下文加载所述业务插件；

2.根据权利要求1所述的方法，所述以独立的上下文加载所述业务插件，包括：创建独立的加载器初始化所述业务插件的上下文，为所述业务插件的上下文分配独立的物理资源，基于所述加载器和业务插件的上下文加载所述业务插件。

3.根据权利要求1所述的方法，所述由运行的业务插件对所述至少一项业务的请求进行响应，包括：由运行的业务插件通过调用宿主主机提供的公共服务，对所述至少一项业务的请求进行响应；所述公共服务为运行在所述宿主主机上的所有业务插件提供调用接口。

4.根据权利要求1所述的方法，所述业务插件安装包包括：业务代码和业务配置，所述业务代码用于实现业务逻辑，所述业务配置用于确定业务代码中可调整参数的值；

所述以独立的上下文加载所述业务插件，包括：将业务配置应用于业务代码后，以独立的上下文加载由所述业务代码生成的业务插件。

5.根据权利要求1所述的方法，所述获取业务插件的安装包，包括：接收插件发布系统分发的新版本业务插件的安装包；

所述以独立的上下文加载所述业务插件，包括：在收到插件发布系统的安装所述新版本业务插件的指令后，以独立的上下文加载所述业务插件；

所述启动运行加载完毕的所述业务插件，由运行的业务插件对所述至少一项业务的请求进行响应，包括：在新版本业务插件加载完毕启动运行后，由新版本业务插件对所述至少一项业务的请求进行响应。

6.根据权利要求5所述的方法，所述方法还包括：在新版本业务插件加载完毕启动运行后，注销对应于所述新版本业务插件的老版本业务插件的各项服务，关闭所述老版本业务插件的上下文，释放所述老版本业务插件的上下文占用的物理资源。

7.根据权利要求1所述的方法，所述业务插件安装包包括实现所述业务逻辑的所有Java类、以及所依赖的所有Java归档文件jar包；

所述以独立的上下文加载所述业务插件，包括：以宿主主机上运行的Java容器的根上下文作为业务插件的父上下文，创建独立的类加载器初始化业务插件的上下文，并加载业务插件安装包中的Java类。

8.根据权利要求7所述的方法，所述宿主主机上Java容器运行在支持控制群组CGroup技术的Java虚拟机JVM上，所述业务插件基于CGroup技术获得宿主主机上独立的内存和中央处理器CPU时间片。

9.一种多业务服务端的实现装置，应用于所述服务端运行的宿主主机上，所述装置包括：

插件加载单元，用于以独立的上下文加载所述业务插件；

10.根据权利要求9所述的装置，所述插件加载单元具体用于：创建独立的加载器初始化所述业务插件的上下文，为所述业务插件的上下文分配独立的物理资源，基于所述加载器和业务插件的上下文加载所述业务插件。

11.根据权利要求9所述的装置，所述插件运行单元由运行的业务插件对所述至少一项业务的请求进行响应，包括：由运行的业务插件通过调用宿主主机提供的公共服务，对所述至少一项业务的请求进行响应；所述公共服务为运行在所述宿主主机上的所有业务插件提供调用接口。

12.根据权利要求9所述的装置，所述业务插件安装包包括：业务代码和业务配置，所述业务代码用于实现业务逻辑，所述业务配置用于确定业务代码中可调整参数的值；

所述插件加载单元具体用于：将业务配置应用于业务代码后，以独立的上下文加载由所述业务代码生成的业务插件。

13.根据权利要求9所述的装置，所述安装包获取单元具体用于：接收插件发布系统分发的新版本业务插件的安装包；

所述插件加载单元具体用于：在收到插件发布系统的安装所述新版本业务插件的指令后，以独立的上下文加载所述业务插件；

所述插件运行单元具体用于：在新版本业务插件加载完毕启动运行后，由新版本业务插件对所述至少一项业务的请求进行响应。

14.根据权利要求13所述的装置，所述装置还包括：老版本卸载单元，用于在新版本业务插件加载完毕启动运行后，注销对应于所述新版本业务插件的老版本业务插件的各项服务，关闭所述老版本业务插件的上下文，释放所述老版本业务插件的上下文占用的物理资源。

15.根据权利要求9所述的装置，所述业务插件安装包包括实现所述业务逻辑的所有Java类、以及所依赖的所有Java归档文件jar包；

所述插件加载单元具体用于：以宿主主机上运行的Java容器的根上下文作为业务插件的父上下文，创建独立的类加载器初始化业务插件的上下文，并加载业务插件安装包中的Java类。

16.根据权利要求15所述的装置，所述宿主主机上Java容器运行在支持控制群组CGroup技术的Java虚拟机JVM上，所述业务插件基于CGroup技术获得宿主主机上独立的内存和中央处理器CPU时间片。

17.一种计算机设备，包括：存储器和处理器；所述存储器上存储有可由处理器运行的计算机程序；所述处理器运行所述计算机程序时，执行如权利要求1到8任意一项所述的步骤。

18.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时，执行如权利要求1到8任意一项所述的步骤。