使用Apache Spark的微服务的实时性能分析和分析

使用Apache Spark的微服务的实时性能分析和分析

作为一种架构风格，微服务因其极高的灵活性，越来越受欢迎。应用程序在功能上分解为一组松散耦合的协作服务，通过定义良好的（REST）API进行交互。通过采用这些设计原则，开发团队可以以极其快节奏的方式独立开发独立的微服务。已知使用这种开发模式的组织将其部署从每天 50到300次更新......。

采用微服务的最大挑战之一是，虽然我们获得了单个微服务的敏捷性，但获得对系统整个运行（包括数十个交互微服务）的洞察变得更加困难。如图1所示，多个联网服务联合工作以生成对用户请求的响应; 应用程序执行的端到端视图对于快速诊断和解决生产部署中的性能下降问题至关重要。在具有数十个微服务（每个数百个实例）的应用程序中，越来越难以理解信息如何流经各种服务，其中阻塞点是什么以及用户所经历的延迟是网络的人工产物还是呼叫链中的微服务。

图1.应用程序是一个松散耦合的微服务集合，它独立于其他服务而发展。

鉴于对在云环境中运行的基于微服务的应用程序的性能分析工具的需求不断增加，我们正在尝试将实时性能分析器烘焙到平台基板本身的想法，类似于自动缩放，负载平衡等等。该服务通过捕获和分析应用程序中的微服务之间的网络通信以非侵入性方式工作。在云规模运营中，服务的分析方面需要实时处理来自租户应用程序的大量通信跟踪，发现应用拓扑，跟踪在网络上的微服务流动中的各个请求等等。由于我们需要运行批处理和实时分析应用程序，因此我们决定使用Apache Spark作为我们的大数据分析平台。

图2.使用Spark的简化性能分析系统

图2展示了一个简单的实验，我们通过这个实验来了解如何利用Spark进行运营分析。我们的设置包括一个Openstack云，一组基于微服务的应用程序，在不同的租户网络中运行，以及一个小的Spark群集。在每台Nova计算主机上安装软件网络抽头以捕获在租户网络内传输的网络数据包。从租户网络捕获的有线数据被压入Kafka总线。我们在Spark应用程序中编写连接器，将数据包从Kafka中提取出来并实时分析。

我们编写了Spark应用程序来尝试回答以下问题：

1. 在生成针对特定最终用户请求的响应时，信息如何跨服务流动？在IT运营分析领域，这种特定类型的分析操作通常被称为“事务跟踪”。
2. 给定一个时间窗口，应用程序中各种微服务之间的调用者/被调用者关系是什么？
3. 给定一个时间窗口，应用程序中各种微服务的响应时间是多少？

我们开发了两个Spark应用程序来回答这些问题：近乎实时的事务跟踪应用程序和批量分析应用程序，以生成应用程序的通信图和延迟统计数据。前者是在Spark的流式抽象之上构建的，而后者是由Spark作业服务器管理的一组批处理作业。

跟踪跨微服务的事务（或请求流）需要在应用程序中的微服务之间建立请求 - 响应对之间的因果关系。为了完全不知道应用程序，我们决定将该应用程序视为黑盒子。我们假设应用程序没有使用任何全球唯一的请求标识符来跟踪跨各种微服务的用户请求，我们设计了我们的系统。

为了追踪因果关系，我们对Aguilera等人在他们的2003年SOSP论文中对一个分布式黑匣子系统进行性能分析所采取的方法稍作了修改。对于同步Web服务，本文提出了一种嵌套算法，它将分布式应用程序表示为节点（服务）的图形，边表示节点之间的交互。嵌套算法检查服务之间的调用时间戳以推断因果关系。简而言之，如果服务A呼叫服务B，并且服务B在向A返回响应之前与服务C对话，则称对C的呼叫B _由_A到B的呼叫。通过分析一大组消息，我们可以通过统计置信度量度来导出跨服务的呼叫链，并消除不太可能的替代方案。本文中发布的原始算法旨在在大型跟踪集上以离线方式运行。我们修改算法以在分组流的移动窗口上进行操作，随着时间的推移渐进式地改进拓扑推断。

图3显示了事务跟踪应用程序中部分作业的工作流程。图4显示了由Spark应用程序推导出的租户应用程序中的事务跟踪。分组流以块的形式到达，以PCAP格式封装。从数据包流中提取各个流并将其分组为滑动窗口，即DStream。在给定的时间窗口内，通过比较标准五元组（src ip，src port，dest ip，dest port，协议），提取HTTP请求和相应的响应，形成下一个DStream，然后将其发送到其余的处理链实现嵌套算法（未在图中显示）。我们将事务跟踪应用程序的输出存储到时间序列数据存储（InfluxDB）中。

图3.实时事务跟踪应用程序中的处理阶段子集

图4.事务跟踪应用程序发现的跨微服务的事务跟踪的单个实例

第二个Spark应用程序是一个标准批量分析应用程序，用于在给定时间窗口内生成服务调用图以及调用延迟统计信息。该应用程序作为标准批处理作业提交给Spark作业服务器。如图5所示，批量分析应用程序将单个事务跟踪从InfluxDB中提取出来，并将它们转换为每个事务跟踪的成对列表。然后将这些列表聚合以形成两个RDD，一个包含顶点列表，另一个包含边缘列表。顶点列表根据顶点名称进一步去重。最后，应用程序的调用图以有向图的形式计算，以及有关图中每个边上的延迟的统计信息。此图是应用程序的时间演变图的一个实例，代表特定时间段的状态。图6和图7显示了批量分析作业输出的租户应用程序的调用图和延迟统计信息。

图5.批量分析应用程序中的处理阶段

图6.批量分析应用程序发现的调用图

图7.由批量分析应用程序计算的平均服务间调用延迟

Spark平台使我们能够使用统一的大数据平台构建不同类型的分析应用程序，如批处理，流式处理和图形处理。