2. 环境规划与架构设计：物理/虚拟化环境规划、网络拓扑设计、高可用架构选型
服务目录平台作为企业 IT 服务管理的核心入口，其底层环境的稳定性与扩展性直接决定了平台可用性。本章从物理/虚拟化资源规划、网络拓扑设计、高可用架构选型三个维度展开，为后续自动化部署与故障排查奠定基础。
2.1 物理与虚拟化环境规划
根据平台规模与业务连续性要求，推荐采用 混合部署 策略：控制平面（数据库、消息队列、配置中心）部署在物理机或高性能虚拟化实例上，业务平面（Web 服务、API 网关、Worker 节点）采用容器化或虚拟化弹性伸缩组。
| 组件角色 | 推荐部署方式 | 最低配置（生产） | 说明 |
|---|---|---|---|
| 数据库（PostgreSQL/MySQL） | 物理机 / 裸金属虚拟化 | 8 vCPU, 32 GB RAM, SSD RAID10 | 高 IOPS 要求，避免资源争抢 |
| 消息队列（Kafka/RabbitMQ） | 物理机 / 专用 VM | 4 vCPU, 16 GB RAM, 高吞吐磁盘 | 磁盘吞吐与网络延迟敏感 |
| 配置中心 / 注册中心 | 虚拟机（3 节点集群） | 2 vCPU, 4 GB RAM | 低资源消耗，但需跨可用区部署 |
| Web 服务 / API 网关 | 容器化（K8s / Docker Swarm） | 2 vCPU, 4 GB RAM / 实例 | 水平扩展，无状态设计 |
| Worker / 异步任务节点 | 容器化 / 虚拟化弹性伸缩组 | 2 vCPU, 8 GB RAM / 实例 | 根据队列深度自动扩缩容 |
规划要点： 生产环境务必为数据库与消息队列预留独立的物理 NUMA 节点或 vCPU 绑定，避免因 CPU 争抢导致延迟抖动。虚拟化层建议使用 VMware vSphere 或 KVM + oVirt，并开启 CPU 预留与内存大页。
2.2 网络拓扑设计
网络拓扑采用 三层隔离 + 东西向流量优化 模型：接入层（公网/内网负载均衡）→ 业务层（服务集群）→ 数据层（有状态中间件）。各层之间通过防火墙策略与安全组实现最小权限通信。
网络隔离策略：
- 接入层 → 业务层： 仅开放 443 (HTTPS) 与 80 (HTTP 重定向)，源 IP 为 SLB 地址池。
- 业务层 → 数据层： 仅开放数据库端口 (5432)、Kafka 端口 (9092)、Redis 端口 (6379)，源 IP 为业务层 Pod/VM 网段。
- 数据层内部： 复制流量走独立存储网络，禁止跨 VLAN 广播。
2.3 高可用架构选型
高可用设计遵循 消除单点 + 自动故障转移 原则。根据组件特性，分别采用不同的 HA 策略：
| 组件 | HA 模式 | 故障切换时间 | 关键依赖 |
|---|---|---|---|
| 负载均衡器 | 主备 (Keepalived + Nginx) / 云 SLB | < 5 秒 | VIP 漂移、健康检查脚本 |
| Web 服务 / API | 水平扩展 + 无状态 + 滚动更新 | < 30 秒（K8s 自动恢复） | 就绪探针、资源配额 |
| PostgreSQL | 流复制同步 + Patroni 自动故障转移 | < 10 秒 | etcd / Consul 作为 DCS |
| Kafka | 多副本 (replication-factor ≥ 3) + ISR | < 2 秒（Leader 选举） | ZooKeeper / KRaft 仲裁 |
| Redis | Sentinel 哨兵 / Redis Cluster | < 3 秒（Sentinel 选举） | quorum 设置、网络分区容忍 |
| 配置中心 | 3 节点集群 (Raft 共识) | < 5 秒（Leader 切换） | 持久化存储、节点间低延迟 |
关键避坑：
- 数据库 HA 务必使用 同步复制 或 半同步复制，异步复制在主机宕机时可能丢失最后一批事务。
- Kafka 副本因子设置为 3，min.insync.replicas 设置为 2，防止单副本故障导致数据不可用。
- Redis Sentinel 的 quorum 设置为 2（3 节点哨兵），避免网络分区时出现双主。
- 所有 HA 组件必须部署在 不同物理机 / 不同可用区，否则无法抵御物理级故障。
2.4 架构选型决策矩阵
根据团队运维能力与预算，提供三种典型架构选型方案：
| 方案 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| 全虚拟化 + 传统 HA | 中小规模，运维团队 2-3 人 | 技术栈成熟，故障排查直观 | 弹性伸缩慢，资源利用率低 |
| 容器化 + K8s 编排 | 中大规模，DevOps 团队 | 弹性好，滚动更新，声明式管理 | 学习曲线陡，网络排查复杂 |
| 混合架构（推荐） | 生产环境，追求稳定性与弹性 | 有状态组件物理隔离，无状态弹性伸缩 | 运维复杂度中等，需统一监控 |