高可用微服务子网规划需按职责分网、信任分级、流量控制，划分public_net、backend_net、internal_net等逻辑隔离平面，预设无冲突CIDR，配合显式网络声明与语义化命名实现安全、可观测、可运维架构。
规划高可用微服务架构的子网，核心不是单纯切分IP段，而是让网络结构映射业务逻辑、故障域和安全边界。关键在于“按职责分网、按信任分级、按流量控通”，而不是堆砌技术参数。
按业务域划分隔离网络平面
不同职责的服务必须运行在逻辑分离的网络中，避免“所有容器都在一个网段里互 ping”。例如电商系统可划分为：
- public_net：仅承载 API 网关、静态资源服务，只开放 80/443，禁止直连后端
- backend_net：用户服务、订单服务、商品服务等业务模块，彼此可通过服务名通信
- internal_net：数据库、Redis、Elasticsearch 等敏感组件，该网络不与 backend_net 全通，仅允许白名单服务（如 order-service）显式接入
为每个网络分配固定、无冲突的子网
生产环境严禁使用 Docker 默认随机子网。应预先规划 CIDR 块，确保不与宿主机、K8s 集群、云厂商 VPC 或办公网重叠。常见做法：
- frontend：172.20.1.0/24（网关、Nginx、前端 SSR 服务）
- backend：172.20.2.0/24（Java/Go 微服务集群）
- internal：172.20.3.0/24（PostgreSQL、Redis、MinIO）
- monitoring：172.20.4.0/24（Prometheus、Grafana、Loki）
每个子网预留足够地址空间（如 /24 提供 253 个可用 IP），兼顾扩容与调试容器临时接入需求。
通过网络连接策略控制服务间可达性
子网本身不自动产生隔离，必须配合显式连接声明。在 docker-compose.yml 中：
- web 服务只接入 frontend 网络
- api 服务同时接入 frontend 和 backend
- db 服务只接入 internal，且 backend 中指定 service 的 networks 下明确列出 internal
这样，即使两个服务同属 backend_net，若未在配置中双向声明，Docker DNS 就不会解析对方服务名，天然实现通信阻断。
绑定语义元数据，支撑可观测性与自动化运维
子网命名需携带业务含义，而非 generic-net 或 net1。例如：
- cn-north-1-backend（地域+层级）
- payment-internal（业务域+安全等级）
- user-canary（服务+发布策略）
这些名称应同步写入服务注册中心（如 Consul、Nacos）的 metadata 字段，并作为标签注入 Prometheus metrics 和日志采集器。当某子网延迟突增时，可立即关联到对应 region、service、deps，无需人工翻配置。
