WO2009129732A1 - 一种分布式调用消息的方法和装置 - Google Patents

Description

一种分布式调用消息的方法和装置

本申请要求于 2008 年 4 月 22 日提交中国专利局、 申请号为 200810094611.1、 发明名称为 "一种分布式调用消息的方法和装置" 的中国专 利申请的优先权， 其全部内容通过引用结合在本申请中。

技术领域

本发明涉及通信技术领域 , 尤其涉及一种分布式调用消息的方法和装置。 背景技术

软总线技术提供跨平台、 3fi吾言的组件通信能力 ,能够解决系统的分布性、 可扩展性问题，是实现分布式消息处理平台的基础。 目前业界比较有影响力的 软总线规范有 3种， 分别是： 公共对象请求代理体系结构 (CORBA, Common Object Request Broker Architecture)、 分布式组件对象模型 (DCOM, Distributed Component Object Model)和 Java2平台企业版 (J2EE, Java 2 Platform, Enterprise Edition)。 其中， CORBA 是由对象管理组织（OMG , Object Management Government)制定的一种标准的面向对象应用程序的体系规范。 DCOM是由微 软公司提出的， 支持在局域网、广域网甚至互联网上不同计算机的对象之间的 通信。 J2EE是 SUN公司提出的分布式对象总线标准。 以下以 CORBA为例简 单介绍分布式平台下调用消息的方式。

当一个客户要使用某个对象实现所提供的服务时 , 其一般过程如下： 1)客户通过某种方式找到特定对象的对象引用；

2) 如果该对象实现有相应的接口定义语言（IDL， Interface Definition

Language)存根， 则客户可以通过该 IDL存根向对象实现发出请求， 否则， 在 接口库的协助下， 客户可以使用动态调用接口来向对象实现发送请求；

3) 当对象调用请求通过 IDL 存根或动态调用接口到达对象请求代理 (ORB, Object Request Broker)核心后 , ORB核心负责请求的传送， 将其传送给 相应的对象适配器；

4)对象适配器接到该请求后， 判断所请求的对象实现是否有 IDL骨架存 在， 如果有， 则对象适配器通过该 IDL骨架调用执行对象实现的操作； 否则， 对象适配器将通过动态骨架接口中的动态实现例程来调用对象实现中的操作；

5)对象实现的特定操作方法体（method )执行完成后， 结果将按照对象 请求传递和执行路径逆向返回给客户对象， 结果可以是输出参数、输入输出参 数， 返回值以及异常信息等。

一般来说， 分布式调用分为两种方式： 异步调用和同步调用。 对于异步调 用， 调用后不能立即获得结果， 并且不阻塞线程而是继续执行后续逻辑。 异步 调用适合于不立即关心调用结果或者连续进行一批不相关调用的情况，以提高 效率。 对于同步调用， 调用时后续逻辑被阻塞， 直到调用完成获得结果或调用 超时。

通常， 开发者更适应于同步调用， 它看起来和本地调用一样方便， 但是由 于分布式远程调用不可能像本地调用那样立即获得结果，而是会阻塞线程直到 得到结果或超时， 这势必影响调用性能。

如果想要提高系统的处理性能就需要使用异步调用方式， 在定义 IDL 时 需要定义两个单向的操作， 一个用于发起调用， 一个用于发送结果， 分别由调 用双方实现， 并被客户端和服务器端调用。

在对现有技术的研究和实践过程中，本发明发明人发现在现有技术中，对 于异步调用， 用户在调用后无法马上得到返回值， 在调用的时候只管调用， 对 于调用结果需要在另外一个地方去接收和处理，这种开发方式在一定程度上打 乱了程序逻辑， 增加了开发的难度和成本， 又降低了程序可读性和可维护性。 对于应用开发来说，使用同步调用的开发效率远比异步方式高，但传统的分布 式系统的同步调用要求将线程阻塞，对于大并发量的通信系统，有限的线程资 源和高代价的锁操作会在很大程度上影响处理性能。 综上，在现有技术的分布 式调用消息的方法中 , 无法兼顾系统处理性能和业务开发效率。

发明内容

本发明实施例要解决的技术问题是提供一种分布式调用消息的方法和装 置， 能够兼顾系统处理性能和业务开发效率。

为解决上述技术问题，本发明所提供的分布式调用消息的方法和装置是通 过以下技术方案实现的：

本发明实施例提供了一种分布式调用消息的方法， 该方法包括： 在方法体内部采用异步方式发送调用请求消息；

保存所述调用请求消息的调用栈信息及当前运行状态并退出所述方法体； 当接收到所述调用请求消息的应答消息时， 恢复保存的所述调用栈信息； 根据恢复的调用栈信息， 恢复到退出所述方法体前所处运行状态， 继续执 行后续逻辑。

本发明实施例提供了一种分布式处理装置，该装置包括： 消息调用单元和 信息处理单元， 其中：

所述消息调用单元包括： 消息发送单元、 消息接收单元、 信息存储单元、 栈信息维护单元， 其中：

消息发送单元， 在方法体内部采用异步方式发送调用请求消息； 消息接收单元， 接收所述调用请求消息的应答消息；

信息存储单元， 保存调用栈信息和所述方法体当前运行状态；

栈信息维护单元，当所述消息发送单元发送调用请求消息后将所述调用请 求消息的调用栈信息和当前运行状态保存到信息存储单元并退出所述方法体； 在消息接收单元接收到应答消息时， 将保存在信息存储单元的调用栈信息恢 复；

信息处理单元，根据栈信息维护单元恢复出的调用栈信息， 恢复到退出所 述方法体前所处运行状态， 继续执行后续逻辑。

从以上技术方案可以看出，本发明实施例在方法体内部采用异步调用发送 调用请求消息， 在等待应答期间， 线程不被堵塞， 可以处理别的业务， 因此可 以保证系统的处理性能； 同时， 当接收到所述调用请求消息的应答消息时， 由 于可以通过恢复保存的栈信息直接恢复到退出所述方法体前所处运行状态，并 继续执行后续逻辑，后续逻辑可以直接应用当前方法体的调用结果，对于开发 人员来说，异步调用被封装在方法体内部，看到的只是该方法体的处理和后续 逻辑的顺序执行， 就像同步调用一样， 因此， 可以降低业务开发的复杂度， 提 高业务开发效率。 总之，本发明实施例所述的技术方案可以同时兼顾系统的处 理性能和业务开发效率。

附图说明

图 1为本发明实施例中分布式处理装置实施例结构示意图；

图 2为本发明实施例中分布式调用消息的方法实施例流程图；

图 3为本发明实施例中异步调用的流程图； 图 4为本发明实施例中的状态图。

具体实施方式

本发明实施例提供了一种分布式调用消息的方法和装置，能够同时兼顾系 统的处理性能和业务开发效率。为使本领域技术人员更好地理解和实现本发明 实施例， 以下参照附图进行伴细说明：

参照图 1， 为本发明实施例中分布式处理装置实施例结构示意图， 该分布 式处理装置包括： 消息调用单元 11和信息处理单元 12, 其中：

消息调用单元 11包括： 消息发送单元 111、 消息接收单元 112、 信息存储 单元 113、 栈信息维护单元 114， 其中：

消息发送单元 111， 在方法体（ method ) 内部采用异步方式发送调用请求 消息；

消息接收单元 112， 接收所述调用请求消息的应答消息；

信息存储单元 113 , 保存调用栈信息和所述方法体当前运行状态； 栈信息维护单元 114， 当所述消息发送单元 111发送调用请求消息后将所 述调用请求消息的调用栈信息和当前运行状态保存到信息存储单元 113 并退 出所述方法体； 在消息接收单元 112接收到应答消息时， 将保存在信息存储单 元 113的调用栈信息恢复；

信息处理单元 12, 根据栈信息维护单元 114恢复出的调用栈信息， 恢复 到退出所述方法体前所处运行状态， 继续执行后续逻辑。

信息处理单元保存的调用栈信息和调用请求消息——对应 ,可以设置调用 请求消息标识与调用栈信息的对应关系，并且消息接收单元所返回的应答消息 中携带有与调用请求消息一致的标识，以使栈信息维护单元能够较快地查找到 保存的调用栈信息并恢复。

信息处理单元执行后续逻辑可以是后续正常逻辑、超时处理逻辑，也可能 是异常处理逻辑，分别对应消息接收单元所接收到的应答消息所携带的业务调 用结果。

可以理解的是， 所述分布式处理装置并不表示具体的设备名称，仅用于表 示可以用于分布式处理的装置。这种分布式处理装置应用范围非常广泛，可以 位于计算机、 网络中等有分布式处理装置的任何的分布式处理系统中。 对于这种分布式处理装置，可以通过消息调用单元对其他的远程服务进行 调用， 指定被调用对象和被调用方法体、设置调用参数等， 通过消息驱动状态 进行迁移， 并且在迁移前消息调用单元已经接收返回结果，信息处理单元可以 直接利用该返回结果， 所以， 从使用体验上来看， 异步调用被封装在方法体内 部， 开发人员看到的只是该方法体的处理和后续逻辑的顺序执行，和同步调用 完全相同 , 因此这种分布式处理装置的消息调用方式对开发人员来讲更友好， 可以降低业务开发的复杂度， 提高业务开发效率。 而在消息调用单元内部， 使 用异步方式进行消息调用， 在等待消息应答期间， 线程不会被堵塞， 可以继续 处理别的业务， 因此同时也可以保证系统的处理性能。 综上， 这种分布式处理 装置既能提高业务开发效率， 又能兼顾系统处理性能。

参照图 2, 为一个分布式调用消息的方法实施例流程图， 以下通过方法体 F1中的具体调用过程进行说明：

步骤 21、 在方法体 F1中采用异步调用方式发送 foo调用请求消息并执行 步骤 22;

其中， 方法体（method )为类的成员， 是与类关联的函数， 可以访问所在 类中的元素。

对于上述异步调用方式，参照图 3 ,为本发明实施例中异步调用的流程图， 在分布式系统中进行一来一回两次异步调用的具体过程如下：

步骤 211、 调用者向被调用者发起调用请求；

调用者发起调用后， 继续执行后续逻辑。

步骤 212、 被调用者接收到请求后进行处理；

步骤 213、 被调用者发起调用请求， 其中携带有处理调用者请求所得到的 结果。

步骤 214、 调用者接收被调用者的调用请求， 进行处理， 得到处理结果。 步骤 22、保存 foo调用请求消息的调用栈信息及当前运行状态并退出方法 体 F1 ;

在退出方法体 F1前保存所述调用栈信息及当前运行状态， 然后释放当前 线程， 此后线程可以继续处理其他调用， 以保证系统的处理性能。

步骤 23、 当接收到 foo调用请求消息的应答消息后，恢复保存的调用栈信 步骤 24、根据恢复的调用栈信息，恢复到退出 F1方法体前所处运行状态， 继续执行后续還辑。

调度线程根据恢复的调用栈信息再次调度进入方法体 F1后， 从退出方法 体 F1前的运行状态继续执行后续逻辑，直到方法体 F1逻辑结束并退出方法体 Fl。

由于后续逻辑可以直接使用步骤 23应答消息中所返回的调用结果，因此， 从开发人员来看， 与同步调用方式相同， 不需要打乱业务逻辑， 因此可以降低 业务开发的复杂度， 提高业务开发效率。

其中， 为了较快地查找到保存的调用栈信息， 迅速恢复到退出方法体 F1 前所处运行状态 ,可以设置调用栈信息与调用请求消息和调用应答消息的对应 关系，具体为：预先设定调用请求消息的标识与该请求消息对应的应答消息具 有相同的标识 (ID， Identification), 在保存调用栈信息的同时， 保存该调用栈信 息对应的调用请求消息的 ID, 当接收到所述调用请求消息的应答消息时， 查 找与应答消息具有相同 ID的调用栈信息， 进而恢复该调用栈信息及退出方法 体前所处运行状态， 执行后续逻辑。

为便于理解，这种方法可以采用状态图对应用服务的逻辑进行描述，可以 定义一系列状态， 由消息驱动状态进行迁移。 参照图 4, 为本发明实施例中的 状态图， 其中， 服务调用图元（ ServiceCall ) 41可以表示对其他远程服务的调 用， 如指定被调用对象和被调用方法体， 设置调用参数等， 并且在继续迁移前 已经接收返回值， 下一状态可以直接使用返回值， 所以从使用体验上看， 和同 步调用完全相同。 服务调用图元有三种出口： 调用正常出口、调用异常出口和 调用超时出口， 分别对应业务调用的三种结果： 下一状态 42、 异常处理 43和 超时处理 44。

如果在状态图中以同步调用的方式调用了远端方法体 foo， 其处理过程如 下： 在方法体 F1内部采用异步方式发送 foo请求后会中途退出方法体 Fl， 退 出前要把调用栈信息以及当前运行状态保存下来， 然后释放当前线程，此时线 程可以继续处理其他调用， 等到 foo请求的应答消息到达后， 调度线程再次调 度进入方法体 F1 , 此时要恢复上次退出时保存的调用栈信息和退出前所处当 前运行状态， 然后从退出前状态继续执行后续逻辑， 直到方法体 F1的逻辑结 束并退出方法体 Fl。

这里例举的仅仅是一种实现方案，可以理解的是， 为了达到调用栈信息保 存和恢复的目的， 并不仅限于此种方案。

从该技术方案可以看出，通过在方法体内部采用异步调用方式发送调用请 求消息， 在等待应答期间， 线程被释放， 可以处理别的调用请求， 因此可以保 证系统的处理性能； 同时， 当接收到所述调用请求消息的应答消息后， 可以根 据保存的调用栈信息直接恢复到退出所述方法体前所处运行状态，继续执行后 续逻辑， 因此， 后续逻辑可以直接应用当前方法体的调用结果， 对于开发人员 来说，看到的只是该方法体的处理和后续逻辑的顺序执行，执行逻辑并没有被 打乱， 因此， 可以降低业务开发的复杂度， 提高业务开发效率。 综上可知， 本 发明实施例可以兼顾系统处理性能与业务开发效率。

以下通过具体的应用场景 ,对本发明实施例中分布式调用消息的方法进行 详细描述：

具体场景为： 类 CDemoClass调用远端 IF2接口 , 在类 CDemoClass中的 方法体 StateProcess中实现分布式调用， 以下通过具体步骤进行伴细说明： 步骤 51、 类 CDemoClass启动后， 进入方法体 StateProcess的同时将自身 的一个 Context成员 m— StateContext传入作为 Context类链表的才艮节点；

步骤 52、 方法体 StateProcess在方法体内部创建 CStateProcessContext实 例并保存在 Context类链表上；

步骤 53、 方法体 StateProcess从初始状态开始迁移；

步骤 54、 当方法体 StateProcess迁移到方法体调用状态， 此时需要调用远 端的 IF2:： foo(int a)接口方法体；

1) 首先产生一个本地代理 IF2存根类型的对象， 然后调用 IF2存根的 foo 方法体；

2) 在 IF2 存才 的方法体内部又会创建一个 Context 类实例并保存在 Context类链表上， 然后进入 foo方法体的状态机， 该状态机有两个状态： 发 送请求状态和接收应答状态；

3) 首先进入发送请求状态， 按照异步调用方式构造一个调用请求消息并 通过软总线发送出去，发送后将当前运行状态设置为接收应答状态， 并且需要 等待应答消息， 然后退出方法体 StateProcess, 释放调度线程， 此时所有的调 用栈信息都保存在 Context类中。

可以将被调用对象、方法体和调用参数等调用信息构造成调用请求消息并 发送。

步骤 55、当收到软总线上返回的应答消息时，再次调进方法体 StateProcess 内部，并根据应答消息的 ID从 Context链中找到当前 Context对象并恢复上次 调用栈信息， 从退出点继续执行， 再次进入 IF2存根的方法体， 直接迁移到接 收请求状态， 取出应答消息中的返回值返回；

步骤 56、 继续执行后续处理逻辑， 所述后续处理逻辑可以直接使用方法 体 StateProcess调用的返回值。

可以看出， 该实施例中由于在方法体 StateProcess内部采用异步方式发送 调用请求消息，发送后将当前运行状态设置为接收应答状态， 并且需要等待应 答消息， 然后退出方法体 StateProcess, 释放调度线程， 此时所有的调用栈信 息都保存在 Context类中。 当收到应答消息时， 再次调进方法体 StateProcess 内部，并根据应答消息的 ID从 Context链中找到当前 Context对象并恢复上次 调用栈信息， 从退出点继续执行， 再次进入 IF2存根的方法体， 直接迁移到接 收请求状态， 取出应答消息中的返回值返回， 并继续执行后来处理逻辑， 所述 后续处理逻辑可以直接使用方法体 StateProcess调用的返回值。 因此， 在等待 应答期间， 线程可以处理别的业务， 不占用线程， 与同步调用相比， 可以保证 系统的处理性能； 而对于开发人员来说， 当接收到所述调用请求消息的应答消 息后， 可以根据保存的调用栈信息直接恢复到退出所述方法体前所处运行状 态，继续执行后续逻辑， 因此，后续逻辑可以直接应用当前方法体的调用结果， 对于开发人员来说，看到的只是该方法体的处理和后续逻辑的顺序执行，执行 逻辑并没有被打乱， 因此， 可以降低业务开发的复杂度， 提高业务开发效率。 综上可知，该实施例所采用的调用消息的方法可以同时兼顾系统的处理性能与 业务开发效率。

与上一实施例的不同之处在于，该技术方案采用了不同的调用栈信息保存 和恢复方法， 该方法具体为： 首先定义一种用于保存上下文关系的辅助类： 上 下文 (Context)类， 事实上， 可以对每个方法体生成对应的 Context类， 把方法 体的参数和局部变量作为该 Context类的成员， 在对应方法体中， 对参数和局 部变量的访问全部转换为访问 Context类的成员。 并且， 在进入方法体时， 都 把该方法体的 Context类对象链接到上一层方法体的 Context类对象上， 由此 可以形成一个 Context链， 所以即使中途退出以后还可以方便地找到整个 Context链。

当进行分布式远程调用时，会把调用信息构造成请求消息， 并通过软总线 发送， 该消息由一个唯一的消息 ID进行标识， 将该消息 ID存储在调用的 Context中； 而应答消息的 ID与前面发送的调用请求消息的 ID是一致的， 因 此， 当应答消息返回时， 可以 据应答消息的 ID找到对应的 Context对象， 再从中恢复出保存的调用栈信息。

这里例举的仅仅是一种实现方案，可以理解的是， 为了达到调用栈信息保 存和恢复的目的， 并不仅限于此种方案。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤 是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可 读存储介质中， 该程序在执行时， 包括如下步骤：

在方法体内部采用异步方式发送调用请求消息；

保存所述调用请求消息的调用栈信息及当前运行状态并退出所述方法体； 当接收到所述调用请求消息的应答消息时， 恢复保存的所述调用栈信息； 根据恢复的调用栈信息， 恢复到退出所述方法体前所处运行状态， 继续执 行后续逻辑。

上述提到的存储介质可以是只读存储器， 磁盘或光盘等。

以上对本发明所提供的一种分布式调用消息的方法和装置进行了详细介 绍， 对于本领域的一般技术人员， 依据本发明实施例的思想， 在具体实施方式 及应用范围上均会有改变之处， 综上所述，本说明书内容不应理解为对本发明 的限制。

Claims

权 利 要 求

1. 一种分布式调用消息的方法， 其特征在于， 包括：

在方法体内部采用异步方式发送调用请求消息；

保存所述调用请求消息的调用栈信息及当前运行状态并退出所述方法体； 当接收到所述调用请求消息的应答消息时， 恢复保存的所述调用栈信息； 根据恢复的调用栈信息， 恢复到退出所述方法体前所处运行状态， 继续执 行后续逻辑。

2. 如权利要求 1 所述的分布式调用消息的方法， 其特征在于， 保存所述 调用请求消息的调用栈信息具体为：保存所述调用请求消息的标识和对应的调 用栈信息；

恢复保存的所述调用栈信息具体为：根据接收到的所述调用请求消息对应 的应答消息的标识， 查找保存有相同标识的调用栈信息并恢复， 其中， 预设所 述应答消息的标识与调用请求消息的标识一致。

3. 如权利要求 1 所述的分布式调用消息的方法， 其特征在于， 保存所述 调用请求消息的调用栈信息的方法具体为：

将调用请求消息的标识及调用栈信息保存在预设的上下文类中，所述上下 文类中类对象与方法体——对应，且所述方法体对应的类对象链接到上一层方 法体的类对象上形成上下文类链表；

所述恢复保存的调用栈信息具体为：查找与所述应答消息的标识一致的类 对象， 再将保存的该类对象对应的调用栈信息恢复， 其中， 预设所述应答消息 的标识与调用请求消息的标识一致。

4. 如权利要求 1至 3任一项所述的分布式调用消息的方法， 其特征在于， 所述保存的调用栈信息包括： 被调用对象、 方法体、 调用参数。

5. 如权利要求 1至 3任一项所述的分布式调用消息的方法， 其特征在于， 所述执行后续逻辑具体为： 执行后续正常逻辑、执行超时处理逻辑或者执行异 常处理逻辑其中之一。

6. 一种分布式处理装置， 其特征在于， 包括： 消息调用单元和信息处理 单元， 其中：

所述消息调用单元包括： 消息发送单元、 消息接收单元、 信息存储单元、 栈信息维护单元， 其中：

消息发送单元， 在方法体内部采用异步方式发送调用请求消息； 消息接收单元， 接收所述调用请求消息的应答消息；

信息存储单元， 保存调用栈信息和所述方法体当前运行状态；

栈信息维护单元，当所述消息发送单元发送调用请求消息后将所述调用请 求消息的调用栈信息和当前运行状态保存到信息存储单元并退出所述方法体； 在消息接收单元接收到应答消息时， 将保存在信息存储单元的调用栈信息恢 复；

信息处理单元，根据栈信息维护单元恢复出的调用栈信息， 恢复到退出所 述方法体前所处运行状态， 继续执行后续逻辑。