CN110083350B - 一种云计算环境下基于rmae的微服务自适应演化方法 - Google Patents

一种云计算环境下基于rmae的微服务自适应演化方法 Download PDF

Info

Publication number
CN110083350B
CN110083350B CN201910210739.8A CN201910210739A CN110083350B CN 110083350 B CN110083350 B CN 110083350B CN 201910210739 A CN201910210739 A CN 201910210739A CN 110083350 B CN110083350 B CN 110083350B
Authority
CN
China
Prior art keywords
micro
service
user
rmae
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910210739.8A
Other languages
English (en)
Other versions
CN110083350A (zh
Inventor
陆佳炜
吴涵
卢成炳
高燕煦
徐俊
程振波
肖刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang University of Technology ZJUT
Original Assignee
Zhejiang University of Technology ZJUT
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang University of Technology ZJUT filed Critical Zhejiang University of Technology ZJUT
Priority to CN201910210739.8A priority Critical patent/CN110083350B/zh
Publication of CN110083350A publication Critical patent/CN110083350A/zh
Application granted granted Critical
Publication of CN110083350B publication Critical patent/CN110083350B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

一种云计算环境下基于RMAE的微服务自适应演化方法，包括以下步骤：第一步、构建微服务架构下需求交互模型；第二步、给出RMAE框架所需的关键组件模块，特别设计了用于描述微服务的RMAE language，支持系统自适应理解用户需求；第三步、给出RMAE整体架构及运作流程；第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征；第五步、面向用户需求，进一步给出RMAE框架的路由委派方法；第六步、基于前五步，给出RMAE协作算法。本发明提高软件系统的自适应演化能力，满足动态多样化的用户需求。

Description

一种云计算环境下基于RMAE的微服务自适应演化方法
技术领域
本发明涉及软件演化领域，具体涉及云计算环境下一种基于RMAE的微服务自适应演化方法。
背景技术
软件演化是指软件持续变化，并达到人们期望形态的过程，近几十年来一直是学术界和工业界研究的重点。早期软件演化研究多关注于静态演化，然而许多重要领域的关键系统无法以停止、更新或重启等静态方式实现演化，因此需要从自适应角度进行研究，使得系统能够自适应地调节自身行为来实现动态演化。
随着互联网技术的不断发展，越来越多的分布式软件系统选择部署在云计算平台上，并通过网络对外提供服务。而云计算环境的多变性、动态性和开放性也给分布式软件系统的自适应演化增添了不少难度。
近年来，已有不少研究学者针对此类演化问题提出相应的解决方案。李青山等人提出一种基于智能体技术的软件自适应动态演化机制，通过将软件单元封装为Agent，并定义单元间的演化规则，使演化机制重用原有软件单元；焦文品等人提出了一种基于经验交流的自适应机制，通过Agent动态引发环境约束和行为模式，以从其他Agent交换的经验中产生新的适应策略；Haithem Mezni等人提出了一种基于本体的自主服务元数据分类策略用于Web服务的自适应组合；O’Connor等人提出一种情境因素参考框架，该框架基于微服务架构，关注上下文情境在软件过程定义和演化中的作用，适用于连续软件开发和交付的组织；
James Lewis等人指出，微服务架构被认为是解决分布式架构演化问题的有效方案。微服务架构定义为采用一套小型服务构建单个应用，即每个服务都运行在自己的进程中，并通过轻量级机制(通常是HTTP Resource API)进行通信。这些服务是围绕业务功能构建的，并使用自动化部署工具独立发布。通过将系统分解成大量基于通信机制连接在一起的微服务，能提高应用程序弹性以及独立而有效的可扩展性，并且更快更容易地部署。
发明内容
为了应对微服务环境下Web应用所面临的自适应演化问题，本发明提出一种微服务应用自适应演化框架RMAE(Requirements-Driven Microservices AdaptiveEvolution)，该框架面向云计算环境的需求驱动，能够确定实现高度自适应系统所需的核心组件，并在运行时有效控制和实现这些组件之间的相互作用。此外，本发明还为RMAE框架专门设计了RMAE language，用于描述基于RMAE的用户需求转换规则，使系统能够自适应进行动态演化，进而满足动态多样化的用户需求。
为了解决上述技术问题本发明所采用的技术方案是：
一种云计算环境下基于RMAE的微服务自适应演化方法，所述微服务自适应演化方法包括以下步骤：
第一步、在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)，否则取出下一个微服务Microservicei，由调度设施前往微服务仓库选取匹配的微服务Microservicei，进行步骤(6.5)；
步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservicei，则将Microservicei加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；
步骤(6.6)调用注册表更新RMAE language配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；
步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。
进一步，所述第一步中，RMAE的实现需要自适应软件(SAS)系统的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建微服务架构下需求交互模型，模型模块如下：
1.1用户需求解析(User Requirement Parsing)：即系统必须能够将用户的需求转化为规范的需求描述信息；
1.2任务委派(Task Delegation)：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；
1.3微服务配置(Microservice Configuration)：通过RMAE language配置文件描述微服务，并将用户需求与微服务进行映射；
1.4微服务组装(Microservice Assembly)：即系统必须定义满足用户需求所需微服务的有序序列，包括结构间关系，输入和输出规范；
1.5微服务执行(Microservice Execution)：即系统必须能够在执行选定的微服务序列时，进行生命周期控制、自我修复等管理活动；
1.6上下文感知和自适应支持(Context Awareness and Self-AdaptionSupport)：即系统必须能够通过感知上下文来发现用户需求变更，并做出相应的自适应调整；
再进一步，所述第二步的过程如下：
步骤(2.1)构建路由设施，以RCT模型的形式来表示用户需求，该模块中的组件主要执行从用户请求中解析出需求信息和运用RDM模型将需求转化为RCT模型实例这两个活动；
步骤(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)采用RMAE language文件描述微服务，RMAE language描述的是一种基于RMAE的用户需求转换规则，选择XML文件作为RMAE language的载体，XML是一种标记语言，它的结构使其能具有良好的扩展性，便于直观阅读，也更利于RMAE体现出动态适应性；
基于RMAE language，本发明把每个功能点的个性化需求映射到各个微服务的功能描述上，较大粒度的用户需求通过微服务间相互组合的结构关系映射出来。RMAElanguage把用户需求归为数据浏览(browse)、数据删除(delete)、数据增加(insert)、数据更新(update)、数据导入(import)、数据导出(export)和其他业务逻辑(other)这7个主要组成部分，并映射到相应的XML载体中，RMAE language的核心结构定义如下：
element元素代表一组微服务，一个微服务序列包含多组微服务，即多个element元素构成一个微服务序列。element元素使用半形式化方法来描述：
element＝elementAttr,[ms]
elementAttr＝mappingAttr,(description),nextMS
mappingAttr＝key,URI,method
nextMS＝(nextTag),(nextKey)
method＝‘GET’|‘POST’|‘PUT’|‘PATCH’|‘DELETE’
nextTag＝‘browse’|‘delete’|‘insert’|‘update’|‘import’|‘export’|‘other’
其中，element元素由element属性elementAttr与若干微服务ms构成，elementAttr包括映射属性mappingAttr、该组微服务的描述信description与微服务序列中的下一个微服务nextMS，mappingAttr中的子属性URI、method、key分别映射为匹配树中的u、m、t节点，nextMS中的子属性nextTag与nextKey则分别表示微服务序列中下一个微服务所对应的执行器和RMAE language配置，nextTag中browse、delete、insert、update、import、export、other七种值代表用户需求对微服务七种操作逻辑的映射，属性method与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE。
同一element下的ms为同类微服务，其先后顺序决定了微服务执行的次序，ms元素半形式化方法描述如下：
ms＝msAttr,{param},view
msAttr＝type,value,(description)
view＝{title},{output}
type＝‘class’|‘service’|‘sql’
其中，微服务ms由微服务属性msAttr、输入参数param以及返回给用户的可视化参数view组成，view包括标题title与输出参数output，msAttr包含微服务的描述信息description和子属性type、value，属性type表明了微服务的实现方式，若值为class表示通过反射机制执行对应本地程序类，属性value为执行类的名称；若值为service则表示调用外部服务来完成，属性value为该服务的调用接口；当值为sql时则表示对关系型数据库的动态执行，相应地，属性value为执行所需SQL语句，RMAE能提供对关系型数据库数据处理自动化的支持，包括SQL语句的参数注入、动态执行、返回对象自动封装及服务化等功能。
param元素代表微服务执行所需要的输入参数，这部分使用半形式化方法描述如下：
param＝(notNull),scope
notNull＝TRUE|FALSE
scope＝(request),(session),(application)
session＝TRUE|FALSE
request＝TRUE|FALSE
application＝TRUE|FALSE
其中，param由属性notNull和scope组成，notNull表示param是否允许为空，scope代表请求作用域范围，其内部包含三个布尔型子属性request、session与application，它们分别表示请求作用域是否为request、session与application；
进行步骤(2.4)；
步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求，该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入RMAE language配置文件中，并依据配置结果完成相应微服务的组装。在这一过程中，本发明采用Villegas Machado等人提出的SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；
步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
所述步骤2.1的流程如下：基于第一步的需求交互模型，面向需求驱动，明确软件运行时模型建模需求，进而给出需求驱动的微服务(Requirements-DrivenMicroservices,RDM)本体模型和面向用户需求的上下文感知Web任务(Requirements-Oriented Context-Sensitive Tasking,RCT)模型的建模方法，过程如下：
步骤(2.1.1)构建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图的形式进行实例化，进行步骤(2.2)。
所述步骤2.4的过程如下：
步骤(2.4.1)结合第一步，将微服务架构下需求交互模型的主要概念抽象为需求解析层rLayer、任务委派层tLayer、微服务组装层mLayer和微服务配置层wLayer，分别包含用户需求、Web任务、微服务和RMAE language四种元素，各层间映射关系如下：
rLayer-tLayer(多对多)：需求解析层的每个用户需求为一次独立的用户请求，一个用户需求由多个Web任务协作完成，而每个Web任务又能参与满足多个用户需求；
tLayer-mLayer(一对一)：每个Web任务由单个微服务完成，单个微服务也仅能完成一个Web任务；
mLayer-wLayer(一对一)：每个微服务都对应唯一的一个RMAE language配置片段；
进行步骤(2.4.2)；
步骤(2.4.2)结合步骤(2.1)，路由设施通过处理RDM模型将用户需求转化为RCT模型，并生成(Generate)RDF图，该图由多个Web任务构成(Constitute)，可满足特定的用户需求，进行步骤(2.4.3)；
步骤(2.4.3)，采用SmartContext推理引擎将RDF图进行推理，并根据推理得出的Web任务序列将结果值注入(Inject)到RMAE language的nextTag(序列中下一个微服务所对应的执行器)和nextKey(序列中下一个微服务所对应的RMAE language配置)属性中，进行步骤(2.4.4)；
步骤(2.4.4)根据步骤(2.4.3)更新后的RMAE language配置进行微服务序列的组装与调度。
所述第三步的过程如下：
步骤(3.1)构建需求层(Requirements Layer)，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在。在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施(Routing Facility)接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施(Execution Facility)将最终结果返回给需求层用户，并完成本次用户请求。进行步骤(3.2)；
步骤(3.2)构建处理中枢层(Processing Layer)，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障。在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施(RoutingFacility)根据用户需求，把用户需求转换为RDF图(RDF Graph)，搜索匹配树(MappingTree)，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施(ExecutionFacility)进行加载。当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施(Scheduling Facility)发起调度请求。
若匹配树中查找结果为空，将用户需求转换的RDF图(RDF Graph)通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施(Scheduling Facility)发起调度请求。
最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有RMAE language配置与注册表，并实时将配置信息缓存到内存池(MemoryPool)中，通过心跳模式与其他服务器维持长连接。
进行步骤(3.3)；
步骤(3.3)构建微服务层(Microservices Layer)，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成。在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库(MicroservicesRepository)中的微服务(Microservice)及相关资源(Resources)，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表(Registry)中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址。组装完毕的微服务序列(Microservices Sequence)将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕。期间，监控设施(Monitor Facility)将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
所述第四步中，控制目标反馈回路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)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将RMAE language配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与RMAE language配置文件的映射关系定义如下：
elements＝{element1,element2,element3,…,elementn}；
对于所有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以及一种用于描述用户需求转换规则的语言RMAE language，进而使框架能够确定实现高度自适应系统所需的核心组件，并在运行时有效控制和实现这些组件之间的相互作用，提高软件系统的自适应演化能力，满足动态多样化的用户需求。
附图说明
图1示出了微服务架构下需求交互模型概念图。
图2示出了RDM本体模型图。
图3示出了RCT模型图。
图4示出了微服务调度超网络图。
图5示出了RMAE架构图。
图6示出了上下文驱动的自适应软件系统参考模型DYNAMICO。
具体实施方式
参照图1～图6，一种云计算环境下基于RMAE的微服务自适应演化方法，所述微服务自适应演化方法包括以下步骤：
第一步、在Web应用程序中，用户的需求和上下文决定了Web交互的决策和行为，为此，这些应用程序必须将用户的需求转化为可以代表用户自动执行的一系列Web任务，以提供更好的用户体验；
RMAE的实现需要自适应软件(Self-Adaptive Software,SAS)的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建如图1所示的微服务架构下需求交互模型，模型模块如下：
1.1用户需求解析(User Requirement Parsing)：即系统必须能够将用户的需求转化为规范的需求描述信息；
1.2任务委派(Task Delegation)：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；
1.3微服务配置(Microservice Configuration)：通过RMAE language配置文件描述微服务，并将用户需求与微服务进行映射；
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)采用RMAE language文件描述微服务，RMAE language描述的是一种基于RMAE的用户需求转换规则，选择XML文件作为RMAE language的载体，XML是一种标记语言，它的结构使其能具有良好的扩展性，便于直观阅读，也更利于RMAE体现出动态适应性。
基于RMAE language，把每个功能点的个性化需求映射到各个微服务的功能描述上，较大粒度的用户需求通过微服务间相互组合的结构关系映射出来。RMAE language把用户需求归为数据浏览(browse)、数据删除(delete)、数据增加(insert)、数据更新(update)、数据导入(import)、数据导出(export)和其他业务逻辑(other)这7个主要组成部分，并映射到相应的XML载体中，RMAE language的核心结构定义如下：
element元素代表一组微服务，一个微服务序列包含多组微服务，即多个element元素构成一个微服务序列。element元素使用半形式化方法来描述：
element＝elementAttr,[ms]
elementAttr＝mappingAttr,(description),nextMS
mappingAttr＝key,URI,method
nextMS＝(nextTag),(nextKey)
method＝‘GET’|‘POST’|‘PUT’|‘PATCH’|‘DELETE’
nextTag＝‘browse’|‘delete’|‘insert’|‘update’|‘import’|‘export’|‘other’
其中，element元素由element属性elementAttr与若干微服务ms构成，elementAttr包括映射属性mappingAttr、该组微服务的描述信description与微服务序列中的下一个微服务nextMS，mappingAttr中的子属性URI、method、key分别映射为匹配树中的u、m、t节点，nextMS中的子属性nextTag与nextKey则分别表示微服务序列中下一个微服务所对应的执行器和RMAE language配置，nextTag中browse、delete、insert、update、import、export、other七种值代表用户需求对微服务七种操作逻辑的映射，属性method与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE。
同一element下的ms为同类微服务，其先后顺序决定了微服务执行的次序，ms元素半形式化方法描述如下：
ms＝msAttr,{param},view
msAttr＝type,value,(description)
view＝{title},{output}
type＝‘class’|‘service’|‘sql’
其中，微服务ms由微服务属性msAttr、输入参数param以及返回给用户的可视化参数view组成，view包括标题title与输出参数output，msAttr包含微服务的描述信息description和子属性type、value，属性type表明了微服务的实现方式，若值为class表示通过反射机制执行对应本地程序类，属性value为执行类的名称；若值为service则表示调用外部服务来完成，属性value为该服务的调用接口；当值为sql时则表示对关系型数据库的动态执行，相应地，属性value为执行所需SQL语句，RMAE能提供对关系型数据库数据处理自动化的支持，包括SQL语句的参数注入、动态执行、返回对象自动封装及服务化等功能。
param元素代表微服务执行所需要的输入参数，这部分使用半形式化方法描述如下：
param＝(notNull),scope
notNull＝TRUE|FALSE
scope＝(request),(session),(application)
session＝TRUE|FALSE
request＝TRUE|FALSE
application＝TRUE|FALSE
其中，param由属性notNull和scope组成，notNull表示param是否允许为空，scope代表请求作用域范围，其内部包含三个布尔型子属性request、session与application，它们分别表示请求作用域是否为request、session与application。
进行步骤(2.4)；
步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求。该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入RMAE language配置文件中，并依据配置结果完成相应微服务的组装。在这一过程中，本发明采用Villegas Machado等人提出的SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；
结合图4，步骤2.4的过程如下：
步骤(2.4.1)结合第一步，将微服务架构下需求交互模型的主要概念抽象为需求解析层rLayer、任务委派层tLayer、微服务组装层mLayer和微服务配置层wLayer，分别包含用户需求、Web任务、微服务和RMAE language四种元素，各层间映射关系如下：
rLayer-tLayer(多对多)：需求解析层的每个用户需求为一次独立的用户请求，一个用户需求由多个Web任务协作完成，而每个Web任务又能参与满足多个用户需求；
tLayer-mLayer(一对一)：每个Web任务由单个微服务完成，单个微服务也仅能完成一个Web任务；
mLayer-wLayer(一对一)：每个微服务都对应唯一的一个RMAE language配置片段。
进行步骤(2.4.2)；
步骤(2.4.2)结合步骤(2.1)，路由设施通过处理RDM模型将用户需求转化为RCT模型，并生成(Generate)RDF图，该图由多个Web任务构成(Constitute)，可满足特定的用户需求，进行步骤(2.4.3)；
步骤(2.4.3)，采用SmartContext推理引擎将RDF图进行推理，并根据推理得出的Web任务序列将结果值注入(Inject)到RMAE language的nextTag(序列中下一个微服务所对应的执行器)和nextKey(序列中下一个微服务所对应的RMAE language配置)属性中，进行步骤(2.4.4)；
步骤(2.4.4)根据步骤(2.4.3)更新后的RMAE language配置进行微服务序列的组装与调度。
步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
第三步、基于第二步提出的RMAE框架组件模块，并结合图5给出RMAE整体架构及运作流程，过程如下：
步骤(3.1)构建需求层(Requirements Layer)，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在。在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施(Routing Facility)接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施(Execution Facility)将最终结果返回给需求层用户，并完成本次用户请求。进行步骤(3.2)；
步骤(3.2)构建处理中枢层(Processing Layer)，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障。在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施(RoutingFacility)根据用户需求，把用户需求转换为RDF图(RDF Graph)，搜索匹配树(MappingTree)，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施(ExecutionFacility)进行加载。当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施(Scheduling Facility)发起调度请求。
若匹配树中查找结果为空，将用户需求转换的RDF图(RDF Graph)通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施(Scheduling Facility)发起调度请求。
最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有RMAE language配置与注册表，并实时将配置信息缓存到内存池(MemoryPool)中，通过心跳模式与其他服务器维持长连接。
进行步骤(3.3)；
步骤(3.3)构建微服务层(Microservices Layer)，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成。在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库(MicroservicesRepository)中的微服务(Microservice)及相关资源(Resources)，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表(Registry)中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址。组装完毕的微服务序列(Microservices Sequence)将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕。期间，监控设施(Monitor Facility)将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
第四步、将Villegas提出的DYNAMICO参考模型引入RMAE框架，DYNAMICO提供了实现SAS系统所需组件的结构和行为特征，该模型定义了如图6所示的三个因果连接的反馈回路子系统：控制目标反馈回路(CO-FL)、动态监控反馈回路(M-FL)和自适应反馈回路(A-FL)，三者间的主要作用关系是：
CO-FL负责接收外界的变化信息，以此触发M-FL或A-FL(如图6箭头A)；
M-FL负责感测上下文信息(Context Information)、A-FL与CO-FL反馈信息，并将感测信息反馈至CO-FL或A-FL(如图6箭头B、箭头C)；
A-FL：负责接收CO-FL与M-FL的触发信息，并将自身反馈信息发送至M-FL(如图6箭头D)。
将CO-FL、M-FL和A-FL分别映射到路由委派、监控执行和微服务调度过程中，进而满足变更的用户需求。其中，CO-FL对应于负责接收用户需求的路由委派过程。该层跟踪用户需求的变化，以触发微服务调度或监控执行的适配。路由委派的主要目标是解析用户请求，对Web任务进行委派，确保RMAE能精确处理不断演化的用户需求；M-FL对应监控执行过程，它由协作单元和运行单元共同完成，协作单元负责各单元间的协同。运行单元在执行微服务序列的过程中，时刻受到监控，监控设施会将反馈信息实时动态更新；微服务调度的基础设施由查询单元、装配单元和通知单元组成，对应于A-FL。收到调度请求后，调度设施通过查询单元匹配内存池中的微服务描述信息(包括功能及结构).装配单元根据已有描述信息，前往微服务仓库进行匹配并动态组装微服务序列，若配置的微服务未能成功匹配，则通知单元将请求注册表更新对应的微服务信息。
第五步、面向用户需求，进一步给出RMAE框架的路由委派方法，过程如下：
步骤(5.1)利用步骤(2.2)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将RMAE language配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与RMAE language配置文件的映射关系定义如下：
elements＝{element1,element2,element3,…,elementn}；
对于所有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)，否则取出下一个微服务Microservicei，由调度设施前往微服务仓库选取匹配的微服务Microservicei，进行步骤(6.5)；
步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservicei，则将Microservicei加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；
步骤(6.6)调用注册表更新RMAE language配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；
步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。

Claims (8)

1.一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述微服务自适应演化方法包括以下步骤：
第一步、在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以及第二步完成运行时模型构建，模型包括RDM模型和RCT模型，进行步骤(6.3)；
步骤(6.3)基于第五步，结合RCT模型到内存池MemoryPool中获取对应的配置片段config，若配置片段config为空，则结束，否则进行步骤(6.4)；
步骤(6.4)遍历配置片段config的微服务，若遍历完成，则进行步骤(6.7)，否则取出下一个微服务Microservicei，由调度设施前往微服务仓库选取匹配的微服务Microservicei，进行步骤(6.5)；
步骤(6.5)若微服务仓库MicroservicesRepository中包含微服务Microservicei，则将Microservicei加入微服务序列Microservices，返回步骤(6.4)，否则进行步骤(6.6)；
步骤(6.6)调用注册表更新RMAE language配置文件，并将更新结果存入内存池MemoryPool，返回步骤(6.4)；
步骤(6.7)将微服务序列Microservices返回至执行设施，执行设施激活等待中的执行器，将微服务序列Microservices按序加载执行，直到序列中的所有微服务执行完毕。
2.如权利要求1所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述第一步中，RMAE的实现需要SAS系统的实施，以在微服务架构下尽可能地支持自动化调整，因此，先构建微服务架构下需求交互模型，模型模块如下：
1.1用户需求解析：即系统必须能够将用户的需求转化为规范的需求描述信息；
1.2任务委派：即系统必须能够将用户的请求派发给具有相应功能的组件进行处理；
1.3微服务配置：通过RMAE language配置文件描述微服务，并将用户需求与微服务进行映射；
1.4微服务组装：即系统必须定义满足用户需求所需微服务的有序序列，包括结构间关系，输入和输出规范；
1.5微服务执行：即系统必须能够在执行选定的微服务序列时，进行生命周期控制和自我修复管理活动；
1.6上下文感知和自适应支：即系统必须能够通过感知上下文来发现用户需求变更，并做出相应的自适应调整。
3.如权利要求1或2所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述第二步的过程如下：
步骤(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)采用RMAE language文件描述微服务，RMAE language描述的是一种基于RMAE的用户需求转换规则，选择XML文件作为RMAE language的载体，XML是一种标记语言，它的结构使其能具有良好的扩展性，便于直观阅读，也更利于RMAE体现出动态适应性；
基于RMAE language，把每个功能点的个性化需求映射到各个微服务的功能描述上，较大粒度的用户需求通过微服务间相互组合的结构关系映射出来，RMAE language把用户需求归为数据浏览、数据删除、数据增加、数据更新、数据导入、数据导出和其他业务逻辑这7个组成部分，并映射到相应的XML载体中，RMAE language的核心结构定义如下：
element元素代表一组微服务，一个微服务序列包含多组微服务，即多个element元素构成一个微服务序列，element元素使用半形式化方法来描述：
element＝elementAttr,[ms]
elementAttr＝mappingAttr,(description),nextMS
mappingAttr＝key,URI,method
nextMS＝(nextTag),(nextKey)
method＝‘GET’|‘POST’|‘PUT’|‘PATCH’|‘DELETE’
nextTag＝‘browse’|‘delete’|‘insert’|‘update’|‘import’|‘export’|‘other’
其中，element元素由element属性elementAttr与若干微服务ms构成，elementAttr包括映射属性mappingAttr、该组微服务的描述信description与微服务序列中的下一个微服务nextMS，mappingAttr中的子属性URI、method、key分别映射为匹配树中的u、m、t节点，nextMS中的子属性nextTag与nextKey则分别表示微服务序列中下一个微服务所对应的执行器和RMAE language配置，nextTag中browse、delete、insert、update、import、export、other七种值代表用户需求对微服务七种操作逻辑的映射，属性method与互联网的HTTP协议方法相对应，包括GET、POST、PUT、PATCH、DELETE；
同一element下的ms为同类微服务，其先后顺序决定了微服务执行的次序，ms元素半形式化方法描述如下：
ms＝msAttr,{param},view
msAttr＝type,value,(description)
view＝{title},{output}
type＝‘class’|‘service’|‘sql’
其中，微服务ms由微服务属性msAttr、输入参数param以及返回给用户的可视化参数view组成，view包括标题title与输出参数output，msAttr包含微服务的描述信息description和子属性type、value，属性type表明了微服务的实现方式，若值为class表示通过反射机制执行对应本地程序类，属性value为执行类的名称；若值为service则表示调用外部服务来完成，属性value为该服务的调用接口；当值为sql时则表示对关系型数据库的动态执行，相应地，属性value为执行所需SQL语句，RMAE能提供对关系型数据库数据处理自动化的支持，包括SQL语句的参数注入、动态执行、返回对象自动封装及服务化；
param元素代表微服务执行所需要的输入参数，这部分使用半形式化方法描述如下：
param＝(notNull),scope
notNull＝TRUE|FALSE
scope＝(request),(session),(application)
session＝TRUE|FALSE
request＝TRUE|FALSE
application＝TRUE|FALSE
其中，param由属性notNull和scope组成，notNull表示param是否允许为空，scope代表请求作用域范围，其内部包含三个布尔型子属性request、session与application，它们分别表示请求作用域是否为request、session与application；
进行步骤(2.4)；
步骤(2.4)构建调度设施，单个微服务通常无法满足大多数用户需求，因此需要将多个具有单一功能的微服务组装成较大粒度的微服务序列，从而增强系统功能，满足用户需求，该模块通过RDF文件推理，基于用户请求r，根据步骤2.1.2的RCT模型所得出的RDF图实例，将RDF图的输入与需要的关键输出属性注入RMAE language配置文件中，并依据配置结果完成相应微服务的组装，在这一过程中，采用SmarterContext推理引擎来完成RDF的推理过程，最终自动推理出Web任务序列，并根据推理结果自适应调整微服务序列，进行步骤(2.5)；
步骤(2.5)构建监控设施：在微服务序列执行过程中，实时监控用户上下文信息，监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
4.如权利要求3所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述步骤(2.1)的流程如下：
基于第一步的需求交互模型，面向需求驱动，明确软件运行时模型建模需求，进而给出需求驱动的微服务RDM本体模型和面向用户需求的上下文感知Web任务RCT模型的建模方法，过程如下：
步骤(2.1.1)构建RDM本体模型，其是定义基于微服务的Web交互概念的基本模型和本体，这些概念包括：
用户需求：用户服务需求的表示，可以被转化为Web任务,也可被表示为服务输出；
API网关：负责拦截Web任务的请求，执行过滤和验证操作；
Web任务：用户需求解析而成的各Web服务单元；
微服务序列：微服务序列是由若干微服务按序组合而成，Web任务请求也需通过微服务序列的按序执行实现，执行过程受用户上下文规约；
微服务：微服务是微服务序列的基本单元，它包含相关用户上下文信息，并与服务资源保持连接，同时，注册表的相关注册信息也有登记在微服务的描述信息中，保证了不同微服务之间的相互调用；
注册表：注册表记录了各微服务的运行状态、所在服务器的IP地址信息；
活动：活动通过微服务的执行，接收服务输入，并产生相关的服务输出；
资源：服务执行所需的相关软硬件支持，服务的输入有时也需要获取资源作为输入的一部分；
输入：服务执行所需的输入参数及资源条件；
输出：服务执行后产生的输出结果；
用户上下文：表示服务执行过程中的执行环境，包含相关数据、规约信息；
RDM本体可以作为RDF文件形式的运行时模型，并且可以根据用户需求演化来扩展,其中RDF即资源描述框架，其本质是一个数据模型，它提供了一个统一的标准，用于描述实体/资源；进行步骤(2.1.2)；
步骤(2.1.2)构建RCT模型，RCT模型是对iStar框架的扩展和重定义，iStar框架在策略依赖模型中定义了四种依赖关系，分别是：目标依赖，表示一个角色依赖另一个角色来完成某一个目标；资源依赖，表示一个角色依赖另一个角色为它提供物理资源和信息；任务依赖，表示一个角色依赖另一个角色来完成某个任务；非功能需求有关的软目标依赖，类似于目标依赖，扩展了iStar的角色、目标、任务和资源的原子概念，以支持用户需求、Web任务、微服务以及微服务序列之间的映射关系和相关描述规范，RCT模型将以RDF图的形式进行实例化，进行步骤(2.2) 。
5.如权利要求3所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述步骤(2.4)的过程如下：
步骤(2.4.1)结合第一步，将微服务架构下需求交互模型的主要概念抽象为需求解析层rLayer、任务委派层tLayer、微服务组装层mLayer和微服务配置层wLayer，分别包含用户需求、Web任务、微服务和RMAE language四种元素，各层间映射关系如下：
rLayer-tLayer，即多对多：需求解析层的每个用户需求为一次独立的用户请求，一个用户需求由多个Web任务协作完成，而每个Web任务又能参与满足多个用户需求；
tLayer-mLayer，即一对一：每个Web任务由单个微服务完成，单个微服务也仅能完成一个Web任务；
mLayer-wLayer，即一对一：每个微服务都对应唯一的一个RMAE language配置片段；
进行步骤(2.4.2)；
步骤(2.4.2)结合步骤(2.1)，路由设施通过处理RDM模型将用户需求转化为RCT模型，并生成RDF图，该图由多个Web任务构成，可满足特定的用户需求，进行步骤(2.4.3)；
步骤(2.4.3)，采用SmartContext推理引擎将RDF图进行推理，并根据推理得出的Web任务序列将结果值注入到RMAE language的nextTag和nextKey属性中，nextTag为序列中下一个微服务所对应的执行器，nextKey为序列中下一个微服务所对应的RMAE language配置，进行步骤(2.4.4)；
步骤(2.4.4)根据步骤(2.4.3)更新后的RMAE language配置进行微服务序列的组装与调度。
6.如权利要求1或2所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述第三步的过程如下：
步骤(3.1)构建需求层，RMAE框架面向用户需求进行设计，需求层是框架运行的驱动力所在，在系统运行时的需求发送与响应阶段，需求层负责向服务器发送用户请求，路由设施接收并根据用户需求进行任务委派，等待所有组件处理完毕后，执行设施将最终结果返回给需求层用户，并完成本次用户请求，进行步骤(3.2)；
步骤(3.2)构建处理中枢层，处理中枢层是框架的核心模块，同时也是微服务的API网关，保证不同用户需求能被正确处理并执行，是框架自适应功能的保障；在系统运行时的路由委派阶段与微服务调度阶段，中枢层先由路由设施根据用户需求，把用户需求转换为RDF图，搜索匹配树，依据搜索到的结果将Web任务委派给相应的执行器，并通知执行设施进行加载，当执行设施加载完毕后，执行器准备就绪，但由于此时微服务序列为空，执行器进入等待状态，并向调度设施发起调度请求；
若匹配树中查找结果为空，将用户需求转换的RDF图通过SmarterContext推理引擎自适应调整微服务序列，并由调度设施发起调度请求；
最后调度设施向公共服务器发起查询请求，根据得到的微服务功能及结构信息，前往微服务仓库选取匹配的微服务，组装成有序的微服务序列并返回至执行设施，其中公共服务器部署有RMAE language配置与注册表，并实时将配置信息缓存到内存池中，通过心跳模式与其他服务器维持长连接；
进行步骤(3.3)；
步骤(3.3)构建微服务层，微服务层是满足用户需求真正的执行者，根据需求委派的Web任务通过一系列细粒度的微服务协作完成，在系统运行时的微服务调度阶段与监控执行阶段，微服务层负责维护微服务仓库中的微服务及相关资源，并将微服务调度中所需的微服务序列进行组装，组装过程中，不同服务器上微服务之间的相互调用依赖于注册表中的信息，该表记录了每个微服务的运行状态，以及所在服务器的IP地址，组装完毕的微服务序列将返回给中枢层的执行设施，执行设施激活等待中的执行器，并根据微服务调度的结果，将微服务序列逐个加载，加载完毕的微服务由执行器按序执行，直到序列中的所有微服务执行完毕；期间，监控设施将监控每个微服务加载执行的过程，并实时更新反馈信息，自我修复设施负责处理微服务执行过程中的异常状态，用于提供更好的用户体验。
7.如权利要求1或2所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述第四步中，控制目标反馈回路CO-FL、动态监控反馈回路M-FL和自适应反馈回路A-FL之间的作用关系是：
CO-FL主要负责接收外界的变化信息，以此触发M-FL或A-FL；
M-FL主要负责感测上下文信息、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；收到调度请求后，调度设施通过查询单元匹配内存池中的微服务描述信息；装配单元根据已有描述信息，前往微服务仓库进行匹配并动态组装微服务序列，若配置的微服务未能成功匹配，则通知单元将请求注册表更新对应的微服务信息。
8.如权利要求1或2所述的一种云计算环境下基于RMAE的微服务自适应演化方法，其特征在于，所述第五步的过程如下：
步骤(5.1)利用步骤(2.2)构建的匹配树来对用户需求与路由之间的关系进行预处理，匹配树加载的数据来源于内存池，在系统初始化阶段，框架会将RMAE language配置文件缓存至内存池中，以提高匹配树的执行速度，其中，匹配树节点与RMAE language配置文件的映射关系定义如下：
elements＝{element1,element2,element3,…,elementn}；
对于所有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任务委派给相应的执行器，完成路由委派过程。
CN201910210739.8A 2019-03-20 2019-03-20 一种云计算环境下基于rmae的微服务自适应演化方法 Active CN110083350B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910210739.8A CN110083350B (zh) 2019-03-20 2019-03-20 一种云计算环境下基于rmae的微服务自适应演化方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910210739.8A CN110083350B (zh) 2019-03-20 2019-03-20 一种云计算环境下基于rmae的微服务自适应演化方法

Publications (2)

Publication Number Publication Date
CN110083350A CN110083350A (zh) 2019-08-02
CN110083350B true CN110083350B (zh) 2023-02-28

Family

ID=67413329

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910210739.8A Active CN110083350B (zh) 2019-03-20 2019-03-20 一种云计算环境下基于rmae的微服务自适应演化方法

Country Status (1)

Country Link
CN (1) CN110083350B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111107163B (zh) * 2019-12-31 2022-04-08 哈尔滨工业大学 一种面向用户需求变化的微服务自适应方法及系统
CN113934446B (zh) * 2021-12-16 2022-04-22 中电云数智科技有限公司 一种基于容器云平台的微服务配置系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106528169A (zh) * 2016-11-25 2017-03-22 浙江工业大学 一种基于AnGo动态演化模型的Web系统开发可复用方法
CN107203388A (zh) * 2017-06-14 2017-09-26 浙江工业大学 一种面向REST架构风格的Web服务快速开发方法
US20180005171A1 (en) * 2016-06-30 2018-01-04 International Business Machines Corporation Managing cross-channel fulfillment impact within shared inventory demand systems
CN109284086A (zh) * 2018-08-17 2019-01-29 浙江工业大学 面向需求自适应的Web服务动态演化方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180005171A1 (en) * 2016-06-30 2018-01-04 International Business Machines Corporation Managing cross-channel fulfillment impact within shared inventory demand systems
CN106528169A (zh) * 2016-11-25 2017-03-22 浙江工业大学 一种基于AnGo动态演化模型的Web系统开发可复用方法
CN107203388A (zh) * 2017-06-14 2017-09-26 浙江工业大学 一种面向REST架构风格的Web服务快速开发方法
CN109284086A (zh) * 2018-08-17 2019-01-29 浙江工业大学 面向需求自适应的Web服务动态演化方法

Also Published As

Publication number Publication date
CN110083350A (zh) 2019-08-02

Similar Documents

Publication Publication Date Title
CN110069380B (zh) 一种基于微服务的Web分布式软件演化与监控方法
CN112272234B (zh) 一种实现边云协同智能即服务的平台管理系统及方法
WO2004038587A2 (en) Enterprise multi-agent software system
Bǎdicǎ et al. Rule-based distributed and agent systems
CN110083350B (zh) 一种云计算环境下基于rmae的微服务自适应演化方法
Jiang et al. Semantic agent technologies for tactical sensor networks
Abiteboul et al. The AXML artifact model
Cassar et al. Composition of services in pervasive environments: A Divide and Conquer approach
Shakshuki et al. Agent-based system architecture for dynamic and open environments
CN110069276B (zh) 一种面向开放动态互联网环境的微服务需求驱动方法
Karakoc et al. A workflow-based Web service composition system
Poggi et al. An application of semantic technologies to self adaptations
Poggi et al. Integrating semantic run-time models for adaptive software systems
Poggi et al. Semantic run-time models for self-adaptive systems: A case study
Guermah et al. Exploiting semantic web services in the development of context-aware systems
Zhu et al. An intelligent collaboration framework of IoT applications based on event logic graph
Giallonardo et al. Semantics-driven programming of self-adaptive reactive systems
CN111913929A (zh) 一种云脑机器人智库创建方法及其装置、计算机终端设备
Razavi et al. Dynamic macroprogramming of wireless sensor networks with mobile agents
Khadir et al. TaAutonomous avatar-based architecture for value-added services provision
CN114819483B (zh) 一种面向工业机器人的柔性服务编排系统及其方法
Brunner et al. SEMbySEM: a framework for sensors management
Dourlens et al. Semantic modeling & understanding of environment behaviors
Wu et al. Knowledge object modeling
Brazier et al. Dynamics and control in component‐based agent models

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant