文章探讨云退出架构：企业迁移云服务商为何困难

大多数企业进入云计算时，都认为灵活性是交易的一部分。更快行动。按需扩展。按使用量付费。避免漫长的采购周期。不再购买那些闲置等待峰值需求的硬件。这是当初的承诺，而且大部分确实兑现了。

然而，许多企业还做了一个后来被证明只对了一半的假设：如果有一天你需要离开某个云服务商，你可以做到。技术上，是的。实际上，并不总是如此。在许多情况下，系统的设计、部署、安全、集成和运维方式，使得离开某个服务商的成本高到足以让这个选项更多停留在理论层面而非现实层面。

这正是云退出架构（cloud exit architecture）的用武之地。

云退出架构不是放弃云计算的计划。它不是对云原生服务的排斥。它不是回到过去那种假装一切应该在任何地方以相同方式运行的旧时光。它是一种设计系统的纪律，使系统能够在定价、监管、故障、地缘政治关切、供应商策略或业务优先级发生变化时迁移。这听起来很无聊，直到你需要它的那一天。那时，它就成为你没有做出的最重要的架构决策。

可移植性是业务需求

企业通常将可移植性作为技术目标来讨论。这太狭隘了。可移植性是业务风险控制。如果服务商改变定价，如果某个区域变得不可用，如果法规要求数据迁移，或者如果重大故障暴露了集中度风险，业务需要选择权。这些选择权不应需要两年的重写和让董事会震惊的预算。

许多组织犯的错误是等到有了离开的理由才开始思考离开将如何运作。到那时，每一个依赖都已经深埋在生產系统中。身份绑定在一个服务商的访问模型上。数据存储在专有服务中，使用服务商特定的格式或API。网络围绕云特定的构造而构建。基础设施即代码模板充满了只在一个环境中有效的假设。监控、日志、密钥、密钥管理和部署流水线都依赖同一个控制平面。

到那时，你并不是真正在使用云。而是云在使用你。

身份应该能够迁移

身份通常是第一个可移植性问题，也是架构师最后才想到的问题。许多系统过度依赖服务商原生身份服务，而没有创建清晰的抽象。这在组织需要迁移工作负载、支持多云或满足改变认证和授权发生位置的监管要求之前一直运作良好。

更好的方法是设计身份使其能够迁移。这通常意味着使用基于标准的联合，如SAML、OAuth或OpenID Connect，并将企业身份锚定在不会与单一云部署不可分割的地方。它还意味着分离人类身份、工作负载身份、服务间身份和授权策略。

太多系统将这些混在一起。一个服务账户、一个云角色、一个权限边界和一个应用授权决策变成一团纠缠的乱麻。它能工作，但只在一个地方。好的退出架构使身份在服务商之外也能被理解。用户是谁？工作负载是什么？它能访问什么？该策略在哪里定义？这些规则能否在其他地方表示而无需逆向工程整个应用？如果答案是否定的，系统就不可移植。

数据才是真正的陷阱

计算通常比数据更容易迁移。数据有重力、治理、成本和格式问题。企业喜欢托管数据库、对象存储、分析平台和AI数据服务，因为它们消除了运维负担。这没问题。问题始于组织不再思考数据将如何被提取、转换、验证并在其他地方重新水化。

云退出架构需要对数据格式、元数据、血统、加密、保留和复制有清晰的思考。如果你数据唯一可用的形式存在于服务商特定的服务中，你就有了可移植性问题。这并不意味着每个数据库都必须是开源或自管理的。那是另一个极端，通常是个糟糕的极端。它意味着架构师在选择服务之前应该理解退出路径。

数据能否以标准格式导出？模式是否在平台之外有文档记录？加密密钥的控制方式是否允许迁移？另一个系统能否消费这些数据而无需重建每条流水线？迁移成本是多少？需要多长时间？你将如何验证正确性？这些问题是战略灵活性和云俘虏之间的区别。

网络决定了你有多被困住

网络是许多退出计划失败的地方。应用很少单独存在。它们连接用户、合作伙伴、数据中心、SaaS平台、API、消息代理、安全工具和其他云服务。随着时间推移，网络变成了一张关于一切事物所在位置的假设地图。如果那张地图是特定于一个云服务商的，迁移就变得痛苦。

好的退出架构使用可复制的网络设计。地址规划应该是有计划的，而不是即兴的。连接性应该有文档记录。DNS策略应该支持迁移。流量管理应避免硬编码端点。私有连接应设计时考虑替代方案。

企业还需要考虑出口成本和延迟。一个技术上可移植但财务上无法迁移的系统在任何有意义的层面上都不可移植。架构应该明确哪些数据流是昂贵的，哪些依赖是延迟敏感的，哪些工作负载必须一起迁移。云网络不仅仅是管道。它是退出计划的骨架。

IaC应该描述意图

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）