端到端的性能分析方案对比

作者：吴志伟，新炬网络高级技术专家。

端到端的分析的技术方案有很多， 但其中我觉得相对靠普的方案有三种：

第一种方案是通过网络抓包解码的方式分析两个网元之间的通信，链路上承载了所有业务数据，借助于对业务数据的解析，我们可以具体到每一步的业务操作以及它操作结果、状状、延迟，通过会话关联，我们可以将每个业务操作关联形成业务流程，这种方案在发现性能问题时除了可以准确定位是那个业务的性能问题的同时，还可以协助用户分析是否是因为网络上其它业务量过大而导致网络阻塞延时，但这种方案也有它缺点，那就是系统部署成本较高，特别是针对流量大的网络，对千兆网络的抓包解码，不单单需要高性能软件支持，硬件的要求也是惊人，对于现在主干网常见的万兆、十万兆、百万兆，未来可能是万万兆，亿万兆，很难想像我们需要建设一个多大处理能力的硬件平台以及在这平台上搭建一个什么样的大数据处理系统，仅仅只是为了分析业务的性能，使用这么宏大的工具似乎有点杀鸡用牛刀。

第二种方案是通日志的分析，一直以来相关落地的方法不断的被提出来，最终又被否定，主要的原因在于，想通过日志分析业务性能，则首先要求所有端点都应该按一定的规则输出相应的过程处理日志，借助不同端点在处理某一业务时为其所打上的唯一标签，我们不仅仅可以从单一个日志中获取某一个业务处理步骤的结果、状态、延迟、过程情况，还可将每个业务处理步骤连成一体，获得整个业务流程健康指标情况。要建立一个统一的日志规格， 虽说并不是一件多难的事情，但要落地执行却实属不易，我们必须面临将所有的业务系统升级改造，这在完成自主建设的系统中或许可以尝试，但对国内多数用户来说，要求其所有软件的软件供应商做升级改造只能是一个美好的愿望，再者后续增加分析的内容亦有可能涉及增加日志输出信息，这是又是一个无底洞。尝试思考过这个问题的解决方法，或许可以通过对现有现有常用的开源日志工具进行封装，增加相应的日志标签处理，以及动态配置管理接口，这样一方面可以解决现在多数业务系统无须经过大改造就可以输出预期的日志数据，同时支持日志输出的扩展管理；近几年Splunk日志分析产品的出现着实让人眼前一亮，它证明通过纯技术的手段也是可以解决以往一直认为不可行的问题，但毕竞是巧妇难为无米之炊，没有数据源Splunk就算是神也无法分析出端到端之间的性能问题。第二方案的优点明显示， 只要你愿意，你可分析任何维度，任务粒度的数据，只要你将日志输出，当然它的缺点也非常明显“很难落地”，或者说“落不了地”。

第三种方案则是通过对中间件的业务处理逻辑进行拦截，这个方法早在10几年前就已经出现当时的Precise就是其中的佼佼者，但真正被人们所认可却是近几年的事情，纠其原因，并非当年Precise做得不好，应该说它做得很强，从浏览端到Web服务端，业务处理端，外部服务端，数据库端，操作系统端，存储端全线监控，并打通它们之间的关联性，实了从用户体验开始，钻取分析性能问题的原因，而之所以没有被人们接受，我觉得很大因素在于人们对于新生事物的接受，需要时间周期。在没有垄断者的领域有着供野蛮生长的土壤，正是有这段周期，后来者蜂拥而至，加上虚拟机技术的成熟发展，对虚拟机上运行着的业务处理逻辑进行拦截分析已不再是什么门槛， 但Precise也不是浪得虚名，几年下来能与Precise平起平坐的产品曲指可数。第三方案的优点在于它可以达到任何细的粒度，业务处理类的层面，函数层面，调用栈层面，这些信息已不单单用于位定业务性能，用于定位代码的性能也绰绰有余，它也有不足的地方，影响业务处理逻辑的性能，而且伴随分析粒度越来越细，消耗的性能也越来越大。