刚工作那会,有一次,上游调用我服务的老哥说,你的服务报&34;。
当时那个服务里正好有个调用日志,平时会记录各种200,4xx状态码的信息。于是我跑到服务日志里去搜索了一下502这个数字,毫无发现。于是跟老哥说,&34;
现在想来,多少有些不好意思。
不知道有多少老哥是跟当时的们从状态码是什么开始聊起。
HTTP状态码
我们平时在浏览器里逛的某宝和某度,其实都是一个个前端网页。
一般来说,前端并不存储太多数据,大部分时候都需要从后端服务器那获取数据。
于是前后端之间需要通过TCP协议去建立连接,然后在TCP的基础上传输数据。
而TCP是基于数据流的协议,传输数据时,并不会为每个消息加入数据边界,直接使用裸的TCP进行数据传输会有&34;问题。
因此需要用特地的协议格式去对数据进行解析。于是在此基础上设计了HTTP协议。详细的内容可以看我之前写的《既然有HTTP协议,为什么还要有RPC》。
比如,我想要看某个商品的具体信息,其实就是前端发的HTTP请求中传入商品的id,后端返回的HTTP响应中返回商品的价格,商店名,发货地址的信息等。
这样,表面上,我们是在刷着各种网页,实际上背后正有多次HTTP消息在不断进行收发。
但问题就来了,上面提到的都是正常情况,如果有异常情况呢,比如前端发的数据,根本就不是个商品id,而是一张图片,这对于后端服务端来说是不可能给出正常响应的,于是就需要设计一套HTTP状态码,用来标识这次HTTP请求响应流程是否正常。通过这个可以影响浏览器的行为。
比方说一切正常,那服务端返回个200状态码,前端收到后,可以放心使用响应的数据。但如果服务端发现客户端发的东西异常,就响应个4xx状态码,意思是这是个客户端的错误,4xx里头的xx可以根据错误的类型,再细分成各种码,比如401是客户端没权限,404是客户端请求了一个根本不存在的网页。反过来,如果是服务器有问题,就返回5xx状态码。
但问题就来了。
服务端都有问题了,搞严重点,服务器可能直接就崩溃了,那它还怎么给你返回状态码?
是的,这种情况,服务端是不可能给客户端返回状态码的。所以说,一般情况下5xx的状态码其实并不是服务器返回给客户端的。
它们是由网关返回的,常见的网关,比如nginx。
nginx的作用
回到前后端交互数据的话题上,如果前端用户少,那后端处理起请求来,游刃有余。但随着用户越来越多,后端服务器受资源限制,cpu或者内存都可能会严重不足,这时候解决方案也很简单,多搞几台一样的服务器,这样就能将这些前端请求均摊给几个服务器,从而提升处理能力。
但要实现这样的效果,前端就得知道后端具体有哪些个服务器,并一一跟他们建立TCP连接。
也不是不行,但就是麻烦。
但这时候如果能有个中间层挡在它们中间就
以上就是朝夕生活(www.30zx.com)关于“502问题怎么排查?”的详细内容,希望对大家有所帮助!