Request-Id
或X-Request-Id
,用来标识一个HTTP请求。重试同一个请求时,一般会使用不同的Request Id,以区分前后的两次不同的请求(尽管这两次请求的意图可能是一样的)。Request ID一般由客户端生成,一般使用足够长度的随机字符串或UUID。
也有系统会把Request Id当成Idempotent Key来使用,在服务器端用来做请求去重。但是这种做法,不但容易产生误解,而且也仅仅达成了API幂等性要求的一部分,并没有起到幂等性应当起的作用:让API的行为本身幂等,并让服务间的集成更加便捷与鲁棒。
Idempotency-Key
是一种由客户端负责生成,由服务器端负责校验的,用于确保同一个用户请求,不会被重复处理两次,而产生额外副作用的机制。2020年12月,paypal起草了《The Idempotency HTTP Header Field》,对Idempotency-Key
进行了系统化的描述与定义。并已经被不少公司接纳和采用。但是这个实现尚未形成标准,仅供参考。有关Idempotent Key的更多内容,请参考:幂等控制
无论具体实现如何,引入独立的字段来做幂等控制,与请求本身的ID区分出来,从未来的可扩展性上来讲,是更优的。而且,一个接口,如果声明自己需要RequestId
和Idempotency-Key
,那么也会引发初级使用者的深入思考,引导其正确地传递参数值,而不是无脑地传随机UUID。
在微服务构架体系下,一每个用户请求的处理,常常是由一组后端服务协同的结果。在这个过程,各个微服务之间,可能会有远大于一次的系统交互。
Correlation-Id
可以用于把这些独立,但是相关的请求(及消息),以统一的方式关联起来而引入的概念。从而解决服务可见性及故障排查的问题。所以并不建议将CorrelationId放到业务请求体之中。
Correlation Id,在HTTP中并没有官方定义[1],而在JMS中有相关定义。
用于业务实体之间关联的ID,也被称为Correlation Id,但是具有业务属性,需要与上述用于请求关联的Correlation ID区分。
这个业务关联ID的命名并不没有业界的统一规范,有时还会被称为SourceId
或ParentId
。需要结合上下文,通过ID的使用方式,来仔细分辩ID的本质。不能单纯通过名字来推断其用途。