问题的现象

线上正常在运行的系统，取消供应商订单这个场景，某天开始偶尔出现Http 400。经常观察错误报错。大致有这样几个特点。

偶尔，少量报错，大部分的请求都是成功的；
报错的机器也不是固定的；

排查过程

指导处理

由于正常忙其他的任务，且初步判断问题并不严重；于是交由组内具体负责该系统的同学处理
发现问题，抽查了一些后，发现都是未支付的订单；且只是少量报错，于是交由具体负责的同学处理。但经过几个小时，报错依赖偶尔出现，且排查问题的同学没有发现有用的线索；TA做了下面的尝试

分析报错分布，结果集群中机器上的报错分布相对均匀，应该与具体机器无关
报错的请求，拿同样的请求到机器上去curl，都是成功的
不得以，我让TA先添加重试逻辑，看情况是否改善

介入处理

糟糕的是，重试逻辑上线后，报错量并没有减少。而且陆续有PM过来询问情况，也有供应商反馈订单库存没有释放。我也放下工作参与到实际的排查当中。
查看报错日志，Http 400 bad request, header or cookies too large. 从信息中看，方向比较清楚。查header和cookies是不是太大了；查看具体代码发现，业务逻辑往HttpPost里面放的Header并不长，不会超限。

baidu, bing, google, stackoverflow, 查了一番，讲的大多是浏览器中遇到Http 400解决方案，对于我们遇到的HttpPost发请求的场景，没有太多用处
自己也curl了一下请求，一样是无法重现问题
分析代码，是否会有公共的代码逻辑，自动添加加Header；发现用了THttpClient, 而不是Appach的HttpClient, 是公共组件团队封装过的；
找公共组件的负责人咨询，果然，得知他们默认往Header里面放了traceid, spanid两个值，但正常情况下不会超长。
打印HttpPost, Header信息，验证；上线后过了一个小时，再一次出现Http 400, 查看日志，果然是spanid过长。
公共组件团队，临时去除添加Header逻辑，应用重启，至此问题解决。

后续

-http请求header的最大值是8024个字节（8KB）Tomcat的配置上可以设置。
-什么造成了这个偶发的超长Header, 组件团队排查中，待更新
最终组件团队给出的原因是【 spanId超长的问题经排查是xxl-job-core中的一个bug，使用trace后没有在线程内进行关闭导致后面会持续累加。】