目录

1 背景

2 需求

3 方案

4 问题

5 解决方案

6 最后记录

7 参考文献

---

1 背景

        最近我们在做一个能源类智能化转型的项目，整个项目非常大，下面有很多的子项目组。不同项目组之间都是独立的子系统。 客户对技术上做了统一要求，使用统一的微服务架构，使用统一的注册中心，统一管控。 希望通过这种方式，打破系统之间的数据壁垒。

        这是一种很好的思路，但实际实施的时候困难重重，因为各个子项目组是不同的供应商支撑，各项目组在正式进入的时候，就已经在赶工期，赶功能，而技术规范、技术要求是后来提出的，而且整个大的项目组又缺少统一的技术负责人 ，或者说缺少能实际落地接地气的技术负责人，就造成从上还是理论化的要求技术统一、框架统一，但是到各个子系统还是自己做自己的。 

        这种情况我遇到不止一次，很多大的集团，大的企业都会这样理想的想法，为了后期自主接手做准备，做统一的技术要求，统一的规范，但能落地的真是凤毛麟角。 我想主要有以下几个原因：

        ① 太过于“急功近利”，项目的deadline和工作量之间有不可调和矛盾，交付了先解决眼下直观的问题往往优先级最高。

        ② 部门太多，人多，就会有各种各种的阻力

        ③ 大领导不懂技术，或者根本不重视技术

        ④ 计划和规划太滞后，甲方缺乏坚定推陈换新，又能接地气的技术负责人

        大集团的企业信息化转型，任重道远，也正是如此，我们这些乙方才能不断有机会有饭吃。

2 需求

        我们所在子项目组，需要调用智能化团队的两个接口，双方在约定好接口规范之后，智能化团队直接给了两个无需校验的post-json接口，我们需要将这两个接口对接上，并将数据回显到页面。

3 方案

        关于这种对接，比较常见的一种方式就是我们自己的后端应用调用智能化的接口，然后我们自己封装接口出来给前端调用。 这种方式可以避免前端跨域请求，也能更好的屏蔽接口细节，而且还能对接口做加工，记录日志等等。

        但是考虑到系统之间的对接容易扯皮，拉扯，而且这两个接口的出入参非常简单，对于业务功能上也仅仅是将内容做展示，我们最终确定的方案是前端直接对接，不通过后端中转，这样如果出问题了，会第一时间在前端有体现，容易将责任划分清楚。 

4 问题

        前端直接对对方的接口，最直接的问题就是跨域访问，另外一个就是前端资源打包的时候，对于外围系统的接口要做ip:port的配置，这就很繁琐或者不方便了。

        基于此一种非常常见的解决方法就是通过nginx做代理转发。 现在的软件架构基本上都已经前后端分离的方式，部署的方案很多时候也是前后端分离部署，前端放到Nginx静态代理中去访问，后端接口通过nginx转发到对应的后端服务去，就这个场景对于我们而言，无非就是nginx上多配置一个代理，多了一个服务而已，这太简单了。 两个接口信息如下：

http://127.0.0.1:8895/iio-data-recognition/specRecommend

http://127.0.0.1:8895/iio-data-recognition/specRecognition

我们的系统入口为：

http://127.0.0.1:9001/platform/#/login

我给集成的小伙说，去做个代理，代理规则如下：
http://127.0.0.1:9001/iio-data-recognition/specRecommend →  http://127.0.0.1:8895/iio-data-recognition/specRecommend

http://127.0.0.1:9001/iio-data-recognition/specRecognition →  http://127.0.0.1:8895/iio-data-recognition/specRecognition

这很清晰了，对于nginx上来说，就是简单的location匹配就好了。

集成的同学配好之后，让前端做验证，发现一直报如下错误：

我本地使用postman尝试了下，发现一直报请求方式不支持

        但是，明明已经是post请求了，为什么通过一层转发就变成了get请求？ 这太诡异了。 

然后集成的同学，尝试加了一个proxy_method POST，如下：

        还是不行，后端开始报body没有携带参数。 

        百思不得其解，想着是不是接口有问题，尝试直接在Nginx所在主机上，使用curl post方式请求，发现接口正常返回，这就说明还是出在代理上。 

5 解决方案

        仔细看了代理的配置，从配置上看好像也没什么毛病，但是其实这两个接口有相同的上下文，完全没必要在location的匹配上落到接口层面，直接对上下文iio-data-recognition做匹配，然后转发即可。 最后调整如下：

问题消除！

6 最后记录

        为什么会出现这样的问题？

        参考 Nginx转发post请求变get请求_nginx post-CSDN博客这里，这篇博客讲的更彻底更清晰。 

        我理解主要还是和location、proxy_pass中配置带/不带/，或者带到哪儿有关系。这块的信息参考如下两段引用，尤其第二段，摆事实非常清晰。 

7 参考文献

【1】nginx location/区别详解

【2】Nginx转发post请求变get请求