在混合云中管理微服务的6大性能挑战

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

在回顾企业应用程序的历史时，我们发现多年来出现了几种趋势。 在90年代中期，我们将应用程序构建为大型且整体的，因为它们注定要发布到非常大型且垂直可伸缩的机器（例如大型机）上。 即使应用程序已从大型机迁移到更灵活的语言（例如Java和大型服务器），我们仍然希望节省内存，因此将我们的应用程序部署为大型企业归档文件（EAR文件）是我们的最大利益。

当我们发现虚拟化并能够在多个虚拟机上运行我们的应用程序时，我们将应用程序分解为可单独部署的服务。 这些服务在面向服务的体系结构中得到了普及，它们具有不同的角色，但是它们仍然是大型部署，因为我们要运行的虚拟机数量有限。 虚拟机的价格比物理服务器便宜，但是与它们相关的成本仍然很高。 然后云进入，我们能够灵活地扩展和缩小虚拟机来满足我们的负载，因此我们进一步细分了应用程序。 基于云的虚拟机的启动速度仍然相对较慢，尽管以秒或最多几分钟为单位进行了度量，这使我们意识到了部署服务的粒度。

在过去的几年中，利用Docker等技术引入了容器化，这鼓励了我们将应用程序分解为微服务。 微服务是一种非常小的服务，具有定义明确且开放的接口，可以做一件事并且做得很好。 这种范式的转变为我们带来了许多好处，其中主要是：

–独立部署
–独立的可扩展性
–隔离且可重复使用的功能

从应用程序管理的角度来看，微服务使我们可以更频繁地进行部署，并且与构成应用程序的其他组件隔离。 例如，如果我们构建用户配置文件服务，则只要我们维持接口协议，我们就可以自由部署它，而不会无意间破坏应用程序的其他部分，例如我们的网站甚至是身份验证服务，而这可能直接取决于在我们的用户个人资料服务上。 换句话说，构建用户配置文件服务的团队可以与我们应用程序的其他组件分开部署，并以不同的发布时间表进行部署。

此外，由于每个微服务都与其他应用程序组件分开部署，这意味着我们可以独立扩展微服务。 如果我们的认证服务比用户配置文件服务承受的负载大得多，那么我们可以部署更多的认证容器。 微服务鼓励我们经常部署，这有助于我们实现长期以来一直追求的敏捷性和精益性。 微服务架构可以产生数百甚至数千个微服务，这在管理这些微服务的部署和性能方面带来了新的挑战。

本文回顾了管理微服务性能的六个挑战：

–在整体应用程序中管理单个微服务
–集中管理整个应用程序中的多种微服务
–管理依赖于我们的微服务的整体业务交易的绩效 –在新的弹性世界中管理我们的微服务的性能 –管理在跨公共云和私有云的混合云环境中运行的微服务 –管理托管我们的微服务的容器，例如Docker

管理单个微服务

我们使用的术语“业务交易”是与应用程序的重要交互，例如登录，向购物车中添加项目或签出。 在微服务体系结构中，业务交易可能与数十个微服务交互，并且单个微服务可能会被数十个不同的业务交易调用。 取决于应用程序的客户体验，我们评估业务成果是否成功的最重要的度量单位是度量业务交易的性能，但是由于业务交易需要数十种微服务，因此，单个微服务可能不会出现在业务交易级别。

此外，我们鼓励我们以高弹性构建应用程序，因此，如果微服务不可用或超时，则我们的业务交易可能会正常返回，但会丢失一些信息。 图1显示了四个业务事务，每个事务调用两个不同的微服务。

图1：调用多个微服务的多个业务交易

因此，最好的策略是全面衡量业务交易的性能以及单个微服务。 作为微服务所有者，您不仅要识别调用微服务的所有业务交易，而且还想要评估微服务的性能，而与分布式应用程序环境无关，捕获与微服务有关的性能问题的详细快照。 。 图2显示了这种聚合视图的示例。

图2：AppDynamics服务端点仪表板

此仪表板显示关键性能指标（KPI），例如单个微服务的每分钟呼叫数，平均响应时间和每分钟错误，并提供对包含微服务的业务交易异常执行时捕获的快照的访问。 为了有效管理微服务的性能，您需要隔离微服务，并在调用它的所有业务交易中分析其行为。

管理多种微服务

如上所述，微服务体系结构必须将应用程序分解为不同的小块，并通过将数十个这些块拼接在一起来组装其业务功能。 细粒度的服务提供了上面讨论的许多好处，但是这种类型的体系结构确实意味着您的应用程序可能包含数百甚至数千个微服务。 管理如此多的微服务的规模和规模之大，否定了手动对其进行性能监控和设置实际服务水平协议（SLA）阈值的手段。 考虑将每个服务手动注册到性能存储库并定义实际的性能标准将是多么不堪重负–可以做到，但是在这种规模下，它将花费大量的时间和精力，并且在定义数千个性能预期时微服务，您肯定会遇到至少一些错误！

因此，解决方案是采用一种监视技术，该技术可自动发现应用程序中的所有微服务并为每个微服务的性能构建基准。 基准标识了微服务的“正常”行为，应根据您的用户行为进行配置。 例如，如果您的服务在周五早上的负载比周日下午的负载更多，那么您希望将周五早上的微服务行为与历史性的周五早上的正常行为进行比较。 进行比较之后，如果服务行为异常，则可以发出警报，捕获说明问题的方法级快照，然后开始进行故障排除。 更好的是，您可以配置一个规则来启动更多微服务实例，以快速修复问题。

关键是，微服务架构中部署单元数量的绝对规模需要自动化解决方案。

衡量绩效整体业务交易

在前微服务时代，单个业务交易由少数几个服务调用组成，但是今天，同一业务交易可能会调用数十个微服务。 结果，了解应用程序的性能很复杂，并且可能是一项艰巨的任务。 衡量应用程序性能的最重要指标是业务交易的性能和可用性。 商业交易绩效回答了关键问题：用户是否能够在可接受的时间内完成其业务目标？ 如果答案是“是”，则您的申请成功，您的公司正在赚钱。 如果答案为“否”，则您的申请受到了威胁，您可能会亏本。

衡量业务交易绩效的策略是（1）正确识别启动业务交易的“入口点”，（2）捕获业务交易中每个“层”的响应时间，其中层是由来自的呼叫定义的一项服务与另一项服务之间的关系，（3）构建每层以及整体业务交易的绩效基准，并且（4）将业务交易及其层的当前响应时间与适当的基准进行比较。 基线会因用户和应用程序的行为而异。 共同的基准包括：

–一天中的小时：如果您的应用程序在上午8点收到的负载多于上午2点，则应将当前响应时间与一天中的同一历史时间进行比较

–一周中的一天：如果您的应用程序在一周中的不同日期承受不同的负载，则应将当前响应时间与一天中同一小时但一周中同一天的响应时间进行比较（比较上午9点）周一至历史记录（周一上午9点​​）

–每月的某天：如果您的应用在当月的不同日期承受不同的负载，例如银行应用程序在人们于当月15日或30日获得付款时可能会承受更大的负载，那么您需要比较当前对每月某天的该小时的历史响应的响应时间

一旦为您的业务交易确定了适当的基准，就可以根据基准评估当前响应时间，以确定性能是否正常。 图3显示了一个示例，该示例将业务交易的当前响应时间与其基准进行比较，并在响应时间大于平均值的两个标准差时发出警报。

图3：警告异常行为

应针对业务交易以及构成这些业务交易的层创建基准。 从微服务的角度来看，每个微服务调用将代表业务交易中的一层，并在该业务交易的上下文中具有自己的基准。 通过此策略，您可以了解用户是否能够实现其业务目标，以及在特定业务交易的上下文中您的微服务是否正常运行。

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

管理弹性环境的性能

通常，公共云（例如Amazon Web Services（AWS），特别是容器化）最强大的功能是弹性伸缩的能力。 随着负载的增加，容器的数量（运行微服务的实例）可以增加，而随着负载的减少，容器的数量也可以减少。 此外，这种弹性可以由性能规则来驱动，而无需任何人工干预。 容器化使此过程比传统的虚拟化效率更高，因为容器可以在几秒钟内启动，而虚拟机则可能需要几分钟才能完全启动。 这意味着集装箱化可以在需要时提供额外的弹性。 由于这种动态弹性，某些容器可能会整天运行，而其他容器可能只运行几分钟。

这使性能监视具有挑战性，因为随着容器或节点的来来往往，很难在其关联的业务交易的上下文中跟踪节点。 结果，您的监视解决方案可能会认为您有数千个节点，其中大多数不可用，因为这些容器已停止并重新启动了几次！ 因此，解决方案是跟踪并保留容器在其上运行的瞬态节点的历史行为。 停用并随后重新启动容器后，它可以从上次停止的地方开始取走，而不会丢失过程中的历史数据。 这减少了监视解决方案中无意义的节点的数量，并为您提供了给定容器的持续历史性能。

在混合云环境中运行的微服务

将微服务部署到基于公共云的环境是许多公司试图实现的强大解决方案，但是与任何新技术一样，采用过程可能会缓慢且分阶段进行。 业务和合规性规则可能要求某些组件保留在公司自己的数据中心中，例如那些管理PCI和PII信息的组件

大多数大公司已经在基础架构上进行了大量投资，因此立即迁移到公共云并出售现有基础架构没有任何意义。 许多公司没有完全拥抱公共云，而是使用OpenStack或MesoSphere之类的技术在自己的数据中心中建立自己的私有云，然后将其部署拆分到自己的私有云和公共云中。

既包含私有云又包含公共云的部署称为混合云环境，它会带来一系列挑战：

–私有云中的硬件与公共云中的硬件不同，因此同一容器的一次部署在私有云和公共云中的执行可能会有所不同。

–许多绩效管理解决方案将自己限制在一个数据中心内，这意味着您的某些绩效数据可能位于一个位置，而另一些可能位于另一个位置。 当确实出现性能问题时，在不同环境中进行故障排除可能会很困难，因为您不知道哪个环境托管着所需的数据。

–此外，许多业务交易将在私有云和公共云之间来回传递，并且为了完全评估应用程序的性能，您需要构建整个应用程序的整体视图。 这种混合环境如图4所示。

图4：混合云部署

此示例说明了大概从Web应用程序调用或来自移动应用程序的服务调用开始的单个业务交易如何轻松地跨越私有云和公共云。 从部署的角度来看，管理混合云的最佳策略是采用单一容器化技术（例如Docker），以便可以使用抽象底层环境的工具将微服务轻松部署到私有或公共云。 从监视和性能管理的角度来看，执行以下操作很重要：

–在业务事务级别监控性能，以便您全面了解应用程序行为

–跨数据中心（私有云和公共云）遍历呼叫时跟踪业务交易

–监视托管微服务的容器的性能

–捕获有关您的微服务正在其上运行的节点的信息，以便您能够考虑底层硬件的差异

这就是说，您需要在业务事务级别上监视应用程序，包括在整个混合云环境中运行的组件。 您需要能够隔离单个微服务的性能，以便检测那些服务中的系统性问题。 您需要了解私有云中运行的基础硬件与公共云中运行的硬件之间的区别。

微服务和Docker

微服务和容器化是齐头并进的。 您不想为每个微服务指定一个完整的虚拟机，而是希望在虚拟机集群之间安装容器化技术，并让该容器化技术按其认为适当的方式分发容器。 在撰写本文时，最流行的容器化技术是Docker，因此本节专门介绍Docker。 监视在Docker容器中运行的微服务时要做的重要事情是：

1.监视微服务本身的性能

2.监控运行微服务的Docker容器的性能，并将容器的行为与微服务的性能相关联

3.监控Docker集群的运行状况

我们已经全面审查了监视微服务性能，这既是业务交易的一部分，又是单独的隔离端点。 图5显示了我们想要收集的有关Docker本身的信息类型。

图5：监控Docker

图5显示Docker环境包含三个正在运行的容器以及总共53个不同的可用映像（映像是我们可以从中运行容器的二进制“模板”）。 顶部的图表显示该环境配置为运行三个容器（容器数），并且我们可以从历史上看到随着时间的推移已经运行了多少个容器。 底部的四个图表显示了有关正在运行的容器的综合性能指标：

–总CPU使用率
- 内存使用情况
–每分钟网络传输兆字节 –网​​络每分钟接收兆字节

能够捕获此类信息非常重要，这样您才能知道何时向上和向下扩展环境。 例如，如果我们正在运行最多10个容器中的5个，并且这5个容器的平均CPU利用率高于80％，那么我们将希望启动更多的容器来处理负载。

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

翻译自: https://www.javacodegeeks.com/2017/05/top-6-performance-challenges-managing-microservices-hybrid-cloud.html