调用接口返回失败，根据之前的了解，抛给了开发请求参数，希望帮助他定位问题。结果开发需要Request-ID，并指名返回值里存在。纳尼？？黑人问号。。后台返回null，哪来的Request-ID，于是面对开发的鄙视下，决定了解并记录

1. Request Id 是为了解决下面问题

问题一： 客户端访问的Web服务时，如何将客户端请求与服务端日志关联 
问题二： 微服务架构下，访问日志如何查询
问题三： 不同项目交互出现异常，如何做日志关联

2、存在Request-ID和不存在Request-ID的区别

代码层层封装后，无法通过日志关键与用户请求关联
微服务架构下，用户请求逻辑层分解多个子任务给下层服务处理，下层服务无法与用户请求关联
不同项目交互，如何在并发，错误重试，参数相同的情况下，无法通过关键字，时间来确定日志

requestid

1、当前项目，根据request id 可以找到所有与请求相关的日志

2、不同项目，可以根据request id 确定唯一的请求

3、Request Id 好处

用户请求日志关联 项目间请求日志关联

4. Request Id 依赖

参考：http://www.ireage.com/%E5%85%B6%E4%BB%96/2018/12/16/request_id.html 

 

1. 使用request id，要有配套日志记录系统
2. 周边系统支持，保持统一
3. request id 每次用户请求，必须保证唯一。
4. 多服务间日志聚合
5. 调用关系分析
6. 日志分析

 

 

RESTful API中返回的Request ID有什么用？

似乎有些大型项目都会给RESTful API返回时加上一个Request ID，这个ID有什么用？会不会是服务端把一次请求的完整内容（所有的header和body等）也保存下来了所以才有这个ID的？如果是的话这样做的意义在哪呢？

因为现在很多服务都是分布式的，随着系统复杂度的不断提升，Request ID 可以帮助开发运维人员便捷有效地追踪定位问题

一般来说，在一个完整的请求中（对外暴露的是一个接口，对内的话可能经过 N 多个子服务），每个子服务共用一个相同的、全局唯一的 Request ID，这样当出现问题时，根据 Request ID 就可以检索到请求当时的各个子服务的日志。应用 Request ID 的前提是，得先有一套健全的日志系统。

参考
链接：https://www.zhihu.com/question/53513509/answer/381261421