记一次Nginx代理配置的奇怪经历

凉茶冰

于 2024-08-16 11:14:18 发布

阅读量733

点赞数 21

文章标签： nginx 运维

本文链接：https://blog.csdn.net/liangcha007/article/details/141252403

版权

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匹配就好了。

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