🚀 保护您的微服务:API Gateway + Docker 私有网络
Source: Dev.to
🚀 为首次构建分布式系统的开发者提供的实用指南
在第一次构建微服务时,大多数开发者会关注功能、扩展或拆分单体——几乎没有人谈论安全架构。而这正是出错的关键点。在开发自己的分布式系统时,我发现几个内部 API 甚至 PostgreSQL 数据库意外地对外暴露了。😬
于是我实现了一个简单、可投入生产的模式:API 网关 + Docker 私有网络。本文展示了我如何(以及为什么)这样做,以及你如何在自己的项目中复用同样的做法。
真正的问题:微服务意外暴露了一切

典型的初学者配置如下:
- 每个服务都在自己的端口上暴露
- 客户端直接与所有服务通信
- 数据库也可能被暴露
- 没有统一的控制或路由
这会导致安全问题、调试复杂度提升以及架构混乱。
第 1 部分 — API 网关:你的唯一入口点
为什么 API 网关至关重要

工作原理
- 客户端向网关发送单一请求。
- 网关决定由哪个服务处理该请求。
- 它在私有 Docker 网络内部转发请求。
- 内部 URL 永不对外暴露。
网关不仅是一个花哨的路由器——它是整个系统的前门。
它的重要性体现在
- 统一的身份验证点
- 统一的路由点
- 内部服务保持隐藏
- 代码更简洁、控制更好
如果直接调用每个服务:
http://localhost:3000/orders
http://localhost:4000/reports
客户端只需要调用:
http://gateway/api/orders
网关在内部转发请求,服务本身无需对外暴露。
第 2 部分 — Docker 私有网络(物理安全层)
Docker 网络如何保护系统

为什么这很重要
如果没有私有网络,Docker 会把容器直接暴露给宿主机。有了私有网络:
- 只有网关可以从外部访问
- 所有内部流量都停留在网络内部
- 数据库无法被直接访问
将服务放入私有 Docker 网络可以阻止外部世界访问除你显式暴露的内容之外的任何东西。
好处
- 仅内部通信
- 零意外端口暴露
- 数据库完全隔离
- 干净、专业的架构
即使有人设法绕过网关(极少见),他们仍然无法访问 Service A、B 或数据库,因为这些容器不在公共网络上。
两者结合:简洁且坚固的安全模式
完整架构的协同工作方式

当你同时使用:
- 逻辑安全(API 网关)
- 物理安全(私有网络)
就能得到既简单又强大的微服务架构——无需 Kubernetes、服务网格或繁重的 DevOps 工具。
Client
↓
API Gateway
↓
Private Docker Network
├── Service A
├── Service B
└── Database
只有网关是公开的,其他一切都安全地隐藏在其后。
最小化 Docker Compose 示例(可直接复制)
services:
api-gateway:
build: ./gateway
ports:
- "8080:8080"
networks:
- public_net
- private_net
service-a:
build: ./service-a
expose:
- "3000"
networks:
- private_net
service-b:
build: ./service-b
expose:
- "4000"
networks:
- private_net
internal-db:
image: postgres:16
expose:
- "5432"
environment:
POSTGRES_PASSWORD: password
networks:
- private_net
networks:
public_net:
private_net:
关键要点
- 只有网关拥有已发布端口 → 对外公开
- 内部服务使用
expose→ 私有 - 所有服务都在
private_net中 - 通过最少的配置实现干净、安全的架构
我的收获
- 完全避免内部服务意外暴露
- 安全、可预测的入口点
- 调试更快
- 团队成员上手更容易
- 为未来服务提供可扩展的基础
- 使用入门级工具实现专业级架构
最后思考
这个架构看起来很简单——正因为如此它才有效。你并不需要 Kubernetes、服务网格或复杂的 DevOps 环境,就能构建安全且可扩展的分布式系统。
从以下两点开始:
- 一个 API 网关
- 一个私有 Docker 网络
这套基础设施会随着系统的成长自然支撑你的需求。
简洁、干净、安全、高效。