基础设施组件全景 / Infrastructure Components Landscape
📅 创建时间：2026-07-28 🏷️ 标签：#Infrastructure #ReverseProxy #APIGateway #ServiceDiscovery #ConfigCenter #ServiceMesh #IaC 📚 前置知识：[[../00-overview]]（中间件全景）
📋 本章目标
- 理解基础设施层的五大核心组件及其在架构中的定位
- 掌握反向代理与 API 网关的差异——不只是"功能多少"的区别
- 理解服务发现的三种模式，以及每种模式适合的场景
- 理解配置中心与简单配置文件/环境变量的根本差异
- 建立基础设施即代码（IaC）的思维——用代码管理基础设施，而不是手动操作
- 能够在实际项目中为基础设施选型提供清晰的决策理由
第1部分：基础设施组件全景
1.1 从单体到微服务——基础设施为什么变得重要
┌─────────────────────────────────────────────────────────────┐
│ 单体时代 vs 微服务时代 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 单体时代（1 个进程）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 一个进程搞定一切 │ │
│ │ • 不需要服务发现（只有一个服务） │ │
│ │ • 配置文件写在本地（config.properties） │ │
│ │ • 不需要负载均衡（没有多个实例） │ │
│ │ • Nginx 只是"静态文件服务器" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 微服务时代（50 个服务，200 个实例）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 问题爆炸了 │ │
│ │ • 服务 IP 天天变 → 需要服务发现 │ │
│ │ • 配置散落 50 处 → 需要配置中心 │ │
│ │ • 实例扩缩容 → 需要负载均衡 │ │
│ │ • 外部请求怎么路由 → 需要 API 网关 │ │
│ │ • 手动部署不可持续 → 需要 IaC │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 结论：微服务解决的是代码组织的问题，但把复杂度转移到了 │
│ 基础设施层。基础设施层要做的事情，就是管理这种复杂度。 │
│ │
└─────────────────────────────────────────────────────────────┘1.2 基础设施组件全景图
┌─────────────────────────────────────────────────────────────┐
│ 基础设施五大组件 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 入口流量层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 反向代理 │ │ API 网关 │ │ 负载均衡 │ │ │
│ │ │ Nginx │ │ Kong │ │ LVS / HAProxy │ │ │
│ │ │ Caddy │ │ APISIX │ │ Nginx upstream │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 服务通信层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 服务发现 │ │ 服务网格 │ │ RPC 框架 │ │ │
│ │ │ Consul │ │ Istio │ │ gRPC / Dubbo │ │ │
│ │ │ Nacos │ │ Linkerd │ │ Thrift │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 配置管理层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 配置中心 │ │ 密钥管理 │ │ Feature Flags │ │ │
│ │ │ Apollo │ │ Vault │ │ LaunchDarkly │ │ │
│ │ │ Nacos │ │ KMS │ │ OpenFeature │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 基础设施即代码层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 资源编排 │ │ 配置管理 │ │ CI/CD 部署 │ │ │
│ │ │ Terraform│ │ Ansible │ │ Pulumi │ │ │
│ │ │ CloudF. │ │ Chef │ │ Crossplane │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 每往上一层，离业务代码越近；每往下一层，离基础设施越近。 │
│ │
└─────────────────────────────────────────────────────────────┘1.3 五大组件的职责边界
┌─────────────────────────────────────────────────────────────┐
│ 组件职责边界 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 组件 │ 核心问题 │ 关键能力 │
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ 反向代理 │ 请求转发与流量管理 │ 负载均衡、SSL │
│ │ (Reverse Pxy)│ │ 终止、缓存、限流 │
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ API 网关 │ API 生命周期管理 │ 认证、限流、路由 │
│ │ (API Gateway)│ │ 转换、监控、版本 │
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ 服务发现 │ 找到"谁可用" │ 注册、健康检查 │
│ │ (Svc Disc) │ │ 注销、负载均衡 │
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ 配置中心 │ 配置的"唯一真相源" │ 动态更新、版本 │
│ │ (Config Ctr) │ │ 灰度、审计 │
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ 服务网格 │ 服务间通信治理 │ mTLS、流量控制 │
│ │ (Svc Mesh) │（Sidecar 模式） │ 可观测性、故障注入│
│ ├──────────────┼─────────────────────┼──────────────────┤
│ │ IaC │ 基础设施的版本管理 │ 声明式、幂等 │
│ │ (Infra as Cd)│ │ 可重复、自动化 │
│ │
└─────────────────────────────────────────────────────────────┘第2部分：从单体到微服务的基础设施演进路线图
2.1 阶段一：单体应用（< 10 台服务器）
┌─────────────────────────────────────────────────────────────┐
│ 阶段一：最简单的架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Nginx（静态资源 + 反向代理） │ │
│ │ • 一个 nginx.conf 配所有路由 │ │
│ │ • upstream 写死后端 IP │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 单体应用（Node.js / Spring Boot） │ │
│ │ • 配置文件在 src/main/resources/ │ │
│ │ • 环境变量区分 dev/staging/prod │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ PostgreSQL / MySQL │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 这个阶段不需要服务发现、不需要配置中心。 │
│ 基础设施 = Nginx + 数据库 + 一些环境变量。 │
│ │
└─────────────────────────────────────────────────────────────┘2.2 阶段二：服务拆分（10-50 个服务实例）
┌─────────────────────────────────────────────────────────────┐
│ 阶段二：开始拆服务 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Nginx / HAProxy（负载均衡） │ │
│ │ upstream backend { │ │
│ │ server 10.0.1.1:3000; │ │
│ │ server 10.0.1.2:3000; ← 手动维护，IP 变了要改 │ │
│ │ } │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ 用户服务 │ │ 订单服务 │ │ 商品服务 │ │
│ │ :3000 │───▶│ :3001 │───▶│ :3002 │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ │
│ 痛点： │
│ • Nginx upstream 要手动改（服务 IP 变了怎么办？） │
│ • 配置文件散落各处（改一个配置要重启所有实例） │
│ • 服务之间调用的 URL 写死在代码里 │
│ │
│ 信号：这时候需要服务发现 + 配置中心了。 │
│ │
└─────────────────────────────────────────────────────────────┘2.3 阶段三：基础设施成熟（50+ 服务实例）
┌─────────────────────────────────────────────────────────────┐
│ 阶段三：基础设施成熟 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ API 网关（Kong / APISIX） │ │
│ │ • 认证鉴权 • 限流 • 路由 • 插件化 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 服务发现（Consul / Nacos） │ │
│ │ • 所有服务启动时注册 │ │
│ │ • 健康检查自动剔除故障实例 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 配置中心（Apollo / Nacos） │ │
│ │ • 所有配置集中管理 │ │
│ │ • 配置变更实时推送，无需重启 │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 用户服务 │ │ 订单服务 │ │ 商品服务 │ │
│ │ ×2 实例 │ │ ×3 实例 │ │ ×4 实例 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 这个阶段，基础设施不再是"辅助工具"，而是架构的骨架。 │
│ │
└─────────────────────────────────────────────────────────────┘2.4 阶段四：服务网格与 IaC（100+ 服务实例）
┌─────────────────────────────────────────────────────────────┐
│ 阶段四：服务网格 + IaC │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 服务网格（Istio / Linkerd） │ │
│ │ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 用户服务 │ │ 订单服务 │ │ │
│ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │
│ │ │ │ Sidecar │◀─┼───┼─▶│ Sidecar │ │ mTLS 加密 │ │
│ │ │ │ (Envoy) │ │ │ │ (Envoy) │ │ 流量控制 │ │
│ │ │ └────────┘ │ │ └────────┘ │ │ │
│ │ └──────────────┘ └──────────────┘ │ │
│ │ 业务代码不感知 Sidecar（透明代理） │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ IaC（Terraform / Pulumi） │ │
│ │ • 所有基础设施通过代码声明 │ │
│ │ • 一键创建/销毁整个环境 │ │
│ │ • 基础设施变更进入 Git 版本管理 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 这个阶段的标志：基础设施的变更频率与代码变更频率持平。 │
│ │
└─────────────────────────────────────────────────────────────┘2.5 演进路线总结
┌─────────────────────────────────────────────────────────────┐
│ 基础设施成熟度模型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Level 0：手动阶段 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 手写 nginx.conf，手动部署，SSH 上去改配置文件 │ │
│ │ 适用：3 台以内服务器，1 个应用 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Level 1：脚本阶段 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 用 Ansible/Bash 脚本自动化部署 │ │
│ │ 适用：10 台以内服务器，2-3 个服务 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Level 2：平台阶段 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 引入服务发现（Consul）+ 配置中心（Apollo） │ │
│ │ 适用：50 台以内服务器，10+ 服务 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Level 3：声明式阶段 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ K8s + Terraform + 服务网格 │ │
│ │ 适用：100+ 服务器，50+ 服务，多环境 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键原则：不要超前建设。Level 0 的项目不要上服务网格。 │
│ 每升一级，运维团队的能力必须同步升级。 │
│ │
└─────────────────────────────────────────────────────────────┘第3部分：反向代理 vs API 网关
3.1 核心差异——不是"谁功能多"的问题
┌─────────────────────────────────────────────────────────────┐
│ 反向代理 vs API 网关 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 反向代理（Nginx / Caddy / Traefik）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 核心职责：流量转发 │ │
│ │ • 接收客户端请求 → 转发给后端 → 返回响应 │ │
│ │ • 工作在 L4（TCP/UDP）或 L7（HTTP/HTTPS） │ │
│ │ • 关心的是"怎么转发"而不是"转发给谁" │ │
│ │ • 配置 = nginx.conf（声明式，静态） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ API 网关（Kong / APISIX / Envoy）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 核心职责：API 生命周期管理 │ │
│ │ • 认证鉴权 • 限流 • 路由转换 • 协议转换 │ │
│ │ • 工作在 L7（HTTP/HTTPS/gRPC） │ │
│ │ • 关心的是"这个 API 允许谁调用、怎么调用" │ │
│ │ • 配置 = Admin API（动态，运行时修改） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 一句话区分： │
│ 反向代理说："我不知道你是谁，我帮你把请求转过去。" │
│ API 网关说："让我看看你是谁，你要调用什么 API，有什么权限。"│
│ │
└─────────────────────────────────────────────────────────────┘3.2 Nginx / Kong / Envoy 三方对比
┌─────────────────────────────────────────────────────────────┐
│ Nginx vs Kong vs Envoy │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 维度 │ Nginx │ Kong │ Envoy │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 定位 │ 反向代理/ │ API 网关 │ 数据平面 │
│ │ │ Web 服务器 │ (基于 Nginx) │ Sidecar │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 配置方式 │ 静态配置文件 │ Admin API │ xDS 动态 │
│ │ │ nginx.conf │ (RESTful) │ 配置 │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 插件生态 │ 编译时模块 │ Lua/Go/JS │ WASM/ │
│ │ │ (需重新编译) │ 插件 │ 内置 Filter│
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 性能 │ ⭐⭐⭐⭐⭐ │ ⭐⭐⭐⭐ │ ⭐⭐⭐⭐ │
│ │ │ C 语言原生 │ 基于 Nginx │ C++ 原生 │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 动态配置 │ ❌ 需 reload │ ✅ Admin API│ ✅ xDS │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 服务发现集成 │ ❌ 需插件 │ ✅ 内置 │ ✅ 内置 │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 适用场景 │ 静态路由/ │ API 管理/ │ 服务网格 │
│ │ │ 静态资源 │ 微服务网关 │ Sidecar │
│ │
│ 选型建议： │
│ • 简单反向代理 + 静态资源 → Nginx │
│ • 需要 API 管理能力（认证/限流/插件）→ Kong │
│ • 服务网格数据平面 → Envoy（通常配合 Istio） │
│ • 现代化替代 → Caddy（自动 HTTPS）或 Traefik（容器原生） │
│ │
└─────────────────────────────────────────────────────────────┘第4部分：服务发现的三种模式
4.1 三种模式图解
┌─────────────────────────────────────────────────────────────┐
│ 服务发现的三种模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 模式一：DNS-based（DNS 服务发现） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 客户端 → DNS 查询 "user-service.internal" │ │
│ │ → 返回 [10.0.1.1, 10.0.1.2, 10.0.1.3] │ │
│ │ → 客户端选一个连接 │ │
│ │ 优点：零代码侵入，任何语言都支持 │ │
│ │ 缺点：DNS 缓存 TTL 导致故障感知慢 │ │
│ │ 代表：K8s CoreDNS, Consul DNS 接口 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 模式二：Client-side Discovery（客户端发现） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 客户端 → 查询注册中心（Consul/Nacos） │ │
│ │ → 拿到所有健康实例列表 │ │
│ │ → 客户端自己负载均衡选一个 │ │
│ │ 优点：没有额外网络跳转，性能好 │ │
│ │ 缺点：客户端需要集成服务发现 SDK（语言绑定） │ │
│ │ 代表：Dubbo + Zookeeper, Spring Cloud + Eureka │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 模式三：Server-side Discovery（服务端发现） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 客户端 → 负载均衡器（Envoy/Nginx） │ │
│ │ → 负载均衡器查询注册中心 │ │
│ │ → 负载均衡器选择实例并转发 │ │
│ │ 优点：客户端零感知，无语言绑定 │ │
│ │ 缺点：多一跳网络，负载均衡器需高可用 │ │
│ │ 代表：K8s Service + kube-proxy, Istio + Envoy │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘4.2 三种模式的决策矩阵
┌─────────────────────────────────────────────────────────────┐
│ 服务发现模式选型 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 条件 │ 推荐模式 │
│ ├────────────────────────────┼──────────────────────────┤
│ │ 已有 K8s 平台 │ DNS-based (CoreDNS) │
│ ├────────────────────────────┼──────────────────────────┤
│ │ Java 技术栈统一 │ Client-side (Nacos) │
│ ├────────────────────────────┼──────────────────────────┤
│ │ 多语言异构 │ Server-side (Envoy/Istio)│
│ ├────────────────────────────┼──────────────────────────┤
│ │ 已有服务网格 │ Server-side (内置) │
│ ├────────────────────────────┼──────────────────────────┤
│ │ 传统 VM 部署（非 K8s） │ Client-side (Consul) │
│ ├────────────────────────────┼──────────────────────────┤
│ │ 最小复杂度 │ DNS-based │
│ │
│ 核心原则：选择与当前基础设施复杂度匹配的方案， │
│ 而不是"最先进"的方案。 │
│ │
└─────────────────────────────────────────────────────────────┘第5部分：配置中心 vs 环境变量 vs Feature Flags
5.1 三种配置方式的定位差异
┌─────────────────────────────────────────────────────────────┐
│ 配置管理三兄弟 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 环境变量（Env Var）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ DATABASE_URL=postgres://... │ │
│ │ REDIS_HOST=redis.internal │ │
│ │ • 适合：连接信息、密钥等启动时确定的配置 │ │
│ │ • 修改需要重启进程 │ │
│ │ • K8s 中通过 ConfigMap/Secret 注入 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 配置中心（Config Center）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Apollo / Nacos 管理的配置 │ │
│ │ • 适合：业务参数、开关、阈值等需要动态调整的配置 │ │
│ │ • 修改后实时生效（Long Polling / Push） │ │
│ │ • 支持灰度发布、版本管理、审计日志 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Feature Flags（特性开关）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LaunchDarkly / OpenFeature │ │
│ │ • 适合：新功能逐步放量、A/B 测试、紧急关闭功能 │ │
│ │ • 按用户/租户/百分比精细控制 │ │
│ │ • 更偏向业务决策，而非基础设施配置 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 三者不是替代关系，是互补关系： │
│ 环境变量 → "这个服务怎么连接数据库"（基础设施） │
│ 配置中心 → "订单超时时间是 30 分钟还是 60 分钟"（业务） │
│ Feature Flag → "新推荐算法给 5% 的用户开放"（决策） │
│ │
└─────────────────────────────────────────────────────────────┘第6部分：基础设施即代码（IaC）
6.1 为什么 IaC 不是"用脚本部署"
┌─────────────────────────────────────────────────────────────┐
│ IaC 的核心价值 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统方式（点击操作 / 手动 SSH）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 登录云控制台 → 创建 VM → 选规格 → 等待 │ │
│ │ 2. SSH 上去 → apt install nginx → 改配置 │ │
│ │ 3. 搞了半天 → "咦，上次这个参数设的是什么？" │ │
│ │ 4. 环境不一致：测试环境 2 核 4G，生产 8 核 16G │ │
│ │ 5. 续聘交接：前运维离职，没人知道服务器怎么配的 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ IaC 方式（Terraform / Pulumi）： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 写 .tf 文件声明你要什么 │ │
│ │ 2. terraform plan → 预览变更 │ │
│ │ 3. terraform apply → 自动创建/更新 │ │
│ │ 4. Git 里记录所有基础设施变更历史 │ │
│ │ 5. 任何人 clone 仓库，terraform apply 得到同样环境 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ IaC 的本质：用声明式代码描述"你想要什么状态"， │
│ 工具负责把当前状态"调和"到目标状态（状态收敛）。 │
│ │
└─────────────────────────────────────────────────────────────┘6.2 IaC 工具对比
┌─────────────────────────────────────────────────────────────┐
│ Terraform vs Pulumi vs Ansible │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 维度 │ Terraform │ Pulumi │ Ansible │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 范式 │ 声明式 │ 声明式 │ 过程式 │
│ │ │ (HCL) │ (通用语言) │ (YAML) │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 语言 │ HCL（专用） │ TS/Py/Go/ │ YAML │
│ │ │ │ C#/Java │ │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 状态管理 │ State File │ State File │ 无状态 │
│ │ │ (本地/S3) │ (托管服务) │ │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 适用场景 │ 云资源编排 │ 云资源+应用 │ 配置管理 │
│ │ │ (Infra) │ (Infra+App) │ 部署 │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 幂等性 │ ✅ 天然 │ ✅ 天然 │ ⚠️ 需保证 │
│ ├──────────────┼─────────────┼─────────────┼──────────┤
│ │ 学习曲线 │ 中等 │ 低（熟语） │ 低 │
│ │
│ 选型建议： │
│ • 纯基础设施（VM/网络/数据库）→ Terraform（行业标准） │
│ • 基础设施 + K8s 应用 → Pulumi（统一语言） │
│ • 配置管理/批量操作 → Ansible（过程式更灵活） │
│ │
└─────────────────────────────────────────────────────────────┘核心总结
总结1：基础设施是微服务的骨架
微服务把代码拆开了，但如果没有服务发现、配置中心、API 网关这些基础设施组件，微服务就是"分布式单体"——服务之间互相找不到、配置散落各处、流量无法治理。
总结2：从问题出发选组件，而不是从功能出发
不要问："我要不要上服务网格？"
要问："我当前的服务间通信有什么问题？这些问题用代码能解决吗？"基础设施组件的引入成本很高——不只是技术成本，还包括团队学习成本、运维成本、故障排查复杂度。
总结3：基础设施的成熟度应该与业务规模匹配
10 个服务不需要服务网格，3 台服务器不需要 Terraform（手动操作更高效）。基础设施的建设应该是"演进式"的，而非"一步到位"的。
总结4：环境变量、配置中心、Feature Flags 各有各的定位
它们不是竞争关系，而是互补关系。环境变量管连接，配置中心管参数，Feature Flags 管决策。强行用一个替代另一个只会增加复杂度。
章节测试
测试1：反向代理和 API 网关的核心区别是什么？
A. 反向代理性能更好，API 网关功能更多 B. 反向代理负责流量转发，API 网关负责 API 生命周期管理（认证/限流/路由） C. 反向代理只能 HTTP，API 网关支持所有协议 D. API 网关是反向代理的升级版，功能完全覆盖
测试2：以下哪种场景最适合使用 DNS-based 服务发现？
A. 需要客户端自定义负载均衡策略 B. 已有 K8s 平台，希望零代码侵入 C. 多语言异构服务间通信 D. 需要实时感知服务上下线
测试3：配置中心相对于环境变量的核心优势是什么？
测试4：Terraform 和 Ansible 的最核心区别是什么？
测试5：有一个 5 人团队的初创公司，3 个微服务，跑在阿里云 5 台 ECS 上。以下哪个基础设施方案最合适？
A. K8s + Istio + Terraform + Apollo B. Nginx 反向代理 + 环境变量 + 手动部署 C. Envoy + Consul + Nacos + Pulumi D. Kong + Etcd + Vault + Crossplane
参考答案
测试1答案
答案：B。反向代理的核心是"流量转发"——接收请求，转发到后端。API 网关的核心是"API 生命周期管理"——管理谁可以调用什么 API，以什么速率调用。两者的设计哲学完全不同：反向代理不关心请求内容，API 网关深度理解请求内容。
测试2答案
答案：B。DNS-based 服务发现的核心优势是零代码侵入——客户端只需要解析 DNS 就能获取服务地址，不需要引入任何 SDK。K8s CoreDNS 是这种模式的典型实现。但它的弱点是 DNS TTL 缓存导致故障感知延迟（通常 30s-5min）。
测试3答案
配置中心相对于环境变量的核心优势：
- 动态更新：修改配置无需重启服务，实时生效
- 版本管理：每次配置变更都有记录，可以回溯和回滚
- 灰度发布：可以按实例/集群逐步推送配置变更
- 集中管理：几十个服务的配置在同一平台管理，而不是散落在各处的 .env 文件
- 审计日志：谁、什么时候、改了什么配置，全有记录
测试4答案
Terraform 是声明式的资源编排工具：你写"我要什么"（如"我要一个 2C4G 的 VM"），Terraform 计算差异并执行。有状态文件追踪资源。适合云基础设施的创建和管理。
Ansible 是过程式的配置管理工具：你写"怎么做"（如"安装 Nginx → 复制配置文件 → 启动服务"），Ansible 按顺序执行。无状态。适合服务器的配置管理和应用部署。
简单说：Terraform 负责"把机器造出来"，Ansible 负责"把机器配置好"。
测试5答案
答案：B。5 人团队、3 个微服务、5 台 ECS——这个规模不需要过度建设基础设施。Nginx 反向代理 + 环境变量 + 手动部署是最匹配的方案。选项 A 引入了太多组件，运维成本远超收益。
相关笔记
- [[01-nginx-and-reverse-proxy]] — Nginx 反向代理/负载均衡/SSL
- [[02-service-discovery]] — 服务发现深入（Consul/Nacos/DNS）
- [[03-configuration-center]] — 配置中心深入（Nacos/Apollo/Vault）
- [[../00-overview]] — 中间件全景总览
下一步学习
- [ ] 阅读 01 - Nginx 与反向代理 — 掌握 Nginx 的架构与配置
- [ ] 阅读 02 - 服务发现 — 理解 Consul 和服务发现的三种模式
- [ ] 阅读 03 - 配置中心 — 掌握配置管理的演进与最佳实践
- [ ] 评估你当前项目的架构处于哪个成熟度阶段，是否需要引入新的基础设施组件
学习状态：🟡 开始学习