10.1 Spring Cloud 全链路监控概述
在传统的SOA架构体系中，系统的调用层级不多，调用关系也不复杂，凭借系统的异常信息，可以比较快捷的定位到问题并进行排查。但是在微服务的系统中，服务数量成百上千，服务之间的调用关系成网状结构，无法通过人力进行问题的排查，在这种情况下，一个完善的调用链路监控系统就显得至关重要。
10.1.1 全链路监控背景
在微服务的架构体系下，服务按照不同的维度进行拆分，一次请求可能会涉及多个服务，并且可能是由不同的团队开发，甚至是由不同的编程语言开发，有可能分布在上千台服务器上，横跨全球不同的机房。因此，我们需要一种工具，可以记录每个请求的调用链、调用链上调用每个服务的时间、各个服务之间的拓扑关系，以便发生故障时，可以帮助我们快速的定位和解决问题。
现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》(https://research.google.com/pubs/pub36356.html )，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。国内，淘宝的“鹰眼”、京东的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是这样的系统。
Dapper论文中对一个分布式追踪系统提出了如下设计目标：
- 低消耗：跟踪系统对在线服务的影响应该做到足够小。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
- 应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，