分布式云应用的导图生成方式比较

所谓应用导图，就是分布式应用内部组件的拓扑图，该拓扑图包含了组件连接成的网络和节点间的信息交互。AppDynamics、OpenTracing 以及 Netsil 等工具内部都使用了多种不同的应用导图绘制方法，近期有文章针对这些方法进行了综述。

可以把应用导图看做一个图，组件对应图的节点，而组件间的交互对应图的边。这里说的组件，可以单指进程(同一机器内部) 以及计算实例，或者二者的组合。如果是前者，进程间通信(IPC) 就是图的边，而这种通信又是架构在后者构成的网络之上。应用导图有很多重要特征，例如执行实例分组、提供应用级别的详细信息和错误率等关键度量指标的可视性等。

应用导图之所以重要，主要是因为对内部组件的观测、获取组件的依赖信息等，都离不开应用导图。应用导图可以快速定位问题根因，加快甄别监控和告警中的关键路径，同时，在数据驱动能力规划和潜在的安全问题方面，应用导图也可以发挥作用。

上述的文章总结了具体实践中导图的两种常用制作方法，即静态方法和动态方法，并详述了动态方法。通过追踪各种组件间的请求路径，导图生成软件可以绘制出分布式应用的应用导图。动态跟踪技术包含了端到端跟踪方式和个体跟踪方式。

应用性能管理(APM) 工具和代码仪表盘SDK 等工具都属于端到端(E2E) 跟踪软件，对这类工具来说，要么需要提供本地软件代理，要么能够直接修改远程应用源码，二者必选其一。 AppDynamic 、 Dynatrace 以及 New Relic 通过对代码做 profiling 和跟踪事务处理路径来创建导图。对 APM 工具来说，只要有新技术栈出现，就需要对其增加支持，这对新技术栈的广泛传播带来了较大的挑战。 OpenTracing 、 Datadog APM 以及 AWS X-Ray 这三个工具在发送请求时，会把唯一 ID 和元数据夹裹到请求消息的头部，来搜集组件间的相关性，以协助完成导图的构建。

端到端跟踪方式虽然可以跟踪到请求的精准路径，但代价巨大，因为追踪过程中会产生海量的数据，入侵威胁也会在路径集成时被引入，因为入侵不会影响到性能，所以这种入侵也不易被察觉。但是像 Zipkin 等工具已经专注于分析性能的微小波动了。

个体追踪 (也指 Ingress 和 Egress) 有两类数据源，即日志文件跟踪和系统级跟踪，这两类数据源相比动态方法中的技术栈来说波动较小，较为稳定。由于工作在网络层，个体跟踪技术可以把在网络上通信的组件一一进行绘制，也可以处理那些通过 E2E 方式不能追踪到的组件。但是，这种方法也有弊端，那就是由于其内在的低层次特征，在请求的生命周期内产生的特定数据包的上下文对于这种追踪方式来说并不明显，而且获取上下文的复杂性对于不同的应用软件来说不一样。所以这种方法对经过加密的调用请求无能为力，同时，为了找到数据和上层业务内部事务执行过程之间的相关性，引入深度的包检测机制是非常必要的。

查看英文原文： A Comparison of Mapping Approaches for Distributed Cloud Applications

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。