vercel和netlify部署代码并解决接口代理转发的问题(和Nginx功能一样)

文章详细介绍了如何在Vercel和Netlify平台上解决接口代理和跨域问题。在Vercel中,通过配置`vercel.json`进行重写规则,并使用`http-proxy-middleware`创建代理,转发请求。在Netlify中,通过`netlify.toml`配置重定向规则实现相同功能。此外,文章还提到了部署过程中可能遇到的Node版本兼容问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

  • 部署过程就不说了,部署完成后是这样子的

  • 然后访问链接,无法访问

解决

  • 依次点击 Settings–>Domains,在输入框中输入你的域名并点击 Add 按钮。

  • 以此域名为例子demo.gshopfront.dreamlove.top为例,点击添加

  • 我们前往域名管理系统,记录下绿色的值以腾讯云的为例

  • 上图中的Name对应的是主机记录,Value对应的是记录值,记录类型选择CNAME

  • 验证成功,vercel自动生成ssl证书当中

  • 访问成功

  • 例子http://demo.gshopfront.dreamlove.top/

vercel解决接口代理问题

  • 编译为静态文件后,代理转发没有了,跨域了,所以我们需要自己配置下代理转发给vercel使用

  • 一模一样添加完成https://segmentfault.com/a/1190000042276351?sort=newest

  • 安装开发依赖

npm i -D http-proxy-middleware
  • 目录建立vercel.json,注释记得删除
//注释记得删除
{
  "rewrites": [
    {
      "source": "/api/(.*)", //要匹配的路径前缀(我们本地访问的路径),结合自己的前缀设置
      "destination": "/api/proxy" //需要转发给哪一个目录下的配置
    }
  ]
}
  • 建立api/proxy.js文件
    • 注意: 由于这里的接口不需要pathRewrite,所以就删除了pathRewrite配置
      • 效果,当我们访问搭建好的目录https://demo.gshopfront.dreamlove.top/api/user的时候,就会被转发给http://gmall-h5-api.atguigu.cn/api/user
    • 如果需要去除掉api这个前缀,就把pathRewrite打开,
      • 效果:当我们访问搭建好的目录https://demo.gshopfront.dreamlove.top/api/user的时候,就会被转发给http://gmall-h5-api.atguigu.cn/user,(去除掉了api)
// api/proxy.js
// 该服务为 vercel serve跨域处理
const { createProxyMiddleware } = require('http-proxy-middleware')

module.exports = (req, res) => {
    let target = ''
    // 代理目标地址
    // 这里使用 backend 主要用于区分 vercel serverless 的 api 路径
    // target 替换为你跨域请求的服务器 如: http://gmall-h5-api.atguigu.cn
    if (req.url.startsWith('/api')) {
        target = 'http://gmall-h5-api.atguigu.cn'
    }
    // 创建代理对象并转发请求
    createProxyMiddleware({
        target,
        changeOrigin: true,
        pathRewrite: {
            // 通过路径重写,去除请求路径中的 `/api`
            // 如果开启了,那么 /api/user/login 将被转发到 http://gmall-h5-api.atguigu.cn/user/login
            //'^/api/': '/',
        },
    })(req, res)
}
  • 目录结构

  • 编辑好后推送,然后等待重新编译
  • 之后会出现此下拉栏目

  • 如果没有出现Functions栏目,就点击这里

  • 这样子也可以出现Function

  • 选择我们的api/proxy

  • 然后就可以正常啦

  • 如果部署遇到这种问题error @achrinza/node-ipc@9.2.2: The engine "node" is incompatible with this module. Expected version "8 || 10 || 12 || 14 || 16 || 17". Got "18.13.0"

  • 发现vercel设置node版本后重新部署也不行,不知道为什么,…

netlify解决接口代理问题

  • 建立netlify.toml文件
[[redirects]]
  from = "/prod-api/*"
  to = "http://gmall-h5-api.atguigu.cn/:splat"
  status = 200
  • 在netlify网站请求接口如果使用 http://localhost/prod-api/news 就会被转发到 https://http://gmall-h5-api.atguigu.cn/news 来获取 news 接口数据。

    • 部署演示地址:https://demo.gshopfront.dreamlove.top/
  • 官方的配置说明

    • https://docs.netlify.com/configure-builds/file-based-configuration/#headers
    • https://docs.netlify.com/routing/redirects/redirect-options/
    • https://docs.netlify.com/routing/redirects/#syntax-for-the-netlify-configuration-file

参考文章

<think>好的,我现在需要回答用户的问题:在微服务加前后端分离架构中,是否还需要像集群架构那样部署Nginx进行前后端交互。首先,我需要明确用户的问题核心。用户可能已经了解集群架构中使用Nginx的情况,现在想知道在微服务前后端分离的架构中是否同样需要。这可能涉及到Nginx在两种架构中的不同作用,以及微服务架构中是否有其他替代方案。 首先,我应该回顾一下Nginx在传统集群架构中的作用。通常,Nginx作为反向代理负载均衡器,处理客户端的请求,将流量分发到多个后端服务器,同时可能处理SSL终止、静态资源服务、缓存等。在集群架构中,Nginx帮助提高可用性扩展性,确保请求被合理分配到不同的服务器实例。 接下来,考虑微服务加前后端分离架构。在这种架构下,前端通常是独立的静态应用(如React、Vue),通过API与后端微服务通信。后端由多个微服务组成,可能通过API网关(如Spring Cloud Gateway、Kong)进行路由统一管理。此时,用户的问题变为:在这样的架构中,是否需要在前端后端之间部署Nginx,或者API网关是否已经承担了这部分职责? 需要分析以下几点: 1. **前端静态资源托管**:在前后端分离架构中,前端代码通常是静态文件,需要托管在Web服务器上。Nginx擅长处理静态资源,因此可能仍需要用于托管前端文件,尤其是在生产环境中,提供高效的静态资源服务。 2. **反向代理负载均衡**:在微服务架构中,API网关通常负责路由请求到具体的微服务,可能处理负载均衡。但如果有多个API网关实例或需要进一步分发流量到网关层,可能需要Nginx作为入口点的负载均衡器。此外,如果前端直接与多个后端服务通信(不经过网关),可能需要Nginx代理这些请求,但这种情况在微服务架构中不常见,因为通常推荐通过API网关统一入口。 3. **SSL终止缓存**:Nginx常用于处理SSL终止,减轻后端服务的负担,同时提供缓存功能以提高性能。即使存在API网关,这些功能可能仍然由Nginx处理,尤其是在网关不具备这些能力或需要统一管理的情况下。 4. **架构层次**:微服务架构可能包含多个层次,例如前端层、网关层、微服务层、支撑服务(注册中心、配置中心等)。Nginx可能部署在前端层网关层之间,或者作为整个架构的入口点,处理来自客户端的初始请求,再将动态请求转发给API网关,而静态请求直接处理。 5. **替代方案**:是否有其他工具可以替代Nginx的角色?例如,云服务提供的负载均衡器(如AWS ALB、GCP Load Balancer)可能替代Nginx的部分功能。但在自建环境中,Nginx仍然是一个常见选择。 然后,需要验证用户提到的集群架构是否与微服务架构中的部署有不同需求。在集群架构中,Nginx主要用于后端服务的负载均衡,而在微服务架构中,API网关可能已经具备类似功能。但前端静态资源的托管可能的入口负载均衡仍可能需要Nginx。 还需要考虑用户可能存在的误解,例如认为微服务架构中的API网关完全取代了Nginx的角色,但实际上两者可能有不同的职责,可以共存。例如,Nginx作为边缘服务器处理静态资源SSL,而API网关处理动态请求的路由微服务相关的策略。 此外,是否需要区分开发环境生产环境。在开发环境中,可能使用Webpack Dev Server等工具处理前端请求,而在生产环境中则需要Nginx这样的高效服务器。 最后,总结回答的结构:明确回答需要部署Nginx解释其在微服务加前后端分离架构中的具体作用,与API网关的分工,以及可能的部署场景。同时,指出替代方案的存在,但Nginx仍然是常见选择。</think>在微服务加前后端分离架构中,**仍然需要部署Nginx**,但其角色集群架构中的使用场景有所不同。以下是具体分析: --- ### **一、Nginx的核心作用对比** | **场景** | **集群架构** | **微服务+前后端分离架构** | |-------------------------|-------------------------------------|----------------------------------| | **主要职责** | 负载均衡、反向代理、静态资源服务 | 静态资源托管、边缘路由、补充负载均衡 | | **交互对象** | 直接代理后端应用集群 | 前端静态资源服务 + 与API网关协同工作 | | **典型配置** | `upstream`指向Tomcat/Node服务 | 前端资源托管 + 部分API请求转发至网关 | --- ### **二、在微服务架构中Nginx的必要性** #### 1. **前端静态资源托管** - **核心需求**: 前端工程(Vue/React)编译后为静态文件(HTML/CSS/JS),需通过Web服务器高效分发。 - **Nginx优势**: - 高性能处理静态请求(吞吐量可达万级QPS) - 支持`gzip压缩`、`缓存控制`(如配置`expires 7d`) - 示例配置: ```nginx server { listen 80; location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; # 支持前端路由 } } ``` #### 2. **边缘代理与安全防护** - **SSL终结**: 由Nginx统一处理HTTPS加密(避免微服务自身处理SSL开销): ```nginx server { listen 443 ssl; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; # 转发动态请求至网关 location /api { proxy_pass http://gateway:8080; } } ``` - **安全过滤**: - IP黑白名单控制 - 防御CC攻击(限制请求速率) - 示例: ```nginx limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s; location /api { limit_req zone=api_limit burst=50; proxy_pass http://gateway; } ``` #### 3. **与API网关的分工协作** - **典型架构流**: $$ \text{客户端} \xrightarrow[\text{静态资源}]{\text{HTTPS}} \text{Nginx} \xrightarrow[\text{动态请求}]{\text{/api/*}} \text{Spring Cloud Gateway} \xrightarrow{\text{路由}} \text{微服务集群} $$ - **分工明确**: - Nginx:处理静态资源、SSL、基础安全 - API网关:服务路由、鉴权、熔断等微服务治理 --- ### **三、不依赖Nginx的替代方案** 1. **云服务方案**: - AWS CloudFront + S3(静态资源) + ALB(负载均衡) - 阿里云CDN + SLB 2. **现代前端方案**: - 使用Vercel/Netlify等平台托管前端,内置CDN边缘网络 3. **Service Mesh**: - Istio Ingress Gateway替代传统反向代理(需结合Kubernetes) --- ### **四、部署建议** 1. **基础架构必选**: - 生产环境建议保留Nginx,尤其在高发场景 - 开发环境可用`webpack-dev-server`简化流程 2. **性能调优方向**: - 启用`HTTP/2`提升多请求发效率 - 配置`Broti`压缩替代`gzip`(节省带宽约20%) - 静态资源分离至CDN(如配置`location ~* \.(jpg|js|css)$`指向CDN域名) --- ### **五、总结** 在微服务+前后端分离架构中,**Nginx非用于直接代理微服务**(这部分由API网关处理),但仍是**不可或缺的基础组件**,主要承担: 1. 前端静态资源服务 2. 安全防护第一道防线 3. 补充性负载均衡(例如网关集群的负载均衡) 实际架构中,Nginx与API网关形成互补,共同构建高效可靠的服务入口。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

未成年梦想

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值