蓝科溯源

错综复杂，微服务架构面临挑战

第二个场景，用户使用用浏览器选择商品的时候，加载缓慢，影响了用户体验，位于AWS的Apache-Http-Server应用接受应用的请求，通过页面请求分析，发现DNS、建连很快，服务器的响应很慢，初步判断是Apache-Http-Server原因，进一步的分析发现Apache-Http-Server 调用了Inventory-Server这个应用，因为Inventory-Server的GoodsList.aspx接口使用本地类库出现了阻塞，导致了整个商品选择的性能故障。

随着架构的演进，近年来微服务的架构模式被更多的团队采用，当然这种架构也会面临一些挑战，服务节点多了，逻辑的拓扑会很复杂，调用关系变成网状结构，而且多个项目组件不再使用单一语言实现，例如前端Python、Ruby，后台Java 、.Net等，异构环境下为了实现高可用的服务架构，需要采用多种多样的通信机制来保证数据的高效传输。另外，在实际的运行过程中，服务一旦出现性能问题，如何回溯用户的问题，如何能够定位到底是前端渲染的问题，还是后端应用问题？如何实现复杂场景下的用户调用链追踪？这是微服务架构面临的挑战。

逻辑拓扑复杂，对服务节点的管理困难，难于用户调用链的追踪，有没有一些技术方案对调用链进行追踪实现性能问题定位呢？为了实现用户调用链的追踪，需要做几件事：首先需要生成一个Transaction ID标识用户的一次请求，然后将Transaction ID随着Http request向后传递，通过数据建模、分析将调用链理清楚。目前实现调用链的追踪可以采用如下两种方式：、需要研发把Transaction ID写到Log文件里面，多个应用的Log集中管理，如果是一两个应用的话还比较简单，可以通过脚本或一小段代码来明确它们的关系，如果分布式的微服务集群，问题会变得复杂，动辄几TB数据量以及错综复杂的调用关系，这时需要用专门的数据分析、检索工具。另一种方法是基于传输协议，从传输协议上作出一定的改变，对于Http协议，在Request Header中增加Transaction ID数据，经过网络传输，接收到该Transaction ID的服务记录下调用关系，并将Transaction ID继续向后传递，直到服务的末端；而对于RPC的协议，Dubbo attachment、Thrift body field 等都可以帮助我们实现调用链的追踪，从而定位性能问题。

根据以上内容如何形成一个体系结构？这涉及到了一个全新的概念——全栈溯源，在复杂的应用环境下，精确定位并判断网络、移动端、浏览器端、服务端性能问题根源的技术手段。

第三个场景，订单的提交失败，Apache-Http-Server的CI/commit服务提供订单提交业务，该接口调用了Fulfillment-Server的OrderGateway/order接口，OrderGateway/order在查询用户是执行了一条SQL，该SQL的执行平均消耗了20s的时间，导致了订单提交的失败。

那我们怎去实现APM？程序的世界都是有方法或者函数组成的，为了能够记录特定方法或函数的性能消耗，需要在方法或函数的开始取一个时间点，结束的时候再取一个时间点，可以知道这个方法或函数的执行时间，如果方法出错，收集错误信息。通过Tracer机制，将所有的这些方法的方法签名和性能数据串联起来，我们知道是什么导致一次请求的性能问题，这是实现APM的技术手段。

以前的场景，客户遇到问题会打电话投诉到客服部门，说某个服务不可用，运维去查应用环境（网络、硬件）有没有问题，研发去查代码的问题、DBA去查数据库的问题，这之间的过程中需要很多部门去协作，利用全栈溯源可以通过Transaction ID来还原用户使用场景，来定位是哪个环节出现了问题，降低跨部门处理的成本，提高工作效率，把以前几天的事情用几小时甚至几分钟来完成；以前运维老是背黑锅，而有了全栈溯源，能够清晰性能问题的界定，协助运维明确责任，协助研发修改问题，做到有据可依，以前需要查很多Log才能定位问题，现在可以直接通过全栈溯源直接定位到代码行级。我们下面来从案例看一下。

拨云见日，两种方法追踪根源所在

渐入佳境，APM记录问题根源

躬行实践，由APM实现全栈溯源

个场景是一个电商系统，通过App、浏览器登录、选择商品、下单、支付等行为。当用户通过App登录电商系统时出现了性能问题，通过全站溯源技术采集的数据，我们发现登录请求由App用户触发，调用位于Azure上的一个Portal的一个服务接口导致了登录的性能故障，而该Portal又通过Http的协议调用了一个Java的服务，该Java 接口的响应时间过长，导致终的问题。通过对该用户登录请求的追踪，发现该用户当时使用的手机的CPU和内存没有太大的变化，主线程对网络的请求消耗了很多，根据Tranaction ID向后追溯，发现是Java应用的这个接口调用了一个SQL，该条SQL的执行时间过长，导致了登录的失败。

我们刚提到两种方式实现但用户的追踪，一是研发修改代码，二是修改传输协议的方式。对于第二种方法，如果每个团队都修改一遍传输协议，不符合互联网思想。我们可以通过其他的方法去实现，通过多年的发展，我们发现了可行的技术解决方案，这个方法叫做APM，英文全称是Application Performance Management & Monitoring，即对应用的监控和管理，复杂情况下识别性能问题，保证服务的质量，这个概念为什么会用到，和性能测试有什么不同？性能测试只能发现测试的问题，APM则是在项目运营阶段实行的。

本文系2016年10月25日听云研发总监杨金全在OSC大咖说视频直播中的分享内容，点击文中视频链接即可观看直播视频回放，还可在文章底部下载本期大咖说嘉宾演示文稿。

利用Java Instrumentation、PHP Zend Extensions、IOS Hook和 Android Class Rewriting来实现性能采集代码的自动嵌入；将调用链维护到Tracer数据结构里，保证可能引起性能瓶颈的每一个方法都能够记录；那么怎么向Http Request Header、Dubbo attachment加Transaction ID呢？通过研究这些协议或框架的源码，识别出一些关键的核心方法，当这些方法处理请求时，创建Tranaction ID并存储到特定的数据结构里，然后向后传递，所有接收到Transaction ID的服务记录并关联，从而实现完整调用链记录。

【腾讯云】云上实验室：开发者零门槛，免费使用真机在线实验！>>>  

点击下面链接，即可下载本期大咖说嘉宾演示文稿哦！

【视频回顾】