CN110069276A - 一种面向开放动态互联网环境的微服务需求驱动方法 - Google Patents

Abstract

一种面向开放动态互联网环境的微服务需求驱动方法，包括以下步骤：第一步、应用程序将用户的需求转化为可以代表用户自动执行的一系列Web任务；第二步、给出RMAE框架所需的关键组件模块；第三步、给出RMAE整体架构及运作流程；第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征；第五步、面向用户需求，给出RMAE框架的路由委派方法；第六步、给出RMAE协作算法。本发明基于微服务技术架构，以用户需求为驱动，给出微服务架构下需求交互模型，用于支持运行时受需求和上下文影响的SAS系统的实现，进行实现面向用户需求驱动。

Description

一种面向开放动态互联网环境的微服务需求驱动方法

技术领域

本发明涉及软件演化领域，具体涉及一种面向开放动态互联网环境的微服务需求驱动方法。

背景技术

在开放动态的互联网环境下分布式软件系统呈现出发散、异构、多变等特征，为了适应快速变化的用户需求，Web应用需要以灵活、自适应的方式来有效理解和管理需求，进而构建可重用的软件单元以增强软件的演化能力。

随着互联网技术的不断发展，各类资源异构且组织机构分散的分布式Web应用系统已被广泛地应用在各个领域。构建成功的自适应Web应用需要以用户需求为驱动，并依赖于Web任务自动化的能力，以及基础架构和软件内部结构自发调整来支持变更的需求。

对于分布式系统，面向服务的架构(SOA)将称作“服务”的工作单元围绕一套明确定义的原则(标准契约、发现、松散耦合、自主性、可重用性、可执行性、无状态和抽象化等)构建系统功能。而微服务(Microservices)是SOA思想的扩展，微服务架构定义为采用一套小型服务构建单个应用，即每个服务都运行在自己的进程中，并通过轻量级机制(通常是HTTP Resource API)进行通信。这些服务是围绕业务功能构建的，并使用自动化部署工具独立发布。通过将系统分解成大量基于通信机制连接在一起的微服务，能提高应用程序弹性以及独立而有效的可扩展性，并且更快更容易地部署。目前，微服务架构被认为是解决分布式架构演化问题的有效方案。

发明内容

为了将个性化Web应用程序实现为自适应软件(Self-Adaptive Software,SAS)系统，本发明基于微服务技术架构，以用户需求为驱动，给出微服务架构下需求交互模型，进而设计出一种微服务应用自适应演化框架RMAE(Requirements-Driven MicroservicesAdaptive Evolution)，将用户需求，系统概念和上下文实体表示为维持因果连接并可以在系统运行时被操作的实体，并将Villegas提出的DYNAMICO参考模型引入RMAE框架，用于支持运行时受需求和上下文影响的SAS系统的实现，进行实现面向用户需求驱动的微服务演化方法。

为了解决上述技术问题本发明所采用的技术方案是：

一种面向开放动态互联网环境的微服务需求驱动方法，所述微服务需求驱动方法包括以下步骤：

第一步、在Web应用程序中，用户的需求和上下文决定了Web交互的决策和行为，为此，这些应用程序必须将用户的需求转化为可以代表用户自动执行的一系列Web任务，以提供更好的用户体验；

第二步、给出RMAE框架所需的关键组件模块；

第三步、基于第二步提出的RMAE框架组件模块，给出RMAE整体架构及运作流程；

第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征，该模型定义了三个因果连接的反馈回路子系统：控制目标反馈回路CO-FL、动态监控反馈回路M-FL和自适应反馈回路A-FL；

第五步、面向用户需求，进一步给出RMAE框架的路由委派方法；

第六步、基于前五步，给出RMAE协作算法，过程如下：

步骤(6.1)接收用户请求，程序执行器executor检索执行请求url，若结果为空，则结束，否则进行步骤(6.2)；

步骤(6.2)解析用户请求，获得请求参数profile，根据请求参数profile以及步骤(2.1)完成运行时模型构建(RDM模型和RCT模型)，进行步骤(6.3)；

步骤(6.3)基于第五步，结合RCT模型到内存池MemoryPool中获取对应的配置片段config，若配置片段config为空，则结束，否则进行步骤(6.4)；

步骤(6.4)遍历配置片段config的微服务，若遍历完成，则进行步骤(6.7)，否则取出下一个微服务Microservice_i，由调度设施前往微服务仓库选取匹配的微服务Microservice_i，进行步骤(6.5)；

步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservice_i，则将Microservice_i加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；

步骤(6.6)调用注册表更新XML配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；

步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。

进一步，所述第一步中，RMAE的实现需要SAS系统的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建微服务架构下需求交互模型，模型模块如下：

1.1用户需求解析：即系统必须能够将用户的需求转化为规范的需求描述信息；

1.2任务委派：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；

1.3微服务配置：通过XML配置文件描述微服务，并将用户需求与微服务进行映射；

1.4微服务组装：即系统必须定义满足用户需求所需微服务的有序序列，包括结构间关系，输入和输出规范；

1.5微服务执行：即系统必须能够在执行选定的微服务序列时，进行生命周期控制和自我修复管理活动；

1.6上下文感知和自适应支持：即系统必须能够通过感知上下文来发现用户需求变更，并做出相应的自适应调整。

再进一步，所述第二步的过程如下：

步骤(2.1)构建路由设施，以RCT模型的形式来表示用户需求，该模块中的组件主要执行从用户请求中解析出需求信息和运用RDM模型将需求转化为RCT模型实例这两个活动；

步骤(2.2)构建匹配树，该模块负责实例化RDF图中Web任务、用户需求与执行器之间的映射关系，并以一种树形结构进行存储，通过该结构，系统能够快速定位对应的执行器，提高任务委派效率；

一个匹配树T可表示为由其根节点和多个索引结构组成的二元组

T＝<v,{RS}>，

其中，v为根节点或虚拟节点，代表所有用户请求的起点；RS为索引结构，表示用户请求的资源路径u、执行方法m和转发目标s之间的对应关系.RS的数目与系统所提供的微服务数量有关；

匹配树的性质如下：

给定用户请求r，在T中，对于资源路径节点u，仅当用户请求r的路径u＇∈u时，访问u的所有子节点，并对于m∈RS，验证用户请求r的执行方法与m的匹配关系，其中用户请求r的执行方法与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE；

给定用户请求r，对于方法节点m，有且仅有一个子节点t符合条件；

给定匹配节点u的用户请求r，对于方法节点m，仅当用户请求r的执行方法m＇∈m时，访问m的唯一子节点t，进一步，根据子节点t的值跳转至对应转发目标s中；

进行步骤(2.3)；

步骤(2.3)采用XML文件描述微服务，XML是一种标记语言，该语言可被机器理解，同时又方便直观阅读；通过XML配置了微服务的功能及结构描述，这些微服务能够完成RCT模型中所述的Web任务，其配置项包括：微服务的名称、微服务的编号、微服务的功能描述说明、微服务输入/输出参数、微服务所属服务器IP信息，进行步骤(2.4)；

步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求，该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入XML配置文件中，并依据配置结果完成相应微服务的组装；在这一过程中，采用SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；

步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

优选的，所述步骤(2.1)中，基于第一步的需求交互模型，面向需求驱动，明确软件运行时模型建模需求，进而给出需求驱动的微服务本体模型和面向用户需求的上下文感知Web任务模型的建模方法，过程如下：

步骤(2.1.1)构建RDM本体模型，其是定义基于微服务的Web交互概念的基本模型和本体，这些概念包括：

用户需求：用户服务需求的表示，可以被转化为Web任务,也可被表示为服务输出；

API网关：负责拦截Web任务的请求，执行过滤、验证相关操作；

Web任务：用户需求解析而成的各Web服务单元；

微服务序列：微服务序列是由若干微服务按序组合而成,Web任务请求也需通过微服务序列的按序执行实现，执行过程受用户上下文规约；

微服务：微服务是微服务序列的基本单元，它包含相关用户上下文信息，并与服务资源保持连接；同时，注册表的相关注册信息也有登记在微服务的描述信息中，保证了不同微服务之间的相互调用；

注册表：注册表记录了各微服务的运行状态、所在服务器的IP地址信息；

活动：活动通过微服务的执行，接收服务输入，并产生相关的服务输出；

资源：服务执行所需的相关软硬件支持，服务的输入有时也需要获取资源作为输入的一部分；

输入：服务执行所需的输入参数及资源条件；

输出：服务执行后产生的输出结果；

用户上下文：表示服务执行过程中的执行环境，包含相关数据、规约信息；

RDM本体可以作为RD文件形式的运行时模型，并且可以根据用户需求演化来扩展，其中RDF即资源描述框架，其本质是一个数据模型，它提供了一个统一的标准，用于描述实体/资源，进行步骤(2.1.2)；

步骤(2.1.2)构建RCT模型，RCT模型是本发明对多伦多大学Eric YU教授等人提出的iStar框架的扩展和重定义，iStar框架在策略依赖模型中定义了四种依赖关系，分别是：目标依赖，表示一个角色依赖另一个角色来完成某一个目标；资源依赖，表示一个角色依赖另一个角色为它提供物理资源和信息；任务依赖，表示一个角色依赖另一个角色来完成某个任务；非功能需求有关的软目标依赖，类似于目标依赖，扩展了iStar的角色、目标、任务和资源的原子概念，以支持用户需求、Web任务、微服务以及微服务序列之间的映射关系和相关描述规范，RCT模型将以RDF图的形式进行实例化，进行步骤(2.2)。

所述第三步的过程如下：

步骤(3.1)构建需求层，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在，在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施将最终结果返回给需求层用户，并完成本次用户请求，进行步骤(3.2)；

步骤(3.2)构建处理中枢层，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障；在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施根据用户需求，把用户需求转换为RDF图，搜索匹配树，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施进行加载，当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施发起调度请求；

若匹配树中查找结果为空，将用户需求转换的RDF图通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施发起调度请求；

最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有XML配置与注册表，并实时将配置信息缓存到内存池中，通过心跳模式与其他服务器维持长连接；

进行步骤(3.3)；

步骤(3.3)构建微服务层，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成；在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库中的微服务及相关资源，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址；组装完毕的微服务序列将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕；期间，监控设施将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

所述第四步中，控制目标反馈回路CO-FL、动态监控反馈回路M-FL和自适应反馈回路A-FL之间的作用关系是：

CO-FL负责接收外界的变化信息，以此触发M-FL或A-FL；

M-FL负责感测上下文信息(Context Information)、A-FL与CO-FL反馈信息，并将感测信息反馈至CO-FL或A-FL；

A-FL：负责接收CO-FL与M-FL的触发信息，并将自身反馈信息发送至M-FL；

将CO-FL、M-FL和A-FL分别映射到路由委派、监控执行和微服务调度过程中，进而满足变更的用户需求，其中，CO-FL对应于负责接收用户需求的路由委派过程；该层跟踪用户需求的变化，以触发微服务调度或监控执行的适配，路由委派的主要目标是解析用户请求，对Web任务进行委派，确保RMAE能精确处理不断演化的用户需求；M-FL对应监控执行过程，它由协作单元和运行单元共同完成，协作单元负责各单元间的协同；运行单元在执行微服务序列的过程中，时刻受到监控，监控设施会将反馈信息实时动态更新；微服务调度的基础设施由查询单元、装配单元和通知单元组成，对应于A-FL；收到调度请求后，调度设施通过查询单元匹配内存池中的微服务描述信息，装配单元根据已有描述信息，前往微服务仓库进行匹配并动态组装微服务序列，若配置的微服务未能成功匹配，则通知单元将请求注册表更新对应的微服务信息。

所述第五步的过程如下：

步骤(5.1)利用步骤(2.2)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将XML配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与XML配置文件的映射关系定义如下：

elements＝{element₁,element₂,element₃,…,element_n}；

对于所有element的属性URI，有且仅有一个节点u与URI对应；

对于所有element元素的属性method，有且仅有一个节点m与method对应，且m为u的子节点，u对应的URI和m对应的method为同一个element的属性；

对于所有element元素的属性key，有且仅有一个节点t与key对应，且t为m的子节点，m对应的method和t对应的key为同一个element的属性；

tag为当前配置片段所对应的路由，即微服务序列的首个执行器；

进行步骤(5.2)；

步骤(5.2)路由设施的解析单元根据接收到的Web请求，基于步骤(2.1)解析出有效的用户需求，并运用RDM模型将其转换为相应的RCT模型实现，得出相应的RDF图，进行步骤(5.3)；

步骤(5.3)基于步骤(5.1)预加载的匹配树结构，路由设施的转发单元将RDF图中的Web任务委派给相应的执行器，完成路由委派过程。

本发明的有益效果是：以用户需求为驱动，提出了一种需求驱动的微服务应用自适应演化框架RMAE，同时设计了软件运行时建模方法，包括需求驱动的微服务(RDM)本体模型和面向用户需求的上下文感知Web任务(RCT)模型，用以支撑框架的自适应特性。通过本发明方法，可以便捷、高效的将个性化Web应用程序实现为自适应软件SAS。

附图说明

图1示出了微服务架构下需求交互模型概念图。

图2示出了RDM本体模型图。

图3示出了RCT模型图。

图4示出了RMAE架构图。

图5示出了上下文驱动的自适应软件系统参考模型DYNAMICO。

具体实施方式

下面结合附图对本发明作进一步描述。

参照图1～图5，一种面向开放动态互联网环境的微服务需求驱动方法，所述微服务需求驱动方法包括以下步骤：

第一步、在Web应用程序中，用户的需求和上下文决定了Web交互的决策和行为，为此，这些应用程序必须将用户的需求转化为可以代表用户自动执行的一系列Web任务，以提供更好的用户体验；

RMAE的实现需要SAS系统的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建如图1所示的微服务架构下需求交互模型，模型模块如下：

1.1用户需求解析(User Requirement Parsing)：即系统必须能够将用户的需求转化为规范的需求描述信息；

1.2任务委派(Task Delegation)：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；

1.3微服务配置(Microservice Configuration)：通过XML配置文件描述微服务，并将用户需求与微服务进行映射；

1.4微服务组装(Microservice Assembly)：即系统必须定义满足用户需求所需微服务的有序序列，包括结构间关系，输入和输出规范；

1.5微服务执行(Microservice Execution)：即系统必须能够在执行选定的微服务序列时，进行生命周期控制、自我修复等管理活动；

1.6上下文感知和自适应支持(Context Awareness and Self-AdaptionSupport)：即系统必须能够通过感知上下文来发现用户需求变更，并做出相应的自适应调整；

第二步、给出RMAE框架所需的关键组件模块，过程如下：

步骤(2.1)构建路由设施，以RCT模型的形式来表示用户需求，该模块中的组件主要执行从用户请求中解析出需求信息和运用RDM模型将需求转化为RCT模型实例这两个活动，流程如下：

基于第一步的需求交互模型，面向需求驱动，明确软件运行时模型建模需求，进而给出需求驱动的微服务(Requirements-Driven Microservices,RDM)本体模型和面向用户需求的上下文感知Web任务(Requirements-Oriented Context-Sensitive Tasking,RCT)模型的建模方法，过程如下：

步骤(2.1.1)结合图2，构建RDM本体模型，其是定义基于微服务的Web交互概念的基本模型和本体，这些概念包括：

用户需求(User Requirements)：用户服务需求的表示，可以被转化(transform)为Web任务,也可被表示(representedBy)为服务输出；

API网关(API Gateway)：负责拦截Web任务的请求(request),执行过滤、验证等相关操作；

Web任务(Web Tasks)：用户需求解析而成的各Web服务单元；

微服务序列(Microservices Sequence)：微服务序列是由(builtBy)若干微服务按序组合而成,Web任务请求也需通过(achieveThrough)微服务序列的按序执行实现，执行过程受用户上下文规约(executionPolicies)；

微服务(Microservices)：微服务是微服务序列的基本单元，它包含(contains)相关用户上下文信息，并与(connectsTo)服务资源保持连接。同时，注册表的相关注册信息也有登记(registers)在微服务的描述信息中，保证了不同微服务之间的相互调用(invokes)；

注册表(Registry)：注册表记录了各微服务的运行状态、所在服务器的IP地址等信息；

活动(Activity)：活动通过微服务的执行(performs)，接收(hasParameters)服务输入，并产生(hasResult)相关的服务输出；

资源(Resources)：服务执行所需的相关软硬件支持，服务的输入有时也需要获取(obtained)资源作为输入的一部分；

输入(Input)：服务执行所需的输入参数及资源条件；

输出(Output)：服务执行后产生的输出结果；

用户上下文(User Context)：表示服务执行过程中的执行环境，包含相关数据、规约等信息；

RDM本体可以作为RDF(Resource Description Framework)文件形式的运行时模型，并且可以根据用户需求演化来扩展，其中RDF即资源描述框架，其本质是一个数据模型，它提供了一个统一的标准，用于描述实体/资源，进行步骤(2.1.2)；

步骤(2.1.2)构建RCT模型，RCT模型是本发明对多伦多大学Eric YU教授等人提出的iStar框架的扩展和重定义，iStar框架在策略依赖模型中定义了四种依赖关系，分别是：目标依赖，表示一个角色依赖另一个角色来完成某一个目标；资源依赖，表示一个角色依赖另一个角色为它提供物理资源和信息；任务依赖，表示一个角色依赖另一个角色来完成某个任务；非功能需求有关的软目标依赖，类似于目标依赖。特别地，本发明扩展了iStar的角色、目标、任务和资源的原子概念，以支持用户需求、Web任务、微服务以及微服务序列之间的映射关系和相关描述规范，RCT模型将以RDF图的形式进行实例化。图3是本发明给出的RCT模型图，椭圆形节点表示用户需求(RCT需求节点)，六边形节点表示Web子任务，六边形节点左上方的井号表示Web子任务序号，圆形表示服务，矩形表示信息资源，进行步骤(2.2)；

步骤(2.2)构建匹配树(Mapping Tree)，该模块负责实例化RDF图中Web任务、用户需求与执行器之间的映射关系，并以一种树形结构进行存储，通过该结构，系统能够快速定位对应的执行器，提高任务委派效率；

一个匹配树T可表示为由其根节点和多个索引结构组成的二元组

T＝<v,{RS}>，

其中，v为根节点(虚拟节点)，代表所有用户请求的起点；RS为索引结构，表示用户请求的资源路径u、执行方法m和转发目标s之间的对应关系.RS的数目与系统所提供的微服务数量有关。

匹配树的性质如下：

给定用户请求r，在T中，对于资源路径节点u，仅当用户请求r的路径u＇∈u时，访问u的所有子节点，并对于m∈RS，验证用户请求r的执行方法与m的匹配关系，其中用户请求r的执行方法与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE；

给定用户请求r，对于方法节点m，有且仅有一个子节点t符合条件；

给定匹配节点u的用户请求r，对于方法节点m，仅当用户请求r的执行方法m＇∈m时，访问m的唯一子节点t，进一步，根据子节点t的值跳转至对应转发目标s中；

进行步骤(2.3)；

步骤(2.3)采用XML文件描述微服务，XML是一种标记语言，该语言可被机器理解，同时又方便直观阅读。通过XML配置了微服务的功能及结构描述，这些微服务能够完成RCT模型中所述的Web任务，其配置项包括：微服务的名称、微服务的编号、微服务的功能描述说明、微服务输入/输出参数、微服务所属服务器IP信息，进行步骤(2.4)；

步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求。该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入XML配置文件中，并依据配置结果完成相应微服务的组装。在这一过程中，本发明采用Villegas Machado等人提出的SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；

步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

第三步、基于第二步提出的RMAE框架组件模块，并结合图4给出RMAE整体架构及运作流程，过程如下：

步骤(3.1)构建需求层(Requirements Layer)，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在。在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施(Routing Facility)接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施(Execution Facility)将最终结果返回给需求层用户，并完成本次用户请求。进行步骤(3.2)；

步骤(3.2)构建处理中枢层(Processing Layer)，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障。在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施(RoutingFacility)根据用户需求，把用户需求转换为RDF图(RDFGraph)，搜索匹配树(MappingTree)，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施(ExecutionFacility)进行加载。当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施(Scheduling Facility)发起调度请求。

若匹配树中查找结果为空，将用户需求转换的RDF图(RDF Graph)通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施(Scheduling Facility)发起调度请求。

最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有XML配置(XML Configuration)与注册表，并实时将配置信息缓存到内存池(Memory Pool)中，通过心跳模式与其他服务器维持长连接。进行步骤(3.3)；

步骤(3.3)构建微服务层(Microservices Layer)，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成。在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库(MicroservicesRepository)中的微服务(Microservice)及相关资源(Resources)，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表(Registry)中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址。组装完毕的微服务序列(Microservices Sequence)将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕。期间，监控设施(Monitor Facility)将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征，该模型定义了如图5所示的三个因果连接的反馈回路子系统：控制目标反馈回路(CO-FL)、动态监控反馈回路(M-FL)和自适应反馈回路(A-FL)。三者间的主要作用关系是：

CO-FL主要负责接收外界的变化信息，以此触发M-FL或A-FL(如图5箭头A)；

M-FL主要负责感测上下文信息(Context Information)、A-FL与CO-FL反馈信息，并将感测信息反馈至CO-FL或A-FL(如图5箭头B、箭头C)；

A-FL：负责接收CO-FL与M-FL的触发信息，并将自身反馈信息发送至M-FL(如图5箭头D)。

将CO-FL、M-FL和A-FL分别映射到路由委派、监控执行和微服务调度过程中，进而满足变更的用户需求。其中，CO-FL对应于负责接收用户需求的路由委派过程。该层跟踪用户需求的变化，以触发微服务调度或监控执行的适配。路由委派的主要目标是解析用户请求，对Web任务进行委派，确保RMAE能精确处理不断演化的用户需求；M-FL对应监控执行过程，它由协作单元和运行单元共同完成，协作单元负责各单元间的协同。运行单元在执行微服务序列的过程中，时刻受到监控，监控设施会将反馈信息实时动态更新；微服务调度的基础设施由查询单元、装配单元和通知单元组成，对应于A-FL。收到调度请求后，调度设施通过查询单元匹配内存池中的微服务描述信息(包括功能及结构).装配单元根据已有描述信息，前往微服务仓库进行匹配并动态组装微服务序列，若配置的微服务未能成功匹配，则通知单元将请求注册表更新对应的微服务信息。

第五步、面向用户需求，进一步给出RMAE框架的路由委派方法，过程如下：

步骤(5.1)利用步骤(2.2)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将XML配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与XML配置文件的映射关系定义如下：

elements＝{element₁,element₂,element₃,…,element_n}；

对于所有element的属性URI，有且仅有一个节点u与URI对应；

对于所有element元素的属性method，有且仅有一个节点m与method对应，且m为u的子节点，u对应的URI和m对应的method为同一个element的属性；

对于所有element元素的属性key，有且仅有一个节点t与key对应，且t为m的子节点，m对应的method和t对应的key为同一个element的属性；

tag为当前配置片段所对应的路由，即微服务序列的首个执行器；

进行步骤(5.2)；

步骤(5.2)路由设施的解析单元根据接收到的Web请求，基于步骤(2.1)解析出有效的用户需求，并运用RDM模型将其转换为相应的RCT模型实现，得出相应的RDF图，进行步骤(5.3)；

步骤(5.3)基于步骤(5.1)预加载的匹配树结构，路由设施的转发单元将RDF图中的Web任务委派给相应的执行器，完成路由委派过程。

第六步、基于前五步，给出RMAE协作算法，过程如下：

步骤(6.1)接收用户请求，程序执行器executor检索执行请求url，若结果为空，则结束，否则进行步骤(6.2)；

步骤(6.2)解析用户请求，获得请求参数profile，根据请求参数profile以及步骤(2.1)完成运行时模型构建(RDM模型和RCT模型)，进行步骤(6.3)；

步骤(6.3)基于第五步，结合RCT模型到内存池MemoryPool中获取对应的配置片段config，若配置片段config为空，则结束，否则进行步骤(6.4)；

步骤(6.4)遍历配置片段config的微服务，若遍历完成，则进行步骤(6.7)，否则取出下一个微服务Microservice_i，由调度设施前往微服务仓库选取匹配的微服务Microservice_i，进行步骤(6.5)；

步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservice_i，则将Microservice_i加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；

步骤(6.6)调用注册表更新XML配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；

步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。

Claims (7)

1.一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述微服务需求驱动方法包括以下步骤：

第一步、在Web应用程序中，用户的需求和上下文决定了Web交互的决策和行为，为此，这些应用程序必须将用户的需求转化为可以代表用户自动执行的一系列Web任务，以提供更好的用户体验；

第二步、给出RMAE框架所需的关键组件模块；

第三步、基于第二步提出的RMAE框架组件模块，给出RMAE整体架构及运作流程；

第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征，该模型定义了三个因果连接的反馈回路子系统：控制目标反馈回路CO-FL、动态监控反馈回路M-FL和自适应反馈回路A-FL；

第五步、面向用户需求，进一步给出RMAE框架的路由委派方法；

第六步、基于前五步，给出RMAE协作算法，过程如下：

步骤(6.1)接收用户请求，程序执行器executor检索执行请求url，若结果为空，则结束，否则进行步骤(6.2)；

步骤(6.2)解析用户请求，获得请求参数profile，根据请求参数profile以及步骤(2.1)完成运行时模型构建(RDM模型和RCT模型)，进行步骤(6.3)；

步骤(6.3)基于第五步，结合RCT模型到内存池MemoryPool中获取对应的配置片段config，若配置片段config为空，则结束，否则进行步骤(6.4)；

步骤(6.4)遍历配置片段config的微服务，若遍历完成，则进行步骤(6.7)，否则取出下一个微服务Microservice_i，由调度设施前往微服务仓库选取匹配的微服务Microservice_i，进行步骤(6.5)；

步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservice_i，则将Microservice_i加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；

步骤(6.6)调用注册表更新XML配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；

步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。

2.如权利要求1所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述第一步中，RMAE的实现需要SAS系统的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建微服务架构下需求交互模型，模型模块如下：

1.1用户需求解析：即系统必须能够将用户的需求转化为规范的需求描述信息；

1.2任务委派：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；

1.3微服务配置：通过XML配置文件描述微服务，并将用户需求与微服务进行映射；

1.4微服务组装：即系统必须定义满足用户需求所需微服务的有序序列，包括结构间关系，输入和输出规范；

1.5微服务执行：即系统必须能够在执行选定的微服务序列时，进行生命周期控制和自我修复管理活动；

1.6上下文感知和自适应支持：即系统必须能够通过感知上下文来发现用户需求变更，并做出相应的自适应调整。

3.如权利要求1或2所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述第二步的过程如下：

步骤(2.1)构建路由设施，以RCT模型的形式来表示用户需求，该模块中的组件主要执行从用户请求中解析出需求信息和运用RDM模型将需求转化为RCT模型实例这两个活动；

步骤(2.2)构建匹配树，该模块负责实例化RDF图中Web任务、用户需求与执行器之间的映射关系，并以一种树形结构进行存储，通过该结构，系统能够快速定位对应的执行器，提高任务委派效率；

一个匹配树T可表示为由其根节点和多个索引结构组成的二元组

T＝<v,{RS}>，

其中，v为根节点或虚拟节点，代表所有用户请求的起点；RS为索引结构，表示用户请求的资源路径u、执行方法m和转发目标s之间的对应关系.RS的数目与系统所提供的微服务数量有关；

匹配树的性质如下：

给定用户请求r，在T中，对于资源路径节点u，仅当用户请求r的路径u＇∈u时，访问u的所有子节点，并对于m∈RS，验证用户请求r的执行方法与m的匹配关系，其中用户请求r的执行方法与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE；

给定用户请求r，对于方法节点m，有且仅有一个子节点t符合条件；

给定匹配节点u的用户请求r，对于方法节点m，仅当用户请求r的执行方法m＇∈m时，访问m的唯一子节点t，进一步，根据子节点t的值跳转至对应转发目标s中；

进行步骤(2.3)；

步骤(2.3)采用XML文件描述微服务，XML是一种标记语言，该语言可被机器理解，同时又方便直观阅读；通过XML配置了微服务的功能及结构描述，这些微服务能够完成RCT模型中所述的Web任务，其配置项包括：微服务的名称、微服务的编号、微服务的功能描述说明、微服务输入/输出参数、微服务所属服务器IP信息，进行步骤(2.4)；

步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求，该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入XML配置文件中，并依据配置结果完成相应微服务的组装；在这一过程中，采用SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；

步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

4.如权利要求3所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述步骤(2.1)中，基于第一步的需求交互模型，面向需求驱动，明确软件运行时模型建模需求，进而给出需求驱动的微服务本体模型和面向用户需求的上下文感知Web任务模型的建模方法，过程如下：

步骤(2.1.1)构建RDM本体模型，其是定义基于微服务的Web交互概念的基本模型和本体，这些概念包括：

用户需求：用户服务需求的表示，可以被转化为Web任务,也可被表示为服务输出；

API网关：负责拦截Web任务的请求，执行过滤、验证相关操作；

Web任务：用户需求解析而成的各Web服务单元；

微服务序列：微服务序列是由若干微服务按序组合而成,Web任务请求也需通过微服务序列的按序执行实现，执行过程受用户上下文规约；

微服务：微服务是微服务序列的基本单元，它包含相关用户上下文信息，并与服务资源保持连接；同时，注册表的相关注册信息也有登记在微服务的描述信息中，保证了不同微服务之间的相互调用；

注册表：注册表记录了各微服务的运行状态、所在服务器的IP地址信息；

活动：活动通过微服务的执行，接收服务输入，并产生相关的服务输出；

资源：服务执行所需的相关软硬件支持，服务的输入有时也需要获取资源作为输入的一部分；

输入：服务执行所需的输入参数及资源条件；

输出：服务执行后产生的输出结果；

用户上下文：表示服务执行过程中的执行环境，包含相关数据、规约信息；

RDM本体可以作为RD文件形式的运行时模型，并且可以根据用户需求演化来扩展，其中RDF即资源描述框架，其本质是一个数据模型，它提供了一个统一的标准，用于描述实体/资源，进行步骤(2.1.2)；

步骤(2.1.2)构建RCT模型，iStar框架在策略依赖模型中定义了四种依赖关系，分别是：目标依赖，表示一个角色依赖另一个角色来完成某一个目标；资源依赖，表示一个角色依赖另一个角色为它提供物理资源和信息；任务依赖，表示一个角色依赖另一个角色来完成某个任务；非功能需求有关的软目标依赖，类似于目标依赖，扩展了iStar的角色、目标、任务和资源的原子概念，以支持用户需求、Web任务、微服务以及微服务序列之间的映射关系和相关描述规范，RCT模型将以RDF图的形式进行实例化，进行步骤(2.2)。

5.如权利要求1或2所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述第三步的过程如下：

步骤(3.1)构建需求层，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在，在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施将最终结果返回给需求层用户，并完成本次用户请求，进行步骤(3.2)；

步骤(3.2)构建处理中枢层，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障；在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施根据用户需求，把用户需求转换为RDF图，搜索匹配树，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施进行加载，当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施发起调度请求；

若匹配树中查找结果为空，将用户需求转换的RDF图通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施发起调度请求；

最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有XML配置与注册表，并实时将配置信息缓存到内存池中，通过心跳模式与其他服务器维持长连接；

进行步骤(3.3)；

步骤(3.3)构建微服务层，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成；在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库中的微服务及相关资源，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址；组装完毕的微服务序列将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕；期间，监控设施将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。

6.如权利要求1或2所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述第四步中，控制目标反馈回路CO-FL、动态监控反馈回路M-FL和自适应反馈回路A-FL之间的作用关系是：

CO-FL负责接收外界的变化信息，以此触发M-FL或A-FL；

M-FL负责感测上下文信息(Context Information)、A-FL与CO-FL反馈信息，并将感测信息反馈至CO-FL或A-FL；

A-FL：负责接收CO-FL与M-FL的触发信息，并将自身反馈信息发送至M-FL；

将CO-FL、M-FL和A-FL分别映射到路由委派、监控执行和微服务调度过程中，进而满足变更的用户需求，其中，CO-FL对应于负责接收用户需求的路由委派过程；该层跟踪用户需求的变化，以触发微服务调度或监控执行的适配，路由委派的主要目标是解析用户请求，对Web任务进行委派，确保RMAE能精确处理不断演化的用户需求；M-FL对应监控执行过程，它由协作单元和运行单元共同完成，协作单元负责各单元间的协同；运行单元在执行微服务序列的过程中，时刻受到监控，监控设施会将反馈信息实时动态更新；微服务调度的基础设施由查询单元、装配单元和通知单元组成，对应于A-FL；收到调度请求后，调度设施通过查询单元匹配内存池中的微服务描述信息，装配单元根据已有描述信息，前往微服务仓库进行匹配并动态组装微服务序列，若配置的微服务未能成功匹配，则通知单元将请求注册表更新对应的微服务信息。

7.如权利要求1或2所述的一种面向开放动态互联网环境的微服务需求驱动方法，其特征在于，所述第五步的过程如下：

步骤(5.1)利用步骤(2.2)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将XML配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与XML配置文件的映射关系定义如下：

elements＝{element₁,element₂,element₃,…,element_n}；

对于所有element的属性URI，有且仅有一个节点u与URI对应；

对于所有element元素的属性method，有且仅有一个节点m与method对应，且m为u的子节点，u对应的URI和m对应的method为同一个element的属性；

对于所有element元素的属性key，有且仅有一个节点t与key对应，且t为m的子节点，m对应的method和t对应的key为同一个element的属性；

tag为当前配置片段所对应的路由，即微服务序列的首个执行器；

进行步骤(5.2)；

步骤(5.2)路由设施的解析单元根据接收到的Web请求，基于步骤(2.1)解析出有效的用户需求，并运用RDM模型将其转换为相应的RCT模型实现，得出相应的RDF图，进行步骤(5.3)；

步骤(5.3)基于步骤(5.1)预加载的匹配树结构，路由设施的转发单元将RDF图中的Web任务委派给相应的执行器，完成路由委派过程。