React项目中如何通过同一子域名对接多个微服务？微服务生产环境API调用方案咨询

我来分享几个生产环境里常用的落地方案，完美解决你遇到的困惑：

1. 反向代理（Nginx/Apache）+ 路径前缀（最推荐，低成本易维护） #

这是中小团队最常用的方案，完全不需要额外子域名，只用单个域名就能区分所有微服务API。

核心思路是：用Nginx或Apache做反向代理，把同一个域名下的不同路径前缀转发到对应的微服务实例。比如：

• https://yourdomain.com/api/user-service/* → 转发到用户微服务的内部地址（比如http://user-service:3001/）
• https://yourdomain.com/api/order-service/* → 转发到订单微服务的内部地址（比如http://order-service:3002/）

给你一个Nginx的配置示例：

server {
    listen 443 ssl;
    server_name yourdomain.com;

    # 配置SSL证书（省略具体证书配置）

    # 用户服务路由
    location /api/user-service/ {
        proxy_pass http://user-service:3001/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 订单服务路由
    location /api/order-service/ {
        proxy_pass http://order-service:3002/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 前端静态资源路由（如果前端也部署在同一个域名下）
    location / {
        root /path/to/react/build;
        try_files $uri $uri/ /index.html;
    }
}

前端React里只需要统一请求这个域名下的对应路径就行，比如：

// 用户服务请求
fetch(`${process.env.REACT_APP_API_BASE}/user-service/profile`)
// 订单服务请求
fetch(`${process.env.REACT_APP_API_BASE}/order-service/my-orders`)

你可以在.env文件里配置REACT_APP_API_BASE=https://yourdomain.com/api，切换开发/生产环境非常方便。

这个方案完全不违背微服务初衷：反向代理只是做流量路由，不处理任何业务逻辑，每个微服务还是独立部署、独立扩容，只是通过统一入口对外暴露，反而能简化前端对接流程。

2. 通配符子域名+反向代理（满足子子域名需求） #

如果你确实想用api1.subdomain.domain.com这类子子域名，也不需要逐个添加DNS记录——只需要在Cloudflare（或你的DNS服务商）添加一条通配符DNS记录就行，比如*.api.yourdomain.com指向你的Nginx服务器IP。

然后在Nginx里配置基于子域名的路由：

server {
    listen 443 ssl;
    server_name ~^(?<servicename>.*)\.api\.yourdomain\.com;

    # 配置SSL证书（注意要使用支持通配符的域名证书）

    # 根据子域名转发到对应服务
    location / {
        proxy_pass http://${servicename}-service:3000/; # 假设服务命名规则是api1对应api1-service
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这样api1.api.yourdomain.com会自动转发到api1-service:3000，api2.api.yourdomain.com转发到api2-service:3000，不用再手动添加每条子域名的DNS记录。

3. API网关/服务网格（适合大规模微服务场景） #

如果你的微服务数量很多（比如几十个），或者需要更复杂的流量控制、统一认证、链路监控等功能，可以用专门的API网关（比如Kong、APISIX）或者服务网格（比如Istio、Linkerd）。

这类工具本质是更强大的反向代理，能提供统一认证、限流、熔断、日志追踪等进阶功能，前端同样只需要对接网关的地址，网关再转发到各个微服务。这也是大型企业微服务架构的标准实践，完全符合微服务的设计理念。

关于你担心的“中转API违背初衷” #

你提到的“统一公共API中转”如果是指自己写一个业务层的中转服务，那确实可能违背微服务的独立性；但上面说的反向代理、API网关都是纯流量路由层，不介入业务逻辑，反而微服务架构里本来就推荐用统一入口来简化前端对接、降低耦合，所以完全没问题。

内容的提问来源于stack exchange，提问作者polcompany