CN109254859B

CN109254859B - 一种多层控制的自适应微服务系统

Info

Publication number: CN109254859B
Application number: CN201811063032.0A
Authority: CN
Inventors: 毛新军; 刘佩妮; 张帅
Original assignee: National University of Defense Technology
Current assignee: National University of Defense Technology
Priority date: 2018-09-12
Filing date: 2018-09-12
Publication date: 2021-10-26
Anticipated expiration: 2038-09-12
Also published as: CN109254859A

Abstract

本发明公开了一种多层控制的自适应微服务系统，其包括：微服务系统，作为目标系统，微服务系统由一系列微服务组成，这些微服务通过轻量级协议组织成应用程序；基础设施控制层ICL，它用来解决自适应微服务系统基础设施级别的自适应问题；应用程序控制层ACL，它作为自适应微服务系统的上层，解决自适应微服务系统应用层面的自适应问题。本发明具有原理简单、易实现、能够满足动态变化需求等优点。

Description

一种多层控制的自适应微服务系统

技术领域

本发明主要涉及到服务系统及服务架构设计领域，特指一种多层控制的自适应微服务系统。

背景技术

Microservice是作为一种流行的架构风格，在学术界和工业界引起越来越多的关注，现在已经被亚马逊、Netflix、LinkedIn等许多大公司广泛采用。这种架构风格被认为是云计算和面向服务的系统工程的最佳实践。

在面向服务架构的早期，单体架构风格一直是构建Web应用程序的一种方法。这些应用程序是作为一个单元构建的，处理请求的所有逻辑运行在一个独立的进程中。由于这种体系结构下的系统缺乏独立性和灵活性，因此服务必须一起扩展和演化，这会导致服务器资源的巨大浪费。因此，单体的架构风格已经不适合构建超大规模的信息系统了。为了克服这些挑战，微服务已经成为构建如此复杂系统的新架构风格。它将一个复杂的大型软件应用程序按功能分解为一系列微小服务，每个服务运行在自己的进程中，并通过轻量级机制进行通信。微服务架构风格为面向服务的系统带来了许多好处，如可伸缩性、功能分离、松耦合和快速交付。

但是，微服务系统仍面临着严峻的挑战。首先，当变成微服务时，由于这些高度分布式的微服务通常运行和部署在云上的容器里，并且被组织来实现应用程序，所以必须采用具有适应性的软件体系结构。其次，随着微服务系统由于环境和需求的变化而不断发展，系统必须适应应对挑战。另外，敏捷和DevOps方法期望系统不停机并持续集成。因此，系统不再运行在已知的环境和静态要求下，这意味着系统需要重新配置和重构自身以满足动态变化的世界。显然，操作人员不可能考虑所有的变化并手动控制这些系统。

发明内容

本发明要解决的技术问题就在于：针对现有技术存在的技术问题，本发明提供一种原理简单、易实现、能够满足动态变化需求的多层控制的自适应微服务系统。

为解决上述技术问题，本发明采用以下技术方案：

一种多层控制的自适应微服务系统，其包括：

微服务系统，作为目标系统，微服务系统由一系列微服务组成，这些微服务通过轻量级协议组织成应用程序；

基础设施控制层ICL，它用来解决自适应微服务系统基础设施级别的自适应问题；

应用程序控制层ACL，它作为自适应微服务系统的上层，解决自适应微服务系统应用层面的自适应问题。

作为本发明的进一步改进：所述微服务系统包括：

微服务实例，它指处理请求以完成适当功能的真实实体；

微服务，它为一组具有相同功能的微服务实例的抽象。

作为本发明的进一步改进：在运行时，所述微服务通过微服务注册中心相互发现；所述微服务本身不处理请求，但将请求分发给其相应的微服务实例以执行功能；微服务实例是运行在容器中并且部署在云上的最小运行单元，用来提供了一个启发来操作容器来管理微服务实例。

作为本发明的进一步改进：所述微服务通过抽象的微服务接口屏蔽操作细节，并维护应用程序的拓扑结构；一旦拓扑由于动态上下文的变化或者应用需求的变化而改变，自适应系统就及时观察它们之间的微服务和依赖关系来重构应用；微服务系统通过感知微服务实例的运行状态信息以及有组织的微服务应用的拓扑，以确定目标系统是否健康。

作为本发明的进一步改进：所述基础设施控制层ICL由MAPE控制循环组成：Monitor从微服务实例中检测环境的外部上下文和系统上下文并收集监视数据；Analyze分析与系统相关的信息，并在事件发生变化时通过事件触发Plan中的系统级策略；最后，控制循环中的Execute根据策略调整系统配置，以便可以通过调度容器部署的位置，缩放容器数量以及限制或增加容器资源来实现系统调整。

作为本发明的进一步改进：所述应用程序控制层ACL由MAPE控制循环组成：Monitor由微服务组织的应用程序检测上下文-应用程序拓扑；Analyze分析应用程序功能需求信息，并在拓扑更改时触发应用程序开发人员在Plan中编写的策略；最后，循环中的Execute根据调整应用程序中组织的微服务的策略及其相关依赖性来实现系统适应。

作为本发明的进一步改进：所述应用程序控制层ACL在基础设施控制层ICL的协作下管理着变化状态；在基础设施控制层ICL将与应用程序相关的运行时信息定义为要在应用程序控制层ACL中控制的变量；在这种情况下，ICL Monitor会将相关数据上传到ACLAnalyze，以判断它是否满足应用程序非功能需求并决定在计划中获得结果；最后，ACLPlan将方法发送到ICLExecute以指导运行时适应。

与现有技术相比，本发明的优点在于：

1、本发明的多层控制的自适应微服务系统，为多层控制的自适应微服务系统设计了一种新的参考架构，它解耦了满足不同部分变化所需的不同层控制环路，并通过重新配置或重构微服务来实现自适应目标系统。

2、本发明进一步提出了基于我们的参考架构和K8S的微服务系统的实现架构，并提供了带有工具包的扩展平台SAMSP。

3、本发明进一步从样本开发和实验的角度验证了提出的参考架构，并展示了自适应微服务系统架构和平台的可行性和有效性。

附图说明

图1是本发明的拓扑结构示意图。

图2是本发明在具体应用中SAMSP-参考架构的实际实现示意图。

图3是本发明在具体应用中有自适应和没有自适应的系统性能比较示意图。

具体实施方式

以下将结合说明书附图和具体实施例对本发明做进一步详细说明。

在本发明中，实际上具有两个控制层的结构，即自适应微服务系统由多层控制层和微服务系统组成。微服务系统是实现业务功能的目标系统。管理系统具有多个受控层，并且每个层管理不同类型的适应：(1)基础设施控制层(ICL)通过平台预定义规则来感知系统环境和外部环境以管理容器，系统通常通过重新配置来完成适应；(2)应用程序控制层(ACL)检测与应用程序相关的变化，如需求和应用程序上下文，系统可以重新构造或在下层的控制循环帮助下完成系统自适应。

如图1所示，本发明的一种多层控制的自适应微服务系统，包括：

微服务系统，作为目标系统，微服务系统由一系列微服务组成，这些微服务通过轻量级协议组织成应用程序。微服务系统中有两个概念：一个是微服务实例(MSI)，它指处理请求以完成适当功能的真实实体。另一个是微服务(MS)，它可以理解为一组具有相同功能的微服务实例的抽象。

基础设施控制层，参见图中的ICL，它用来解决自适应微服务系统基础设施级别的自适应问题。

应用程序控制层，参见图中的ACL，它用来作为自适应微服务系统的上层。

在具体应用实例中，在运行时，微服务通过微服务注册中心相互发现。具体而言，微服务本身不处理请求，但将请求分发给其相应的微服务实例以执行功能。微服务实例是运行在容器中并且部署在云上的最小运行单元，用来提供了一个启发来操作容器来管理微服务实例。同时，微服务还通过抽象的微服务接口屏蔽了操作细节，并很好地维护了应用程序的拓扑结构。一旦拓扑由于动态上下文的变化或者应用需求的变化而改变，自适应系统就可以及时观察它们之间的微服务和依赖关系来重构应用。因此，微服务系统需要感知微服务实例的运行状态信息以及有组织的微服务应用的拓扑，以确定目标系统是否健康。

在具体应用实例中，基础设施控制层由MAPE控制循环组成：Monitor从微服务实例中检测环境的外部上下文和系统上下文(参见图中的交互(a))并收集监视数据。Analyze分析与系统相关的信息，并在事件发生变化时通过事件触发Plan中的系统级策略。最后，控制循环中的Execute根据策略调整系统配置，以便可以通过调度容器部署的位置，缩放容器数量以及限制或增加容器资源来实现系统调整(参见交互(b))。

在具体应用实例中，应用程序控制层也由MAPE控制循环组成：Monitor由微服务组织的应用程序检测上下文-应用程序拓扑。图中的交互(e))或用户通过适应策略更改需求，Analyze分析应用程序功能需求信息，并在拓扑更改时触发应用程序开发人员在Plan中编写的策略，例如更改两个微服务之间的依赖关系。最后，循环中的Execute根据调整应用程序中组织的微服务的策略及其相关依赖性(参见图中的交互(f))来实现系统适应。

在具体应用实例中，ACL在ICL的协作下管理着一部分变化。本发明进一步在ICL层将与应用程序相关的运行时信息定义为要在ACL中控制的变量。在这种情况下，ICLMonitor会将相关数据上传到ACL Analyze(参见图中的交互(c))，以判断它是否满足应用程序非功能需求并决定在计划中获得结果。最后，ACL Plan将方法发送到ICLExecute(参见图中的交互(d))以指导运行时适应。

由上可知，本发明中多层控制自适应微服务系统的架构中定义了功能元素，以及每层内部元素之间的控制，数据或文件之间的相互作用。此外，参考体系结构表征了多层之间的协作，以确保它可以部分应用，以防有人不需要适应某些部分。

而本发明所采用的自适应系统在运行时能够适应，给系统带来了一些启发，自适应系统可以帮助在动态变化中系统的保持和优化。例如，基于架构的方法Rainbow允许自适应系统了解软件结构并通过外部控制驱动自适应。另一种反射方法可以利用软件的反射能力来检查并可能在运行时修改其结构(结构反射)或行为(行为反射)。这两种方法将MAPE控制回路构建为自主管理器，以监控微服务系统的状态，分析变化并在运行时计划和执行动作。自适应思想来自自适应系统，它可以根据高层目标管理系统本身。参考架构使微服务系统能够不断了解其动态上下文以及不断变化的需求，以便在运行时调整其行为和结构。这种架构的创新是使用自主计算MAPE控制环路来形成多层控制环路。一方面，自适应微服务系统可能运行在第三方提供的基础架构服务器上，基础架构层的系统工作负载必须通过基础设施控制的环路进行调整。自适应微服务系统为了实现一个应用程序而组织了多个微服务，并且应用程序层的应用程序的需求和性能必须通过应用程序控制的环路来保证。

在一个具体应用中，本发明提供了一个名为SAMSP的扩展平台，并带有一个工具包来实现多层自适应。图2描述了参考架构的实现架构。

在设计阶段，应用逻辑和自适应逻辑是分开的。首先，开发具有独立功能的微服务，并使用jersey.jar来实现Restful交互协议。开发完成后，通过Docker²镜像构建环境，并将其放入Image注册表Harbor³中。另一方面，通过使用自适应策略语言来描述和注册的适应策略注册表，考虑了一些自适应目标。

当涉及运行时阶段时，在微服务系统中，微服务实例化几个微服务实例，运行在容器中并部署在分布式云服务器上。使用容器编排Kubernetes来帮助部署的微服务实例容器，还有一些插件，例如用于微服务发现的Etcd⁴。作为监视系统状态的重要角色，cAdvisor²收集微服务实例的性能，并且logstach在本地获得调用链。

在ICL中，在监控阶段，使用Heapster⁵来收集本地cAdvisor中集群和微服务实例的性能，如CPU使用率，内存使用情况等。在分析和计划阶段，从Kubernetes中的HPA(水平pod自动调节器)扩展的Autosystem组件分析系统状态并为可配置参数选择最佳值。在执行阶段，Kubernetes API服务器将新的配置参数提交给群集kubelet以适应不断变化的环境。

在ACL中，首先，ACL需要从适配策略注册表中加载适配策略。在控制循环内部，ELK⁶(ElasticSearch，Logstash，Kibana)用于从本地logstash收集应用程序的组织结构。在需求分析器的需求检查后，作为我们应用规则引擎的Drools⁷将触发我们定义的自适应策略，并使用拓扑引擎更改微服务之间的依赖关系或构建新结构。至于与ICL的合作，需求分析器向ICL请求与应用程序相关的属性，并且Kubernetes API服务器从Drools获得应用程序所需的结果以操作容器。

综上所述，本发明系统的特点就在于：(1)分析变化的多样性，将适应分为不同的层次；(2)提出了具有多层控制环的自适应微服务系统的架构；(3)确保了架构与实际应用之间的一致性。

为了说明本发明提出的参考架构的可行性及其自适应的有效性，使用图书信息系统(BIS)作为示例。此应用程序提供书籍信息支持，以帮助用户通过互联网了解该书。基本上，BIS应用程序通过撰写书评微服务和书籍内容微服务来显示书籍的信息。同时，图书内容可以由一些不同的图书内容信息提供者提供，例如维基百科，百度百科和几个学校图书馆系统。

A.基于BIS的样本开发；

这里，微服务系统的通用适配场景分为两个方面：基础设施层面适应和应用层面适应。(见表1)

表1.微服务系统的通用适应情景

基于本发明的系统，为此建立了真正的BIS应用程序。该BIS采用微服务，并且ICL/ACL可以按照第IV节完全实现。ICL层用于通过重新配置微服务实例来增强系统的可靠性和性能。它在表1中的S1和S2上生效。在S1中，如果其中一个书评微服务实例不可用，则其余书评微服务实例需要接受来自不可用微服务实例的请求，并重新启动此失败的微服务实例。S2：如果其中一个过载，重新配置微服务实例的数量或将其调度到可用服务器将获得更好的系统性能。

但是，如果所有实例都失败，则微服务将无法访问。因此，ACL负责通过重组应用程序来处理此问题。例如，在S3中，如果书籍内容微服务不可达，ACL将被通知情况。作为响应，该层将向系统注册替代服务(例如维基百科或百度百科)，调整这些相关微服务之间的依赖关系并将该服务重新链接到最新可用的微服务。对于需求更改，在S4中，如果应用程序需要新功能(例如书籍评级)，则ACL将通过将新的微服务推入映像注册表并将新配置导入ICL以利用新近使用的微服务来处理功能需求添加。最后，对于ACL和ICL之间的协作，情景是，如果用户要求服务的平均响应时间不超过1.5s(即S5)。为了满足这一点，ACL将检测来自ICL的平均响应时间信息并在违反条件时权衡规划，最后在ICL中执行计划。

B.实验分析；

为了评估自适应微服务系统与没有自适应的原始微服务系统相比的自适应效果和性能，对分布式测试平台Locust⁸进行了实验。在这个实验中，已经选择了表1中的一些适应场景(例如，S1：微服务实例失败，S2：微服务实例过载，S5：违反应用相关的QoS约束)。在30分钟内观察微服务的平均响应时间(ART)，以评估微服务面临多种变化时的性能。

图3显示了整个运行时间期间系统性能的结果以及没有适应的情况。实线表明，如果没有适应，一旦面对变化时的平均响应时间增加，就不会再次下降。另一方面，虚线表明，如果SAMSP适应适应，平均响应时间会增加，但很快会回到最佳水平。表2显示了这些时期的变化细节，并比较了我们的情况。结果表明，自适应是有效的，并且显着提高了该实验中的系统性能。

表2.场景和案例研究的结果

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，应视为本发明的保护范围。

Claims

1.一种多层控制的自适应微服务系统，其特征在于，包括：

应用程序控制层ACL，它作为自适应微服务系统的上层，解决自适应微服务系统应用层面的自适应问题；

所述应用程序控制层ACL在基础设施控制层ICL的协作下管理着变化状态；在基础设施控制层ICL将与应用程序相关的运行时信息定义为要在应用程序控制层ACL中控制的变量；在这种情况下，ICL Monitor会将相关数据上传到ACL Analyze，以判断它是否满足应用程序非功能需求并决定在计划中获得结果；最后，ACL Plan将方法发送到ICLExecute以指导运行时适应。

2.根据权利要求1所述的多层控制的自适应微服务系统，其特征在于，所述微服务系统包括：

微服务实例，它指处理请求以完成适当功能的真实实体；

微服务，它为一组具有相同功能的微服务实例的抽象。

3.根据权利要求2所述的多层控制的自适应微服务系统，其特征在于，在运行时，所述微服务通过微服务注册中心相互发现；所述微服务本身不处理请求，但将请求分发给其相应的微服务实例以执行功能；微服务实例是运行在容器中并且部署在云上的最小运行单元，用来提供了一个启发来操作容器来管理微服务实例。

4.根据权利要求3所述的多层控制的自适应微服务系统，其特征在于，所述微服务通过抽象的微服务接口屏蔽操作细节，并维护应用程序的拓扑结构；一旦拓扑由于动态上下文的变化或者应用需求的变化而改变，自适应系统就及时观察它们之间的微服务和依赖关系来重构应用；微服务系统通过感知微服务实例的运行状态信息以及有组织的微服务应用的拓扑，以确定目标系统是否健康。

5.根据权利要求1-4中任意一项所述的多层控制的自适应微服务系统，其特征在于，所述基础设施控制层ICL由MAPE控制循环组成：Monitor从微服务实例中检测环境的外部上下文和系统上下文并收集监视数据；Analyze分析与系统相关的信息，并在事件发生变化时通过事件触发Plan中的系统级策略；最后，控制循环中的Execute根据策略调整系统配置，以便可以通过调度容器部署的位置，缩放容器数量以及限制或增加容器资源来实现系统调整。

6.根据权利要求1-4中任意一项所述的多层控制的自适应微服务系统，其特征在于，所述应用程序控制层ACL由MAPE控制循环组成：Monitor由微服务组织的应用程序检测上下文-应用程序拓扑；Analyze分析应用程序功能需求信息，并在拓扑更改时触发应用程序开发人员在Plan中编写的策略；最后，循环中的Execute根据调整应用程序中组织的微服务的策略及其相关依赖性来实现系统适应。