分布式请求跟踪系统设计与实践
2019-09-20 02:22:17   来源：东方头条   

微服务带来的困境：

1、某个核心服务挂了，导致上游出现大量的报警，如何快速确定哪个服务出现了问题？

2、核心服务挂了，导致大量的报错，如何快速确定哪里出了问题？

3、应用程序有性能瓶颈，怎样确定是有哪些服务导致的？

4、App端请求相应延迟高，怎样确定是有哪些服务导致的？

5线上发布了服务，怎么知道它一切正常，比如发布8台服务器，如何直观了解是否有请求进来，访问是否正常？

微服务请求调用路径：

如何解决：

1、业务端查看日志，排查问题。会耗费大量的时间与精力，未必能够快速有效的解决问题；

2、分布式跟踪系统

分布式跟踪系统：

源于Google Dapper论文：《a Large-Scale Distributed Systems Tracing Infrastructure》

开源产品：PinPoint、Twitter Zipkin、APache SkyWalking、大众点评：CAT、京东Hydra

设计目标

低消耗性：跟踪系统对业务系统的影响应该做到足够小。对于使用方透明，在一些高度优化过的服务，即使一点点损耗也容易察觉到，而且有可能迫使在线负责的部署团队不得不将跟踪系统关停

低侵入性：作为非业务组件，应当尽可能少侵入或者无侵入业务系统，对于使用方透明，减少开发人员的负担

时效性：从数据的收集产生，到数据计算处理，再到最终展现，都要求尽可能快

灵活的应用策略：可以根据需求，自定义收集数据的范围和粒度

决策支持：这些数据是否能在决策支持层面发挥作用，特别是从DevOps的角度

数据可视化：做到不用看日志通过可视化进行筛选

实现功能

故障快速定位

调用链路跟踪，一次请求的逻辑轨迹可以完整清晰的展示出来。

各个调用环节的性能分析

调用链的各个环节分表添加调用耗时，可以分析出系统的性能瓶颈，并针对性的优化。

数据分析

调用链是一条完整的业务日志，可以得到用户的行为路径，汇总分析应用在很多业务场景

分布式跟踪系统使用场景

1、调用链跟踪，一次请求的调用过程的展示，以图形化的方式梳理出各个微服务集群之间的调用关系，并记录整个调用过程的耗时情况，协助开发人员分析整个系统的瓶颈点与热点，从而优化系统；

2、调用链路分析，对多条调用链进行分析，整理出集群之间的调用关系，计算出整个调用链路的关键节点、直接依赖、间接依赖、依赖程度等；

3、调用来源分析，针对某一特定的集群，整理出其他集群对其的调用情况，防止错误调用情况的发生；

4、调用量统计，实时统计各个集群的调用次数、QPS、平均耗时、最大耗时等信息，开发人员根据相关信息进行容量规划；

5、监控请求调用量，实时监控调用次数、QPS、平均耗时、最大耗时、最小耗时等；

整体架构：

1、埋点和生成日志：java探针（javaagent技术）通过本地socket将收集到的数据发送给本机的日志收集节点agent，将本机上多个中间件的日志数据发送到日志收集服务器集群；

2、收集和存储日志：日志收集服务器对数据进行格式化处理后，分成三个工作流进行后续处理；

3、分析和统计调用链：原始数据直接存入ES集群，用于页面实时调用链展示；原始数据存入本地日志，通过FLume上传到HDFS集群，利用Hadoop集群定时进行离线分析，分析后结果存入ES集群，用于页面数据分析展示；原始数据发送到Spark在线分析集群，进行QPS、平均耗时等实时数据统计，分别将统计结果保存到Redis集群与ES集群中，用于页面实时数据统计展示；