skywalking 1.0-Final，如何追踪阻塞的调用？

       最近关注skywalking的爱好者们会发现，skywalking一直处于重构和编译失败的状态。这次专门发表这边文章，解释这次重构的原因。

       针对APM的应用监控，我们一般关注一下几个维度：

• 应用出错的异常点
• 应用调用速度缓慢的原因
• 应用各程序内部调用的时间分布情况、TPS
• 应用性能JVM相关参数和性能相关性
• 应用性能改进的目标和建议

        这次的改造，主要针对第二点中，应用速度缓慢的问题。skywalking之前的版本，包括现在国内主流的APM厂商，都是采用在调用链入口调用结束后，组装JVM内的调用树结构，发送到服务端。这种方式有利于组装数据，但是如果出现线程竞争阻塞、死锁，或者超长任务拖慢集群性能的时候，发送时间要远远晚于实际问题的发生时间。

        我们采用全新的策略

1. 保持原有的单个埋点进行单独发送的特性，即单个Span可以独立发送。
2. 原有的一个埋点发送一次的策略，修改为埋点执行前（RequestSpan）和执行后（AckSpan）各发送一次。

        此时监控程序、或者skywalking的扩展程序，可以快速的识别，Span的Request和Ack的配对情况，如果Ack长时间的无法到达，已形成配对，则说明当前埋点出现了超长时间的阻塞性事务，需要关注和告警。

        此时，监控告警程序，需要在特定时间窗口内，缓存RequestSapn，已期待Ack的配对情况。这里会消耗大量的内存，目前没有特别好的方法，目前是期待快速的匹配和清除缓存的模式，提高性能。