1.全链路压测是什么？
（1）怎么理解压测系统
官方理解：基于实际的生产环境，系统环境，模拟海量用户的真实请求，对业务进行整个链路的压力测试，并持续调优的过程。
白话理解：枪的测试、盾的测试，测试平台能不能防弹。压测是不断密集的向平台发射子弹，平台能越实时越真实的详细的给用户结果越好。
自我认识：压测系统是模拟多用户行为的系统。系统需要处理的用户行为是，从web开发发起请求，到服务层，到数据层，最终将请求结果返回给用户。
（2）全链路压测的的关键：
环境：全链路压测必须能在线上生产环境做，不能只在线下做，否则不能称之为全链路压测的。
持续调优：压力发出去，不管系统表现能力如何的压测是没有意义的。压测压测完了，需要知道系统的性能节点在哪里。
【备注】：由于全链路压测开始于2013年阿里、后来于16～18年传播于各大互联网公司，因此持续调优的概念，各大公司并不一致。
（3）与普通压测的区别
普通压测 | 全链路压测 |
单机或者单集群压测 | 从nginx服务器到应用服务器的各个集群，到各个数据节点都能被压测到 |
压测核心业务链路 | 所有链路都压测到 |
人为构造请求数据 | 以线上真实请求为基础 |
压测结果放大后不能真值的反应系统容量 | 压测结果放大后，更能真值的反应系统容量 |
线下环境进行压测 | 直接在线上真实环境压测 |
2.为什么要做全链路压测？
1.业务增长快、海量流量、系统整体表现怎么样？瓶颈在哪里？系统容量规划怎么样？
比如，根据今年的线上容量，规划明年是否要做机器扩容，要采购多少台机器，这些需要数据支持。
2.业务场景、技术框架复杂、线上环境很复杂，因此单机单节点压测结论的总和都无法反映出整个全链路压测结论。
3.线下的任何模拟都无法反映线上环境，且线下环境越接近线上环境，成本越高。
4.提前演练，将流量洪峰提前到来，以便于验证系统的稳定性。比如阿里的双11，今年的流量可能是去年的5倍、10倍，所以每年都要做全链路压测。
3.全链路压测平台的实现原理
1.数据生产
业务nginx日志通过中间件，拉取到压测平台所属的hive表中，固化。
然后，再通过平台配置，流量回放的形式，录制线上流量。具体的是通过配置，要查询hive库中对应url的历史请求数据，并将处理的流量汇总成词表文件，上传给S3。
2.数据准备
刚从NG获取的日志不能直接使用，从NG获取日志到S3词表之间，需要给流量进行染色，过滤和采样。
染色：因为这些是线上真实流量，在压测时，不被识别成压测流量，通过染色，也就是加压测标示，来标注流量。
过滤：
采样：
3.数据改造
为什么要做数据改造？
场景一（数据替换）：某些请求是实时的，带时间戳的，过期的请求就不处理了，而压测录制的都是过期的流量，那么怎么办呢？就要个流量重新加上合适的时间戳，让请求生效。
场景二（数据偏移）：比如滴滴有打车订单压测，压测时，需要将用户id做偏移，让压测制造的测试用户不要和线上用户撞号。另外，如果不偏移，并且如果写接口因为误操作写入了真实库中，全链路压测将会直接影响线上用户打车。
场景三（数据重组）：比如个人当前的业务部，是thrift原生压测，从线上摘下来的数据，并不能直接使用，一些字段要拼接，去除，替代等。
这个数据改造的过程，也可以称之为数据清洗，其目的都是为了使得压测流量真实，安全。
4.压测环境隔离之数据隔离
为什么做数据隔离？因为不能影响线上用户，不能污染线上数据
在阿里还没有提出影子表概念的时候，做压测时，为了保证不影响到线上，会将现有的库表复制一份，压测时用。只是这样做的弊端是，数据库性能是压测不到了，包括链接池，内存区压不到，这样做完全为了数据隔离，造成压测数据库独享了链接池和资源，无法压测出数据库的极限，和数据库对性能是否有影响。
影子表的概念其实就是，有一个压测标示，带上这个压测标示后，数据库的连接还是同一个链接池，内存也是同一个内存区，只是表库中的磁盘是隔离的，在整个数据隔离区中，kv,mq 都可以走到数据节点，然后单独的将压测标签数据存储下来，区分业务数据，其他资源和线上共享，保正所有的数据节点都能压测到。
简单点说个结论，使用影子表，在全链路压测中，既保证了数据隔离，也保证了可以压到数据库性能。
5.压测环境隔离之服务隔离
为什么要做服务隔离？原由很简单，因为全链路压测必须可以在线上做，在线上做，如果不做环境隔离，就会影响线上用户。
如何做服务隔离？MT的服务隔离是（1）基于DAYU平台的自动建站能力，其中，自动建站=帮助用户批量（申请机器+部署服务）（2）基于分布式的trace透传。
为什么要基于分布式trace透传？所有的压测标示的透传必须基于分布式链路追踪。 比如某些服务没有使用分布式会话跟踪系统，那么走到该服务的时候，节点就会中断掉，后面变成正常的线上请求，因为压测导致下游变成真实的流量，最后给线上造成很大的压力。
6.压测监控
压测过程中需要进行服务监控，观察服务表现状态。以前只能很粗略的给出整体服务的评分，具体内部哪个节点有什么问题，都是不清楚的，这个打分又是怎么来的，也是不给说清楚的。
之后细化到每个服务的打分都给出来，之后又细化到哪个接口的性能瓶颈都给出来。这样从服务，机器，再到数据节点进行监控，问题清清楚楚，数据明明白白，有瓶颈的地方该扩容扩容，改治理治理。
7.压测架构体
根据调研，可以看出的是阿里、美团、滴滴等做的全链路压测的平台技术都有统一的路数，那就拿美团来说一说吧。
针对不同的服务，需要有不同的压测数据。
类型 | 业务 |
http 流量 | |
| |
比如有些服务是http服务，有些服务是没有http服务的
4.压测数据隔离
5.压测监控
6.压测报告
7.整体架构
