1.慢请求如何排查
1.1在一体化架构中的慢请求排查如何做
实现方式：打印下每个下单操作的耗时情况，通过耗时情况找到延迟最高的一步
出现问题1：耗时日志是不连续的，无法定位同一个请求的所有日志
解决办法：为每一个请求增加一个request ID（简单实现放在thread loacl中即可）（也可以存放上下文）
出现问题2：针对每次慢请求都需要人为操作，不够抽象
解决办法：通过切面编程进行日志打印
Java中的AOP
- 静态代理（更适合日志的打印）
- AspectJ 编译期做切面代码注入
- 增加编译时间，对运行期性能没有影响
- 动态代理
- Spring AOP 运行期做切面代码注入
- 运行期生成代理对象，运行期性能稍差
出现问题3：日志量过大，怎么减少日志量
解决办法：可以针对请求取样，对request id进行取余
出现的问题4：日志分布在不同机器上，导致需要每台机器查看
解决办法：将日志发送到消息队列中，在由消息队列集中存储（Elasticsearch）（公司的baimai系统）
- 生成requestid，将多次请求日志串起来
- 使用切面管理日志，避免对业务代码侵入
- 增加日志采样率，避免全量日志的打印
- 将日志统一集中存储
2.分布式Trace
相比于单体化架构的清晰程度，需要在分布式架构下通过trace+spanid将上下游关系表示出来
每次传递前，获取当前的traceid和spanid，并计算出新的traceid+spanid后传输
如果是顺序传输（需用引入新的计算方法，不过页更方便梳理上下游关系）
公司采用的每次将接收spanid作为父id，同时生成新的spanid进行传输
3.课程小结
- 服务追踪要求
- 对代码无侵入
- 性能
- 单体架构还是服务化架构
- 保证requestid，保证上下游有span id
