A framework for monitoring microservice-oriented cloud applications in heterogeneous virtualization

异构虚拟化环境中面向微服务的云应用监控框架

摘要

微服务[1]已经成为开发和部署云应用程序的一种新方法，这些应用程序需要更高级别的灵活性、规模和可靠性。为此，基于微服务的云应用架构提倡将单一的应用组件分解为独立的软件组件，称为“微服务”。由于独立的微服务可以彼此独立地开发、部署和更新，因此会带来复杂的运行时性能监视和管理挑战。为了解决这个问题，我们提出了一个通用的监控框架Multi-microservices、Multi-virtualization、Multi-cloud（M3），用于监控在多云环境中跨异构虚拟化平台部署的微服务的性能。我们使用跨AWS和Azure执行的书店应用程序验证了M3的有效性和效率。

1. 介绍

最近出现的微服务体系结构对web应用程序的开发、部署和持续维护做出了重大改变。与传统的单一应用程序体系结构（整个应用程序构建为一个单一的统一系统）相比，微服务方法将应用程序分解为几个独立的可执行软件组件或单元，这些组件或单元一致地互操作以提供特定的应用程序功能。轻量级的基于REST的APIs[2]-[4]等方法已经被广泛采用。基于微服务的应用程序体系结构还通过最小化软件单元之间的代码依赖性，增强了DevOps[5]-[7]的设计理念。

A. 研究内容

尽管将单一应用程序分解为轻量级微服务简化了与代码更新、维护和持续集成相关的DevOps过程，但它并不能解决与持续的性能管理和监视相关的问题。要将其上下文化，请考虑与书店应用程序相关的应用程序部署场景，如下所述。

图 1. 分布在多个云数据中心的微服务的示例场景。
图1说明了基于微服务架构的书店应用程序的概念实现。书店应用程序是一个多层栈，包括（i）用户界面，（ii）图书搜索/购买，和（iii）数据存储。用户界面（UI）部署为web微服务，负责接收用户请求并返回要由智能手机应用程序或浏览器呈现的内容。Book和Purchase层部署为多个应用程序微服务，实现搜索库存与/或处理采购请求的业务逻辑（例如信用卡交易管理、用户通讯簿管理、与分销和航运公司的协调）。另一方面，数据存储部署在多个数据库微服务中，用于管理输入和输出数据集。
为了提高用户数据的安全性以及执行数据隐私条例，如欧盟通用数据保护条例（GDPR）[8]，书店应用程序的所有者可以决定将微服务分布在多个私有与/或公共云环境中。例如，与信用卡交易和用户通讯簿管理相关的微服务更可能部署在安全的私有云数据中心上。另一方面，与当前图书库存相关的微服务更可能部署在公共云数据中心上。因此，向上述微服务（通讯簿、库存等）提供数据所需的数据库微服务也需要分布在公共和私有云数据中心。尽管如此广泛的微服务分布导致了安全性和隐私性的提高，但正如下面讨论的那样，它使正在进行的性能管理和监视复杂化。

• 在多云环境中，微服务的部署环境非常复杂，因为有许多组件在异构环境（VM/container）中运行，并使用基于REST/REST-less的APIs频繁地相互通信。此外，由于微服务类型（例如CPU密集型与I/O密集型与内存密集型）的异构性以及其他竞争性微服务造成的资源干扰[9]-[14]，部署在多云环境中的此类基于微服务的应用程序的性能可能会有很大变化。
• 由于不同的虚拟化环境实现了不同的方式来为微服务分配资源限制，这使得性能监视问题变得复杂。与具有自己的客操作系统的基于hypervisor监控程序的虚拟机（VM）不同，容器化微服务的资源分配是根据与其他容器共享主操作系统的命名空间和cgroup定义的。此外，与总是严格（硬）的VM相比，容器中的资源限制可以是硬的或软的。软限制允许容器超出其分配的资源限制，从而产生更高的干扰几率[15]，[16]。

B. 研究贡献

目前，有多个监控框架，如docker stat[17]、cAdvisor[18]、DataDog[19]、Amazon cloud watch[20]、CLAMS[21]，可用于监控云中运行的应用程序。然而，大多数框架要么是特定于云提供商的，例如[微软Azure结构控制器]，要么是特定于虚拟化架构的，例如cAdvisor。这些监控工具无法满足跨多个云数据中心部署的复杂微服务的性能监控需求。
基于上述挑战，本文提出研究问题：

• 如何监控部署在分布在不同云数据中心的异构虚拟化平台上的多个基于微服务的应用程序的性能？

为了回答上述问题，本文做出了以下新的贡献：

• 它引入了一个新的系统，多微服务（Multi-microservices）、多虚拟化（Multi-virtualization）、多云监控（Multi-cloud）（M3），它提供了一种整体方法来监控部署在多个云数据中心的基于微服务的应用程序栈的性能。
• 它基于一种基于分散代理的方法来实现M3系统，这种方法提供了独立监控异构云环境（例如，不同的虚拟化和云服务提供商平台）的能力。M3与云无关，因为它实现了自己的API栈，用于网络、通信和管理监控数据。
• 它在一个包含Amazon Web服务和Microsoft Azure Cloud的真实测试平台上验证了提议的监控系统M3。详细的实验分析验证了我们提出的M3监控系统的有效性。

本文的其余部分安排如下。第二节论述了近期的相关工作。第三节介绍了M3的系统设计，第四节给出了M3概念实现的证明，第五节讨论了实验评价的结果。最后在第六节提出了今后的工作建议。

2. 相关工作

Docker[17]提供了内置的监控工具Docker stats，用于检查正在运行的容器的资源使用指标。Docker stats提供的各种度量是基本的CPU、内存、块I/O和网络参数。Docker stats捕获容器的总体性能，但是部署在容器中的多个微服务（如果有的话）可能会导致性能下降，这是无法捕获的。cAdvisor[18]是一个开源框架，它还监视给定不同系统参数的容器的性能。但是，它需要为在使用额外系统资源的分布式云环境中执行的每个应用程序栈组件多执行一个容器。
有一些特定于云的监控框架可用，如Amazon CloudWatch[20]、Azure Monitor[22]。这些框架是特定于平台的，只能监视预期的平台，即Amazon Cloud Watch只能监视部署在Amazon云环境中的主机，而不能监视Azure环境中的主机。一些其他的商业监控框架，如DataDog[19]、Prometheus[23]，都是云不可知的，但提供的功能有限。DataDog是一个基于代理的系统，它只向DataDog服务器发送数据，而Prometheus将结果存储在时间序列数据库中。它们都只支持容器，而且支持也仅限于某些特定的云提供商。
学术界也提出了各种监控框架来捕捉不断变化的系统性能。在[21]中，Alhamazani等人。CLAMS是一个面向多云平台的应用监控框架。该模型检索不同云层的QoS性能。但是，它们的监控框架仅限于监控VM性能。此外，该模型仅用于监视web应用程序。在[24]中，作者提出了PyMon框架，该框架使用Docker管理API为网络边缘设备收集系统资源。但是，它可能无法监视VM性能。除此之外，还有一些基准测试框架可用于监控特定的系统参数[25]。
如上所述，现有的监控解决方案无法监控在多虚拟化异构云环境（container/VM）中运行的微服务的性能。我们提出的工作（M3）与上述解决方案不同，因为它可以用于监视在分布在多个云环境中的容器或vm中运行的微服务的性能。
表 1. 相关工作的比较

表一列出了不同相关工程与我们建议的M3的比较。

3. M3系统的设计

提出的M3系统由两个主要部分组成，即监测管理器和监测代理。监视代理放在跟踪底层微服务性能的每个容器/VM中。监控代理不关心底层vm/容器是同构的还是异构的，或者部署在哪个云基础设施上。监视代理收集每个服务的系统级统计信息，并将信息发送给管理器。部署在远程服务器上的管理器从不同的监视代理收集信息，并将这些数据存储在相关的数据库中，以便进行进一步的性能分析和管理。
下面将详细讨论监控代理和监控管理器的设计和工作。

A. 监控代理

监控代理是一个软件组件，它从运行在容器/vm中的微服务收集信息。它能够在不同的云平台上工作。代理将等待来自管理器的请求将监视信息推送到管理器。M3使用HTTP请求作为在代理和管理器之间传输信息的通信系统。

图 2. 监控代理模型（a）；管理器和代理之间的通信模型（b）。
监视代理打包到jar文件中，并配置为在容器/VM启动过程中运行。所有监视代理都扩展了一个公共代理，称为SmartAgent，它由两个组件（SystemAgent和ProcessAgent）组成，如图2（a）所示。SmartAgent代表一个由三个操作组成的服务，首先必须使用“PUT”请求将代理注册信息发送给manager。接下来，代理将使用“POST”请求定期向管理器发送数据。最后，代理配置将使用“GET”请求发送到管理器，该请求可以更新代理配置参数。SystemAgent作为一个整体监视系统，例如容器或虚拟机，而ProcessAgent监视在该系统上运行的特定进程。代理使用SIGAR提供的功能来检索微服务指标和其他定制的API。SIGAR有助于获取特定微服务的信息参数。使用这些功能，代理监视每个微服务的指定功能。在收到管理器的请求后，所有信息都会推送到管理器。

B. 监控管理器

监控管理器是一个软件组件，它从分布在异构云环境中的容器/vm中部署的代理接收监控信息。它还提供了一个API，用于访问数据库和其他服务或应用程序保存的数据。管理器和代理之间的通信基于拉或推机制。管理器使用“RESTLet”库来构建访问代理服务的客户机。对于每个注册的监视代理，管理器启动一个线程，该线程协调“RESTLet”客户端以访问代理数据。每次接收到监控代理的数据时，管理器都会将结果存储在MySQL数据库中以供进一步分析。
使用图2（b）所示的一系列步骤，可以在监控SmartAgent与监控管理器之间进行信息传输。首先，SmartAgent向管理器发送注册请求，管理器接收该请求并注册SmartAgent，访问密钥和端点随返回给SmartAgent的数据一起发送。其次，manager executor（使用Push技术）能够使用其IP地址接收SmartAgent发送的数据并获取指标。最后，SmartAgent定期查询管理器的配置（更改配置）。动态配置支持实时代理管理。
监控代理使用RESTful APIs发送指标信息。有多种方法可以将数据从代理传输到管理器。传输M3支持的数据的两种最常见的架构是（a）集中式架构和（b）分散式架构。在集中式体系结构中，管理器位于中心，所有代理与管理器只有一跳距离。经理和代理人之间有直接的联系。这是最简单的沟通方式，但可能会导致一点失败。为了避免这种情况，M3还支持分散式体系结构，其中每个云都有一个本地监控管理器，从所有常驻容器收集信息。存在一个全局管理器，它从所有本地管理器收集信息。

图3数据采集模型
微服务监控的完整过程以数据采集模型的形式表示，如图3所示。它由三个步骤组成，最初由系统管理员启动监视代理（步骤1）。此外，管理员将代理注册到管理器（步骤2）。接下来，代理持续监视系统（微服务、容器或vm）。最后，所有监视代理定期将监视信息发送给管理器（步骤3）。管理器将接收到的数据存储在共享数据库中，并处理与微服务性能相关的任何查询（如果接收到）。

4. 实现

我们提出的监控系统M3是用Java实现的，它适用于运行在任何主机操作系统（Linux、Windows或Mac OS）上的容器和vm。这些代理是使用SIGAR（https://github.com/hyperic/SIGAR/）和RESTLet（https://RESTLet.com/）库实现的，这些库允许它们在任何云提供商上运行。SIGAR是一个用Java编写的多平台库（Unix、Windows、Solaris、FreeBSD、Mac OS等），它提供了访问操作系统信息的API，而RESTLet是一个Java库，它使开发HTTP REST APIs变得容易。M3系统使用SIGAR获取各种系统参数，即CPU使用率、内存使用率、空闲内存、网络使用率等。RESTLet用于开发监控代理的服务，允许管理者访问代理的监控数据。
管理器和代理都有一些严格的网络要求。管理器必须部署在具有全局IP地址的计算机上，以便代理可以从任何网络访问管理器。每隔30秒，代理查询（GET）管理器以下载其配置文件，确保动态配置。管理器和代理之间的通信仅通过HTTP进行，以避免任何安全或防火墙阻塞。管理器可以动态更改代理的数据转发速率，以管理网络上的请求过载。
在我们的实验中，我们考虑了第一节中讨论的书店应用程序，它使用三种类型的微服务实现，即Tomcat、MySQL和Nginx。这些微服务在分布在多个云上的vm或容器中执行。书店应用分为三层，第一层为用户界面服务（Web层），第二层为购书服务（应用层），第三层为存储服务（数据存储）。在用户界面中，我们考虑了两个微服务（Tomcat、Nginx）。在Book and Purchase服务中，我们有一个或两个微服务（Tomcat和MySQL）。在存储服务中，我们有一个微服务（MySQL）。用户接口服务接收来自JMeter的请求，使用HTTP与图书或购买服务通信，应用层将使用JDEC库（SOCKET network）与数据库通信。当选择一本书时，用户界面接收一个HTTP请求并将其转发给图书服务。Book服务接收请求，向MySQL发送查询，并向用户界面返回500个实体。购买服务接收来自JMeter的请求，将购买保存在MySQL中并更新book实体。

图 4. 模拟web应用模式
我们使用Apache JMeter（HTTP s://JMeter.Apache.org/）生成HTTP请求来测试M3系统的性能。测试由100个用户组成，每个用户有不同的请求。我们生成900个请求来模拟用户的行为。每一个图书选择请求得到500个实体。我们做了三个测试，用监视代理读取1秒、5秒和10秒的数据来捕获度量。实验评估期间的操作和请求如图4所示。所有请求都由Apache JMeter发起，它模拟用户（req。1） ，或模拟另一个应用程序（req。4） 是的。选择各种类型的请求是以覆盖数据持久性服务中的主要加载操作类型为前提的，即：数据查询、插入和更新请求，以及由代理中介的请求。JMeter发出的所有请求都是“GET”类型的。第一个请求流侧重于查询操作，由指向用户界面服务的请求1启动。用户界面通过Nginx web服务器接收请求1，nginxweb服务器充当代理并将其转发给Tomcat（req）。2） 是的。用户界面Tomcat接收请求并创建一个新的“GET”请求到Book服务（req）。3） 是的。请求3由图书服务的Tomcat接收，该服务对MySQL（req）进行查询。6） 是的。第二个请求流负责插入和更新操作。请求4由JMeter发起并定向到购买服务。采购服务Tomcat接收“PUT”请求（req。4） 用于插入购买。这个请求被分解成另外两个：请求5和请求7。请求5使用图书服务作为中介更新库存中的图书数量。请求7将购买插入MySQL。

5. 实验评估

基于第四节中讨论的定义设置，我们对我们提出的监测系统M3进行了实验评估。测试应用程序在容器和VM环境中跨Amazon EC2和Microsoft Azure部署。为了证明M3系统的有效性，我们通过改变工作负载配置来测量不同的系统参数，例如CPU、内存、延迟，进行了一系列的实验。
Amazon EC2和Microsoft Azure机器都运行Linux操作系统Ubuntu:16.04（https://www.Ubuntu.com/），其中安装了Docker平台（版本17.06.1-ee-1）（https://www.Docker.com/）来执行微服务。Azure的VM配置是StandardA1v2，有1个vCPU和2 GB内存。我们考虑了四个这样的虚拟机。Amazons VMs是t2.micro类型的，每台机器有1个VCPU和1 GB内存。在这里，我们还考虑了两个vm用于我们的实验。
为了模拟上一节讨论的书店应用程序的行为，vm和容器使用不同的软件安装。对于web服务器，我们选择了Tomcat（版本7）（http://Tomcat.apache.org/）和Nginx（版本1.13.7）（https://Nginx.org/en/），而对于数据库，我们考虑了MySQL（版本5.7）（https://www.MySQL.com/）。使用的所有容器镜像都是从Docker Hub（https://Hub.Docker.com/）门户获取的。
表 2. 部署在容器和虚拟机的微服务场景

进行实验的机器配置如下：第一台机器在虚拟机客操作系统上使用Java（版本8），第二台机器安装了Docker平台并使用了Docker Compose文件（版本1.18.0），我们为tomcat使用了一个镜像（https://hub.Docker.com/-/tomcat/）和（https://hub.Docker.com/-/mysql/）对于MySQL，第三台机器使用与第二台机器相同的配置，不同的服务，最后一台机器安装了Docker平台，并使用Docker Compose文件，该文件由两个镜像组成：第一个镜像用于Tomcat，第二个镜像用于MySQL。在Amazon上，我们使用了两台机器，一台使用Java虚拟机，另一台安装了Docker平台，应用程序使用Docker Compose文件，由Tomcat的一个镜像和Nginx的一个镜像组成。
我们在以下三种情况下评估了提议的系统，如表二所示：

• 场景01—在Microsoft Azure（表示为M）中部署的一个VM中部署两个用于图书和购买服务的微服务（Tomcat和MySQL）。另外，一个VM为用户界面服务运行两个微服务（Nginx和Tomcat），部署在Amazon Web服务中（表示为A）。
• 场景02–我们为在第一个容器中运行的图书服务部署了两个微服务（Tomcat和MySQL）；为在另一个容器中运行的购买服务部署了两个微服务（Tomcat和MySQL）；所有容器都部署在Azure（M）中。除此之外，我们在一个容器中为用户界面服务部署了两个微服务（Tomcat和Nginx），该容器部署在Amazon Web服务（A）中。
• 场景03–我们为在第一个容器中运行的图书和购买服务部署了一个微服务（Tomcat），并在另一个容器中部署了运行数据库的微服务（MySQL）；所有容器都部署在Azure（M）中。此外，在Amazon Web服务（表示为（A））中部署了一个VM，该VM为用户界面服务运行两个微服务（Nginx和Tomcat）。

我们进行了一些实验，在这些实验中，管理器将推送有关在两个公共云上运行的服务的系统级和进程级统计信息。对于结果分析，为管理器获得的指标与所有JMeter测试相关。如前所述，JMeter测试生成900个模拟工作负载的请求，以验证代理捕获所有三个场景的性能指标的能力。
表 3. 所有场景的请求结果

A. 延迟时间结果

M3分别每隔1、5、10秒测量每个场景（如表III所示）中工作负载请求的平均延迟时间（以毫秒为单位），以及向管理器发送监视信息的代理。为延迟捕获的值清楚地显示了多云环境中多虚拟化（容器/虚拟机）情况的计算差异。如我们所见，与（S1）和（S3）相比，（S2）中的用户界面服务具有最小的平均延迟（最大2.296持续10秒）。这背后的原因是（S2）使用容器体系结构，而（S1）和（S3）使用VM体系结构。此外，对于图书和购买服务，与（S1）和（S3）相比，（S2）获得更好的性能。总之，S2为所有场景提供了最佳性能。结果表明，在多个云中使用每个服务的容器架构可以更有效地利用虚拟机的硬件。

B. CPU结果

所有场景的CPU值如图5所示。在分析S1时，在整个工作负载测试期间，所有微服务都在VMs中运行，并在Azure和Amazon中提交。监控代理分别每隔1秒、5秒和10秒向管理器发送监控信息。如图5（A）所示，Tomcat在Amazon中10秒的用户界面微服务不会像1秒和5秒中观察到的那样受到影响。这背后的原因是，与manager每1或5秒发送一次的情况相比，它的持续时间更长。实验结果表明，监控代理能够针对不同的微服务获取正确的CPU数据，显示了M3的有效性。亚马逊用户界面Nginx微服务在1秒内的平均CPU使用率最高，为2.10%；Tomcat用户界面在1秒内的平均CPU使用率最高，为1.80%。相比之下，在Azure中运行的所有微服务的平均CPU使用率最高的是MySQL的5秒（7.10%），而Tomcat的1秒（7.05%）则相差不大。
在Azure容器中评估S2时，对于在容器（C1）中运行10秒的图书服务，Tomcat microservice的CPU平均使用率最高为6.80%，而对于在购买服务的容器（C2）中运行10秒的Tomcat，CPU的平均使用率为6.60%。对于10秒内在容器（C1）中运行的图书服务的MySQL微服务，CPU使用率为4.90%；对于5秒内在容器（C2）中运行的购买服务的MySQL，CPU使用率为4.10%。但是，运行在由Nginx和Tomcat微服务组成的Amazon容器中的所有微服务的CPU平均使用率在所有1、5和10秒的持续时间内几乎相同，为7.00%，如图5（B）所示。
对于S3的评估，Amazon中Nginx用户界面微服务在10秒内的平均CPU使用率最高为1.90%，Tomcat在10秒内的平均CPU使用率也最高为1.90%。但是，Tomcat微服务在容器（C1）中运行的CPU在10秒内的最高平均使用率为5.80%，在1秒内的最高平均使用率为5.10%。MySQL微服务在容器（C2）中运行10秒，CPU使用率为5.45%，5秒为4.50%，如图5（C）所示。

图 5. （A）Amazon和Azure中的VM，（B）Amazon和Azure中的容器，（C）Amazon中的VM和Azure中的两个容器上的微服务的CPU使用率（百分比）。[为了便于演示，我们使用了以下缩写Nginx（N）、Tomcat（T）和MySQL（M）]。

图 6. 微服务的内存使用（MB）：（A）Amazon和Azure中的虚拟机，（B）Amazon和Azure中的容器，（C）Amazon中的虚拟机和Azure中的两个容器。[为了便于演示，我们使用了以下缩写Nginx（N）、Tomcat（T）和MySQL（M）]。

图 7. 管理器的CPU使用率（百分比）（A）和内存使用率（MB）（B）

C. 内存结果

内存消耗的结果显示了有关监视两个公共云的代理的度量值的统计信息，如图6所示。通过使用M3，我们可以从复杂的多层应用程序中收集细粒度数据，并可以了解微服务的性能。例如，如图6（A）所示，在运行在Azure VMs中的S1中，Book and Purchase服务的微服务（Tomcat和MySQL）的最高平均内存使用量在5秒内几乎相同（1025 MB），而在10秒内，Tomcat使用1010 MB，MySQL使用的是VM总内存的1022 MB，后者为1912 MB。与运行VM的Amazon相比，用户界面的microservices（Tomcat和Nginx）在10秒内使用的最大内存量相同，为215mb，而在5秒内Nginx使用了205mb，Tomcat使用了VM总分配内存992mb中的206mb。如图6（A）所示，Azure上的内存消耗大于Amazon。Azure上更大的内存使用可以用两个云之间的虚拟硬件配置差异来解释。此外，用户界面服务只将请求转发给Book服务，Book服务做更多的处理，因为它处理MySQL查询，并将结果转换为JSON对象，然后发送给底层服务。
对于S2，如图6（B）所示，在Azure中运行容器，MySQL microservice在10秒内为容器（C2）中的购买服务使用的最大内存量为476mb，为Tomcat在10秒内为容器（C2）中的购买服务使用的最大内存量为469mb。容器（C1）中购买服务的MySQL microservice在10秒内的使用量为469mb，容器（C1）中购买服务的Tomcat在10秒内的使用量与容器（C2）中的Tomcat microservice相同，即容器的总分配内存（1920mb）中的使用量为469mb。与此相反，在Amazon中运行容器的用户界面的所有微服务（Nginx和Tomcat）所用的最高内存量在10秒内都是相同的，为425mb，而在5秒内（Nginx和Tomcat）则没有太大不同，这两个微服务的内存使用量相同，为393mb，在1秒内Tomcat使用382MB，而Nginx使用了容器的内存总量（992 MB）中的372 MB。
在S3中，如图6（C）所示，运行在Azure容器中的Tomcat microservice在容器（C1）中的图书服务和在容器（C2）中的购买服务的MySQL microservice在10秒内的最高内存使用量相同（471 MB），而在容器（C1）中的Tomcat在5秒内的最高内存使用量为280 MB，在容器（C2）中的MySQL在5秒内的最高内存使用量为279 MB，容器的总内存为1912 MB。与在VM中运行的Amazon相比，用户界面的microservices（Tomcat和Nginx）在10秒内的平均内存使用量是289mb，Tomcat在5秒内的平均内存使用量是277mb，Nginx在5秒内的平均内存使用量是230mb，而VM的总内存大小是992mb。
为了测量由管理器引起的开销，我们进行了一个实验，在这个实验中，管理器进程被监视CPU和内存的使用情况，同时注册了越来越多的并发代理。数量从2到64个并发代理。从performance manager获得的越来越多的代理的结果被绘制在CPU和内存上，如图7所示。结果表明，代理数量的增加对CPU使用率（A）和内存使用率（B）的增加都有影响。在2到64个并发代理之间，CPU利用率增加了20%，而在16到32个代理之间增加了更大的幅度。内存的使用有一个更为线性的行为，从2个并发代理增加到64个并发代理。
结果表明，在Docker和VM中使用M3模型部署微服务是有效的。我们的贡献是验证在多云服务中监视多虚拟化，以及在运行微服务的多进程容器和vm中监视单个进程的可能性。

6. 总结

在本文中，我们提出并部署了一个基于多虚拟化（containers/VMs）和多微服务的新型应用监控系统M3。提出的解决方案使用户能够监视在容器和vm中运行的微服务的性能，并实时报告其度量性能。该解决方案使用基于代理的体系结构，以便从集中式体系结构扩展到分散式体系结构，以满足监视此类复杂的基于服务的应用程序的需求。我们使用一个书店应用程序开发了一个概念验证实现，该应用程序在Amazon和Azure云环境中部署了Docker容器和vm。该系统在不同的场景下进行了评估，评估结果验证了M3在多虚拟化多云环境中监控微服务的有效性。在未来，我们将使用M3从生产就绪的系统中收集大量数据，以便为微服务开发高效的部署和编排策略。

参考