全链路压测设计---理论
1.首先我们要懂什么是全链路，全链路的核心是什么
其实全链路的核心主要是：监控、引流、熔断
监控：在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路
然后就可能会出现以下几个问题
-
如何快速发现问题？
-
如何判断故障影响范围？
-
如何梳理服务依赖以及依赖的合理性？
-
如何分析链路性能问题以及实时容量规划？
随着服务的复杂性我们可能还需要关注
-
吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
-
响应时间，包括整体调用的响应时间和各个服务的响应时间等。
-
错误记录，根据服务返回统计单位时间异常次数。
然后我们选型的监控工具需要满足
-
请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。
-
可视化：各个阶段耗时，进行性能分析。
-
依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
-
数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。
然后我们的全链路，一般的全链路监控系统，大致可分为四大功能模块
1.埋点与生成日志 不能造成性能负担：
一个价值未被验证，却会影响性能的东西，是很难在公司推广的！
因为要写log，业务QPS越高，性能影响越重。通过采样和异步log解决。
2.收集和存储日志
每个机器上有一个 deamon 做日志收集，业务进程把自己的Trace发到daemon，daemon把收集Trace往上一级发送；
多级的collector，类似pub/sub架构，可以负载均衡；
对聚合的数据进行 实时分析和离线存储； 离线分析 需要将同一条调用链的日志汇总在一起；
3.分析和统计调用链路数据，以及时效性
强依赖：调用失败会直接中断主流程
高度依赖：一次链路中调用某个依赖的几率高
频繁依赖：一次链路调用同一个依赖的次数多
4.展现以及决策支持
span在一次大的跟踪过程中是什么样的。Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上，也共用一个跟踪id。
type Span struct {
TraceID int64 // 用于标示一次完整的请求id
Name string
ID int64 // 当前这次调用span_id
ParentID int64 // 上层服务的调用span_id 最上层服务parent_id为null
Annotation []Annotation // 用于标记的时间戳
Debug bool
}
类似于 树结构的Span集合，表示一次完整的跟踪，从请求到服务器开始，服务器返回response结束，跟踪每次 rpc 调用的耗时，存在唯一标识trace_id。比如：你运行的分布式大数据存储一次 Trace 就由你的一次请求组成。
每种颜色的note标注了一个span，一条链路通过TraceId唯一标识，Span标识发起的请求信息。树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间，他们在整个树形结构中却是相对独立的。
