CN109388401A - 一种服务分发方法及系统 - Google Patents

Abstract

本说明书的一个或者多个实施例公开了一种服务分发方法及系统，通过对上下文隔离框架中的各结构层中各自包含的一个或者多个的功能模块分别创建Spring上下文，使得每个功能模块都包含有各自的Spring上下文；然后将各功能模块进行封装以供调用。若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

Description

一种服务分发方法及系统

技术领域

本申请涉及支付领域，尤其涉及一种服务分发方法及系统。

背景技术

目前，随着支付领域的不断完善，出现了越来越多处理支付业务的方式，而这些处理支付业务的方式一般都是基于代码来实现的。例如业务分发的方式Java为基础进行开发。

具体来说，java应用程序的类与类之间要实现相互的功能协作是非常困难的，某个类A要实现它的功能如果需要依赖另一个类B的协作的话，就需要在A类中主动创建出B类的对象，才能使用B类的方法完成功能。例如开发出Bean Class类之后，会将这些BeanClass类打包成一个一个Jar包进行分发。而使用者在使用企业分发的服务时，必须增加相关Bean配置才能够调用Bean Class类，操作繁琐。

故而需要一种新的方案来解决业务处理操作繁琐的问题。

发明内容

本说明书的一个或者多个实施例提供了一种服务分发方法及系统，以解决或者部分解决业务处理操作繁琐的问题。

为解决上述技术问题，本说明书的一个或者多个实施例提供了一种服务分发方法，所述方法包括：

对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文；其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离；

将每个所述功能模块进行封装以供调用；

若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

本说明书的一个或者多个实施例公开了一种服务分发系统，所述系统包括：

创建模块，用于对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文；其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离；

封装模块，用于将各功能模块进行封装以供调用；

调用模块，用于若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

本说明书的一个或者多个实施例公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。

本说明书的一个或者多个实施例公开了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的步骤。

通过本说明书的一个或者多个实施例的一个或者多个技术方案，本说明书的一个或者多个实施例具有以下有益效果或者优点：

本实施例公开了一种服务分发方法及系统，通过对上下文隔离框架中的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文。由于每个功能模块的创建了Spring上下文，并且各功能模块的Spring上下文中包含用于表征对应功能模块能够提供的第一服务信息，以及用于表征对应功能模块能够提供需要引用的第二服务信息，使得各功能模块的调用关系非常清楚，故而各功能模块调用时不需要在设置文件中增加相关Bean配置，直接利用各功能模块的第二服务信息去调用其他功能模块提供的第一服务信息即可，调用时简单快捷。另外各功能模块的Spring上下文互相隔离，故而让模块和模块之间的Bean的引用无法直接进行，达到了模块在运行时隔离的能力，进而能够避免模块在相互调用时调用了错误的Bean而导致的业务繁琐的问题，然后将各功能模块进行封装以供调用，操作简单方便。

上述说明仅是本说明书的一个或者多个实施例技术方案的概述，为了能够更清楚了解本说明书的一个或者多个实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本说明书的一个或者多个实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本说明书的一个或者多个实施例的具体实施方式。

附图说明

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

图1示出了根据本说明书的一个或者多个实施例的上下文隔离框架的示意图；

图2示出了根据本说明书的一个或者多个实施例的一种服务分发方法的实施过程图；

图3A示出了根据本说明书的一个或者多个实施例的模块之间的调用示意图；

图3B示出了根据本说明书的一个或者多个实施例的模块化的示意图；

图3C示出了根据本说明书的一个或者多个实施例的依赖树的示意图；

图4示出了根据本说明书的一个或者多个实施例的一种服务分发系统的示意图；

图5示出了根据本说明书的一个或者多个实施例的计算机设备的示意图。

具体实施方式

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

本说明书的一个或者多个实施例提供了一种服务分发方法及系统，用以解决现有技术的业务处理操作繁琐的问题的技术问题。

为了便于说明和解释本说明书，请参看图1，本实施例先介绍上下文隔离框架。

上下文隔离框架至少包括sofa框架，sofa(Scalable Open FinancialArchitecture，Scalable Open Financial Architecture)框架是上下文隔离的实践框架，也是金融级分布式中间件，专注为金融用户提供安全、稳定、可靠、高效、敏捷的基础架构能力，帮助金融用户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，加快金融互联网+推进的速度。

上下文隔离框架包括：biz层即业务层，core层俗称核心层，web层即展现层，common层也称数据层，test层测试层。业务层的biz-service发布服务，打成jar包的方式供其他facade外观调用，引用服务在数据层。

在具有上述框架的基础上，本实施例公开了一种服务分发方法，参看图2，包括如下步骤：

步骤21，对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文。

其中，上下文隔离框架中的各结构层中的功能都可以将其模块化，得到功能模块。每个功能模块又都创建了各自的Spring上下文。其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离。

本说明书中的一个或者多个实施例的功能模块是利用通过在各功能模块创建各自的Spring上下文，来实现基于Spring上下文隔离的模块化的方式。这样做的目的是为了简化模块和模块之间的调用关系，模块与模块之间通过JVM Service进行通信，进而避免模块之间由于调用产生的紧耦合。

具体来说，在传统的模块化方式中，一般是基于代码组织上的模块化，也就是在开发期，将不同功能的代码放在不同Java工程下，在编译期被打进不同jar包，在运行期，所有Java类都在一个classpath下且使用同一个Spring上下文，没做任何隔离。故而，在模块间相互调用的过程中，假设有Pay Service(支付服务)模块和Cashier Service(收银台服务)模块。Cashier Service模块需要调用Pay Service模块提供的功能去做支付。由于这种模块化的方案里面，Spring的上下文依然是同一个，类也没有任何做隔离，这就意味着，PayService模块里面的任何的一个Bean，都可以被Cashier Service模块所依赖调用。极端的情况下，可能会导致Cashier Service模块错误地调用了Pay Service模块中的一个内部的Bean，例如，参看图3A，Cashier Service模块原本应当调用Pay Service模块中的内部的Bean“Pay Outer Service”，但是由于Pay Service模块里面的任何的一个Bean，都可以被Cashier Service模块所依赖调用，故而，现在Cashier Service模块错误的调用了PayService模块中的一个内部的Bean“Pay Innter Service”，故而造成了两个模块之间的紧耦合。

这种传统的模块化的问题在于模块化地不彻底。虽然在研发的时候，通过划分模块，把特定职责的类放到特定的模块里面去，达到了类的「物理位置」的内聚。但是在运行时，由于没有做任何隔离的手段，作为一个模块的开发者，并没有办法清楚地知道对方模块提供的对外的接口到底是什么，哪些Bean开发者是可以直接注入来用的，哪些Bean是对方模块的内部的Bean，开发者是不能用的。长此以往，模块和模块之间的耦合就会越来越严重，原来的模块的划分形同虚设。当系统承载的业务越来越大，最后需要做服务化拆分的时候，就需要花费非常大的精力去梳理模块和模块之间的关系，使得业务处理非常的繁琐。

故而，本实施例对于每个功能模块都创建了各自的Spring上下文，并且各功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离，也就是说，本实施例使用了Spring上下文来做不同功能模块的隔离。如此，在开发期和编译期，代码和配置也会分在不同Java工程中，但在运行期，不同的Spring Bean相互不可见，IOC(一个Spring容器)只在同一个上下文内部发生，但是所有的Java类还是在一个ClassLoader下。

通过Spring上下文的隔离，让模块和模块之间的Bean的引用无法直接进行，达到模块在运行时隔离的能力。

作为一种可能的实施例，各功能模块在创建了Spring上下文之后，一个功能模块就可以看作是一个Spring上下文。各功能模块实际上包含了Java代码、配置文件、模块标识。故而在各功能模块的配置文件中声明各功能模块提供的第一服务信息，第一服务信息表征的是功能模块自身提供的服务。在各功能模块的配置文件中声明各功能模块需要引用的第二服务信息。第二服务信息表征的是功能模块需要使用的服务。

因此，每个功能模块实际上都包括两个服务信息：第一服务信息和第二服务信息。那么，在调用的过程中，各功能模块基于各自的第二服务信息，从所述Spring容器中调用其他功能模块提供的第一服务信息，进而实现和其他功能模块的通信功能。而调用之前，可将各功能模块进行封装为符合调用的对象。例如将各功能模块封装为压缩包。

例如，当一个模块需要调用另一个模块里面的一个Bean的时候，提供服务的模块可以在其配置文件中声明一个SOFA Service：使用服务的模块可以在其配置文件声明一个SOFA Reference。通过这种方式，一个模块就可以清晰地知道自身提供了哪些服务，引用了哪些服务，和其他的模块之间的关系也就非常清楚。

由于各模块通过Spring上下文隔离，故而为了支持本实施例中的各功能模块之间的通信，本实施例至少提供了JVM Service/Reference等方式进行模块间的通信，用于解决不同级别的模块间调用问题。

步骤22，将各功能模块进行封装以供调用。

步骤23，若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

作为一种可选的实施例，为了便于管理各功能模块的Spring上下文，本实施例将各功能模块置入Spring容器中进行管理，以对各功能模块的Spring上下文进行统一管理。

作为一种可选的实施例，各功能模块的Spring上下文中发布的功能和引用的功能可以更新。具体来说，本实施例可更新各功能模块的Spring上下文中发布的功能；另外，也可以更新各功能模块的Spring上下文中引入的功能。更新的方式有多种，例如，将各功能模块的Spring上下文中原来发布的功能更新为新发布的功能。将将各功能模块的Spring上下文中原来引用的功能更新为新引用的功能。

综上，本实施例公开了一种服务分发方法及系统，通过对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文。由于各功能模块的创建了Spring上下文，故而各功能模块的调用时不需要在设置文件中增加相关Bean配置，直接调用即可，并且各功能模块的调用关系非常清楚，调用时简单快捷。另外各功能模块的Spring上下文互相隔离，故而让模块和模块之间的Bean的引用无法直接进行，达到了模块在运行时隔离的能力，进而能够避免模块在相互调用时调用了错误的Bean而导致的业务繁琐的问题，然后将各功能模块进行封装以供调用，操作简单方便。

下面请参看图3B，是本说明书的一个或者多个实施例中的模块化的具体示意图。

每个SOFABoot模块使用独立的Spring上下文，每个模块自包含，模块与模块之间通过JVM Service进行通信，避免模块间的紧耦合：

从图3B中可以看到，SOFABoot模块化一共包含三个基本概念，分别是SOFABoot模块、JVM Service以及Root Application Context:

SOFABoot模块:SOFABoot模块是一个包括Java代码、Spring配置文件、SOFABoot模块标识等信息的普通Jar包，每个SOFABoot模块都是一个独立的Spring上下文。作为一种可选的实施例，SOFABoot模块刷新需要等待Root Application Context刷新完毕后进行，因为SOFABoot模块可能依赖Root Application Context中的bean定义。

JVM Service:上下文隔离后，模块与模块间的Bean无法直接注入，JVM Service用于实现模块间通信，用于发布及引用模块服务。对于JVM Service与组件管理来说，上下文隔离后，模块与模块间的Bean无法直接注入，JVM Service用于实现模块间通信，用于发布及引用模块服务。为了实现跨模块的服务发现，我们在SOFABoot内部定义了一个组件管理接口ComponentManager。ComponentInfo是一个接口，用于表示组件信息，目前包含两个具体实现，分别是ServiceComponent和ReferenceComponent，分别表示服务与引用。ComponentName是ComponentInfo的唯一标识，用于区分不同的ComponentInfo实现。在ComponentManager的实现类中包含一个以ComponentName为key，ComponentInfo为value的Map，用于存储所有注册过的ComponentInfo。在发布JVM服务时，我们会调用register方法，将JVM服务注册到ComponentManager中，在发生服务调用时，我们会调用getComponentInfo方法，在ComponentManager中查找其他模块发布的服务并进行调用。

Root Application Context:SOFABoot应用调用SpringApplication.run(args)方法后产生的Spring上下文，是所有SOFABoot模块的Parent基础。

SOFABoot扩展自Spring Boot，SOFABoot应用是通过SpringApplication.run(args)方法启动的，在调用此方法后应用将产生一个Spring上下文，我们把它叫做RootApplication Context。Root Application Context在SOFABoot模块化中是一个很特别的存在，它是每个SOFABoot模块上下文的parent，这样设计的目的是为了保证开箱即用：SOFABoot应用在每增加一个Starter定义时，Starter中可能定义了一些Bean，这些Bean默认只会在Root Application Context中生效，将Root Application Context定义为每个SOFABoot模块上下文的Parent后，每个SOFABoot模块就能发现这些Starter新增的Bean定义，保证开箱即用。

除了会定义一些Bean，Starter还可能定义一些BeanPostProcessor和BeanFactoryPostProcessor，对于这两类特殊的Bean定义，子上下文光能够发现Bean定义还不够，必须将这两类Bean的定义复制到当前上下文才能生效，所以我们在刷新SOFABoot模块对应的上下文时，会将Root Application Context中定义的所有BeanPostProcessor和BeanFactoryPostProcessor复制到SOFABoot模块的上下文中，这样一些Starter定义的Processor就可以直接在SOFABoot模块上下文中使用了，例如runtime-sofa-boot-starter中会定义ServiceAnnotationBeanPostProcessor，该类主要用于实现注解发布服务，自动拷贝后，只要增加了runtime-sofa-boot-starter依赖，就支持在SOFABoot模块中基于注解发布服务。

在刷新SOFABoot模块时，可能出现A模块中发布了一个JVM Service，在B模块的某一个Bean的init方法里面需要调用这个JVM Service，假设B模块在A模块之前启动了，那么B模块的Bean就会因为A模块的JVM Service没有发布而init失败，导致Spring上下文启动失败。此时，我们可以在sofa-module.properties中指定Require-Module来强制A模块在B模块之前启动。

在SOFABoot应用中，每一个SOFABoot模块都是一个独立的Spring上下文，并且这些Spring上下文之间是相互隔离的。虽然这样的模块化方式可以带来诸多好处，但是，在某些场景下还是会有一些不便，这个时候，你可以通过Spring-Parent来打通两个SOFABoot模块的Spring上下文。例如，可以将DAL模块作为Service模块的Parent，这样Service模块就可以直接使用DAL模块定义的DataSource定义，无需将一个DataSource发布成一个JVMService。

SOFABoot会根据Require-Module和Spring-Parent计算模块依赖树，例如参看图3C，以下依赖树表示模块B和模块C依赖模块A，模块E依赖模块D，模块F依赖模块E。

该依赖树会保证模块A必定在模块B和模块C之前启动，模块D在模块E之前启动，模块E在模块F之前启动，但是依赖树没有定义模块B与模块C，模块B、C与模块D、E、F之间的启动顺序，这几个模块之间可以串行启动，也可以并行启动。SOFABoot默认会对模块进行并行启动，这样可以大大加快应用的启动速度。

通过上述描述可知，每个SOFABoot模块使用独立的Spring上下文，模块与模块之间通过JVM Service进行通信，在发布服务时，可以利用服务维度进行服务发布，类似RPC的使用方法，提供一个Facade包，包含接口定义，然后由模块实现接口，并发布服务。

基于相同的发明构思，本说明书的一个或者多个实施例公开了一种服务分发系统，参看图4，该系统包括：

创建模块41，用于对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文。

其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离。

封装模块42，用于将每个所述功能模块进行封装以供调用。

调用模块43，用于若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

作为一种可选的实施例，所述上下文隔离框架中的各结构层包括：web展现层、biz业务层、core核心层。

作为一种可选的实施例，所述系统还包括：

管理模块，用于对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文之后，将各功能模块置入Spring容器中进行管理，以对各功能模块的Spring上下文进行统一管理。

作为一种可选的实施例，所述各功能模块包括有：Java代码、配置文件、模块标识。

作为一种可选的实施例，所述系统还包括：

第一声明模块，用于在各功能模块的配置文件中声明各功能模块提供的第一服务信息：

第二声明模块，用于在各功能模块的配置文件中声明各功能模块需要引用的第二服务信息。

作为一种可选的实施例，所述系统还包括：

调用模块43，用于各功能模块基于各自的第二服务信息，从所述Spring容器中调用其他功能模块提供的第一服务信息，进而实现和其他功能模块的通信功能。

作为一种可选的实施例，所述系统还包括：

第一更新模块，用于更新各功能模块的Spring上下文中发布的功能；

第二更新模块，用于更新各功能模块的Spring上下文中引入的功能。

基于与前述实施例中同样的发明构思，本说明书的一个或者多个实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文任一所述方法的步骤。

基于与前述实施例中同样的发明构思，本说明书的实施例还提供一种计算机设备，如图5所示，包括存储器504、处理器502及存储在存储器504上并可在处理器502上运行的计算机程序，所述处理器502执行所述程序时实现前文任一所述方法的步骤。

其中，在图5中，总线架构(用总线500来代表)，总线500可以包括任意数量的互联的总线和桥，总线500将包括由处理器502代表的一个或多个处理器和存储器504代表的存储器的各种电路链接在一起。总线500还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口505在总线500和接收器501和发送器503之间提供接口。接收器501和发送器503可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器502负责管理总线500和通常的处理，而存储器504可以被用于存储处理器502在执行操作时所使用的数据。

通过本说明书的一个或者多个实施例的一个或者多个实施例，本说明书的一个或者多个实施例具有以下有益效果或者优点：

本实施例公开了一种服务分发方法及系统，通过对上下文隔离框架中的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文。由于每个功能模块的创建了Spring上下文，并且各功能模块的Spring上下文中包含用于表征对应功能模块能够提供的第一服务信息，以及用于表征对应功能模块能够提供需要引用的第二服务信息，使得各功能模块的调用关系非常清楚，故而各功能模块调用时不需要在设置文件中增加相关Bean配置，直接利用各功能模块的第二服务信息去调用其他功能模块提供的第一服务信息即可，调用时简单快捷。另外各功能模块的Spring上下文互相隔离，故而让模块和模块之间的Bean的引用无法直接进行，达到了模块在运行时隔离的能力，进而能够避免模块在相互调用时调用了错误的Bean而导致的业务繁琐的问题，然后将各功能模块进行封装以供调用，操作简单方便。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本说明书的一个或者多个实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本说明书的一个或者多个实施例的内容，并且上面对特定语言所做的描述是为了披露本说明书的一个或者多个实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本说明书的一个或者多个实施例的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本说明书的一个或者多个实施例的示例性实施例的描述中，本说明书的一个或者多个实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本说明书的一个或者多个实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本说明书的一个或者多个实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本说明书的一个或者多个实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本说明书的一个或者多个实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本说明书的一个或者多个实施例的网关、代理服务器、系统中的一些或者全部部件的一些或者全部功能。本说明书的一个或者多个实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本说明书的一个或者多个实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本说明书的一个或者多个实施例进行说明而不是对本说明书的一个或者多个实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本说明书的一个或者多个实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (14)

1.一种服务分发方法，所述方法包括：

对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文；其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离；

将每个所述功能模块进行封装以供调用；

若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

2.如权利要求1所述的一种服务分发方法，所述上下文隔离框架包括：web展现层、biz业务层、core核心层。

3.如权利要求1所述的一种服务分发方法，所述对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文之后，所述方法还包括：

将各功能模块置入Spring容器中进行管理，以对各功能模块的Spring上下文进行统一管理。

4.如权利要求3所述的一种服务分发方法，所述各功能模块包括有：Java代码、配置文件、模块标识。

5.如权利要求4所述的一种服务分发方法，所述对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文之后，所述方法还包括：

在各功能模块的配置文件中声明各功能模块提供的第一服务信息：

在各功能模块的配置文件中声明各功能模块需要引用的第二服务信息。

6.如权利要求1所述的一种服务分发方法，所述对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文之后，所述方法还包括：

更新各功能模块的Spring上下文中发布的功能；

更新各功能模块的Spring上下文中引入的功能。

7.一种服务分发系统，所述系统包括：

创建模块，用于对上下文隔离框架的各结构层中各自包含的一个或者多个功能模块分别创建开放源代码的设计层面框架Spring上下文，使得每个功能模块都包含有各自的Spring上下文；其中，每个所述功能模块的Spring上下文中包含用于表征对应功能模块提供的第一服务信息，以及用于表征对应功能模块需要引用的第二服务信息，每个所述功能模块的Spring上下文和其他功能模块的Spring上下文互相隔离；

封装模块，用于将各功能模块进行封装以供调用；

调用模块，用于若接收到调用指令，则所述调用指令涉及到的功能模块基于所述调用指令执行各自提供的第一服务信息，以提供所述调用指令需求的服务；和/或所述调用指令涉及到的功能模块基于所述调用指令和各自的第二服务信息，调用其他功能模块提供的第一服务信息，以提供所述调用指令需求的服务。

8.如权利要求7所述的一种服务分发系统，所述上下文隔离框架中的各结构层包括：web展现层、biz业务层、core核心层。

9.如权利要求7所述的一种服务分发系统，所述系统还包括：

管理模块，用于对上下文隔离框架中的各结构层中的功能模块分别创建开放源代码的设计层面框架Spring上下文之后，将各功能模块置入Spring容器中进行管理，以对各功能模块的Spring上下文进行统一管理。

10.如权利要求9所述的一种服务分发系统，所述各功能模块包括有：Java代码、配置文件、模块标识。

11.如权利要求10所述的一种服务分发系统，所述系统还包括：

第一声明模块，用于在各功能模块的配置文件中声明各功能模块提供的第一服务信息：

第二声明模块，用于在各功能模块的配置文件中声明各功能模块需要引用的第二服务信息。

12.如权利要求7所述的一种服务分发系统，所述系统还包括：

第一更新模块，用于更新各功能模块的Spring上下文中发布的功能；

第二更新模块，用于更新各功能模块的Spring上下文中引入的功能。

13.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-6任一项所述方法的步骤。

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-6任一项所述方法的步骤。