一种方法开发基于容器的Microservices重建应用程序

文摘

Microservices是小规模的服务,可以独立操作。microservice单位组成的一个应用程序可以独立开发作为服务单位,它可以处理单个逻辑而不影响其他服务。此外,它可以迅速分发配置microservices容器,容器和编制技术,管理分布式实现多个容器;因此,它是可能的更新和分发microservices分别。因此,许多公司正在远离现有整体式结构和试图转向microservices。在本文中,我们提出一个方法应用整体改造成一个基于容器的microservice单位。microservices数据单位是通过单片设计数据的收集和分析。此外,我们提出一个方法来生成一个模板脚本基于部署设计数据,以便派生microservice和支持分布在一个容器环境中可以实现。案例研究的结果进行了验证,本研究基于容器的microservices部署在正常工作。此外,对于独立应用程序的发展和基于容器的发展microservices呈现在这篇文章中,我们确认开发microservices是高效的基础上进行执行时间性能评估API调用在不同的迭代。 Finally, we show that microservices constructed using the proposed method have higher reusability than those constructed using existing methods.

1。介绍

Serverless计算是一个执行模型应用程序的开发和分布式基于microservice单位而不需要建立一个单独的基础设施在云环境中(1]。目前,主要的云计算公司提供serverless计算技术,比如Amazon AWSλ(2),微软Azure函数(3),和谷歌的云功能(4),他们的服务。到2018年,serverless计算成为了增长最快的云服务,增幅约75%在2017年和2018年之间根据RightScale云的“2018状态报告”(5]。《福布斯》杂志建议serverless架构将注意的十大技术之一在未来五年,直到2022年,它正成为新一代云计算模式(6]。

Microservices,构成serverless计算的核心概念,是小规模的服务,可以独立操作。microservices组成的应用程序是松散耦合结构与不同microservices;因此,个人可能不知道更新应用程序的内部结构。因此,这种结构的优点是快速开发和分布式与现有的整体结构是高度可重用(7]。

最近,集装箱编配技术,例如Kubernetes [8),码头工人群(9),中间层(10),出现了支持容器分销管理。他们适用于灵活的管理大规模microservice-based应用程序,因为他们启用批处理和自动容器创建以及分销管理众多的容器中。

因为这些优势microservices和集装箱编配技术,许多公司正试图采用它们作为替代现有的单一应用程序结构以开发和分发microservice-based应用程序以及将它们部署在一个容器。然而,研究如何重新配置现有的独立应用程序到microservice单位仍然有限(11]。

需要考虑的因素有很多,比如microservice大小、API配置、数据库处理,和安全,这取决于服务时,它的大小是为了重建一个复杂的整体结构进一个小和独立microservice [12]。特别是,其中一个问题是,很难改变microservice单位因为microservice大小不是固定的。此外,有些参数需要手动定义为基于容器的分配和管理,如最初的容器管理数量和网络配置,在配置的情况下甚至microservice [13]。此外,将现有的单片应用程序转换为microservices需要深入理解现有的独立应用程序的结构。因此,基于软件体系结构的方法推导microservices [14)或数据流(15提出了。演变成一个面向对象的开发环境,基于UML(统一建模语言),应用程序设计和开发方法被采用。因此,还有一个需要将现有的UML设计数据转换成microservices基于应用程序。

为了克服这些问题,本文提出一种方法,分析了设计数据的独立应用程序和建构基于容器的microservices。我们应用整体的UML设计数据分类层次结构,构造一个图可以转化成microservices和派生microservices的实体单位。

基于派生microservices和部署设计数据,一个方法来自动生成模板脚本,该脚本可以在集装箱编配分发和管理环境。此外,一个案例研究来验证该方法的有效性和实际的重组microservice显示是一个集装箱编配环境中部署和执行。最后,通过比较和评价,表明该方法优于现有方法的可重用性。

2。相关工作

2.1。Microservices

Rademacher et al。16)调查的特点microservices通过比较现有的面向服务的体系结构(SOA)的概念。他们解释说,microservices比SOA和更独立,microservices应该设置为单位的大小可以由每一个开发团队。他们还表明,microservices之间的耦合是极低的,是高度抽象的接口。在我们的论文中,接口用于施工方法的概念,它被定义为支持用户之间的通信和microservices。

Dragoni et al。17)建议microservice配置由单位携带一个业务功能。如果业务功能单位是大,它需要被分成两个或两个以上的小单位,microservices,数据库被定义为一个distributed-type数据库而不是共享在一个集中的方式。在我们的论文中,我们定义了一个业务能力作为一个整体,是一个数据库。

Yu et al。18)提出了一个参考体系结构模型构建microservice环境在企业环境中。他们分类三种microservices建议的体系结构模型。接口由用户输入,业务逻辑处理输入值,和一个持久层,其中包含的数据区域。我们分类microservices演讲中,业务逻辑层和持久层使用三层概念提出了研究。

2.2。Microservices施工方法

穆斯塔法和马克思戈麦斯(19)提出了一个方法,构建microservices运行时环境。在他们提出的方法中,配置一个相似的时区后作为一个会话,会话是分开的,当有许多访问在一个特定的会话。然而,它是不确认是否频繁访问的服务显然执行一个业务功能。

Mazlami et al。14]microservice定义为一个类组单元的变化发生类似的目的。他们建造了一个图的顶点对应一个类和一个边缘有一个重量根据类之间的相似程度的变化;然后,他们应用了一个聚类算法,可去除低重量的边缘。然而,它是不可能验证的类型实现microservices构造的相关研究。此外,它是不可能验证类的集团单位是否执行业务逻辑。

陈等人。15]分析数据流图(目前)为独立应用程序设计数据和定义一组函数和输出数据作为单个microservice单位。在现有的过程,他们定义了一个规则为每个步骤和连接数据相关的函数来执行业务功能。此外,他们建造了精制过程数据和提取microservices。然而,当我们应用这种方法,完全独立microservices没有配置,因为数据可以与其他功能有关。

2.3。集装箱编配

码头工人(20.)是一个容器软件平台的快速构建和部署应用程序容器的形式。它运行在主机操作系统没有分配一个单独的操作系统或资源,与一个典型的基于系统管理程序的虚拟机。此外,独立的应用程序,比如虚拟机可以运行各种应用程序。为每个microservice码头工人可以独立部署应用程序,它可以驱动高效microservice应用程序。

码头工人的主要问题是,它没有能力来管理其生命周期在处理大量的容器。为了克服这个问题,一个集装箱编配概念,支持容器管理和码头工人群9)开发。码头工人群是一个开源软件,它支持集装箱在码头工人编制。客户端可以通过群经理管理码头工人,和群经理向码头工人守护进程发送一个命令来查找和分配适当的节点创建容器。

Kubernetes是一个开源容器编排最初由谷歌开发的平台。目前,主要的云供应商,如AWS、IBM和微软,结合Kubernetes提供云服务,正在成为事实上的标准。Kubernetes的结构可分为主人和节点。主管理几个节点,节点创建和执行实际的容器。Kubernetes容器管理功能是通过模板脚本中指定YAML或JSON格式。在Kubernetes,容器单元是一个豆荚,可以创建和执行脚本的形式模板。ReplicaSet可以控制这些豆荚。调度器可以使用模板管理和维护多个豆荚脚本。最后,还有一个服务模板脚本支持网络功能,而外部网络客户服务,如loadbalance ServiceDiscovery,可以支持通过连接外部客户端容器。

Kubernetes使用YAML文件定义了部署一个application-e.g所需的状态。,how many ports it wants to service—by attaching labels to various objects, such as Pods, ReplicaSets, Services, and Volume, and passes it to the API server. In Kubernetes’ internal mechanism for creating a new Pod, the ReplicaSet controller included with the Kube controller monitors the ReplicaSet and checks if there is a Pod that satisfies the Label Selector condition defined in the ReplicaSet. A new Pod is created by configuring the Pod template and passing it to the API server.

分发构造microservices在Kubernetes容器环境中,我们提出一个方法,自动生成一个豆荚,ReplicaSet和服务模板脚本文件从整体设计数据。

3所示。基于容器的Microservice重建方法

重建的过程microservices通过分析单片设计数据图中概述1。重建和microservices设计数据,我们在四个步骤执行详细的活动。解释每个步骤如下。

3.1。分析单片设计数据

在这一步中,microservice重建目标的整体设计数据收集和分析。它包括以下活动:(我)收集整体设计数据:设计数据收集的类型是UML类图的设计数据由欧洲央行定义模式(21]。表1总结了类型和刻板印象在UML设计数据的例子。这三个表中定义的刻板印象1收集。(2)3层分类层:类定义为刻板印象是UML类设计数据和分类收集的一个3层的层次结构。在这里,3层意味着表示,业务逻辑和持久性。(3)类类型映射层:定义一个3层的层次结构,和分层执行映射。刻板印象如下:< <边界> >类型是表示层,< <控制> >类型是业务逻辑层,和< <单位> >类型映射到持久层,如表所示1。

3.2。提取Microservice

在microservice提取步骤中,构造图类信息收集和分类的基础上在前面的步骤;然后,执行以下活动获得的microservices单位:(我)分析类的关系和构造图:构造图顶点对应一个类和边组成的代表调用关系。表示层中的顶点分类根据映射关系表所示1被定义为边界顶点(表示为“bv”)。Verices分类在业务逻辑层被定义为控制顶点(表示为“简历”)。持久性层次结构中的顶点分类被定义为实体顶点(表示为“电动汽车”)。此外,调用类的UML设计数据之间的关系表示为优势,如表所示2。泛化和实现:在泛化关系和实现,A是一个父类,继承或实现。因此,类影响B类和调用它。依赖和关联:依赖关系和关联关系,B类调用和使用类的对象和方法;因此,A是B类改变时的影响。作文和聚合:在组合和聚合类包括作为一个B类的一部分;因此,如果改变B类,类将受到影响。(2)重建业务logic-centric图:microservice转换图重建,这样可以由microservice单位配置图。表示层和持久层顶点和边没有直接连接到顶点配置在业务逻辑层中,和图重新配置。(3)提取microservice主要基于实体:最后的活动microservice推导步骤,microservice单元在构造一个实体。在这里,实体是一个顶点在持久层类元素分类。它追溯了顶点的业务逻辑层和表示层被称为实体和构造。然而,作为一个特定的控制类,这是一个业务逻辑层的顶点,可能是由许多实体类,调用配置区域重叠。要解决这个问题,一个主要实体确定控制解决冗余配置。在这里,一个主要实体控制是由计算的比值的方法调用实体类和方法名称相似度的平均值。

如果主要实体调用其他实体直接从控制的角度构建microservice后单位在确定实体的控制,设计数据变化被称为实体通过边界类的表示层。这是因为microservices之间的通信必须由API (22]。这将创建一个新的边界control-entity关系叫做control-boundary-entity直接和改变了设计数据的关系。

图2显示了提取的伪代码microservice基于主要实体获得microservice主要实体单元。输入元素图G,输出元素是microservice构造图。它重复测定的主要实体的控制类图。如果控制类调用多个实体,计算的比值的方法调用实体和实体的方法名称相似,并确定与更高的比率为主要实体的实体。否则,与一个实体相关联的类将自动确定主实体与实体相关联。主要实体确定时,迭代数量的实体和推进microservice配置实体单位对应的主要实体。实体的主要实体是不被排除在microservice配置决定的。最后,当控制连接到另一个microservice的实体或控制类,创建一个新的边界和microservice改变连接的连接通过创建的边界。

3.3。实现Microservice

在这一步中,之间的API连接识别microservices实现根据层次结构:(我)实现microservice 3层:实现顶点类分类在每一层如表所示3。开发人员可以构建的基础上,设计数据为每一层使用开发工具或语言。

例如,当microservices配置了以下三个边界,一个控制,一个实体,三个api,一个控制器,和一个数据库实现,如图3每一层。

(2)实现microservice API连接:生成的边界实现支持API连接microservices microservice推导的步骤。例如,如图4通过边界,当两个microservices相连(API调用1和API调用2)API的实现它们之间的通讯。在节中给出的案例研究4,我们讨论每一层的实现过程。

3.4。部署Microservice

microservice重建过程的最后阶段microservice部署的模板生成脚本,支持在集装箱编配环境中部署和管理的基础上实现microservices和UML部署设计数据。在这里,设计数据收集类和部署设计数据,和microservice指microservice实现microservice步骤中实现。主模板脚本Pod、ReplicaSet和服务,这是三个主要类型的模板脚本运行在Kubernetes,集装箱编配平台。生成模板脚本的过程中根据设计数据和microservice信息如图5。(我)收集部署元素:一个关键模板脚本规范Kubernetes环境中部署和管理模型,这是一个集装箱编配环境,定义如图6。常见的信息是指元素中描述需要所有类型的模板脚本,豆荚,ReplicaSet和服务类型的模板脚本需要管理容器分布。表中给出了每种类型的描述4。(2)生成模板脚本容器部署:我们推导出集合元素从整体设计数据生成模板脚本规范模型元素。(1)Microservice信息:Microservice信息包括信息提取的Microservice的姓名和电话号码。(2)类数据:设计类信息收集类设计的名字。(3)部署设计数据:分为节点信息和连接信息。节点信息收集节点名、资源、操作系统和应用程序创建容器。连接信息收集内部和外部端口,协议,和外部连接的IP通信与外部的容器。

表5是一个映射表映射模板脚本元素生成和收集元素中定义的单片设计数据。在圆荚体的情况下,脚本生成的映射元素类信息和节点信息收集的。ReplicaSet映射生成的类设计名称,microservices配置的数量,和节点信息生成模板信息。最后,服务生成一个脚本映射连接从部署设计数据收集的信息。

方法收集UML设计数据基于映射表和一代的一个模板脚本显示在图7。首先,UML设计数据转换成数据格式(.XMI),这样他们可以被解析。接下来,元素的映射表中定义第二个转变XMI收集数据的解析。最后,根据提取的元素集合,生成模板脚本类型。

4所示。案例研究

在本节中,我们提出一个案例研究过程的基础上重建一个“在线机票交易系统,利用实际的UML设计数据,利用提出的方法部分3。我们也验证改造microservices操作和容器编制环境中正确地运行。

“在线机票交易系统”的案例研究是一个系统的卖方和用户可以注册,询价,sell事件网上(或门票)。图8应用整体的UML设计数据显示“在线机票交易系统”;我们解释microservices和部署基于容器的microservices提取的部分4.1和4.2,分别。

4.1。整体设计的案例研究数据分析和Microservice提取

在第一阶段,即。,the monolithic design data analysis phase, UML class design data of the “online ticket transaction system” are collected. As a result of classifying the collected data by hierarchy, 10 boundary classes, eight control classes, and five entity classes were derived. Table6总结了每个原型的层次分类。

分析类之间的关系,构建一个边缘点的方向进行调用的方法。图9(一个)显示G (E, V)组成的一个顶点分类的类类型和优势作为调用关系。在这种情况下,重建业务logic-centric图方法重建microservice转换图集中在业务逻辑上。如图9(b),作为一个重建的结果,我们可以构造一个转换图G′(E, V) microservice推导的能力。

基于给定的microservice转换图,microservice推导的主要实体单元执行,如图10。“在线机票交易系统”目前包括五个实体(成员、报告、事件、票和付款)。构建的microservice实体单元,配置执行的跟踪电话,每个实体的方向。因此,如图10ev3 microservice配置区域重叠,ev4, ev5。

解决microservice配置区域是重叠的情况下,一个主要实体确定每个控制顶点。图11显示的过程中确定的主要实体cv6 cv6, cv7和cv8类,microservice发生重叠。cv6 (TicketViewController)调用ev3 (EventInfo)和ev4 (TicketInfo)方法。因此,cv6必须确定的主要实体ev3或ev4;它通过应用计算方法调用的方法名称相似的决策标准。调用方法的速度计算的25%因为ev3调用ev3的四种方法之一。在ev4的情况下,四种方法叫做之一;因此,利率25%计算。名称相似性计算100%的速度因为它包含一个名为“票”的方法在所有ev4的方法称为“TicketViewController”,这是cv6的类名。ev3而言,利率0%计算,因为它并不包括“票”和“事务”的方法。最后,调用方法和名称相似度计算值平均,分别和因此,ev3计算12.5%,ev4计算为62.5%,ev4确定为主要的实体。

与cv6一样,的主要实体是决心以同样的方式cv7 cv8,调用各种实体。因此,ev4决定的主要实体cv7 ev8以及cv5,和五个microservices实体单元的配置没有重叠配置区域,如图12。

如果microservice配置区域是不重复的,但是现有的控制访问其他microservice实体(cv6⟶ev3, cv7⟶ev3,和cv8⟶ev4),它改变了设计数据来创建一个新的边界,并调用它的直接调用实体的关系。如图13,对于cv6 cv7 cv8, microservice控件直接调用其他microservice实体,一个新的边界(新bv1 bv2 bv3)创建更改设计数据执行边界microservices之间的沟通。

4.2。Microservice实现和部署的案例研究

提取的重新配置microservices前面步骤中实现的层次结构和microservices之间实现互连的api。图14显示的过程实现成员microservices microservices配置中“在线机票交易系统”的层次结构表3。在这个案例研究中,ExpressJs,包模块节点。js API,用于API的实现表示层。业务逻辑层的控制器使用节点。js JavaScript和MySQL作为数据库的基础上的持久层。

图15显示实际的源代码的成员microservice根据分类层实现。在API的情况下,实现的基础上的内部输入方法参数信息边界类。在加入bv1, API路径实现为“/用户/注册,”和输入参数实现接收应用程序id,应用程序通过,和名称。在控制器的情况下,实现的基础上的名称和方法控制类。它是创建并结合API调用路径。最后,在数据库的情况下,我们实现了表名的基础上实体类名和字段名作为方法参数基于SQL语句。

在实现层,连接microservices之间的API实现。实现一个新的bv1 microservice中生成的三个新边界提取步骤是一样的,如图16。新bv1实现因此cv6边界包含信息调用EventSelect cv3()方法,和新bv1实现调用EventSelect () API路径“/事件/ EventSelect。”

实现microservices之后,模板生成脚本支持Kubernetes分布管理,这是一个集装箱编配的环境。设计数据图的左边17UML部署设计数据的“在线机票交易系统,”组成的两个节点和一个连接信息。我们出口一个XMI文件的UML部署设计数据创建豆荚,ReplicaSet和服务模板脚本根据图所示的方法7。

右边的输出屏幕的图17是出口的结果设计数据作为xml数据。节点和连接信息被定义为<元素>和<连接器>标记值,分别。标签内部属性被定义为名称、刻板印象、类型、和价值,名字是节点的名称或连接信息,刻板印象是设计元素的类型(操作系统、设备等),类型的属性类型(RAM、CPU等设备),和值的值类型。例如,DBserver,这是一个节点名,有一个设备原型,设备是CPU的类型,RAM的价值表示为xml数据和一个核心和256 MB指定为价值。集合元素的映射表转换xml数据的表中定义7和XMI数据解析如图18。

基于提取的值的映射表,每个类型的模板脚本生成如图19。区域标注①表示创建Pod的名称的过程模板脚本/ microservice名字。②所示区域表示的过程生成的复制品价值ReplicaSet模板脚本配置microservices的数量。③表示标记的区域提取类图的过程信息和创造豆荚,ReplicaSet和服务的标签模板脚本。该地区标有④表示提取的过程部署图的节点信息和创建的容器和模板信息Pod和ReplicaSet模板脚本。该地区标有⑤表示提取的过程连接信息并创建服务模板脚本。

4.3。Microservice验证

我们确认,模板脚本文件中生成部分4.2正确地工作。Kubernetes的验证,这是一个集装箱编配环境,构建一个主和两个节点被驱动到一个虚拟机环境。在主的情况下,2个vcpu和4 GB的内存分配,对于一个节点,2个vcpu和2 GB内存分配。执行的结果三个类型的模板脚本生成Kubernetes环境如图20.。在这里,没有。1是一个屏幕询问所有的豆荚州Kubernetes控制环境。由于执行生成的脚本,五个吊舱(userpod, reportpod, ticketpod eventpod, paymentpod)。此外,它是确定的,那就是所有的仓状态是正常运行的。2号是执行的结果ReplicaSet的模板脚本。目前,五个豆荚管理通过标签,我们可以确认所有的豆荚都贯穿仓状态。3号是执行服务模板脚本的结果。证实,5舱通过标签连接到每个端点配置协议、端口信息和外部IP。

当microservices被部署在Kubernetes环境中实现,我们验证了他们正常工作。如图21后,实现的用户microservice”在线机票交易系统,“这是分布式的容器环境(userpod)。检查是否分布式成员microservice执行,我们证实了反应使用邮差[23),一个API测试工具。

如图22API测试后,请求被发送到userpod证实收到响应。图的左面板22显示了一个情况注册API(用户/注册)的主机信息userpod 10.244.5.2。注册成为会员,我们发送信息(app id,应用程序通过名称)JSON形式的直接用户,确认从userpod处理输入的信息。右上角的数字22是一个命令查询数据库信息的dbserver userpod API调用。屏幕底部右面板是查询数据库信息的dbserver userpod后一个API调用。API调用的结果,这是确认的信息输入数据库信息的dbserver userpod生成。

5。Microservice施工方法评价

我们分析的特点和优势,提出了microservice施工方法相比,现有的相关方法和评估他们的可重用性。

5.1。比较分析与相关方法

表8总结了现有的评价microservice配置方法和提出microservice配置方法根据规定的标准。定义的标准是参照microservice配置标准(16- - - - - -18]。microservice是定义为独立运作(独立),microservice接口通信包括(接口),业务执行能力,和独立的数据元素包含(数据存储)。

现有的相关研究表明,由microservice可以有一个独立的配置,但这显然不能确认是否只有一个业务逻辑或是否能有一个业务逻辑而不是一个独立的配置。然而,该方法执行独立配置和一个业务逻辑划分为3层。因此,它可以同时拥有一个接口和一个数据库元素相关的输入/输出在同一时间。

5.2。绩效评估

对于绩效评估,我们实现了“在线机票交易系统”的整体代码和microservices-based代码根据本文提出的方法,分别在同一个主机上,如图23。

如图24后,API执行时间测量应用程序部署环境。我们测量10、20、50、100、250、500年和1000年的每个迭代实现单片和microservices 0.1秒间隔测量最大值,最小值,平均值的API调用的响应时间。

表9显示了整体平均API调用和microservice实现。为应用程序执行时间减少意味着更高的吞吐量。

如表所示9,当API调用,平均API执行结构转换为microservices更快比整体结构在大多数迭代。图25比较的总平均执行时间为每个迭代的api。

如图25在单片的情况下,可以看出,执行时间迅速增加500次迭代和超越。相反,在microservices基于本文提出的方法,可以看出迭代性能稳定在500和1000年的迭代。

5.3。可重用性评价

microservice单位组成的一个应用程序可以单独更新,但不知道其他microservices的内部结构。这是因为microservices整体结构相比具有较高的可重用性。我们测量的可重用性度量microservices由应用该方法和相关的方法相同的整体应用程序(15]。内聚和耦合测量可重用性指标;高内聚和低耦合值表明高可重用性。图26应用设计数据的显示了结果的“在线机票交易系统”的案例研究DFD-based microservice组合方法(15]。虚线区域代表microservices配置,由共有九microservice单位分组到一个数据和流程。

可重用性度量测量使用的方法计算的内聚和耦合程度设计数据由面向对象软件设计(24];的方法计算方程所示的凝聚力是一样的(1)和(2)。是重量的总和的方法米基于米出现在组一个子集树。是获得的值除以样本值的加权和的属性与方法;它有一个样本值在0和1之间。TM是总数量的方法凝聚力(X)是由平均采样值的计算值。对于陈et al。15),属性被定义为数据,访问数据的方法被定义为一个过程,和凝聚力测量的程度。在我们的方法中,我们定义属性实体类和方法作为边界。我们还定义访问控制实体和措施的凝聚力。

表10显示了凝聚力的结果计算microservices构造通过每个配置方法。对于陈et al。15)、9组microservices构造。在该方法中,五组。和组体重的关系计算值与配置相关的组。

个人值,这是分裂的结果组权重之和的最大值的团体关系,如表所示11。的平均值microservice构造通过每个配置的计算方法。凝聚力的程度[microservice建造的15)是0.694,而microservice由该方法计算是0.823。

方程(3)显示了测量的计算方法的类之间的耦合程度。一个,D,我代表协会的类的数量、依赖关系和继承关系。关系越高,越高的类之间的耦合程度。此外,一个,b,c是不确定的常数,被认为是由开发人员或者设计师。在整体设计数据的情况下,不变的是1 0.5直接连接和间接连接。对于陈et al。15)之间的耦合程度,测量数据流程。对于microservices使用该方法,构造之间的耦合程度,实体和控制测量。

之和的综合测量设计陈et al。15)是计算为13.5,所表12。另一方面,在microservice设计数据的情况下使用该方法构造的,作为ev3-ev6直接连接关系,ev3-cv7,和ev4-ev8改为间接连接的新边界,它是计算为9.5,所表13。

因此,我们测量了内聚和耦合,可重用性因素microservices构建的相关研究方法(15),该方法。表14表明该microservice配置方法具有高内聚和低耦合和高度可重用。

6。结论

本文提出了一个方法,分析整体应用程序设计数据和构建基于容器的microservice单位。拟议的方法包括单片设计数据分析的过程,microservice提取、microservice实现和microservice部署。在整体设计数据分析阶段,整体设计数据收集和分为不同的类型。microservice提取的步骤,一个图是由类和关联分析;然后,一个实体单元microservice派生。在microservice实现阶段,microservices由层的实现。最后,在microservice部署阶段,我们创建了一个部署支持脚本,可以收集容器环境中部署环境元素和部署microservices基于集合的元素。

此外,我们进行了一个案例研究的每一步提出microservice施工方法。最后,我们证实了“在线机票交易系统,”这是一个庞大的应用程序,被配置为microservice单元和分布式和一个集装箱的基础上操作。此外,通过比较该方法与相关研究和评估microservices构造的可重用性,我们证实microservices发达在这项研究中优越的可重用性。

如果该microservice施工方法应用于现有的单一应用程序,它可以配置为一个基于容器的microservice单元以低成本。的优势是,在最初的容器环境,用户不需要手动生成模板脚本;他或她可以通过映射表生成一个模板脚本。因此,进一步发展serverless microservice单元的计算环境预计在未来。

特别是,未来的研究将着眼于开发一个监控工具来管理有效的容器操作后分发microservices由该方法和提高性能的API网关解决microservices之间的网络开销问题。

数据可用性

使用的数据来支持本研究的发现可以从作者在合理的请求。

的利益冲突

作者宣称没有利益冲突有关的出版。

确认

这项工作是由韩国国家研究基金会(NRF)授予由韩国政府资助(MSIP)和教育部(没有。nrf - 2017 r1d1a1b03030243)。

引用

1. 答:窗台上,“microservices的设计和架构,”IEEE云计算,3卷,不。5,76 - 80年,2016页。视图:出版商的网站|谷歌学术搜索
2. Amazon AWSλ,https://aws.amazon.com/lambda/?nc1=f_ls。
3. Azure函数,女士https://azure.microsoft.com/services/functions。
4. 谷歌云功能,https://cloud.google.com/functions。
5. 2018年云的状态报告,2018年,https://www.rightscale.com/lp/state-of-the-cloud。
6. 《福布斯》https://www.forbes.com/sites/louiscolumbus/2017/08/15/gartners -炒作周期- -新兴技术- 2017 -添加- 5 g -和-深-学习- - - - - - - - time/ # 272197 a05043。
7. c . m . Aderaldo n . c . Mendonca c . Pahl和p .卷“基准microservices架构研究,要求”学报2017年IEEE / ACM 1日国际研讨会上建立覆盖社区的基础设施架构的软件工程中页8日至13日,布宜诺斯艾利斯,阿根廷,2017年5月。视图:出版商的网站|谷歌学术搜索
8. Kubernetes,https://kubernetes.io/。
9. 码头工人群,https://docs.docker.com/engine/swarm/swarm-tutorial/。
10. 中间层,https://mesosphere.com/。
11. 即巴尔迪尼p·卡斯特罗k . Chang et al .,“Serverless计算:当前的趋势和开放的问题,”研究云计算的发展施普林格,页1 - 20,柏林,德国,2017年。视图:出版商的网站|谷歌学术搜索
12. c·埃斯波西托a马匹,K.-K。r . Choo“挑战microservices交付软件的云,“IEEE云计算,3卷,不。5,10 - 14,2016页。视图:出版商的网站|谷歌学术搜索
13. e . Casalicchio“自主编排的容器:问题定义和研究挑战,”第十EAI学报》国际会议绩效评估方法和工具2016年10月,陶尔米纳,意大利,。视图:出版商的网站|谷歌学术搜索
14. g . Mazlami j .急速地,p .莱特纳,“从整体软件架构提取microservices,”IEEE国际会议上的Web服务,40卷,不。11日,第531 - 524页,2017年。视图:谷歌学术搜索
15. s . r . Chen Li和z,“从庞然大物microservices: dataflow-driven方法,”24日亚太软件工程研讨会论文集(APSEC)南京,页466 - 475年,中国,2017年12月。视图:出版商的网站|谷歌学术搜索
16. f .随处s Sachweh, a . Zundorf“面向服务的模型驱动开发和microservice架构之间的差异,”《IEEE国际会议软件架构研讨会(ICSAW),页38-45,哥德堡,瑞典,2017年4月。视图:出版商的网站|谷歌学术搜索
17. n . Dragoni s Giallorenzo a . l . Lafuente et al .,“Microservices:昨天,今天,明天”现在和不可告人的软件工程施普林格,页195 - 216年,柏林,德国,2017年。视图:谷歌学术搜索
18. h . y . Yu对峙,m .《“一个基于microservice参考体系结构模型在企业架构的背景下,“学报IEEE先进信息管理、通信、电子和自动化控制会议西安,页1856 - 1860年,中国,2016年10月。视图:出版商的网站|谷歌学术搜索
19. o·穆斯塔法和j·马克思戈麦斯,“优化经济规划microservices的粒度级别”学报2017年ProWeb编程技术对未来的Web布鲁塞尔,比利时,2017年4月。视图:谷歌学术搜索
20. 码头工人,https://www.docker.com/。
21. 概念:Entity-Control-Boundary模式,http://ndpsoftware.com/OpenUpBasic/openup_basic/guidances/concepts/entity_control_boundary_pattern _uF-QYEAhEdq_UJTvM1DM2Q.html。
22. 基于Microservices Microservice-Architecture电子书:创建复合界面,https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout。
23. 邮递员,https://www.getpostman.com/。
24. 贝格,“面向对象的systems-derivation测量内聚和耦合和相互学习的内聚和耦合,”2004年,论文,蓝芽http://urn.kb.se/resolve?urn=urn nbn公司禁止:se: - 6010。视图:谷歌学术搜索

版权

版权©2020 Joonseok公园等。这是一个开放的分布式下文章知识共享归属许可,它允许无限制的使用、分配和复制在任何媒介,提供最初的工作是正确引用。