软件应用中计算逻辑的按需远程执行方法

技术领域

本发明属于软件技术领域，针对由于从原部署节点所获计算资源不足而导致的软件应用 性能低下问题提供一种程序执行优化方法，具体涉及一种软件应用中计算逻辑的按需远程执 行方法，适用于软件维护演化。

背景技术

对计算资源(如CPU、内存等)的按需使用是软件应用增强其性能并改善用户体验的一 种主要手段。所谓按需(on-demand)，是指当计算资源不足时，应用可以占有并使用额外的 资源，从而保障其高效运行；而当资源过剩时，应用又可以释放掉多余的资源，从而减少浪 费。随着Internet的飞速发展，软件应用所处的环境变得越来越开放。而开放性则进一步促使 软件应用需要实现对计算资源的按需使用。例如，随着移动互联网的兴起，越来越多的软件 应用被下载运行在不同能力的移动终端上。这些以智能手机为代表的移动终端所拥有的计算 资源本身极其有限，常常导致应用性能低下，带来不佳的用户体验。并且由于不同型号的移 动终端配置不同，在运行同一应用时也会产生不同的性能效果。因此，只有应用做到按需使 用资源才能从根本上缓解开放环境下软硬件不匹配的矛盾，促进用户体验的改善。

对计算资源按需使用必须同时具备两个条件：一是具有额外可用的资源；二是应用可以 真正使用到这些资源。在Internet环境下，虽然网络单节点的计算资源仍然有限，然而互连起 来的网络节点其整体所拥有的计算资源则极为丰富。当应用需要额外资源时，可以通过网络 而获得其他节点所拥有的资源。因而，可以看到，实现对资源按需使用的根本还是在于应用 自身。

应用对分散资源的使用方式主要有两种：复制式使用和分割式使用。复制式的资源使用 方式通过对应用进行复制，将副本运行在额外的节点上，并在原应用和其副本前端加上负载 平衡器来将用户请求转发到多个应用实例组成的集群上(Chuliang Weng，Minglu Li，Zhigang Wang，and Xinda Lu，Automatic Performance Tuning for the Virtualized Cluster System，29th IEEE International Conference on Distributed Computing Systems，2009，pp.183～190)。这种方式可以有 效地应对由于用户请求激增而导致地应用性能急剧下降的情况。然而，该方式的使用范围有 限，主要用于web应用，但对于那些完整安装在智能手机等网络节点且与用户直接交互的本 地应用来说却不适用。此外，有研究已经指出，这种以整个应用为粒度的复制在较大程度上 会造成资源浪费(Duncan Johnston-Watt，Get Smart：The Case for Intelligent Application Mobility in the Cloud，the Cloud Computing Journal，2010)。原因在于，通常情况下不是组成应用的所有 模块都急需资源。那些不急需资源但占有资源的模块会与那些真正急需资源的模块相竞争， 反而导致资源没有充分被急需资源的模块所用，造成了隐性浪费。有介于此，分割式资源使 用将组成应用的模块分别部署在不同的节点上，让那些真正急需资源的模块充分占有计算资 源，以此实现对应用性能的保障和对资源的有效利用。在此基础上，又可将两种使用方式相 结合，在较细粒度上实现复制式资源使用，以进一步高效地保障应用性能。

由此可以看见，应用对计算资源的按需使用要以应用模块的按需分布式部署执行为保障， 也就是说，需要实现应用中计算的按需远程执行。当从原有节点所获资源不足，导致应用性 能下降时，可将应用中对资源需求较大的一部分计算转移到新获取的网络节点上执行，从而 通过占有额外的资源来保障应用的整体性能；而当资源过剩或网络条件不佳导致获取额外资 源的难度增大时，又可将计算移回，从而实现对资源的节省并保障应用正常运行。

目前实现计算逻辑的远程执行主要有两种方式：1)编写分布式应用。将应用中对资源消 耗较大的计算在设计和实现时就安排到拥有较多资源的网络节点上运行。然而，由于分布式 应用要求开发者处理远程方法调用、序列化、同步等与程序分布相关的问题，因而编写起来 通常费时费力。即便是使用分布式中间件，开发者也必须编写特定于中间件但与程序业务逻 辑无关的代码，带来相当的编程负担。此外，更重要的是，开发者很难在设计实现时就准确 预料到应用对资源的使用，因而所开出的应用程序中的本地/远程调用方式通常固定不变，这 就使得应用对资源难以实现真正的按需使用。2)通过程序转换器，自动将给定应用中的程序 代码转换后分为两部分：一部分继续留在原有节点上运行，而另一部分则被移动到其他网络 节点上运行。这两部分之间所需要的跨网络的互操作代码由该转换器以打补丁的方式自动加 入到原有应用当中，从而保证了转换后应用的正确运行。这种方式不要求开发者编写与程序 分布相关的代码，可极大降低应用开发的难度。然而，现有工作中，一个被转换后应用中代 码间的本地/远程调用方式仍然固定不变，导致当资源变化而需要调整计算的本地/远程调用关 系时，必须停机、重转换、重启，因而难以实现应用在运行时对资源的按需使用。

发明内容

本发明的目的是提供一种软件应用中计算逻辑的按需远程执行方法，其核心是支持软件 应用中的计算逻辑实现按需远程执行的设计模式，其主要手段是通过对软件应用代码进行重 构，自动将原始应用转换为符合所提出的设计模式的计算逻辑可按需远程执行的应用。

本发明的软件应用中计算逻辑的按需远程执行方法，其步骤包括：

1)将软件应用的应用类分为执行位置固定类(Anchored)和执行位置可变类(Movable)；

2)将所述应用类的程序代码从源结构转换为目标结构；所述目标结构包含代理(Proxy) 和端点(Endpoint)：所述代理与调用类运行于同一地址空间，负责将方法调用经由所述端点 转发至在本地或远程运行的被调用类；所述端点负责识别所述被调用类的当前位置；

3)将转换为所述目标结构的应用类封装为原始应用格式的应用和可远程执行的软件制 品，分别部署在原网络节点上和远程网络节点上；

4)预测当一应用类远程执行时该应用类所属的软件应用的性能，如果该性能提高，则在 远程执行该应用类，否则在本地执行该应用类。

进一步地：所述源结构包括直接内存调用结构和RCS(Remote Communication Service， 远程通讯服务)远程调用结构；当被调用类在远程运行时，所述端点利用RCS获得对被调用 类的远程引用，调用类通过该引用而远程调用被调用类；当被调用类和调用类运行于同一地 址空间时，所述端点直接获得对被调用类的内存引用，调用类通过该引用而直接调用被调用 类。

进一步地，所述软件制品包含执行位置可变类、代理类、端点以及相关资源文件。所述 相关资源文件可以是图像文件、XML配置文件等。所述软件制品可以有多个副本分别运行在 不同的网络节点上。

进一步地，所述软件应用的性能可以采用多种衡量方式，比如可以采用时间开销、吞吐 量开销、能耗开销中的一种或多种来衡量。

进一步地，本发明可对转换为目标结构的应用类进行聚类，将相互间调用频繁的类在必 要时作为一个整体放到远端执行。可以采用静态程序分析方法或动态程序分析方法进行所述 聚类。

本发明的方法可作为一款单独的工具或是一款插件而集成到各种软件开发平台(如 Eclipse，参见www.eclipse.org)或软件下载平台中(如豌豆夹手机精灵，参见 www.wandoujia.com)。通过自动对软件应用的代码进行重构，将其转换为可按需远程执行的 程序结构，从而帮助软件应用实现对计算资源的按需占有，以提高性能并改善用户体验。

附图说明

图1为直接内存调用结构示意图。

图2为远程调用结构示意图。

图3为计算逻辑可按需远程执行的目标程序结构示意图。

图4为实现软件应用中计算逻辑按需远程执行的代码重构步骤的示意图。

图5为实现计算逻辑按需远程执行的软件应用的运行时系统结构示意图。

具体实施方式

为使本发明的目的、特征和优点能更明显易懂，下文通过具体实施例并配合附图，作详 细的说明。

本发明的技术方案包含两部分：支持软件应用中计算逻辑实现按需远程执行的设计模式； 将软件应用的代码转换成可按需远程执行模式的自动重构方法。对其分别说明如下：

1.支持软件应用中计算逻辑实现按需远程执行的设计模式

一个给定的软件应用中的程序代码无外乎具有两种结构：一种是直接内存调用结构(local invocation)，如图1所示；另一种是远程调用结构(remote invocation)，如图2所示。

图1中应用类X调用应用类N的过程是首先获得对N的内存引用，然后通过该引用去 调用所需要的方法。显然，这种直接内存调用结构并不允许N中的计算被按需转移到远程执 行。这是因为，倘若N转移到远程网络节点后，X不能从它所在的内存地址空间获得对在远 端的N的引用。在一个给定的软件应用中，还可能存在如图2所示的远程调用结构。X通过 Remote Communication Service(RCS，远程通讯服务)而获得运行在远端的N的一个引用， 然后使用该引用去远程调用N中的方法。在该结构中，由RCS负责将N的引用与N相关联。 尽管该结构允许N远程执行，然而却仍然不能支持N实现按需远程执行。原因在于，当N 和X在同一个地址空间中执行时，X对N的方法调用仍需要RCS发消息给网络栈才能传递 到N，而网络栈中的消息传递相比直接内存引用来说极为耗时且耗资源，从而导致应用性能 下降。这与通过计算逻辑的按需转移来保障应用性能的初衷相违背。

为了实现计算逻辑的按需远程执行，目标程序结构必须要允许X能够有效调用N中的方 法而不管当前X与N运行在同一个地址空间还是在不同的网络节点上。本发明给出了一种支 持软件应用中计算逻辑按需远程执行的目标程序结构，主要包含如下两个核心元素：Proxy(代 理)和Endpoint(端点)。此外，N类自身的内部实现也要做相应的修改。比如，实现一些特 殊的接口及对应的一些特殊方法。新添加这些接口及方法的目标是为了使N能够被代理和端 点所使用，但修改后的N和修改前的N的功能和外部表现没有本质区别。如图3所示，本发 明将X和N之间的直接内存调用以及通过RCS的远程调用都转换成了经过NProxy(被调用 类N的代理)和Endpoint进行的间接调用。NProxy的外部行为和N完全一致，只是它本身 不执行任何实际的计算操作，只负责将方法调用转发到N执行。如果N的位置改变，比如从 X所在的内存地址空间转移到了远程网络节点，或是从某一远程网络节点转移到了另一节点， X并不会知道N位置的变化。其原因在于NProxy保持不变且始终与X运行在同一地址空间 中。Endpoint负责识别N当前的位置并且负责X和N之间根据具体需要而进行的跨网络互操 作或直接内存调用。倘若N运行在远程节点，则Endpoint会利用给定的RCS获得对N的远 程引用，并把该引用以NProxy的形式供X使用，使得X能够通过该引用而远程调用N。当 X和N都运行在同一地址空间时，Endpoint会直接获得对N的内存引用，并同样以NProxy 的形式供X所用，使得X调用N时不必经过耗时的网络栈。

2.将软件应用的代码转换成可按需远程执行模式的自动重构方法

在确定了软件应用的源结构(图1和图2)以及目标结构(图3)后，本发明逐步实施如 图4所示的程序转换步骤来实现给定软件应用中计算逻辑的按需远程执行并保障远程执行后 应用整体性能的提升。

首先，应用类分类。对于一个给定的软件应用，本发明自动将其应用类分成如下两类： 执行位置固定类(Anchored)和执行位置可变类(Movable)两种。Anchored类型的应用类 必须留在原网络节点上执行。原因在于，这些类使用到了一些只能在原节点才能获取的特殊 资源(比如图形用户界面显示器以及特殊的文件等)。倘若这些类被转移到远端网络节点上执 行，它们会因找不到所需要的资源而造成执行错误。这些类之外的其他应用类都被自动归为 Movable类型的类。例如，一个用于数学处理的Math类就通常是一个Movable类型的类。在 必要时，这些类可以远程执行，从而通过对远程计算资源的占有来提高整个应用的性能。

其次，应用类转换。在这一步中，会将给定软件应用类代码从源结构转换为目标结构， 使之可远程执行。当一个应用类放到远端执行时，与之交互的应用类都需要被转换成可按需 远程调用的结构，即，生成被调用者的代理类Proxy，重写调用类来使用Proxy。需要注意的 是，如果一个Anchored类被在远端执行的Movable类所调用，后者同样需要前者的代理类。 由于只有根据运行时信息才能最终决定Movable类的本地/远程执行以提高应用整体性能，因 此，必须对所有的被调用类生成相应的代理，并重写调用类来使用这些代理，除非调用类和 被调用类都是Anchored的情况。在本发明所提出的方法中，一个Proxy与其被代理的应用类 在外部表现及功能上完全一致。也就是说，这两个类继承了同样的父类，实现了同样的业务 接口，具有同样的方法签名。这样，才能使那些原本使用被代理类的应用类在使用Proxy时 不能感觉到差别。

接着，应用类聚类。通过聚类可以使计算逻辑的远程执行能够进一步提高应用的性能， 避免频繁的网络调用带来负面影响。因为网络调用通常极为耗时，若调用过于频繁则反而会 影响应用性能的提高。因此需要把相互间调用频繁的类作为一个整体在必要时放到远端执行。 倘若在应用运行才去发现应用类的调用关系，通常会带来巨大的开销。因此，本步骤的目的 就是要简化对应用中哪些计算逻辑需要被真正远程执行的运行时决策。本发明基于应用类聚 类的方法来实现这种简化。例如，通过聚类发现类X和N调用频繁。在运行时，Endpoint可 以只监控X的执行轨迹来决定是否需要将X和N一起放到远端执行。这样做不但可以避免X 和N被分到网络两端时所需要进行地频繁的跨网络互操作，并且可以简化运行时X和N之 间关系的分析以及对N的监控，从而降低开销。上述聚类可以采用多种方法，比如使用静态 程序分析方法，基于调用应用类之间的关系图(call-graph)进行聚类，也可以采用动态程序 分析方法。

最后，应用类封装。本发明所提出的方法的输入是一个给定的软件应用的组成代码以及 相应的资源文件(原始应用所拥有的全部资源文件)，如图像、XML配置文件等。在经历了 以上步骤之后，输出包含两类制品：一个是转换后封装为原始应用格式的应用，该应用留在 原网络节点运行；另一类是原始应用中那些Movable类型的应用类、代理、端点以及相关资 源文件所组成的一个可在远程网络节点部署执行的软件制品。

图5展示了一个可实现计算逻辑按需远程执行的软件应用的运行时系统结构。该应用包 含了6个类，名字分别从a到i。通过步骤1，发现类b和g都是Anchored类，必须留在原 网络节点上执行。其他类都是Movable类，它们既可在原网络节点上执行，也可在新增的远 程网络节点上执行。通过步骤2，每一个应用类都生成了对应的Proxy类，并且应用类间的 调用都通过Proxy和Endpoint来完成。经过步骤3发现a，c，d，e和f是关系紧密的类， 因此它们被聚类在了一起已备在必要时作为一个整体运行在远端。步骤4将所有的Movable 类型的应用类、代理、端点以及相关资源文件封装为可在远端节点部署执行的软件制品，该 制品允许有多个副本分别运行在不同的网络节点上(每个副本运行在一个网络节点)，以支持 本发明所提出的通过计算逻辑的远程执行来实现的对资源的占有。同样，会将全部应用类、 它们的代理以及Endpoint都按照原有应用格式进行封装为转换后的应用，将其部署在原网络 节点上进行。不同之处在于，转换后应用中Movable类的计算可以根据需要而调用在远端的 对应Movable类执行或是直接本地执行。

在运行时，通过Endpoint预测当一应用类远程执行时该应用类所属的软件应用的性能， 如果发现远程执行能够提高性能，则远程执行(即调用部署在远程节点的执行位置可变类)， 否则就本地执行(即调用部署在本地节点的执行位置可变类)。具体来说，Endpoint预测到 若应用类d远程执行时可以提高应用性能，则通过RCS获得对d的远程引用，调用类通过该 引用而远程调用d。具体过程是：首先激活在远端的d，并且把本地d的状态通过Endpoint 注入到远端的d，实现状态同步，接着将本地的d停用。此后，d的Proxy将会通过Endpoint 把对原节点d的调用请求转发到远端的d上执行。由于d、c、e和f在第3步时已经被聚类 为了一个逻辑整体。因此，当d被转移到远端执行时，该聚类中的其他类也跟着被移到远端 执行，以减少频繁的跨网络调用。该过程也一样要经历激活、状态同步、停用等阶段。因此 可以从图中看到，在原节点，a、c、d、e和f的Proxy在起作用，而这些类中计算逻辑的真 正执行是在远端的网络节点上。当网络条件不佳时或是发现仅原节点的资源就足以保障应用 性能时，可以通过停用在远端的a、c、d、e和f，并重新激活在原节点的对应类实例来将远 程执行的计算移回，以节约资源并保障应用正常运行。所有对这些类的调用都将通过Proxy 和Endpoint而转发回原节点，从而以一种按需的方式实现了应用中计算逻辑的远程执行。

上述过程中，应用系统的性能可以采用多种衡量方式，比如可以采用时间开销、吞吐量 开销、能耗开销其中的一种或多种来衡量。吞吐量开销可由应用所能处理的用户请求量来衡 量。能耗开销可由节点(如手机)端的电池续航时间来衡量。时间开销可包含发送调用某一 方法的请求给该应用类所用的时间、该应用类执行该方法所用的时间以及返回执行结果所用 的时间。具体来说，应用类d远程执行的时间开销由如下三部分构成：

1.Tsend，发送需要执行方法m的请求给远程的d所花的时间；

2.Texecute，远程的d执行方法m所花的时间；

3.Tback，返回执行结果所花的时间。

而当d本地执行时m方法耗时为T’execute。

如果d所在的远程节点的计算资源比d原来所在的本地节点的计算资源丰富，比如d所 在的远程节点为PC，而d所在的本地节点为手机(其CPU处理能力远不如PC的CPU处理 能力)。这导致Texecute＜＜(表示远小于)T’execute，以至于Tsend+Texecute+Tback＜＜T’execute。 如果网络不佳，或是远程资源不丰富，使得Tsend+Texecute+Tback＞T’execute，则本地执行就 没有必要了。此时endpoint就直接获得对被调用类的内存引用，调用类通过该引用而直接调 用被调用类。因此，endpoint可以预测出d是否应该本地执行或远程执行以通过占有计算资 源来提高应用性能。须说明的是，本发明并非必须通过端点进行性能的预测。端点还可以通 过收集应用运行数据，将这些数据发送给第三方的预测器来预测性能。该预测器通过分析数 据并进行预测后返回结果给端点，然后端点根据结果来决定哪些应用类实例(比如上述的应 用类d)需要远程执行或是本地执行。

下面通过一个具体应用的实施例说明本发明的方法。该实施例是将一个真实的Java Android应用即“GoGame(围棋对战)”中的计算逻辑按需移动到服务器端执行。

GoGame是由INSA(法国国立应用科学学院Institut National des Sciences Appliquees)研 究人员开发出的一款Android围棋对战游戏。它的游戏模式中有人人对战/人机对战两种。人 机对战中还可以选择机器棋手所采取的智能算法，如基于模式的Pattern算法以及基于统计模 拟的MonteCarlo算法。通常情况下，机器棋手需要进行大量耗能耗时的计算才能决定落子的 位置，而由于手机所拥有的处理器配置通常不高，因此导致该应用的性能较低，对用户的输 入不能快速做出响应，且耗电量很大，带来不佳的用户体验。

本实施例使用三星Samsung S5660型号的Android手机(CPU 800MHz，内存160M， Android22手机操作系统平台，锂电EB494358VU，1350mAh)作为实验手机。使用联想SL400 笔记本作为服务器(CPU Intel Core Duo，T6570，2.1GHz，内存1G)。手机和笔记本通过wifi 关联。相互间的RTT(往返行程时间)为50ms。

本实施例按照图3所示的设计模式以及图4的重构方法，自动将原始的GoGame应用转 换为计算逻辑可按需远程执行的GoGame应用。

首先，识别出原始GoGame中哪些类是Anchored以及Movable，如表1所示。

表1.GoGame转换后得到的类簇

接着自动地对这些类进行转换，并生成对应的Proxy以及Endpoint。随后，通过聚类发 现GoGame中的应用类可以聚为如表1所示的类簇，并将聚类信息存储在转换后应用的 Endpoint中。最后通过封装，自动生成转换后的Android GoGame应用以及由Movable应用 类、Proxy等所组成的可执行的Apk文件。转换后的GoGame应用被部署在手机上，Movable 类对应的Jar文件被部署在服务器上。

实验选择将类簇2移动到服务器端端执行，并使用MonteCarloAI人机对战的方式进行测 试，游戏进行5分钟(即300秒)。测试方案如下：

1.GoGame的计算全部在手机上执行(300秒)。

2.GoGame中的类簇2(即表1中包含MonteCarloAI的类簇)移动到服务器端执行(时 间300秒)。

3.使手机逐渐远离wifi路由器，在300秒时间内使RTT逐渐增大到600ms(用以模拟用 户离开服务器端的场景)，在240秒到300秒这一个时间段内将类簇2移动回手机端执行。

实验得到的机器棋手下棋的响应性能比较和电能消耗如表2所示。

表2.性能和能耗比较(测试时长为300秒)

由该表得到的实验结果如下：

方案2相对于方案1，响应性能提高了86％，电能节省了89％。

方案3相对于方案1，响应性能提高了84％，电能节省了80％。

因此，从表2可以看到，本发明所提出的将软件应用中的计算逻辑按需远程执行能够极 大地提高应用的性能，从而能够有效改善用户体验。

上述具体实施例和附图用以帮助理解本发明的技术原理并据以实施，而不对本发明构成 限制。本领域的技术人员可以理解：在不脱离本发明的权利要求的精神和范围内，各种替换、 变化和修改都是可能的。本发明要求保护的范围应以权利要求书的界定为准。