打开网页时出现“504错误”是网关超时的意思。504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。任何客户端 ( 例如您的浏览器或我们的 CheckUpDown 机器人 ) 在和您的网络服务器通讯时，都需经过以下循环：

• 从您站点的 IP 名称 ( 即您站点的网址-URL, 不带起始的 ‘http://') 获得一个 IP 地址。这个对应关系 ( 即由 IP 名称向 IP 地址转换的对应关系 ) 由域名服务器 (DNSs) 提供。

• 打开一个 IP 套接字 (socket) 连接到该 IP 地址。

• 通过该套接字写 HTTP 数据流。

从您的Web服务器接受响应的 HTTP 数据流。该数据流包括状态编码， 其值取决于 HTTP 协议 。 解析该数据流得到 状态编码和其他有用信息。该错误在以上所述的最后一步生成，即当客户端收到 HTTP 状态编码 并识别其为 ‘504’ 时。“504错误”的解决方法：这个问题完全是由后端电脑之间 IP 通讯缓慢而产生， 可能包括您的 Web 服务器。 如果您的 Web 服务器由某一网站托管， 只有负责那个网站设置的人员 才能解决这个问题。网络上代理和缓存的使用日渐增加。尽管我们 CheckUpDown 机器人将总是试图 ' 钻入 ' 真正收管您的网站的电脑， 但是我们的 HTTP 请求实际上落在哪里并不能完全由我们控制。 只要在处理我们的 HTTP 请求的一连串电脑中， 有一个环节坏了，类似 504 的错误就很容易产生。只要您遇到 504 错误，就请与网站官方联系（例如通过电子邮件） - 此问题个人无法解决。需要网站方和互联网服务供应商 (ISP) 及 Web 服务器软件供应商联络， 检查在其控制下的不同电脑之间的 IP 数据传输的流通状况。 然而， 这个错误不易解决， 由于互联网流通的无规律性， 这种类型的错误是瞬态的。

tep1:   前端 debug 时查看到了504的响应-----（发现问题）

问题分析

nginx访问出现504 Gateway Time-out，一般是由于程序执行时间过长导致响应超时，例如程序需要执行60秒，而nginx最大响应等待时间为30秒，这样就会出现超时。

step2：查看nginx log

==> access.log <==

10.7.0.13 - - [15/May/2020:16:42:19 +0800] 10.7.00.13:9301 60.001 60.001 ars-beta.test_webcn-la.com POST /api/gc/membership/tier/getMembershipTierByTest

HTTP/1.1 "504" 705 "-" "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_144)"

可以看到nginx也是504的状态，于是可以查看后端对应的服务是10.7.00.13:9301

可以使用curl 来验证一下服务是否正常：curl -I http://localhost:9301/test.html

step3：查看9301端口状态

step4：结合业务查看membership.controller 的access.log(本日志记录了所有与本服务交互的请求处理), 查看调用请求的整个过程，有两个惊人发现：第一个是红框里面的ip, 第二个是红框里面的当前请求线程名称

step5:  第一个红框的的ip 居然是我自己的ip, 这下子问题定位了，因为我本地有在请求membership 服务，并且是python开发的监控服务是否正常的应用所发出的请求。

step6:  结论为：因为我本机在每五分钟（从上面的请求日志间隔可以窥探到）请求一次membership 服务的接口，用于保障beta环境的可用性验证，最终因为请求的membership 服务连接一直不能释放导致了membership 服务僵死掉。

 查看9301端口状态时，存在这两个状态，说明如下：

step7:  解决方案：重新重启了服务就恢复了，不过还发现了mq 地址变更但代码配置里面未变更的问题并让开发修复，算是意外的收获。

由于nginx默认的fastcgi进程响应缓冲区太小造成： 这种情况下导致fastcgi进程被挂起，如果fastcgi服务队这个挂起处理不是很好的话，就可能提示“504 Gateway Time-out”错误。504 Gateway Time-out就字面意思,我们可以理解为网页请求超时,也就是浏览网站网页所发出的请求没有反应或者未响应,在网站程序层面来说,就是请求未能够执行相应的PHP-CGI程序,或者PHP-CGI程序未能做出相应的处理,又或者是CGI程序的响应处理结果未能够反馈到浏览器或者未能及时反馈到浏览器。

可以用每个段落加一个执行时间记录，用log输出看看， 还有就是把nginx的timeout时间改的大一点，足够你处理时不超时。 还有一种办法是让他先访问，然后给他一个返回一个值，用ajax查询当前进度， 后台维护一个session的表，告诉他进行到什么程度了，这样ux上也很好的。

当程序报错，最简单且快速的方法就是查询日志中的报错信息了;所以我们在敲代码的时候，一定不能对 CheckedException 只捕捉不处理。

首先不要忽略异常，第一可以在捕捉到异常后将日志信息输出，要么通过 Throw 或 throws 向上抛，让上层的代码进行处理;

接上，不要捕捉异常后，输出完日志又向上抛出异常，这样当查询定位错误时，会产生误导;

对于捕捉到的异常，最好可以精确地指出具体是什么异常，而不要用 catch(Exception e) 替代;

如果选择了输出异常，那么就要把异常单独打印到一个日志文件中，否则你很可能需要在一大堆日志文件中翻阅查找;

另外，日志信息尽可能的详细，比如方法的入参、与其他系统交互的报文等等。

在打开网页时有时我们会发现有504的错误信息,但它不影响我们的程序,所以无需担心.

504错误代表网关超时 （Gateway timeout），是指服务器作为网关或代理，但是没有及时从上游服务器收到请求。

服务器（不一定是 Web 服务器）正在作为一个网关或代理来完成客户（如您的浏览器或我们的 CheckUpDown 机器人）访问所需网址的请求。 为了完成您的 HTTP 请求， 该服务器访问一个上游服务器， 但没得到及时的响应。

这通常意味着上游服务器已关闭（不响应网关 / 代理），而不是上游服务器和网关/代理在交换数据的协议上不一致。

正常情况下，是由于被请求服务器发送超时引起。

问题：

从信息上我们可以看出错误是  连接超时

原因: 我们的网关默认的等待时间为1秒,时间到了还没有响应的话就会报错.

因此我们就需要在网关的配置是上下点功夫了

我们可以通过以下方式解决:

我们只需要在网关的服务配置yml配置文件中的负载均衡的超时时间就可以解决了.

解决之后:

• 情况一：由于nginx默认的fastcgi进程响应缓冲区太小造成

  这种情况下导致fastcgi进程被挂起，如果fastcgi服务队这个挂起处理不是很好的话，就可能提示“504 Gateway Time-out”错误。

• 情况一解决办法：

  默认的fastcgi进程响应的缓冲区是8K，我们可以设置大一点，在nginx.conf里，加入：fastcgi_buffers 8 128k

  这表示设置fastcgi缓冲区为8块128k大小的空间。

• 情况一解决办法（改进）：

  在上述方法修改后，如果还是出现问题，我们可以继续修改nginx的超时参数，将参数调大一点，如设置为60秒：

  send_timeout 60;

  经过这两个参数的调整，结果没有再提示“504 Gateway Time-out”错误，说明效果还是挺不错的，问题基本解决。

• 情况二：PHP环境的配置问题

  这里我们需要对php-fpm和nginx进行配置修改。因为这种情况下，也会出现“504 Gateway Time-out”错误提示。

• 情况二解决办法（ php-fpm配置修改）：

  将max_children由之前的10改为30，这样操作是为了保证有充足的php-cgi进程可以被使用。

  将request_terminate_timeout由之前的0秒改成60秒，这样使php-cgi进程处理脚本的超时时间提高到60秒，可以防止进程被挂起以提高利用效率。

• 情况二解决办法（nginx配置修改）：

  为了减少fastcgi的请求次数，尽量维持buffers不变，我们要更改nginx的几个配置项，如下：

  将fastcgi_buffers由4 64k改为2 256k;

  将fastcgi_buffer_size 由64k改为128k;

  将fastcgi_busy_buffers_size由128k改为256k;

  将fastcgi_temp_file_write_size由128k改成256k。

第一部分：主要从问题出发，引入接口测试的相关内容并与前端测试进行简单对比，总结两者之前的区别与联系。但该部分只交代了怎么做和如何做？并没有解释为什么要做？

　　第二部分：主要介绍为什么要做接口测试，并简单总结接口持续集成和接口质量评估相关内容。