Adaptive Applications：让应用跨云与本地可移植的架构模式

为什么云原生应用需要「可移植性」重新被讨论

过去几年，云原生架构在弹性、可观测性和交付效率上取得了巨大成功。但 Azure Essentials Show 的一期节目中，嘉宾 Haishi 指出，越来越多客户提出了新的约束：数据主权、合规要求、间歇性网络连接，甚至特殊硬件集成。这些需求的核心都指向同一个问题——业务连续性。

企业希望在 Azure 上运行良好，同时在必要时也能把关键系统迁移到由 Azure Arc 管理的本地基础设施，或边缘环境。这正是 Adaptive Applications（自适应应用）这一架构模式试图解决的矛盾：把「应用需要什么」和「不同环境如何提供」彻底分开。

Azure Arc 是微软提供的混合云与多云管理平台，它能把 Azure 的管理能力（如策略、RBAC、监控、GitOps 配置）延伸到 Azure 之外的任何基础设施——包括本地数据中心、其他公有云和边缘设备。被 Arc 纳管的资源在 Azure 控制台中表现为一等公民，因此企业可以用同一套工具链管理云端与本地工作负载。

在数据主权与合规场景中，Arc 的价值尤为突出：当法规要求数据必须留在本地或特定地理区域时，业务逻辑可以在 Arc 管理的本地 Kubernetes 集群上运行，同时仍受 Azure 的统一治理。这正是 Adaptive Applications 模式得以跨环境落地的基础设施前提——没有 Arc 这类统一控制平面，抽象层之上的能力将难以在不同环境中被一致地提供和观测。

核心思路：以「能力」而非「平台」编程

传统做法是应用直接依赖某个平台的 SDK 或服务端点，一旦换环境就要改代码。Adaptive Applications 提倡 capability-oriented thinking（面向能力的思维）。

以 AI 应用为例：应用真正需要的只是「AI 推理」这项能力，以及一个可访问的端点。至于这个端点背后是 Azure OpenAI 还是本地部署的开源模型，对应用代码来说并不重要。只要抽象层保持不变，部署到 Azure 时接入云端模型，部署到自包含本地环境时换成 Kaito 管理的本地模型，应用本身无需改动。

这一模式的关键在于：平台级依赖被隐藏在能力抽象之后，而能力的构建方式成为独立的关注点。

不止 AI：数据库、缓存与身份的同一套逻辑

Haishi 特别强调了一个常见误解：很多开发者认为只要采用云原生模式、持续迭代应用，代码自然就可移植。但现实中，应用往往依赖认证身份、分析服务等平台级能力，而这些能力未必能随应用一起迁移。

在演示中，团队不仅展示了 AI 依赖的抽象，还展示了数据库、缓存和身份系统如何通过同一套抽象来管理。

Redis 在这里扮演了关键角色。Haishi 早年参与过 Redis 项目，他指出 Redis 的对象模型与这一设计高度契合：可以把能力抽象为资源，再为不同环境定义不同的 recipe（配方）。例如定义一个 SQL 数据库资源，在 Azure 上用 ARM 模板或 Terraform 模板实例化 Azure SQL，在本地则用另一套模板实例化本地 SQL Server 实例。资源定义契约，配方决定实现。

开发者与平台团队的职责如何重新划分

这一模式明确区分了两类角色。开发者面向能力编程，日常工作是调用抽象后的端点与资源，不必关心底层环境的差异；平台团队则负责编写和维护不同环境的 recipe，确保能力在目标环境中被正确提供。

为了让模式落地更顺畅，团队定义了一系列 Redis 资源扩展，覆盖常见抽象场景，并提供命令行工具，用于生成 Redis 制品、以流式方式部署应用。此外还有文档、教程，以及针对数据同步等棘手问题的通用指导——因为数据同步方案在不同平台间差异极大，很难用一套模板通吃。

Haishi 强调，这本质上是一个设计模式，不强制绑定特定工具链。团队可以按自己的节奏采纳和调整。

Recipe（配方） 是 Adaptive Applications 中的核心落地机制，它是一组可参数化的基础设施即代码模板（如 ARM、Bicep 或 Terraform），负责把抽象的资源定义实例化为具体环境中的真实服务。

Recipe 的关键在于「契约与实现分离」：资源定义只声明应用需要什么（例如一个兼容 SQL 的数据库、一个 Redis 兼容的缓存），而 recipe 决定用哪家云、哪种产品、什么规格来满足它。同一个资源定义可以绑定多份 recipe，分别对应 Azure 生产环境、本地自包含环境或边缘环境。平台团队维护 recipe 的版本与适配，开发者则完全无需感知差异。这种机制也让企业可以把内部专有平台封装成 recipe 对外发布，从而在生态中获得更多使用者。

用 AI 代理舰队改造「棕地」应用

对于已经存在的大型遗留系统，如何引入这一模式是最常被问到的问题。团队的思路是借助大模型对代码库的理解能力：

• 分析现有代码库，识别出与平台强耦合的依赖项；
• 提出需要修改的差距清单；
• 进一步生成必要的制品，让开发者能快速部署、试运行、观察差距，并持续迭代。

演示中出现的命令行工具采用了**代理舰队（fleet of agents）**的设计：有负责生成的 agent，也有负责批判性审查的 critique agent，最终输出一份关于「改了什么、删了什么」的详细总结。

该工具已与 Radius 团队提供的技能集成，并计划接入更多技能，同时欢迎社区贡献。不过 Haishi 也坦言，这一工具仍处于早期阶段。

棕地（brownfield）应用 是软件工程中的常用术语，指已经存在并长期运行、承载业务但技术栈陈旧的系统，与之相对的是从零开始构建的「绿地（greenfield）应用」。棕地改造的难点在于：代码规模庞大、平台耦合深、缺乏完整文档，且无法停机重写。

传统的棕地现代化往往依赖人工审读代码、逐项识别依赖，成本高、周期长。而借助大模型对代码库的语义理解能力，可以先自动梳理出与平台强耦合的依赖清单（如硬编码的服务端点、专有 SDK 调用），再生成对应的抽象层与制品，让开发者以增量方式验证和迭代，而不必一次性重写。这也是 AI 代理舰队这一工具设计的主要动因。

一个可运行的多层示例

演示里的示例是一个简易的股票交易模拟器，包含 Web 前端、另一种语言编写的后端、消息管道，以及一个可对话的 agent。身份方面，演示环境使用 Keycloak 作为身份提供方，也可以改为 Entra，或与本地 Active Directory 联合。

最值得注意的一点是部署的「平淡无奇」：一条 rad deploy 命令即可完成，其余交给抽象层。换到 Azure 时 agent 由 OpenAI 模型支撑，本地部署则可选择本地模型。

Radius 是这一模式背后的开源项目，也是演示中 rad deploy 命令的来源。它提供了一套应用定义模型，把应用、其依赖的资源以及环境绑定关系统一描述，并由 Radius 控制平面负责把抽象资源解析为具体环境中的实现。

rad deploy 之所以显得「平淡无奇」，正是因为所有环境差异都被 recipe 和资源抽象吸收：同一条命令在本地与 Azure 上执行，触发的却是不同的底层模板。Radius 本身不绑定特定云或编排器，可运行在 Kubernetes 之上，这也印证了 Haishi 所说的「这是一个设计模式，而非某款产品」——Radius 只是该模式的一个参考实现，团队完全可以基于既有工具链自建等价能力。

如何开始

如果这个模式切中了你的痛点，官方给出的下一步很直接：先在 Azure Architecture Center 阅读模式文档，然后到公开仓库获取全部代码、示例与文档。作者认为简单的实验体验非常顺畅——只需一台机器就能跑通全部内容。

对于拥有专有云平台或本地系统的团队，也可以编写并发布自己的 recipe，官方表示愿意将其展示出来，为你的平台带来用户。

核心结论：Adaptive Applications 不是某款产品，而是一种把平台依赖抽象为能力的架构思路。它让应用在云端、本地与边缘之间保持同一份代码，而这正是当下合规、主权与连续性诉求下越来越重要的能力。