业务处理系统、业务处理方法以及业务更新方法与流程

本发明涉及通信技术领域，尤其涉及一种业务处理系统、业务处理方法以及业务更新方法。

背景技术：

目前，各业务平台承载着众多不同类型的业务，并且这些业务更新频繁，因此，需要经常更新业务平台上已有的业务实例。传统的业务平台中，业务请求与业务实例之间没有建立合理的对应关系，各个业务实例作为整体接受业务处理平台的管理和调用。因此，当对一项业务内容进行更新(即需要更新业务实例)时，需要对整个业务平台进行重新部署，需要重新启动相关业务进程，严重影响平台上各业务实例的正常服务进程。

例如，paas(platform-as-a-service，简称paas)平台采用代码下发，进程重启方式来实现业务内容的更新，即当检测到有业务内容更新时，paas平台停止该业务的相关进程运行，并重新加载新的业务实例，若加载完成后，需要重新启动该业务相关进程后，才能进行正常的业务处理。

因此，现有技术至少存在如下缺陷：当进行业务更新时，平台需停止该业务的相关进程的运行直至新的业务内容成功加载，这样会造成长时间的业务中断，且在重启过程中也存在各种风险，可能会导致业务中断，影响业务运行的稳定性。

技术实现要素：

本发明提供一种业务处理系统、业务处理方法以及业务更新方法，以实现在更新业务内容时，减少对平台运行的影响。

为达到上述目的，本发明提供了一种业务处理方法，包括：接收业 务请求；提取业务请求的url中所包含的业务实例路由信息；根据所述业务实例路由信息，调用所述业务实例路由信息对应的业务实例，对所述业务请求进行处理，其中，所述每个所述业务实例与至少一个业务实例路由信息相对应。

本发明还提供了一种业务处理方法，所述业务处理方法在业务处理系统上执行，所述业务处理系统包括业务处理服务器，所述业务处理服务器包括路由层和业务层，所述路由层中运行有路由模块，所述业务层中运行有多个执行业务处理的业务实例，所述业务处理方法包括：

所述路由模块接收业务请求，提取业务请求的url中所包含的业务实例路由信息，并根据所述业务实例路由信息，调用所述业务实例路由信息对应的业务实例，对所述业务请求进行处理，其中，所述每个所述业务实例与至少一个业务实例路由信息相对应。

本发明还提供了一种业务处理系统，包括业务处理服务器，所述业务处理服务器中包括路由层和业务层，在所述路由层中运行有路由模块，所述业务层中运行有多个业务实例，

所述路由模块用于接收业务请求，提取业务请求的url中所包含的业务实例路由信息，并根据所述业务实例路由信息，对与所述业务实例路由信息对应的业务实例进行调用，其中，所述每个所述业务实例与至少一个业务实例路由信息相对应；所述业务实例用于执行所述业务请求对应的业务处理。

本发明还提供了一种业务更新方法，所述业务更新方法在业务处理系统上执行，所述业务处理系统包括业务处理服务器和配置服务器，

所述业务处理服务器包括路由层和业务层，所述路由层中运行有路由模块，所述业务层中运行有多个执行业务处理的业务实例，

在所述配置服务器中存储有业务实例路由信息与各个业务实例的业务实例名称之间的第一对应关系信息，所述每个所述业务实例名称与至少一个业务实例路由信息相对应，

所述业务层中包括第一实例运行空间和第二实例运行空间，在所述第一实例运行空间中的业务实例能够接受所述路由模块的调用，在所述 第二实例运行空间中的业务实例不接受所述路由模块的调用，

业务更新方法包括：

在所述配置服务器中，监听业务内容的更新，并通知所述业务处理服务器；

所述业务处理服务器根据新的业务内容生成新的业务实例，用该新的业务实例替换对应的旧的业务实例。

在本发明的业务处理系统、业务处理方法以及业务更新方法的技术方案中，将针对每项业务的业务请求与具体业务实例建立直接的对应关系，在业务请求的处理过程中，通过url中包含业务实例路由信息找到并完成业务实例的调用。通过这样的调用机制，在进行具体业务调用时，通过业务请求中的url(统一资源定位符)信息就能够直接定位到一个具体的业务实例，这样的调用机制使得业务请求到业务实例的调用关系非常清晰，每项业务相对独立，便于业务的管理和部署，尤其在进行业务内容更新时，仅涉及与该业务内容对应的业务实例的更新操作，而不会影响到其他的业务实例，也不会影响到整个业务处理系统的运行。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。

图1为本发明实施例一的业务处理方法的流程图。

图2为本发明实施例二的业务处理系统的结构示意图之一。

图3为本发明实施例二的业务处理系统的结构示意图之二。

图4为本发明实施例三的业务处理系统的结构示意图之一。

图5为本发明实施例三的业务处理系统的结构示意图之二。

图6为本发明实施例四的业务处理系统的结构示意图之一。

图7为本发明实施例四的业务处理系统的结构示意图之二。

图8为本发明实施例六的业务更新方法的流程示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。下面结合附图对本发明实施例进行详细描述。

实施例一

如图1所示，其为本发明实施例一的业务处理方法的流程图，该方法包括：

步骤101：接收业务请求。

步骤102：提取业务请求的url(统一资源定位符)中所包含的业务实例路由信息。本实施例对url的字段信息进行重新的设计定义，在其中加入了业务实例路由信息。本实施例的url的结构可以采用如下结构：http：{host}/{instancepath}？auth[token]，其中，“http”为网路协议部分，“host”为服务器的ip地址和主机名，“auth[token]”为url的参数部分，“instancepath”是业务实例路由信息。例如：http：//www.test.com/testpay？auth[token]＝xxxx&。其中，这里的“testpay”就是业务实例路由信息。

步骤103：根据业务实例路由信息，调用业务实例路由信息对应的业务实例，对业务请求进行处理，与上面的url结构相对应地，可以预先将“instancepath”与在业务处理系统中的业务实例建立映射关系，从而使得业务处理系统根据“instancepath”就可以找到对应的业务实例，例如前面的示例的url中，可以将“testpay”与处理支付的业务实例建立映射关系，从而实现对处理支付的业务实例的调用。其中，每个业务实例与至少一个业务实例路由信息相对应，这是因为一般从业务实例的设计角度来说，会将彼此关联的业务处理内容设计在一个业务实例中，这样能够更加有效地利用系统资源，并且也便于业务实例的管理。

具体地，在实际的程序处理过程中，只要获知了业务实例的名称就 可以针对该业务实例进行调用，因此，在上述步骤103中，可以先根据业务实例路由信息获取对应的业务实例名称，然后，再通过业务实例名称，调用业务实例。其中，每个业务实例名称与至少一个业务实例路由信息相对应，该对应关系可以预先存储在业务处理系统中。优选地，在业务层中运行的多个业务实例之间彼此相互独立，并且业务实例的名称是唯一的。

在上述的业务实例调用机制中，将针对每项业务的业务请求与具体业务实例建立直接的对应关系，在业务请求的处理过程中，通过url中包含业务实例路由信息找到并完成业务实例的调用。通过这样的调用机制，在进行具体业务调用时，通过业务请求中的url(统一资源定位符)信息就能够直接定位到一个具体的业务实例，这样的调用机制使得业务请求到业务实例的调用关系非常清晰，每项业务相对独立，便于业务的管理和部署，尤其在进行业务内容更新时，仅涉及与该业务内容对应的业务实例的更新操作，而不会影响到其他的业务实例，也不会影响到整个业务处理系统的运行。

此外，在调用业务实例执行业务处理时，还需要使用业务参数，例如用户信息参数等。这些业务参数可以包含在url中，也可以包含在业务请求的数据包，也可以预先存储在业务处理系统中。

因此，上述的业务处理方法还可以包括向业务实例发送业务参数的步骤，具体地，包括如下几种情况：

1)从url中和/或业务请求的数据包中提取第一业务参数，并发送给业务实例。这里所说的第一业务参数是来自于业务请求自带的参数，例如发出业务请求的用户信息等。

2)根据业务实例路由信息获取预先存储的作为系统默认参数的第二业务参数，并发送给业务实例。在这种情况下，上述的业务实例路由信息除了可以指向业务实例名称之外，还指向了用于业务处理的系统默认的第二业务参数，从而使得在调用业务实例的同时也能获取到该第二业务参数。这里所说的第二业务参数为系统默认的业务参数，例如，业务实例有些私密数据，需要进行加密处理，那么第二业务参数可以是密钥 这样的参数。再例如，对某个业务实例不希望太频繁的调用，设置了1分钟内只能调用预定次数的系统默认参数。

3)也可以结合上述1)和2)的情形，除了从url中和/或业务请求的数据包获取第一业务参数以外，同时还调用系统默认的第二业务参数，用于业务实例执行业务处理。

综上所述，上述的业务实例路由信息与业务实例名称以及第二业务参数的对应关系可以表示为如下对应形式，该对应关系存储在业务处理系统中，用于业务实例的调用和业务处理：

表一

从上面的表一中可以看出，业务请求与业务路由信息之间是一一对应的，也就是说不同的业务请求的url中的业务路由信息是不同的。而不同的业务请求可能会由同一个业务实例来处理，如上表中的业务请求1和业务请求2均由“业务实例名称1”对应的业务实例来进行处理。此外，第二业务参数为系统默认的业务参数，会根据业务请求的不同而预先设定，不同的业务请求可以对应相同的第二业务参数，也可以对应不同的第二业务参数。当然，针对部分业务请求，系统业务可以不预先配置系统默认参数，完全依靠业务请求中携带的业务参数进行业务处理，例如上表中的业务请求5。

在实际应用中，在业务实例和业务实例路由信息之间，还可以增加一层索引结构，在本实施例中称为路由名字，例如下表二中所示：

表二

即通过业务路由信息先找到路由名字，然后再通过路由名字获取业务实例名称或者第二业务参数。在实际应用中，配置服务器会存在一定的数据存储和索引的规则。因此，会按照配置服务器本身的索引规则将路由名字和业务实例名称等信息进行预先存储，然后再增加业务路由信息和路由名字之间的映射关系。

实施例二

如图2所示，其为本发明实施例二业务处理系统的结构示意图之一，该业务处理系统包括业务处理服务器1，该业务处理服务器中包括路由层11和业务层12，在路由层中运行有路由模块111，业务层中运行有多个业务实例121，

路由模块111用于接收业务请求，提取业务请求的url中所包含的业务实例路由信息，并根据业务实例路由信息，对与业务实例路由信息对应的业务实例121(图中将业务实例编号为1至n)进行调用，业务实例121用于执行业务请求对应的业务处理。

其中，每个业务实例与至少一个业务实例路由信息相对应，即业务实例与业务实例路由信息之间可以是一对一或者一对多的关系，每个业务实例可以具有处理多个不同具体业务的功能，即可以用来处理多个不同的业务请求，这些业务请求可以通过调用时使用的业务参数的不同来触发业务实例执行不同的业务处理。图中仅示例性地表示出n个业务请求与n个业务实例一一对应的情形，实际上，图中的业务请求1～n可以有小于n个的业务实例来执行业务处理。

例如，以网购的业务处理系统为例，在进行业务实例设计时，可以将支付相关的功能(例如，计算总价功能和转账支付功能)设计为由一 个业务实例完成，用户在完成购物选择后，可以在点击“结算”按键后，客户端首先会想业务处理系统发出“计算总价”的业务请求，并在业务请求中携带已选商品信息等相关业务参数，业务处理系统通过上述的业务方法调用支付业务实例进行总价计算，并返回数据呈献给用户，之后，在用户点击“确认”按键后，客户端会再次向业务处理系统发出“转账支付”的业务请求，并在业务请求中携带用户支付相关的参数，业务处理系统再次调用支付业务实例进行转账支付的业务处理，从而完成整个支付过程。

进一步地，业务实例与业务实例路由信息之间的对应关系可以存储在单独设置的配置服务器中。如图3所示，其为本发明实施例二业务处理系统的结构示意图之二，本实施例的业务处理系统还可以包括配置服务器2，在配置服务器2中存储有业务实例路由信息与各个业务实例的业务实例名称之间的第一对应关系信息，每个业务实例名称与至少一个业务实例路由信息相对应。如实施例一中所说明的，只要获知了业务实例的名称就可以对业务实例进行调用，因此，每个业务实例都会在配置服务器中进行注册，预先配置好业务实例路由信息与各个业务实例的业务实例名称之间的第一对应关系信息。需要说明的是，图中仅示出了n个业务实例路由信息与n个业务实例的名称之间的一一对应关系，实际上在配置服务器所存储的第一对应关系中，n个业务实例路由信息可以对应于与小于n个的业务实例的名称。

通过设置配置服务器2，路由模块111在接收业务请求后，会提取业务请求的url中所包含的业务实例路由信息，然后访问配置服务器2，根据业务实例路由信息和第一对应关系信息，获取对应的业务实例名称，并通过业务实例名称，调用业务层中的业务实例执行对应的业务处理。

进一步地，如实施例一中所说明的，在调用业务实例执行业务处理所需要业务参数可以包含在url中或者业务请求的数据包中，而对于一些系统默认参数可以存储在配置服务器中，通过业务实例路由信息来进行获取。具体地，如图3所示，其为本发明实施例二的业务处理系统的结构示意图之二，配置服务器中预先存储有作为系统默认参数的第二业 务参数，并存储有第二业务参数与业务实例路由信息之间的第二对应关系信息。需要说明的是，图中仅示出了n个业务实例路由信息与n个第二业务参数之间的一一对应关系，实际上，也可以是n个业务实例路由信息对应小于n个第二业务参数。

基于上述配置服务器的设置，在业务请求需要调用系统默认的第二业务参数的情况下，路由模块可以访问配置服务器，根据业务实例路由信息和第二对应关系信息，获取第二业务参数，并发送给业务实例。此外，如上面实施例一中所说明的，路由模块还会根据情形，从url中和/或业务请求的数据包中提取第一业务参数，并发送给业务实例。

本实施例中的业务处理系统采用了分层架构，将业务实例统一放在业务层中，而用于查找和调用业务实例的功能放在了路由层中，并且在url中设置了业务实例路由信息，同时在业务处理系统的内部建立了业务实例路由信与业务实例的对应关系，从而能够通过url定位到具体的业务实例，便于业务的管理和部署。尤其在进行业务内容更新时，仅涉及与该业务内容对应的业务实例的更新操作，而不会影响到其他的业务实例，也不会影响到整个业务处理系统的运行。

进一步地，通过设立独立的配置服务器来存储业务实例路由信息与业务实例名称之间的第一对应关系信息，使得路由模块能够直接获取到业务实例名称，从而完成调用。此外，在配置服务器中还存储了第二业务参数与业务实例路由信息之间的第二对应关系，使得路由模块在获取业务实例名称的同时还能获取到与本次业务请求对应的系统默认参数，从而可以在业务实例的调用过程中直接传递给业务实例。

实施例三

本实施例在实施例二的基础上增加了服务层的结构，如图4所示，其为本发明实施例三的业务处理系统的结构示意图之一，本实施例的业务处理服务器还包括服务层10。相应地，业务实例路由信息包括业务类别字段和业务路由字段，业务类别字段标识业务类别，路由层设置有多个路由模块，每个路由模块可以分别对应一个业务类别对应。其中，

举例来说，可以采用如下url结构：

http：{host}/{app}/{path}？auth[token]

其中，“http”为网路协议部分，“host”为服务器的ip地址和主机名，“auth[token]”为url的参数部分，而业务实例路由信息由“{app}/{path}”这里两部分构成，其中{app}代表业务类别字段，{path}代表该业务类别下面的具体业务实例的路由字段，即通过{app}字段将所有全部路由实例进行了分类，然后在每个类别下面利用{path}字段建立具体业务实例的路由。

例如：http：//www.test.com/test/pay？auth[token]＝xxxx&。这里的“test”就是业务类别，而“pay”则标识着在“test”大的业务类别下的和支付相关的业务实例的路由信息。

基于上述的业务实例路由信息结构，服务层就可以根据业务类别字段进行业务分发。具体地，如图4所示，服务层10包括分发模块101，用于接收业务请求，并根据业务请求的url中所包含的业务类别字段将该业务请求分发给对应的路由模块111。相应地，对应的路由模块111，接收到业务请求后，可以再按照实施例二中的方式，访问配置服务器2，根据业务实例路由信息，即根据“{app}/{path}”来查找对应业务实例的名称，并进行后续调用处理。从图在路由层示例性的示出了两个路由模块，在进行业务分发后，两个路由模块分别对应了业务实例1～m和业务实例m+1～n。

另外，服务层还可以包括权限认证模块，用于在进行路由分发之前，对业务请求进行权限认证，如果业务请求不具备业务调用权限，则直接屏蔽该业务请求或者向该业务请求的发送方返回拒绝应答。此外，服务层还可以包括协议解析模块，用于对业务请求进行协议解析。服务层作为业务处理系统的最上层，服务层需要对多种网路协议进行支持，从而能够接收并向下层转发相应的业务请求，例如，服务层可以至少对http、https等常规的网路访问协议提供支持。

本实施例通过三层的分层结构来实现业务请求的调用处理，相应地，在业务实例路由信息方面也进行了对应设计，将业务实例路由信息分为能够标识业务大类的业务类别字段和该大类下面的具体业务实例路由的 业务路由字段两部分。通过上述的架构设计和url字段的设计，首先在服务层上将业务处理系统接收到的大量业务请求按照业务大类进行分流，分流后的业务请求再交给路由层曾的路由模块，进行进一步的路由操作，从而定位到具体的业务实例并进行调用，而实际的业务处理则完全由业务层中运行的业务实例来完成。通过上述侧分层处理机制，能够让业务请求快速准确地进行调用，并且便于业务实例的分类管理。

进一步地，为了便于在业务实例更新的过程中，进行平滑的业务实例更新，如图5所示，其为本发明实施例三的业务处理系统的结构示意图之二，在业务层12中可以将业务实例的运行空间划分为第一实例运行空间和第二实例运行空间，在第一实例运行空间中的业务实例能够接受路由模块的调用，在第二实例运行空间中的业务实例不接受路由模块的调用。

相应地，配置服务器2还可以包括监听模块21，业务处理服务器还可以包括业务实例更新模块15。监听模块21，用于监听业务内容的更新，并通知业务实例更新模块15；业务实例更新模块15，用于根据新的业务内容生成新的业务实例，用该新的业务实例替换对应的运行在第一运行空间中的旧的业务实例，并将该旧的业务实例放入第二实例运行空间中，这些旧的业务实例可以在第二实例运行空间中继续进行更新前接收到的业务请求的业务处理，待完成业务处理后，再由系统进行注销。

通过在业务层中设置两个实例运行空间，在进行业务实例的更新时，能够在不影响之前的业务处理的前提下，完成业务实例的更新替换。

实施例四

如图6所示，其为本发明实施例四的业务处理系统的结构示意图之一，本实施例在实施例三的基础上，增加了存储层13，业务处理所需要的业务数据存储在存储层13中，业务实例121在进行业务处理的过程中，从存储层13中调取所需的业务数据。

通过设计存储层和业务层的结构，将业务处理逻辑封装在业务层执行，而将业务处理中涉及的业务数据放在存储层，从而将业务逻辑和业 务数据进行了分离，这样能够更加方便地对业务逻辑或者业务数据进行变更，而不会对整个业务处理系统造成过多的影响。在实际应用中，业务处理系统中，更新较多的是业务处理逻辑，基于上述架构，如果业务内容的更新仅仅涉及业务处理逻辑的更新，那么只要更新业务层中的业务实例即可，而不会影响存储层中的业务数据。

另外，为了更好的解决底层数据存储格式和业务层的数据调用的问题，如图7所示，其为为本发明实施例四的业务处理系统的结构示意图之二，本实施例的业务处理系统还可以包括设置在业务层12与存储层13之间的数据接口层14，存储层13的业务数据具有多种数据存储格式，数据接口层用于在业务层12与存储层13之间进行数据格式的转换，并向业务层的业务实例121，提供通用的数据访问接口。

例如，如图7所示，在存储层13中的数据可以采用oracle数据库系统、sybase数据库系统或者mssqlserver等常见的数据系统。数据接口层用于在业务层与存储层之间进行数据格式的转换，并向业务层的业务实例，提供通用的数据访问接口。

通过设置数据接口层，可以彻底地将业务逻辑和业务数据进行分离，在存储层中，可以采用不同的数据存储格式，从而能够兼容各种不同的平台数据等，而数据格式的转换工作，可以交由数据接口层来完成。此外，从业务层的角度来看，业务层中运行的业务实例直接面对数据接口层即可，可以采用统一的数据接口对存储层的数据进行调用，从屏蔽掉了底层数据差异性。

实施例五

本实施例涉及基于上述实施例二至四的业务处理系统的业务处理方法，该业务处理方法在业务处理系统上执行，业务处理系统至少包括业务处理服务器，业务处理服务器包括路由层和业务层，路由层中运行有路由模块，业务层中运行有多个执行业务处理的业务实例，

业务处理方法包括：路由模块接收业务请求，提取业务请求的url中所包含的业务实例路由信息，并根据业务实例路由信息，调用业务实 例路由信息对应的业务实例，对业务请求进行处理，其中，每个业务实例与至少一个业务实例路由信息相对应。

通过这样的调用机制，在进行具体业务调用时，通过业务请求中的url(统一资源定位符)信息就能够直接定位到一个具体的业务实例，这样的调用机制使得业务请求到业务实例的调用关系非常清晰，每项业务相对独立，便于业务的管理和部署。

进一步地，业务处理系统还可以包括配置服务器，在配置服务器中存储有业务实例路由信息与各个业务实例的业务实例名称之间的第一对应关系信息，每个业务实例名称与至少一个业务实例路由信息相对应。

在引入配置服务器后，上述的根据业务实例路由信息，调用业务实例路由信息对应的业务实例的操作可以具体为：路由模块访问配置服务器，根据业务实例路由信息和第一对应关系信息，获取对应的业务实例名称；路由模块通过业务实例名称，调用业务实例。

更进一步地，配置服务器中预先存储有作为系统默认参数的第二业务参数，并存储有第二业务参数与业务实例路由信息之间的第二对应关系信息。相应地，该业务处理方法还可以进一步包括：

路由模块访问配置服务器，根据业务实例路由信息和第二对应关系信息，获取第二业务参数，并发送给业务实例；和/或，从url中和/或业务请求的数据包中提取第一业务参数，并发送给业务实例。

此外，业务处理服务器还可以包括服务层，业务实例路由信息包括业务类别字段和业务路由字段，业务类别字段标识业务类别，路由层设置有多个路由模块，每个业务模块分别对应一个业务类别对应。相应地，业务处理方法还可以包括：服务层接收业务请求，并根据业务请求的url中所包含的业务类别字段将该业务请求分发给对应的路由模块。

本实施例中，通过三层的分层结构来实现业务请求的调用处理，相应地，在业务实例路由信息方面也进行了对应设计，首先在服务层上将业务处理系统接收到的大量业务请求按照业务大类进行分流，分流后的业务请求再交给路由层曾的路由模块，进行进一步的路由操作，从而定位到具体的业务实例并进行调用，而实际的业务处理则完全由业务层中 运行的业务实例来完成。通过上述侧分层处理机制，能够让业务请求快速准确地进行调用，并且便于业务实例的分类管理。

实施例六

本实施例涉及基于上述各实施例的业务处理系统的业务更新方法，业务处理系统至少包括业务处理服务器和配置服务器，

业务处理服务器包括路由层和业务层，路由层中运行有路由模块，业务层中运行有多个执行业务处理的业务实例，

在配置服务器中存储有业务实例路由信息与各个业务实例的业务实例名称之间的第一对应关系信息，每个业务实例名称与至少一个业务实例路由信息相对应，

业务层中可以进一步包括第一实例运行空间和第二实例运行空间，在第一实例运行空间中的业务实例能够接受路由模块的调用，在第二实例运行空间中的业务实例不接受路由模块的调用，

如图8所示，其为本发明实施例六的业务更新方法的流程示意图，本实施例的业务更新方法包括：

步骤201：在配置服务器中，监听业务内容的更新，并通知业务处理服务器，这里所说是业务内容可以是执行具体业务内容的程序代码等。

步骤202：业务处理服务器根据新的业务内容生成新的业务实例，用该新的业务实例替换对应的旧的业务实例。具体地，在该步骤中，新旧业务实例的替换操作可以具体为：用新的业务实例替换对应的运行在第一运行空间中的旧的业务实例，并将该旧的业务实例放入第二实例运行空间中。

本实施例的业务更新方法，仅涉及与该业务内容对应的业务实例的更新操作，而不会影响到其他的业务实例，也不会影响到整个业务处理系统的运行。并且，通过旧的业务实例置于不接受路由模块调用的第二实例运行空间继续进行业务处理，而将新的业务实例置于能够接受路由模块的调用的第一实例运行空间中，使得新旧业务实例能够并存，实现平滑地进行业务实例更新。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。