微服务中的Bad Request

场景描述

我们的系统是基于rest的微服务架构，各个子系统的调用都是通过HTTP请求来交互的，并且请求参数要经过base64编码。

前端时间在做一个数据迁移需求的时候时候，发现总是有一些数据莫名其妙的丢失，当初是根据数据的自增id分段做的迁移，一次迁移一部分。迁移过程会去另一个系统调用一个服务确认这些数据是否都属于要迁移范围。

迁移过程中发现数据丢失之后，我们查找日志发现有Bad Request错误。经过定位发现是调用数据有效性确认的服务发生了问题。当初我们的段长度是1000，发生这个问题后我们翻看这个服务的细节发现他处理请求的类型是GET，也就是说它的请求数据和地址长度受WEB服务器的URL长度限制。我们的URL长度过长导致了这个问题。因为这个GET问题迎来了我们的质检。

从中我们也可以体会到，当我们在对问题进行抽象的时候，不可避免的会隐藏掉底层的一些细节，就如我们通过TSP服务名去标识服务的时候，我们就丢失了对这个请求类型的直接感知。所以工作中还是要多想一想，多看一看，三思而后动，不然回头就会浪费更多的时间。

现在收集了一些关于URL长度的信息：

在http协议中，其实并没有对url长度作出限制，往往url的最大长度和用户浏览器和Web服务器有关，不一样的浏览器，能接受的最大长度往往是不一样的，当然，不一样的Web服务器能够处理的最大长度的URL的能力也是不一样的。
下面就是对各种浏览器和服务器的最大处理能力做一些说明.