7.6　典型业务场景

1.服务实时监控

在应用服务化后的体系中，单纯对操作系统等基础架构层面的资源监控（比如CPU、内存、网络、磁盘IO等）已经很难满足业务的要求。在一定比例的系统出现问题时，这些基础设施层面的指标并没有异常体现，但实际的应用和服务已经不能正常提供业务服务了，这就需要对系统和平台的监控一定要细化到服务的粒度，对于服务的运行状态有一个更加及时、准确的管控。

对于服务的监控就是鹰眼平台的典型应用场景。鹰眼平台能够从各应用节点上收集到的这些日志信息，再加上处理效率极高的后端流式处理引擎，使得我们在分布式应用环境下，能够实时掌控服务运行的状态。

通过在应用的不同层次进行埋点日志的打印，鹰眼平台可以实现从应用入口、服务层、服务方法层的精细管控。

如图7-11所示，鹰眼平台对max-artist应用的HTTP入口请求中设置了埋点日志，所以该应用不管部署了多少应用实例，对于该应用的某一HTTP访问地址可进行实时的QPS访问、请求耗时的信息全局可视化。

图7-11　对HTTP请求入口的实时指标监控

同样，对于不同的应用可以设置不同等级的埋点日志信息和采样率，如果业务需要，可以将服务监控的粒度细化到服务中（如图7-12所示），让该应用的开发和运维人员对于该应用所提供的服务运行状况有一个实时、直观的感知，比如某一服务或方法的QPS、响应时间等实时指标。

图7-12　对服务接口和方法的实时指标监控

结合监控报警能力，鹰眼可实现到HTTP请求、服务粒度的报警规则设置，从实际表现来说，当服务运行指标出现异常时，该应用的运维人员接收到报警信息的时间是在秒级，真正做到比用户更早一步感知到系统异常，并快速修复。

图7-13　精确到HTTP请求和服务粒度的监控报警

正是因为有了鹰眼平台所提供的服务监控能力，才使得今天在阿里巴巴每天几千亿次的服务调用中，服务的开发和运维人员对于各自服务在线运行状况能够实时、准确的感知，同时也能在第一时间察觉到服务的异动，为快速的故障发现和及时恢复提供了基础的服务监控数据。

2.服务调用链跟踪

上面提到过，当在服务调用链上某一服务出现异常时，因为无法及时、清晰的定位出该服务到底是在哪一个业务场景或服务调用链、哪一次的业务请求中，所以产生异常很难定位问题，甚至出现无人为此负责的情况。

鹰眼平台中的服务调用链跟踪的功能真是针对这个问题的杀手锏。通过对服务调用时的埋点信息的收集，以及TraceID和RCPID的串联作用，给运维人员在Web界面上清晰还原出每一次业务请求所产生的服务链调用情况。

当开发或运维人员通过服务监控或接收到客服团队报来的问题后，运维人员除了可以通过发生异常服务器上的日志中搜索到对应的TraceID（服务在调用过程中一旦出现异常，会自动将TraceID等埋点信息打印到日志文件中），也可以通过应用、IP地址、服务名称、时间段等多条件组合查询的方式，搜索并定位在出现问题时间段内的服务调用链记录，如图7-14所示。

一旦搜索出问题对应的调用链记录后，则可通过平台提供的链路跟踪功能详细查看这次出问题的请求到底是在哪里。

图7-14　服务调用链查询界面

图7-15中以淘宝实际的一次业务请求所产生的一系列服务调用以及资源访问的链路展示情况。说明如下：

图7-15　服务调用链跟踪详细信息

·该视图的第一列应用名清晰地展现出这次业务请求所涉及的应用间服务调用关系，因为存在着一系列的服务嵌套调用，所以是一个典型的树形结构。

·第二列的IP地址列则显示了在此次调用链中提供对应服务的应用实例所在的服务器地址。

·第三列显示出服务调用的类型，是HSF的RPC服务调用，还是对Tair缓存的服务访问，以及数据库的访问等。

·第四列的状态显示出每次服务调用的结果如何，针对不同的服务类型有不同的状态标识，如OK、TIMEOUT、NOTEXSIT等，这样当查看某一业务请求到底是在链路中的哪个部分出现的问题，则一目了然。

·第五列是进行服务调用和访问过程中所产生的数据大小，为数据和优化提供数据支持。

·第六列是更精确地展现出到底是应用中的哪个服务以及方法在此次调用链中被调用，让开发和运维人员更快定位到问题。

·第七列是该业务请求整个处理时间，以及每一个服务调用所花的时间。

在定位到具体出问题的应用实例以及IP地址信息，就可以到对应的服务器上查看更加详细的日志信息，进行快速的故障定位和修复工作。

调用链跟踪除了对于系统出现问题时，起到快速定位问题的作用，也对应用的性能优化带来帮助。在分布式应用中，一次前端请求的响应时间已经不单单是在一台服务器上程序的处理时间，而是多个分布在不同服务器上的服务处理时间和网络上的传输时间的总和。如何定位出应用请求的响应时间太慢问题？也是很多技术团队在面对分布式应用场景下解决不好的一个问题。

通过调用链跟踪中对于一次请求中服务的调用关系，特别是服务调用的并行度以及一次请求所消耗的时间分布，对于定位应用的性能瓶颈点和优化有较大的帮助。

服务调用的并行度实际指的是在业务不受影响的前提下，进行服务的异步调用，使得多个原本依次调用的服务能并行执行，从而大大减少了整个的业务处理响应时间，如图7-16所示，在左图中，所有服务如果都是进行调用，调用并行度为0的情况下，整个处理时间为326毫秒；在右图中进行了服务并行调用的优化后，请求处理时间降低到188毫秒，单次请求处理时间减少了超过40%的响应时间。

利用调用链跟踪中对服务消耗情况的时间轴展现，对于服务调用链路中耗时较长的服务或资源访问（如数据库访问）一览无余，以图7-17中的链路示例，在整个链路中RCPID为0.23的服务消耗了204ms，占到了整个请求处理时间的1/3，开发人员就可针对这一耗时最长的服务进行相应的优化，找出该服务程序中的优化点，将该服务所消耗的时间减少到100毫秒，从而让整个链路处理时间尽可能降到最低。

图7-16　通过服务调用链跟踪优化业务请求处理并行度

图7-17　服务调用链跟踪快速定位性能瓶颈点

正是有了调用链跟踪这一功能，才使得阿里巴巴应用服务化后的平台从一个无服务管控的状态变成为一个具备真正可管可控的状态，形成了完善的服务化管控体系。所以，在今天很多的企业中，单单实现了应用服务化工作，但对于随之而来所需的服务管控能力考虑并不多，使得很多的应用和平台都运行在一个不可管控的状态，对于这一类的平台，从专业角度来说这些平台是一个不可用的状态，完全不能支撑起企业业务的进一步发展，同时也存在很大的运维隐患。

3.服务调用链分析

服务调用链跟踪的功能是对服务运行状态和调用关系进行实时呈现，在一定程度上满足了服务开发人员对于服务监控方面的诉求。但对于业务架构师所关心的服务间的依赖关系以及服务运行的持续稳定和优化并没有太大的帮助，所以在完成了服务调用跟踪的功能开发后，紧接着开发出针对业务架构师诉求的服务调用链分析功能。

在服务调用链跟踪数据基础上，给业务架构师提供了可按一定时间区域（比如一个月、三个月、半年等）对服务调用数据进行统计和分析的功能，让业务架构师对服务调用链有一个更加理性和由事实数据支持的业务决策优化。

在图7-18所示的服务调用链分析界面中，每一列都清晰地展现出服务调用链中有价值的统计数据。说明如下：

图7-18　服务调用链分析界面

·第一列显示了该调用链各服务的嵌套调用层次关系，使业务架构师可直观地看到业务请求所进行的一系列服务调用的顺序及嵌套关系。

·第二、三列显示了服务调用链中所调用的服务方法、服务以及服务所属的应用、不同资源（数据库、缓存、文件系统等）类型的操作，使业务架构师可清楚地了解当前业务请求所需要的服务和资源。

·第四、五列展现各服务或资源请求的QPS当前值以及所选时间段内的峰值。主要目的是让业务架构师对于各服务的历史峰值QPS有一个准确的了解，针对接下来的大促活动时，服务器的资源准备有一个更科学的理论依据。

·第六列的“调用次数”表示在这次调用链路中，对于同一个服务或资源的调用次数，通过该数值可以直观地看到当前调用链路对于哪些服务的依赖是比较多的，从而为接下来的服务依赖强弱提供参考。

·第七列“平均耗时”展现了在选定时间区域内，对于当前服务调用链各个服务或资源访问的平均耗时时间。这对于业务架构师是非常有帮助的信息，通过与调用链跟踪中单次服务耗时的比较，可以了解当前链路中哪些服务的响应时间处于比较稳定的状态，为服务的持续稳定提出更高的要求，同时也能从统计分析的角度，定位出链路中耗时的瓶颈到底在何处。

·第八列“本地耗时”指抛开网络层的会话建立以及数据在网络层的传输所花费的时间，更准确地显示出服务调用或资源访问过程中在服务器本地进行处理请求计算时所花的平均耗时。

·第九列的“依赖度”表示一次链路中调用某个依赖服务的几率的高低。

·第十列是对第七列各服务和资源访问平均耗时占整个业务请求链路总耗时的比例，更直观的展现出当前链路中各服务的耗时占比。

·第十一列主要用于对服务调用链路中强弱依赖的标记。对于什么是强弱依赖，还是以商品订单创建的链路为例。在整个订单创建的过程中会按照业务逻辑按顺序调用超过上百个不同的服务，在这些服务中，有些是否运行是否成功直接决定了这个订单的链路是否还能继续往下执行，比如库存检查的服务，如果发现订单中所买的商品数量超过了商品的库存，则库存检查会抛出库存不足的异常，订单后续的服务调用就应该停止，也就是说库存服务这个服务对于订单创建的链路属于必须执行，而且一定是要执行成功的，这个链路才能正常继续执行，我们将这一类的服务对于这个链路称为强依赖；而同样在订单创建链路中也会调用比如快递优惠（江、浙、沪免邮）这样的服务，设想一下，如果这个服务在订单创建链路中没有被调用，或者计算这个优惠的结果失败，最终导致生成的订单的价格并没有享受到快递免邮的优惠。从用户体验角度来说确实有一定影响，但从业务处理流程上，用户只要给卖家提出这个优惠的问题，让卖家在订单中扣减相应的快递费用，则最终成交的价格和快递优惠服务成功调用后的结果是同样的。我们把快递优惠这一类的服务成为弱依赖。

为什么将服务链路中的服务以业务的维度标示出强弱依赖的关系，一方面让对那些标记为强依赖的服务有更高的可用和稳定性的要求，另一方面用于今后的“限流降级”功能，参见第8章。

总体来说，服务调用链分析的功能是为业务架构师度身定制的一个统计分析功能，让业务架构师对于自己设计的业务链路在实际生产中的运行状况有一个直观的了解，利用分析出的数据可以更有针对性的优化业务链路流程或提升某些服务的服务质量，给用户提供更好的用户体验。

在某种程度上说，服务调用链跟踪的功能着重于对业务链路数据的实时监控，服务调用链分析则是对服务调用数据按照不同维度进行离线的统计和分析，两者相辅相成，很好地解决了服务开发人员和业务架构师针对应用服务化后服务管控的诉求，是阿里巴巴服务管控体系最为重要的两个核心功能。

4.业务全息排查

服务调用链跟踪功能上线后，成为了平台日常环境中，开发和运维人员用来实时感知服务运行状况以及定位故障和问题的最大利器，但慢慢发现服务调用链跟踪所展现的数据都是服务调用、资源访问等技术方面的数据，无法在调用链跟踪平台中查看到该调用链与之相关的业务信息，比如线上的某次系统调用异常，是由哪笔订单的什么操作引起的？这笔异常订单，是否由卖家对所对应商品的运费模板的某些异常操作导致？买家A在某段时间内分别进行了哪些操作，每次操作的调用链路是怎样的？这一系列关于订单、商品、买家与调用链间的关系也是开发与运维人员关心的。从实际解决问题的角度，如果有了调用链对应操作的业务信息，对于系统异常的定位会更加精准和快捷。

在这样业务需求的推动下，在服务调用链跟踪功能的基础上，阿里巴巴又实现了“全息排查”的功能。

所谓的全息排查系统，本质上是将服务链路信息与业务事件进行了集成，将业务事件通过服务调用链的traceID&rcpID进行双向关联。当业务事件发生时，在应用代码中将该业务事件所在的服务调用链路、所在服务的信息以及当前业务事件的信息以日志的方式输出，同样基于鹰眼平台中的Tlog日志处理引擎进行统一的日志收集和计算。在阿里巴巴的业务时间日志中包含了以下主要关键信息：

·“TraceId”将业务事件和鹰眼链路关联在一起的重要ID，用于定位该事件属于哪条鹰眼调用链路。如果日志中没有此字段，通过业务ID将只能查到用户配置的业务信息，但无法反向关联查找出匹配的鹰眼链路。

·“RpcId”定位该事件在这条调用链路中的位置，比如业务事件发生在哪个服务中。阿里巴巴中间件团队将获取当前上下文的TraceID和RpcID打包成了SDK并封装到了应用运行容器层，应用开发人员只需简单调用EagleEye.getTraceId（）和EagleEye.getRpcId（）来获取当前上下文中的TraceId和RpcId。

·“DateKey”该字段为必填，用于记录当前业务事件发生的时间。

·“业务主键”需要被查询的业务主键字段。比如一行日志中包含了交易订单id，会员id，商品id等，在此处配置一个或多个主键，随后即可在全息排查平台中通过该主键查询出这条日志的相关信息。

·“业务详细记录”上面的业务主键为查询的主键，业务详细记录则为被存储的键值。

在进行了业务事件日志的输出后，运维和开发人员就能通过“业务轨迹”的方式，在查看某一业务请求服务调用跟踪的同时，也能看到服务中所产生的业务事件以及相关业务主键，如图7-19所示，其中userid、item均为日志中的业务主键。有了业务事件信息的参考，能够更加清晰、快速定位出现异常的服务链路到底是哪一个用户在对哪个商品进行订单创建，可以查看到关键业务值在链路过程中的变化，也可用于业务正确的判断，同时也能从业务的维度进行用户行为的分析。

通过全息排查平台，将鹰眼平台从对跨系统调用追踪升级为跨业务领域追踪，走出了从运维平台向运营平台转型的重要一步。

图7-19　全息排查在系统中的展现

5.业务实时监控

相信在每年天猫双11的时候，在媒体上播放的非常酷炫的双11实时销售大屏给很多人留下了印象，随着大屏上实时变化和跳动的业务指标，比如实时交易金额、移动端比例、top10的热销商品、top10的商家销售排名等，这些实时业务指标的变化信息不仅能让运营或者商家对销售情况实时掌握，也可以基于这些实时业务数据进行精准类的营销工作。比如平台运营人员发现当前某一区域的移动端用户比例比较低，就可以采用向该区域的手机客户投放一定数量的红包，这在一定程度上可以达到提升移动端用户比例的目的。

这样的场景其实还有很多，而且我们也发现，有些数据在产生后的一段时间内如果不利用好，就会随着时间的推移其业务价值陡降（如图7-20所示）。比如之前例子中提到的移动端用户实时占比情况数据，在双11结束后再对这些数据进行离线计算和分析，所能发挥的业务价值就会大打折扣。

如何通过发掘数据的最高时效价值，为业务增长进行保驾护航的同时，帮助业务寻求潜在的增长点呢。传统的技术方案有两种，一种是直接访问在线交易数据库，但因为业务大屏展现所需的数据并不是简单地获取单个数据记录，还会产生大量的数据统计、排序、查询、计算等操作，这种方式很显然会对在线交易数据库产生非常大的压力，直接影响到在线交易数据库服务的性能，所以这种方案在实际中很少采用，因为没有人会选择为了实时展现业务指标的变化而牺牲在线数据库的正常服务。另一种方案是将业务数据从在线交易数据库通过ETL的方式同步到数据仓库或其他的数据库中，业务展现大屏通过访问数据仓库获取到相关业务指标和统计数据。这样的方案基本能做到准实时的效果，但如果数据更新量较大，会有较长的数据同步时间，也会给在线数据库带来不少数据同步的压力。从实际的案例来说，这一类方案能实现的业务指标一般是分钟级。

图7-20　数据价值随着时间会出现陡降

淘宝天猫双11大屏秒级实时业务指标的展现是利用分布式日志处理平台TLog的能力。其架构如图7-21所示。

图7-21　业务实时监控平台功能架构示意图

这次处理的日志就跟服务调用完全没有关系，所有的业务事件（订单成功创建、订单成功支付、用户登录等）日志都要求应用在这些业务事件发生时输出到日志中，再由TLog日志处理平台实现对这些日志从各个应用服务器上的采集，采用TLog提供的图形化日志处理流程的定制，将处理任务下发到流式引擎JStorm中，实现实时对采集到的日志内容进行解析和分类处理，按照业务大屏上所需的数据信息，将不同类型的数据保存到后端的在线数据库HBase或数据库平台中，最后通过API的方式给前端业务展示大屏提供数据的服务，就会实时展示双11的相关数据。

采用这样的方案就使得业务大屏对业务指标的实时展现完全不影响在线交易数据库，也能将发生的业务指标变化在秒级就体现在业务大屏上，有了这样的实时业务大屏，给市场运营人员提供了有价值的参考数据，如实时、精准营销策略或活动时计划等，真正对企业的运营提供了精准有效的数据支持。