基础设施即代码

概述 去年给一家做电商的客户搭 IaC 体系，接手时他们的 Terraform 代码库大概长这样：三个环境（dev/staging/prod）各自一套配置，加起来 3000 多行，90% 是复制粘贴。改一个 VPC CIDR 要同步改三个文件，漏改一个就是环境漂移。最离谱的是有个安全组规则在 prod 里少了一条，三个月没人发现。 这种痛每个用过 Terraform 的团队都经历过。模块化是公认的解法——但很多人做完模块化后发现：代码确实短了，可维护性反而更差了。一个模块塞了 40 个变量、3 层嵌套，改一个参数要翻三个文件才能理解影响面。这就是"把模块写成黑盒"的典型症状。 这篇文章拆解我在多个企业客户项目中验证过的一套 Terraform 模块分层架构，以及 6 个在生产环境中真实踩过的反模式。不是泛泛的"最佳实践"罗列，而是每个决策点都附上"为什么这么做"和"什么场景下不推荐这么做"。 为什么需要模块化 先说清楚模块化解决什么问题。不是"代码复用"这么笼统的话，而是三个具体痛点： 痛点一：环境漂移。 三个环境的配置本应一致，但人工复制必然出错。在某出行项目中，我们统计过：复制粘贴的配置平均每个环境有 3-5 处细微差异（CIDR 偏移、可用区数量不一致、安全组规则遗漏），这些差异在平时不爆发，一出故障就是定位地狱。 痛点二：变更同步成本。 改一个 AMI ID 要在 3 套环境里各改一次。如果团队有 5 个人同时改不同模块，合并冲突频繁到让人怀疑人生。 痛点三：知识传递断裂。 新人来了看一个 800 行的 main.tf，完全不知道哪些资源是有关联的、改哪个会影响哪个。没有模块边界，就没有认知锚点。 模块化的本质不是"把代码拆短"，而是建立明确的抽象边界——让每个模块成为一个可以独立理解、独立测试、独立变更的单元。 模块分层架构设计 三层模型 我推荐的三层架构如下： 层级 职责 示例 变量数量 资源数量 基础模块 封装单一云资源 modules/vpc、modules/rds 5-15 3-8 组合模块 组合多个基础模块 modules/eks-platform 15-30 调用 3-5 个基础模块 环境层 定义环境差异化配置 envs/prod/ 不限 调用 2-4 个组合模块 这三层不是什么新概念，但很多人在实际落地时会把层级搞混——最常见的是基础模块里塞了组合逻辑，或者环境层直接调用基础模块跳过了组合层。下面逐层拆解。...

概述 凌晨三点，手机震了。告警群一条消息：某云厂商华东 region 存储服务大面积不可用。你负责的核心业务全量部署在这个 region，数据库的主库也在那边。故障已经持续 12 分钟，客户开始投诉，老板在群里问"多久能恢复"。 你心里清楚：跨 region 容灾方案半年前就评审过，但因为"成本太高"被砍了。现在只能硬扛。 这是真实发生过的场景。2023 年阿里云香港机房宕机事件，让不少只做单 region 部署的团队第一次认真思考跨云容灾的问题。但多云架构远不止"把服务部署到两个云"那么简单——网络怎么连通？数据怎么同步？监控怎么统一？成本怎么控制？切换时谁来决策？ 这篇文章拆解多云架构设计中的关键决策点，每一层都给出我在实际项目中的选型理由和踩过的坑。不是教科书式的"多云架构有哪些优势"，而是一线架构师面对真实约束时做的取舍。 多云 vs 混合云 vs 多区域：先搞清楚你在做哪个 很多人把这三个概念混着用，但它们解决完全不同的问题。 维度 多云（Multi-Cloud） 混合云（Hybrid Cloud） 多区域（Multi-Region） 定义 使用 2+ 个公有云厂商 公有云 + 私有云/本地机房 同一云厂商的不同区域 核心目标 避免厂商绑架、选择性采购 数据合规+弹性扩展 容灾+就近访问 网络复杂度 高（跨厂商 VPC 互联） 中（VPN/专线） 低（厂商内网） 典型场景 A 云跑 AI 推理，B 云跑数据库 核心数据在本地，弹性计算在云 同 region 双活+跨 region 灾备 我的判断：如果你的核心诉求只是"不把鸡蛋放在一个篮子里"，先做多区域部署，成本和复杂度远低于跨厂商多云。真正的多云架构应该由业务需求驱动——比如某个云的 GPU 性价比明显更好，或者合规要求特定数据必须在特定云上处理。 我在某出行项目里做过一次"伪多云"的评估：技术团队想用多云来"降低成本"，但拆开账单后发现，95% 的成本来自计算和存储资源，跨云迁移后资源单价差异不到 8%，而增加的运维和跨云传输成本吃掉了这块差价。最后改成同厂商多区域 + 预留实例优化，成本反而降了 22%。 别为了多云而多云。先算清楚收益和成本的账。 为什么真的需要多云：四个真实驱动因素 1. 供应商绑架规避 这是最常见的多云驱动因素，但也是最容易被高估的。...