CN112817567A - 一种微服务应用的openwhisk无服务框架迁移方法 - Google Patents

Abstract

本发明公开了一种微服务应用的openwhisk无服务框架迁移方法，利用了Node.js语言的exprima语法解析工具生成抽象语法树节点，并从中提取关键信息来生成函数调用图，微服务子模块间通信图以及判断微服务子模块的性质，并对有状态的微服务模块尝试划分，最大限度的实现自动化迁移。从抽象语法树的层面解析项目源代码文件，项目包文件，配置文件等，实现简单，效率高。目前并上还没有同类的技术方案，本发明的出现将会帮助开发人员提高将应用向无服务器计算平台上的迁移效率。

Description

一种微服务应用的openwhisk无服务框架迁移方法

技术领域

本发明涉及计算机软件技术领域，尤其涉及一种微服务应用的openwhisk无服务框架迁移方法。

背景技术

随着互联网的高速发展，软件架构也发生了翻天覆地的改变。微服务(Microservices)是从域驱动设计、持续交付、平台和基础设施自动化、可扩展系统、多语言编程和持久性等领域发展起来的一种软件体系结构模式。微服务并没有明确的定义，是一个相对概念。在传统的单体应用程序中，所有功能模块集中在一个服务中，用户界面、数据访问层和数据存储层之间紧密耦合。而在微服务的软件架构中，各个功能模块被拆分成松散耦合的组件，并通过协调工作来执行任务。这些功能独立的微服务子模块不仅可通过多种语言(Java、PHP、Python)进行开发，还能独立部署，使用多种轻量级通信协议(Http/Https/JMS)相互通信。

通过使用微服务，开发者可以快速完成构建部署，维护成本也大为降低，扩放性较单体程序而言也有了显著的提高，但是从本质上来说，微服务依然没有摆脱“客户机—服务器”模型。在这种模型下用户需要自己搭建运行时环境，然后将服务部署在预先分配好的云计算资源上。无服务器计算(Serverless Computing)是云计算的一个新范式。目前常见的无服务器计算服务有aws lambda、apache openwhisk等。

不论是单体架构应用还是微服务架构应用，都必须时刻保持运行以便应对“客户端”的突发请求，这将造成极大的资源浪费，此外“客户机——服务器”模型应用在面对突发流量时，其资源占用量不能弹性伸缩而无服务器计算的出现解决了这一问题。在无服务器计算架构中，每次收到服务请求时都由计算平台随机分配一个短暂的环境来执行代码，处理请求。运行完毕后所有计算资源会被计算平台回收，运行过程中在内存保存的数据，生成的文件等都将随之消亡。若该服务下一次的请求可能需要依赖这些保存在内存和文件中的数据时，该服务迁移后将无法提供正常的服务。因此对于一个由多个微服务子模块组成的微服务应用，并非所有的微服务子模块都适合迁移为无服务器计算架构，自动化迁移的一个挑战是检测识别出适合迁移的微服务子模块并完成迁移，对不适合迁移的微服务子模块对不适合迁移的微服务子模块需要检测具体原因，但是，目前没有较为有效的方案。

发明内容

本发明的目的是提供一种微服务应用的openwhisk无服务框架迁移方法，能够检测识别出适合迁移的微服务子模块并完成迁移。

本发明的目的是通过以下技术方案实现的：

一种微服务应用的openwhisk无服务框架迁移方法，包括：

解析微服务应用源代码，对每一微服务子模块分别生成相应的抽象语法树；

遍历每一抽象语法树的节点信息，通过分析与文件存储、网络长连接、消息队列订阅以及数据库的阻塞同步操作相关的函数调用情况判断微服务子模块状态的有无情况，从而将微服务子模块初步分为无状态微服务子模块与有状态微服务子模块；

根据微服务子模块之间的通信信息，构建微服务子模块间的通信图，以及结合有状态微服务子模块的抽象语法树节点构建有状态微服务子模块内的函数调用图；

对于有状态微服务子模块，根据其函数调用图判断是否能够做进一步划分，若是，则将其划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，并更新微服务子模块间的通信图；

基于更新后的微服务子模块间的通信图，迁移所有的无状态微服务子模块。

由上述本发明提供的技术方案可以看出，利用了Node.js语言的exprima语法解析工具生成抽象语法树节点，并从中提取关键信息来生成函数调用图，微服务子模块间通信图以及判断微服务子模块的性质，并对有状态的微服务模块尝试划分，最大限度的实现自动化迁移。从抽象语法树的层面解析项目源代码文件，项目包文件，配置文件等，实现简单，效率高。目前并上还没有同类的技术方案，本发明的出现将会帮助开发人员提高将应用向无服务器计算平台上的迁移效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。

图1为本发明实施例提供的一种微服务应用的openwhisk无服务框架迁移方法的流程图；

图2为本发明实施例提供的抽象语法树部分信息示意图；

图3为本发明实施例提供的Web微服务子模块部分URL通信信息示意图；

图4为本发明实施例提供的微服务子模块间的通信图；

图5为本发明实施例提供的一个微服务子模块内的函数调用图；

图6为本发明实施例提供的微服务子模块进一步划分后的函数调用图；

图7为本发明实施例提供的更新后的微服务子模块间的通信图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。

本发明实施例提供一种微服务应用的openwhisk无服务框架迁移方法，如图1所示，其主要如下步骤：

一、解析微服务应用源代码，对每一微服务子模块分别生成相应的抽象语法树。

本发明所实施例中，对于每一微服务子模块，扫描源代码的存放位置；对于源代码文件主要考虑“*.js”文件和“.coffee”文件。对于后缀名为js的文件，通过语法解析，生成抽象语法树；扫描到后缀名为coffee的文件则先将其编译为js文件，再通过语法解析，生成抽象语法树。本发明实施例中，可以使用Node.js语言的第三方模块esprima语法解析工具来生成抽象语法树。生成的抽象语法树是源代码的抽象语法结构的树状表现形式，树的节点包含了运算符，关键字，变量名等所有程序中出现的内容。通过对树的分析可以准确的将语句分类为声明语句、赋值语句、运算语句等等，并且可以得到这些语句在程序中的具体位置。

示例性的，以基于express框架的多人在线协作文档应用中的某些微服务为例，相关微服务由13个子微服务模块和两个数据库(redis与mongodb)组成。每个微服务子模块的代码放在不同的文件夹下，均由coffeescript语言编写，对应的源代码文件后缀名为“.coffee”。本发明扫描到这些文件时会先将其编译为Node.js语言的源代码，生成“.js”文件，然后读取所有的后缀名为“.js”文件进行语法解析，生成抽象语法树。图2为生成的抽象语法树部分信息。

二、遍历每一抽象语法树的节点信息，通过分析与文件存储、网络长连接、消息队列订阅以及数据库的阻塞同步操作等相关的函数调用情况判断微服务子模块状态的有无情况，从而将微服务子模块初步分为无状态微服务子模块与有状态微服务子模块。

本领域人员可以理解，网络长连接是指在一个连接上可以连续发送多个数据包。

本发明实施例中，通过遍历抽象语法树的节点信息能够获得源代码中定义的各项信，例如，代码中定义的各种变量，函数，调用的库，应用框架等丰富的信息。这些信息能够用于判断一个微服务子模块性质(状态的有无情况)。此外，通过对函数定义和调用情况的分析和推导可以得到一个微服务子模块内部的所有的函数调用情况，通过对字符串进行特定正则表达式的匹配能够识别出所有的通信URL，通过这些URL可以帮助我们了解服务间的通信情况等。

本发明实施例中，通过分析与文件存储、网络、数据库操作等相关的函数调用情况微服务子模块初步分为两大类：无状态微服务子模块与有状态微服务子模块。具体来说，通过检测是否生成文件，是否有网络长连接以及一些特殊的数据库操作来判断，无状态的微服务是没有这些操作的；基于这样的原理，对于不含上述所有操作相关函数调用情况则为无状态微服务子模块，反之为有状态微服务子模块。并且无状态微服务子模块面对同一个请求时，在不考虑缓存机制的情况下，返回相同的结果，有状态微服务子模块则返回不同结果。无状态的微服务子模块很适合迁移为无服务器计算。

此处初步划分的方案可以通过常规方案来实现，例如，某个微服务子模块会创建一个文件，那么这个微服务子模块是一个有状态微服务子模块，本发明可以通过检测代码中是否使用创建文件相关的函数(fs.write，fse.mkdir)来判断这个微服务子模块状态的有无情况。

所述有状态微服务子模块根据迁移难度还划分为强状态微服务子模块与弱状态微服务子模块；其中，强状态微服务子模块指的是除监听网络端口处理来自客户端的请求外，还需要监听其他信息(例如，消息队列的订阅等)，反之为弱状态微服务子模块。强状态的微服务子模块迁移代价大，不适合直接迁移。

示例性的，还以之前提及的微服务为例，在本步骤中，将逐一遍历13个微服务子模块的抽象语法树节点以及解析所有语法树及其每一棵子树。这样就可以得到程序中的函数接口调用，变量定义，赋值表达式，循环，条件判断等信息。首先判断这些信息中是否含有本地文件存储，服务间通信，消息队列的使用等可能影响到微服务子模块的性质信息。经过这一步检测后发现，real-time，nginx微服务子模块存在websocket长连接为强状态，filestore与clsi存在本地文件存储为弱状态，Web模块需要存储csrf_token与大文件为弱状态，document-update需要监听redis数据库为强状态，其他均为无状态。确定了每个微服务子模块的性质后其次使用正则表达式根据匹配收集所有服务间通信的URL相关信息，并在所有的微服务子模块中标记出了与redis，mongodb数据库通信的部分提示开发者可能需要修改。

上述示例中所提及的长连接，本地文件存储等信息均为检测出的不适合迁移的具体原因。

三、根据微服务子模块之间的通信信息，构建微服务子模块间的通信图，以及结合有状态微服务子模块的抽象语法树节点构建有状态微服务子模块内的函数调用图。

本发明实施例中，通过抽象语法树的节点信息，能够得到微服务子模块之间通信的URL，从而构建微服务子模块间的通信图；同时，通过抽象语法树的节点信息能够确定微服务子模块的函数调用情况，从而构建微服务子模块内的函数调用图。

上述两种图在逻辑上均为有向图。为了方便处理，在本发明中采用邻接表的数据结构来表示这两种图。假设函数A调用函数B，则在调用图上存在一条由A指向B的边，在邻接表中A节点上有指向B节点的指针。对于微服务子模块A访问微服务子模块B与函数A调用函数B的情况类似。

示例性的，还以之前提及的微服务为例，在上一步骤中，将13个微服务子模块分为无状态，强状态和弱状态三大类，并且收集了每个微服务子模块中与其他模块通信的URL。在本步骤本发明继续对这些URL进行文本分析，将URL中的字符串与其他模块的名称以及其他模块的路由函数进行对比，确定该URL请求的目的微服务子模块。图3展示了web微服务子模块的部分URL信息，由此可知web微服务子模块会发送请求到tags，spelling微服务子模块。通过对URL进行分析就可以了解微服务子模块的请求发往何处，对应的通信图上就有一条由相应节点出发的边。图4展示了微服务子模块间的通信调用图。微服务子模块的函数调用情况只需要以抽象语法树中的函数节点为根节点构建子树，子树中的函数节点及所在的层数表示了与该函数节点的关系。图5展示了其中document_updater微服务子模块的函数调用图。

四、对于有状态微服务子模块，根据其函数调用图判断是否能够做进一步划分，若是，则将其划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，并更新微服务子模块间的通信图。

本发明实施例中，有状态微服务子模块包含强状态微服务子模块与弱状态微服务子模块，这两类微服务子模块都需要判断是否能够做进一步划分；如果可以，则：1)将强状态微服务子模块将被划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，称为第一强状态微服务子模块和第一无状态微服务子模块；第一强状态微服务子模块的迁移需要对程序语义层面上的理解，依旧部署为微服务子模块；第一无状态微服务子模块能够迁移部署为无服务器计算单元。2)将弱状态微服务子模块划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，称为第一弱状态微服务子模块和第二无状态微服务子模块；第二无状态微服务子模块能够迁移部署为无服务器计算单元；第一弱状态微服务子模块依旧部署为微服务子模块，或者借助第三方服务将状态转移后迁移部署为无服务器计算单元。

本步骤的优选实施方式如下：

本发明在第二个步骤中通过检测代码中是否存在本地存储，本地内存数据库，网络长连接等信息来判断一个微服务子模块是否有状态，并且记录下相关的位置；所述相关的位置是指有状态函数调用的位置，例如，在某个程序中115行调用了redis.blpop()，则记录的信息为相应文件名称以及对应行号115。对于当前有状态微服务子模块，提取出相关函数，再遍历当前有状态微服务子模块的函数调用图将所述相关函数所在节点及所有的父节点祖先节点均标记为有状态函数；经过以上步骤后，如果还包含未被标记为有状态的函数，则未被标记为有状态的函数组成一个新的无状态微服务子模块，标记为有状态的函数则组成一个新的有状态微服务子模块；划分后，当前有状态微服务子模块在通信图上原来的一个节点也分裂为两个节点，一个节点代表一个微服务子模块；节点的分裂使得通信图中边的信息也需要更新：节点的出边很容易更新，只需要根据分裂后两个节点的通信信息(即发出的通信请求)更新出边即可；通信图中某个节点的入边代表着该节点的父节点发到该节点的通信URL请求，所以分裂后两个节点入边的更新需要分析分裂前对应节点的父节点的中的通信URL请求，然后参考分裂后的两个节点中的路由信息，确定由某一分裂后节点处理相应通信URL请求，从而建立由父节点通往相应分裂后节点的入边。

此外，除了图上信息的更新，还需要将该当前有状态微服务子模块根目录及其中文件复制一份，然后通过分析抽象语法树，定位到无关函数将其注释即可。分裂后得到的新的无状态微服务子模块改名为原模块名+“_stateless”，分裂后得到的新的有状态微服务子模块依旧保保留原名。

当然根据函数的状态划分微服务子模块也会有会遇到极端情况，即遍历后所有的函数均标记为有状态函数，此时不能划分为两部分。

示例性的，还以之前提及的微服务为例，在第二个步骤中，将13个微服务子模块分为无状态，有状态两大类，其中，有状态又划分为强状态和弱状态两类，强状态微服务子模块有document_updater,real_time，nginx。弱状态微服务子模块为filestore,clsi，web。这一步需要对这六个微服务子模块进行拆分。下面以document_updater为例说明划分过程。首先通过第二步对抽象语法树中信息的分析，检测程序中是否存在本地文件存储，网络长连接，数据库监听等来判断一个微服务子模块是有状态还是无状态。最终在检测到document_updater微服务子模块中检测到了数据库监听操作(redis.blpop)，所以该微服务子模块为强状态。根据第二个步骤中记录的位置将强状态定位到具体的函数中，在函数调用图中有状态函数所在节点的父节点均会成为有状态函数。具体来说，根据函数调用图可以知道该函数对应节点有三个父节点(createAndStartDispatchers,createDispatcher)，所以如图6所示，这三个函数及这三个函数会调用到的函数均划分到第一强状态部分(第一强状态微服务子模块)。一共是12个函数：

1)createAndStartDispatchers；

2)createDispatcher；

3)waitForUpdateThenDispathWork；

4)redis.createClient；

5)redis.blpop；

6)UpdateManager.processOutStandingUpdatesWithLock；

7)UpdateManager.continueProcessingUpdatesWithLock；

8)tryLock；

9)processOutStandingUpdates,；

10)releaseLock；

11)fetchAndApplyUpdates；

12)applyUpdates。

不会调用reids.blpop的函数，以及这些函数所需调用的函数组成第一无状态部分。如新图2所示。根据函数调用的情况将该子模块的所有函数分为两个部分后，对应的将其代码文件复制一份并命名为document_updater_stateless。并且在新复制的代码文件注释掉所有第一强状态部分包含的函数定义及调用，同理需要在原来的代码文件中注释掉第一无状态部分包含的函数定义及调用。如是便将document_updater子模块划分为两个部分，然后再分析这两个子模块中的URL信息以及原document_updater子模块对应节点的父节点(real_time,web)中URL情况，更新图4所示的通信图，更新后的通信图如图7所示。

五、基于更新后的微服务子模块间的通信图，迁移所有的无状态微服务子模块。

经过之前的操作所有的有状态的微服务子模块均被划分为更细粒度且不能在继续划分的微服务子模块，得到了新的微服务子模块间的通信图，此时通信图上所有的无状态微服务子模块均适合迁移为无服务器计算单元。此处所提及的无状态微服务子模块包含了第二个步骤中得到的无状态微服务子模块、以及第四个步骤划分后得到的第一无状态子模块与第二无状态子模块。

迁移的主要步骤如下：

1)对于每一个无状态微服务子模块插入两个js文件，其中一个js文件作为整个无状态模块的入口，其main函数将被openwhisk无服务框架所调用；根据相应的抽象语法树，能够得到无状态微服务子模块的express对象；在main函数中，将express对象和输入参数(例如，从_ow_path,__ow_body等openwhisk无服务器计算平台从无服务计算单元URL中解析获得的)传递给另一个js文件中的转发函数；该转发函数将根据输入参数，生成一个新的HTTP请求，并将其转发给express对象，在这一过程中，考虑到模块原本的express监听端口可能与运行环境冲突且灵活多变，引入了Unix Domain Socket机制，这一机制可以生成无冲突的本地监听Socket，同时避免传统Socket中TCP传输带来的开销。除了上述的“js”文件之外，还更新package.json文件，在该文件中指明无状态微服务子模块的入口函数为新插入js文件的main函数。

2)在确定微服务子模块中插入了以上两个“.js”文件后，能够部署在openwhisk无服务计算平台上：首先确定每个待部署的无状态微服务子模块的根目录所在路径(例如，Node.js项目的“package.json”文件所在目录即为根目录)，并将相关文件夹处理为压缩文件(例如，压缩为“.zip”文件)，随后调用openwhisk无服务器计算平台的相关命令创建无服务器计算单元(action)；创建成功后每个无服务器计算单元都有一个对应的URL，通过这个URL和有关参数即可触发对应的无服务器计算单元提供服务；在得到URL后，根据更新后的微服务子模块间的通信图，将原来所有微服务子模块中访问部署前微服务子模块的URL替换为部署后得到的无服务器计算单元的URL。例如，两个通信模块A和B，A通过URL1访问B，将B部署为无服务计算单元后，需要通过新的URL2来访问，所以需要将A中所有URL1更新URL2。

示例性的，还以之前提及的微服务为例，第四个步骤执行完毕后，可以得到所有适合迁移的微服务子模块(即所有无状态微服务子模块)。首先通过检索“package.json”文件确定微服务子模块的根目录所在位置，然后插入两个“js”文件，分别为“handler.js”和“owExpressServerless.js”。前者作为整个无状态模块的入口，其main函数将被openwhisk所调用。根据第一步中得到的抽象语法树，可以得到每个模块的express实例。

在项目文件夹中添加了两个“.js”文件后，将各个带迁移微服务子模块文件夹压缩为“.zip”文件，如“document_updater_stateless.zip”,“tags.zip”等。然后执行openwhisk平台的计算单元的创建命令创建openwhisk无服务器计算单元并为其命名。如“wsk action create–i document_updater_stateless.zip document_updater_stateless”创建了一个名为document_updater_stateless的openwhisk无服务器计算平台的执行单元。创建完毕后可以使用“wsk action get[计算单元名称]--URL”命令得到触发该无服务器计算单元的URL，最后再按照微服务子模块间的通信图协同更新上游访问该微服务子模块的URL为无服务器计算单元的URL。

需要说明的是，本发明实施例上述方案，对于其他语言的微服务应用迁移到其他无服务计算平台也有一定的参考价值。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (8)

1.一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，包括：

解析微服务应用源代码，对每一微服务子模块分别生成相应的抽象语法树；

遍历每一抽象语法树的节点信息，通过分析与文件存储、网络长连接、消息队列订阅以及数据库的阻塞同步操作相关的函数调用情况判断微服务子模块状态的有无情况，从而将微服务子模块初步分为无状态微服务子模块与有状态微服务子模块；

根据微服务子模块之间的通信信息，构建微服务子模块间的通信图，以及结合有状态微服务子模块的抽象语法树节点构建有状态微服务子模块内的函数调用图；

对于有状态微服务子模块，根据其函数调用图判断是否能够做进一步划分，若是，则将其划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，并更新微服务子模块间的通信图；

基于更新后的微服务子模块间的通信图，迁移所有的无状态微服务子模块。

2.根据权利要求1所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，所述解析微服务应用源代码，对每一微服务子模块分别生成相应的抽象语法树包括：

对于每一微服务子模块，扫描源代码的存放位置；对于后缀名为js的文件，通过语法解析，生成抽象语法树；扫描到后缀名为coffee的文件则先将其编译为js文件，再通过语法解析，生成抽象语法树。

3.根据权利要求1所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，将微服务子模块划分为两大类的步骤包括：

通过遍历抽象语法树的节点信息能够获得源代码中定义的各项信息；

通过分析与文件存储、网络长连接、消息队列的订阅以及数据库的阻塞同步操作相关的函数调用情况将微服务子模块初步分为两大类：无状态微服务子模块与有状态微服务子模块；若不含上述所有操作相关函数调用情况则为无状态微服务子模块，反之为有状态微服务子模块，并且在不考虑缓存机制的情况下，无状态服务子模块面对同一个请求时会返回相同结果。

4.根据权利要求1或3所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，所述有状态微服务子模块根据迁移难度还划分为强状态微服务子模块与弱状态微服务子模块；其中，强状态微服务子模块指的是除监听网络端口处理来自客户端的请求外，还需要监听其他信息，反之为弱状态微服务子模块。

5.根据权利要求1所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，根据微服务子模块之间的通信信息，构建微服务子模块间的通信图，以及结合有状态微服务子模块的抽象语法树节点构建有状态微服务子模块内的函数调用图包括：

通过抽象语法树的节点信息，能够得到微服务子模块之间通信的URL，从而构建微服务子模块间的通信图；

同时，通过有状态微服务子模块的抽象语法树的节点信息能够确定有状态微服务子模块的函数调用情况，从而构建微有状态服务子模块内的函数调用图。

6.根据权利要求1所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，所述对于有状态微服务子模块，根据其函数调用图判断是否能够做进一步划分，若是，则将其划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，并更新微服务子模块间的通信图包括：

有状态微服务子模块包含强状态微服务子模块与弱状态微服务子模块，这两类微服务子模块都需要判断是否能够做进一步划分；如果可以，则：

将强状态微服务子模块将被划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，称为第一强状态微服务子模块和第一无状态微服务子模块；第一强状态微服务子模块依旧部署为微服务子模块；第一无状态微服务子模块能够迁移部署为无服务器计算单元；将弱状态微服务子模块划分为一个新的有状态微服务子模块与一个新的无状态微服务子模块，称为第一弱状态微服务子模块和第二无状态微服务子模块；第二无状态微服务子模块能够迁移部署为无服务器计算单元；第一弱状态微服务子模块依旧部署为微服务子模块，或者借助第三方服务将状态转移后迁移部署为无服务器计算单元；

划分后，当前有状态微服务子模块在通信图上原来的一个节点也分裂为两个节点，一个节点代表一个微服务子模块；节点的分裂使得通信图中边的信息也需要更新：根据分裂后两个节点的通信信息更新出边；通信图中当前节点的入边代表着当前节点的父节点发到当前节点的通信URL请求，分裂后两个节点入边的更新需要分析分裂前对应节点的父节点的中的通信URL请求，参考分裂后的两个节点中的路由信息，确定由某一分裂后节点处理相应通信URL请求，从而建立由父节点通往相应分裂后节点的入边。

7.根据权利要求6所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，对有状态微服务子模块进行划分的方式包括：

对于当前有状态微服务子模块，提取出相关函数，再遍历当前有状态微服务子模块的函数调用图将所述相关函数所在节点及所有的父节点祖先节点均标记为有状态函数；经过以上步骤后，如果还包含未被标记为有状态的函数，则未被标记为有状态的函数组成一个新的无状态微服务子模块，标记为有状态的函数则组成一个新的有状态微服务子模块。

8.根据权利要求1所述的一种微服务应用的openwhisk无服务框架迁移方法，其特征在于，基于更新后的微服务子模块间的通信图，迁移所有的无状态微服务子模块包括：

对于每一个无状态微服务子模块插入两个js文件，其中一个js文件作为整个无状态模块的入口，其main函数将被openwhisk无服务框架所调用；根据相应的抽象语法树，能够得到无状态微服务子模块的express对象；在main函数中，将express对象和输入参数传递给另一个js文件中的转发函数；该转发函数将根据输入参数，生成一个新的HTTP请求，并将其转发给express对象，同时引入了Unix Domain Socket机制，该机制能够生成无冲突的本地监听Socket；并且，还更新package.json文件，在该文件中指明无状态微服务子模块的入口函数为新插入js文件的main函数；

在插入两个js文件后，能够部署在openwhisk无服务计算平台上：首先确定每个待部署的无状态微服务子模块的根目录所在路径，并将相关文件夹处理为压缩文件，随后调用openwhisk无服务器计算平台的相关命令创建无服务器计算单元；创建成功后每个无服务器计算单元都有一个对应的URL，通过这个URL和有关参数即可触发对应的无服务器计算单元提供服务；在得到URL后，根据更新后的微服务子模块间的通信图，将原来所有微服务子模块中访问部署前微服务子模块的URL替换为部署后得到的无服务器计算单元的URL。

Images