本文整理自听云华南区技术总监黄八斤于 OpsWorld 运维世界大会题为《秒极时代下的全栈溯源》的分享。 大家好，我是听云华南技术黄八斤。今天分享的主题是 “ 秒极时代下的全栈溯源

本文整理自听云华南区技术总监黄八斤于OpsWorld运维世界大会题为《秒极时代下的全栈溯源》的分享。

大家好，我是听云华南技术黄八斤。今天分享的主题是“秒极时代下的全栈溯源”。首先来简单解释一下什么叫秒极，秒即响应需要达到秒，极可以认为是极致，就是互联网对于用户性能的追求是非常极致的。另外一个关键词是“全栈溯源”，刚刚其他老师分享时说到对于一些技术架构，无论是主机、带宽，还是业务系统，都有可能影响业务发展之后的性能，实际上我们应该走出去，走出数据通讯、防火墙、用户端，用全栈溯源的意思进入从用户端，到网络、到服务端的端到端追究，发现问题的根源。刚刚说的是技术架构层面的运维，接下来分享的是应用层，大家跟着我的思路走。

刚刚说到秒极时代，这里列了几组数据，互联网业务对于用户的体验，有一个8秒钟定义，如果我们的业务在互联网发布出去之后，如果用户访问时间超过8秒，有70%用户会放弃对业务的等待。还有一块是移动电商，如果电商页面加载时间超过3秒，会有40%客户放弃等待。像刚刚过去的“双十一”，包括马上到来的“双十二”，你们的系统能不能达到这么快的响应速度？既然需要秒极性能，相对应的就是我们需要有秒极平台，技术架构的平台正如下图右方所显示的那样

可以说是经过了三代，第一代是以计算为中心，主机的计算效率不是很高的时候，我们追求的是计算资源的高效。第二代平台以应用为中心，第三代平台是大家天天都在说的云计算、微服务，以大数据为特征，以用户体验为中心的平台。无论用公有云、私有云或混合云，最终是希望能够确保业务的发布令用户感觉很爽，所以我们应该站在用户的角度而不是站在我们自己的角度。

可能大家对于秒极时代的概念不是很深，刚刚也提到在业务上需要达到这么一个水平，实际上经过听云的大数据分析，我们已经进入秒极时代了。下图是传统PC Web页面发布的统计 分为门户网站、电商网站、政府网站、履行预订、网上支付、综合搜索，我们发现首屏时间，也就是比如我们打开百度搜索，第一屏充满整个屏幕的时间，这个屏出来之后就不会有太多的焦虑，这是一个对于用户体验来说非常关键的指标，现在首屏时间基本在2.3秒左右。

下图是移动互联网，今天讨论的是在移动互联网场景之下我们的业务真的能达到秒极水平，网络这一块的DNS、建连时间、首包时间、下载速度。这两组数据想说明的是无论你的业务是在PC时代，还是移动互联网时代，业务响应时间都要达到秒的水平，才有可能你的业务会被用户所接受。

但很不幸的是，我们现在面对的技术架构很复杂，这里有一组图片

左上角是模块化或者抽象化了的，用户访问移动互联网，通过移动互联网访问数据中心业务的全流程图。手机要连上后端业务，需要经过哪些设备或者经过哪些环节呢？首先是运营商的基站，然后到基站控制器，到信令网关，路由，DPI设备，再到防火墙等等，然后经过互联网，最后到达数据中心，数据中心有一大堆安全设备，接着过来是防火墙，然后是流量清洗、防护，然后到APP服务器，最后到数据库查询，然后再把请求响应回用户那里。大家肯定都比较熟悉《西游记》，唐僧取经无外乎如此，中间要经历很多磨难，一个用户的请求能到达你的服务器，能快速到达秒极响应，这是非常困难的事情，中间环节，网络拥塞、丢包都有可能导致用户访问不了或者访问慢，我们自己业务的发布、架构稍微有一些设计不好，都有可能导致用户访问响应非常慢，所以说想要确保用户秒极响应是非常难的。

我们怎么优化业务，达到这个水平呢？唐僧西天取经有个孙悟空，什么妖怪都能打，对于现实来说，我认为从前到后这一套东西，无论是技术架构，还是网络，包括业务系统，很少有一个牛人什么都能通吃，我们的业务需要优化，实际上也会涉及到很多方面，这个时候需要的是全栈溯源的解决方案，全栈溯源是应用性能管理领域耳熟能详的话题，要达到客户网络到服务端的整体性能监控，这是应用性能管理领域。应用性能管理简单来说就是对应用的网管。从用户，到网络，到服务，实际上有很多雷，我们把中间那些影响用户体验的叫做雷，这么多雷怎么排？这可能是你一直寻找的业务运维利器。

刚刚做了一个简单的铺垫，我们需要这么一个东西来确保达到用户的体验，今天分享的主题“全栈溯源”大概有三个方面，一是全栈溯源的含义，二是全栈溯源的价值对我们意味着什么，第三会以电商平台为例，来讲一讲怎么运用全栈溯源。

定义

全栈溯源指的是在复杂的应用环境下，精确定位并判断网络、移动端、浏览器端、服务端性能问题根源的技术手段，现在听云能够实现的端到端解决方案包括四个方面，大家可以想象一下，从用户角度出发访问我们的业务实际上也就几个入口，一是从浏览器过来或者是APP过来，这两个入口听云都有相应的解决方案，能够做到端到端全栈溯源，从移动端到服务端的性能溯源，从网络到服务端的性能溯源，从浏览器端到服务端的性能溯源，以及服务端跨语言跨应用的性能溯源。

价值

那么全栈溯源到底会给我们的工作带来哪些好处呢？一是会降低部门排障沟通成本，如果有一天用户投诉了，我们会是怎样的处理方式？有可能我们会找管网络的，有可能找开发，甚至我们会找云服务商、找运营商，这么多环节，这么多角色，等我们把问题定义出来，中间有很多信息沟通消化的成本，而全栈溯源会打通一个平台，让你从网络、应用、客户方面就能看到问题所在。二是能把对问题定位的效率，从以天为级别到以分钟为级别。比如登录慢、商品支付慢，简单几步，几分钟你就能发现问题的根源所在。三是能够很明确的帮你分析问题到底在谁那边，是你的网络还是业务或者是数据库的问题。我能很清楚的给到你数据源，把截图给到你，这就是你的问题，经过分析以后赶紧去解决。四是能够完整的对业务调用链进行追踪，全栈溯源是以用户为中心的，我们追究用户的每一笔交易，如果用户的交易失败了，交易超过了系统阈值，就会把整个行为追踪下来。

回到刚才我说的全栈溯源的四个方面，接下来会提供四个场景，来说一下全栈溯源达到的实际效果。场景一是我会模拟从手机客户端对服务端业务的访问慢，整个过程是通过HTTP调用的。场景二是模拟从浏览器端到服务端的业务访问，怎么定位商品选择缓慢这个现象。场景三是订单提交失败，从网络端到服务端的性能，到底哪个环节影响最终提交的失败。场景四是订单提交时跟后端多业务节点之间的调用。

场景一：登录缓慢——登录请求耗时过长

这是理想的电商大概系统图

前面是移动APP、PC，中间是我们发布的Portal，后端是业务节点，包括库存、支付、订单处理以及后端相关数据库的调用，这是理想的订单系统发布流程。但是一旦这个系统上线，尤其是像现在经常搞活动，版本经常迭代，版本上线之后会出现很多问题，问题出现之后怎么定位问题？这个时候我们就要有端到端全栈溯源来帮你处理。

通过APP访问业务系统，发现登录缓慢，缓慢在什么地方呢？有一天可能领导跟你说现在很多用户投诉，说登录非常缓慢，超过了9秒钟，我不知道现在怎么解决这个问题，会用什么思路来解决这个问题。如果拥有全栈溯源解决方案的话，登录了监控平台首先可以看到的是登录链接，总体用户响应时间超过9.1秒，并且发现DNS时间、TCP时间以及网络延时都很好，中间这一小块绿色的是首包时间。

通过这一点我们可以判断出来，网络是没有问题的，主要是在服务端有问题。服务端有问题，上面就会自动跳转，到底是哪个服务提供了登录呢？我们直接通过界面跨到Web应用过程，后来发现是SP.login这个后端服务提供了用户登录，同时这个服务当前这段时间的消耗又是由于一个外部调用，导致登录服务提供给用户最终的响应交互慢。至此我基本可以判断出来，登录应用Web服务调用组件影响了性能。但是对于用户而言，这一段时间影响了多少用户？每个用户在这段时间经历了什么？我们应该把现场还原，所以我们提供单个用户单笔交易追踪，可以看到用户当时打开登录页面的情况，这是手机APP监控画面


会提供详细的用户登录的是哪个页面，包括用户用的是哪个智能终端，在哪个省、哪个运营商，通过哪种方式接入的，以及用户打开页面时CPU内存的变化和一系列使用情况，到底哪些线程消耗怎么样，我们可以把它全部还原出来。在主线程里，网络访问花了将近12秒，同时用户访问时调了后端Login服务，在客户端就已经发现在访问页面的时候，用户的手机是不是有问题的，通过线程可以判断出来，用户方登录慢是因为网络访问慢，这里对于单个用户我们有跳转界面，这个应用端直接跳的是单个客户访问的是后端的哪个应用，以及应用实例名称，以及服务端的响应时间花了多少。追踪详情的话就会告诉你用户访问的时候，服务端组件是怎样的调用关系来响应用户登录请求的。这里我们看到有两个组件的请求，以及每个组件的消耗时间占比，通过消耗时间占比我们可以看到是哪个组件消耗了时间，99%花在认证请求上，花了9秒钟，这个请求又做了哪些事情？它同样有Web调用，调用的是认证服务器，认证服务器的应用过程是什么，当时这个服务器的应用性能是怎么样的，对后端服务器的性能同样分成几块，就是代码的问题、数据库的问题还是Web调用的问题，从这里看到当时它是数据库调用花了93%的时候，到这一步我们可以判断用户登录慢是因为数据库调用引起的。


再往下走，进入调用的第二个服务器，这个服务器是提供登录认证的服务器，我们高亮显示是哪个组件响应时间慢了，以及当时这个组件启用的是数据库查询，我们都把它抓取出来。



简单回顾一下，刚刚这个场景说用户登录缓慢，是因为用户做数据库查询登录的时候慢导致花了9秒钟时间。这是第一个场景，从移动端访问过来慢，我们通过全栈溯源的方式找到问题的根源。如果我们自己去发现这个问题有可能需要至少以天为单位，有可能一天都不一定能解决问题。

场景二：商品选择——库存查询缓慢

第二个场景，通过页面选择商品的时候慢，我们模拟了一个场景，首先是商品选择页面响应时间很长

同时通过监控同样把它切片一下，分为服务端响应时间、网络耗时、DOM处理、页面渲染四个部分，通过这个图就能看到服务端的响应时间很长，导致用户在商品选择时响应很慢，花了24秒。既然是商品选择，我们看一下后端提供商品选择服务，当时整个实际消耗就是商品选择页面响应用户请求时调用商品列表，商品列表的响应导致用户选择商品慢。从这一点来说，当前用户选择商品慢是因为列表反应时间很差。

对于每个用户的访问情况我们同样提供数据，我们会提供“慢页面追踪”

这个信息就是用户当时访问你的商品选择页面的真实情况，包括访问时间、访问哪个页面，客户端IP，以及接入运营商，地域等上下文信息，包括是从中国联通接进来的，用的是Windows7系统，这些数据都可以抓取出来。第二个是把它分成前端和后端，初步看，这个应用服务的响应时间花了将近30秒，从页面加载时序来看，用户访问页面是从上往下加载图片，每一个元素加载的时候我们同样把它切片出来，到底是DNS有问题，TCP有问题，还是服务端响应有问题。这里能看到，用户访问商品选择页面花了30秒，主要时间消耗在服务端响应，商品选择页面服务端的性能差了。

同样进入服务端，这是服务端提供用户商品选择的服务情况

当时用户请求时的商品详情组件执行花了21秒，这个组件当时也是做了外部请求，请求的是库存服务。从这个界面直接可以看到外部调用是库存系统里是哪个实例以及请求的应用过程是什么，以及当时服务器的IP地址，列表当时响应慢主要是应用层慢引起的，所以现在基本上可以判断出来用户商品选择慢是商品列表本身的应用代码有直接关系。我们从这个界面直接跳转到商品列表服务器的性能追踪，可以进一步追踪分析库存服务器响应慢具体是哪个代码引起的。所以，对于web页面访问慢，听云同样会提供全栈溯源的能力。

场景三：提交订单耗时过长

登录上去选择了商品，接下来的步骤就是放入购物车。全国用户访问我们的业务，出现高量红色显示时，这就是一个非常紧张的时刻，因为通过性能地图，越是红色代表你的性能越差，有可能搞一次活动，全国用户访问都差，估计大家的压力会比较大。面对这张全国地图，看到这么多红色，我们怎么去发现问题，到底是运营商的网络出现震荡引起的，还是我们自己的服务有问题引起的？可能我们心里有几个问号同时出现。


怎么快速定位呢？首先看到全国地图，点击任意一个省份，你会看到用户访问的散点图

每一个点代表的是一次用户的一个访问，纵坐标表示用户访问时间的分布，有30秒、60秒、90秒、120秒，大部分用户访问时间都在60秒，以秒极要求来说这个业务性能已经很差了，我们选择其中一个点，看到120秒响应时间，能看到用户来自哪个省、哪个运营商，把这些信息全部拿到。点击进去，用户做任意一个网上交易的过程经过了三个步骤，一是登录，这个步骤响应时间还是比较快的，第二个步骤是商品选择，大概也就20秒，最后一块在订单提交的时候花了将近30秒，这个过程慢，全国为什么性能都是红色呢？就是因为我们在订单提交的时候慢，如果提交不了订单，我相信所有活动相关的投入会受到非常大的损失。我们会把订单提交这个步骤的页面加载还原出来，把整个加载耗时切片化，从客户端的渲染，到网络，到服务端，这里看到的是服务端慢，大部分颜色都是红色区域，服务端有问题，我们可以通过跨应用追踪按键直接跳到服务端进行性能分析。

到服务端，看到的是订单提交服务组件在响应用户的请求，这个组件的执行花了27秒，它调用了订单提交网关，我们可以展开看到当时这个外部调用的详细信息，包括调用的URL，调用的实例信息，以及被调用时订单提交网关的性能分解，主要数据库调用耗时，数据库调用占78%的时间，所以我们基本上判断是数据库的问题。当时用户提交订单的时候，订单提交网关响应组件的执行，以及执行慢的现场数据，都把它抓取出来。整个过程用户提交订单慢，我们同样告诉你慢在什么地方、什么代码上，进行代码级别的精确的抓取。所以，网络端到服务端访问慢的场景，听云提供全栈溯源的能力可实现快速问题分析定位。

场景四：用户信用校验——JMS消息处理缓慢

提交订单过程还有另外一个步骤，会涉及到要对用户的信用等级做校验，可能会调用征信系统，如果用户提交订单，这边响应很好，接下来会调用征信系统，这边是订单提交服务器，它会调用征信网关，通过JMS这种方式，订单提交服务器调了JMS外部请求，当时订单征信网关的时间主要是在外部响应上，同样我们进入到订单征信系统做分析，当时这个服务器也有外部调用，调用的是第三方支付网关，看到这里，我的订单支付很缓慢，有可能是第三方支付网关的问题，可以尽快找他们协商解决。

以上我通过四个步骤，从用户登录、商品选择、订单提交，到最后支付，从不同场景下接入进来，定位从前端到网络、到服务端的问题。我举的例子都是跟服务端相关的，也有一些是程序代码质量问题导致了崩溃，错误等问题，这些我们同样可以精确到代码级别的定位，时间关系就不展开了。

通过部署听云全栈溯源解决方案，针对前面提到的电商架构图，我们可以自动的呈现系统调用业务逻辑拓扑，这个图就是系统抓取出来的，业务交易从前到后的架构是怎么样的，通过前端的Server，到后端的应用服务器，把它全部拓扑出来。同时通过不同颜色区分调用业务逻辑中各应用节点的性能，如果性能差，会用红色显示，告诉你当时整个用户交易过程就是服务节点性能差了，你可以点击这个节点往下钻取。这里展示的是每个应用节点自身的响应时间、吞吐率、错误率，还有它跟外部接口时间调用的响应时间和吞吐率，针对这个图，你很容易看到当前业务信息流的流转到底怎么样，哪些地方有拥塞，哪些地方有性能响应时间很长的情况。

针对单笔用户的交易，我们同样会提供逻辑拓扑图，告诉你这个用户的本次请求，他调了后台哪些应用节点，我觉得这是很有必要的，因为对于单个用户来说后端有那么多服务，他这次访问到底调用了哪些业务节点呢？这样可以更加直观的帮助排查问题。

今天我把听云的解决方案，尤其是全栈溯源这一块做了很全面的解析，为什么我们能做到全栈溯源呢？因为听云有四款产品，包括以听云APP、听云Network、听云Browser这三个负责前端监控的产品，以及听云Server这个负责服务端监控产品，全栈溯源的简单原理就是，负责前端Web监控，App监控和网络监控的产品，与负责服务端监控的产品，通过全局唯一的标识ID做性能数据的关联，实现针对性能问题的精确到代码级别的端到端追踪。这也是今天这个秒极时代，听云推荐给大家的业务级运维利器。