使用 Spark 进行微服务的实时性能分析（使用苦舍恒）

使用 Spark 进行微服务的实时性能分析（使用苦舍恒）

作为一种灵活性极强的构架风格，时下微服务在各种开发项目中日益普及。在这种架构中，应用程序被按照功能分解成一组松耦合的服务，它们通过 REST APIs 相互协作。通过这个设计原则，开发团队可以快速地不断迭代各个独立的微服务。同时，基于这些特性，很多机构可以数倍地提升自己的部署能力。

因此，Spark 应用被编写试图来回答下列问题：

对终端用户的请求响应时，信息流是如何通过服务的？在 IT Operational Analytics领域，这种分析操作通常被称为“事务跟踪”。在给定时间窗中，应用中各种微服务之间的调用/被调用关系是什么？在给定时间口中，应用中各种微服务的响应时间是多少？

根据以上问题，这里开发了2个 Spark 应用程序：1个实时事务跟踪的应用程序和1个批量分析应用来生成应用的通信图和延迟统计。前者基于 Spark 流抽象，后者则是一组由 Spark 作业服务器管理的批处理作业。

跟踪不同微服务之间的事务（或请求流）需要根据应用程序中不同微服务之间的请求-响应对创建因果关系。为了完全不受应用程序，这里将该应用当作一个黑盒。因此不妨认为应用程序中没有利用任何全局唯一请求标识符来跟踪跨微服务的用户请求。

为了追踪上文所提的因果关系，这里采用了 Aguilera 等人在 2003 SOSP 论文中提出的一种对黑盒分布式系统进行性能分析的方法，并做细微的修改。对于同步的网络服务，论文提出了一种 nesting algorithm，将分布式应用程序表示为一个图，各条边代表节点之间的相互作用。这个 nesting algorithm 会检查服务之间的调用时间戳，进一步推断其因果关系。简单地说，如果服务 A 调用服务 B，而 A 在返回响应之前会和服务 C 通信，那么服务 B 呼叫 C 被认为是由 A 调用 B 引起的。通过分析一大组消息，这里可以得到服务间有统计性置信度的调用链，并消除可能性较小的选项。论文发表的原始算法旨在离线方式下操作大型的跟踪集。这个用例会修改该算法来操作数据包流的移动窗口，并慢慢逐步完善的拓扑结构推断。