全链路压测设计---理论

1.首先我们要懂什么是全链路，全链路的核心是什么

其实全链路的核心主要是：监控、引流、熔断

监控：在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路

 然后就可能会出现以下几个问题

1. 如何快速发现问题？

2. 如何判断故障影响范围？

3. 如何梳理服务依赖以及依赖的合理性？

4. 如何分析链路性能问题以及实时容量规划？

随着服务的复杂性我们可能还需要关注

1. 吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。

2. 响应时间，包括整体调用的响应时间和各个服务的响应时间等。

3. 错误记录，根据服务返回统计单位时间异常次数。

然后我们选型的监控工具需要满足

1. 请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。

2. 可视化：各个阶段耗时，进行性能分析。

3. 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。

4. 数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。

然后我们的全链路，一般的全链路监控系统，大致可分为四大功能模块

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的开始和结束时间，他们在整个树形结构中却是相对独立的。