第2章核心概念与架构

二、核心概念与架构：资源抽象、统一认证、成本管理、自动化编排

好，咱们进入正题。这一章讲的是多云管理平台的骨架——核心概念与架构。说白了，就是搞清楚这玩意儿到底怎么搭、怎么用。我见过不少团队，一上来就急着写代码、接API，结果做到一半发现架构撑不住，回头返工。嗯，咱们别走那条弯路。

多云平台要管AWS、Azure、阿里云、腾讯云……每家云厂商的虚拟机叫法都不一样，API参数更是五花八门。怎么办？

资源抽象层就是干这个的。它把不同云的资源“翻译”成统一的模型。比如，不管你是AWS的EC2，还是阿里云的ECS，在平台里都叫“云主机”。

核心思路：定义一套通用的资源元数据模型，然后为每个云厂商写一个“适配器”（Adapter）。适配器负责把厂商特有的API响应，映射到通用模型上。

我在项目中遇到过最头疼的事：某云厂商突然改了返回字段名，从 InstanceId 改成了 instance_id。幸好我们有抽象层，只改一个适配器就行，上层代码纹丝不动。你想想看，要是每个业务模块都直接调云厂商API，那得改多少地方？

抽象层通常包含这几类资源：

每个资源都有统一的属性：id、name、region、status、tags 等等。这样上层做展示、做编排，就非常舒服了。

我的习惯：抽象层不要做得太“重”。只抽象80%的通用属性，剩下20%的厂商特有属性，通过“扩展字段”（extensions）透传。否则适配器会越写越臃肿。

每个云厂商都有自己的IAM系统。用户记一堆账号密码？不现实。所以多云平台必须做统一认证。

统一认证的核心是身份联邦。平台本身不存密码，而是对接企业的身份源（比如LDAP、AD、Okta）。用户登录平台后，平台再通过“扮演角色”（Assume Role）的方式，去操作各个云厂商的资源。

流程大概是这样的：

我曾经见过一个团队，直接把云厂商的Access Key存在数据库里。嗯，这很危险。一旦数据库被拖库，所有云资源都暴露了。统一认证+临时凭证，才是正道。

注意：临时凭证的过期时间要合理。太短了影响用户体验（老要重新登录），太长了有安全风险。我个人建议默认1小时，允许管理员按需调整。

多云最大的痛点是什么？成本失控。每个云厂商的账单格式不一样，计费项更是千奇百怪。你很难说清楚“这个月到底花了多少钱，花在哪了”。

成本管理模块要解决三个问题：

这里有个坑：不同云厂商的标签策略不一样。AWS的标签区分大小写，Azure的不区分。如果你直接拿标签做成本分摊，很容易对不上。我的做法是：在平台里统一做一次标签标准化，全部转成小写，再去匹配。

成本展示上，我习惯用趋势图和占比图。趋势图看“这个月比上个月涨了多少”，占比图看“哪个云厂商花钱最多”。

避坑指南：我曾经遇到过一个案例，某团队只看总账单，没看趋势图。结果某云厂商的存储费用悄悄涨了3倍，一个月多花了2万美金。后来加了每日成本趋势告警，再也没出过这种问题。

自动化编排，说白了就是“用户点一下，平台自动把资源建好”。不用再走工单、等运维手动操作。

编排的核心是模板化。用户定义一个模板（比如“一套Web应用需要1台Nginx、2台Tomcat、1个RDS”），平台根据模板自动调用各云厂商的API去创建。

模板引擎通常支持两种方式：

方式	说明	适用场景
声明式（Declarative）	用户描述“最终状态”，平台自动计算差异并执行	基础设施即代码（IaC），如Terraform
命令式（Imperative）	用户一步步指定“先做什么、再做什么”	复杂流程编排，如CI/CD流水线

我个人更倾向声明式。你想想看，用户只需要说“我要3台2核4G的云主机”，平台自己去判断：现在有几台？缺几台？要不要替换？省心多了。

编排引擎还要处理依赖关系。比如，先建VPC，再建子网，最后建云主机。如果顺序错了，资源创建就会失败。我习惯用有向无环图（DAG）来管理依赖，每个节点是一个资源操作，边表示依赖关系。

小技巧：编排执行过程中，一定要有“回滚”机制。我曾经有一次编排脚本写错了，一下子创建了50台按量付费的GPU实例。幸好有回滚，5分钟内全部释放，只损失了几百块。要是没有回滚，那账单可就“好看”了。

这四个核心概念，就是多云管理平台的四大支柱：