为智能应用铺平道路：从本地/IaaS 迁移到云原生应用

生成式 AI 的蓬勃发展正在为智能应用铺平道路，这类应用利用 AI 能力提供无与伦比的功能和用户体验。正如我们在之前的文章《揭秘智能应用：在应用开发中利用人工智能》中所述，智能应用不仅仅是高级编码的产物。它们通过现代人工智能和机器学习 (ML) 的突破进行交互、学习和演进。

从传统应用到智能应用的范式转变要求我们改变软件和架构设计的技术挑战应对方式。它还要求我们在组织内部采纳新的思维和运营方式，这一点我们在《培育智能应用文化：组织准备和变革管理》中进行了更深入的探讨。

本文探讨了驱动智能应用的底层技术基础设施，为将传统的本地或基础设施即服务 (IaaS) 解决方案迁移到部署在云原生平台和服务的智能应用提供路线图。我们将了解传统应用与智能应用之间的差异、重构现有应用的选项，以及对现代应用构建方法至关重要的关键战略考量。

理解转变：传统应用与智能应用

智能应用不仅仅是传统应用的渐进式演进。它们涉及软件解决方案设计、开发和部署的根本性转变。清楚地理解每种范式的不同之处，对于理解此次迁移的影响至关重要。

功能和用户体验

传统应用通常基于规则且僵化，依赖于预编程的操作。例如，传统的打卡应用通常使用预定的数据源来显示结构化的、基于位置的预报。与此同时，智能应用利用 AI 进行数据驱动的决策和个性化。它不仅仅是显示天气预报，而是将 ML 与其他数据源（如用户的日历和健身数据）结合起来，以确定他们喜欢的户外活动，提供相关的着装建议，甚至根据用户最佳的天气偏好自动设计理想的假期和时间。

同样，传统应用倾向于提供“一刀切”的 UI，而智能应用则使用 AI 来创建量身定制的交互。例如，一款智能银行应用可能会使用生成式 AI 提供一个支持语音的 UI，让客户可以使用自然语言查询交易并获得个性化的财务建议。

基础结构

集成这些复杂功能的智能应用需要高度可扩展、灵活的基础设施，该基础设施针对 AI 功能进行了优化，并且能够处理大量实时数据。与部署在本地或基础设施即服务 (IaaS) 环境中的传统应用不同，智能应用需要云原生架构的灵活性和可扩展性。

基于本地或 IaaS 的电子商务应用可能在将数据连接到 AI 服务或扩展以满足海量实时数据和请求方面遇到困难。但是，一款以云原生方法和可扩展性为核心构建的智能应用可以更有效地处理可变的需求。它还按需维护其基础设施组件，无论是用于收集 AI/ML 使用的数据，还是用于面向用户的功能，如 AI 赋能的客户支持和个性化。

考虑一款基于 Azure 构建的智能应用，它可以使用自定义数据创建类似 ChatGPT 的体验。它可以将 Azure OpenAI 和 Azure Cognitive Search 连接到一个运行在 Azure 容器应用 或 Azure Kubernetes 服务 上的应用。

该架构可能看起来像下面的图，该图基于此 演示应用

虽然云非常适合处理与转向以 AI 为中心的基础设施相关的挑战——处理实时数据处理和存储、集成和管理 AI 服务、配置事件驱动和微服务架构、以及确保分布式环境的安全性——但将传统应用重构为智能应用需要仔细的规划和执行，以确保它能充分利用 AI 和云计算的能力。

云基础设施类型

在我们深入探讨支持智能应用的底层基础设施之前，让我们回顾一下四种不同类型的云服务：IaaS、PaaS、FaaS 和 SaaS。

基础设施即服务 (IaaS)，例如 Azure 虚拟机，提供基本的云服务，如服务器、存储、网络和操作系统。虽然 IaaS 为您提供了控制权和灵活性，但它也要求您管理基础设施软件、系统和配置。

平台即服务 (PaaS)，例如 Azure 应用服务，提供了一个完全托管的框架，用于构建和部署应用程序，而无需维护底层基础设施。

功能即服务 (FaaS)，或称无服务器计算，采用模块化的云组件方法。像 Azure Functions 这样的服务允许代码响应事件而运行，使其成为一种可扩展的按使用付费的基础设施。

软件即服务 (SaaS) 包括构建在云基础设施类型上的互联网应用程序。它们范围广泛，从 Microsoft 365 等生产力工具到 Azure DevOps 等开发人员辅助工具。

牢记这些概念，让我们深入探讨本地/IaaS 与云基础设施之间的主要区别，重点关注这些区别如何影响智能应用的开发。

本地/IaaS 与云原生基础设施

虽然本地和 IaaS 解决方案提供了对数据和流程的实质性控制，但这种细粒度的控制伴随着设置和维护成本，并且可能缺乏 AI 驱动的智能应用所需的扩展性。本地托管涉及购买和维护硬件，包括服务器和存储系统。IaaS 则涉及租赁虚拟硬件，然后聘请和培训 IT 人员来运营、维护和保护基础设施。

相反，在 Microsoft Azure 的云原生应用服务上构建的基础设施提供了几乎无限的扩展性，而且没有持续的硬件和维护成本。这一功能对于需要适应和扩展以适应不断变化的工作负载和数据流的智能应用来说是理想的。而且，由于这些云基础设施通常采用按使用付费的模式，因此传统上大量的初始成本变成了可预测的运营费用，从而降低了启动应用程序的成本和风险。

此外，云服务提供商会不断更新其产品，因此通过云构建复杂的 AI 工具和服务，例如 Azure AI 平台以及使用 Azure Kubernetes 服务 进行的编排能力，可以确保您能够获得最新的 AI 和最先进的 AI 模型和技术。

迁移到智能应用的战略考量

在制定迁移到智能应用的策略时，您必须考虑成本、人员技能开发和数据管理。

单体架构不太可能支持智能应用所需的规模和迭代便捷性，因此您可能需要进行代码更改以支持迁移。您选择的托管解决方案以及您的应用程序将处理的数据量会影响成本和性能，此外还会决定隐私和合规性要求。

管理或存储 TB 甚至 PB 数据的应用程序将需要存储优化型虚拟机或托管数据库服务托管。同时，处理视频内容或执行资源密集型计算的应用程序应优先考虑高性能计算。最大化存储和性能可能会变得异常昂贵。

最后，从传统应用程序向智能应用的转变可能会遇到兼容性冲突，具体取决于数据库类型或现有系统底层编程语言。正如您可能想象的那样，一个在本地运行并使用共享本地数据库的传统应用程序可能需要进行大量重构才能支持云原生架构。您需要制定数据迁移、潜在停机时间和培训计划。

接下来，让我们看看这个转换过程。

将单体应用重构为微服务

从 单体应用程序 转向微服务是迁移到智能应用的关键，您可以利用这一转变机会，将您的遗留软件转化为利用微服务赋能的 AI 解决方案的灵活性和强大功能的智能应用。

传统上，一个单体应用程序（以在线市场为例）可能会在本地服务器或云服务器中处理所有活动——从提供网页到处理付款。然而，这种方法难以扩展，并且容易受到网络故障或网络攻击的影响。

将这些应用程序分解为具有特定职责的多个服务，例如身份验证或通知，可以克服这些限制。这些服务通常部署为微服务，在 Azure Kubernetes 服务 等容器环境中，或使用自动化流程在 Azure Functions 等无服务器平台上部署。这种方法提供了可扩展性、健壮性和改进的性能，因为每个微服务都可以独立运行并使用自己的数据库。

在应用架构中转向更小、独立的微服务，使我们能够获得 AI 驱动的智能应用的优势，例如，使用微服务来处理 AI 任务，如处理自然语言输入、分析行为数据或个性化内容。

事件驱动架构：何时使用它们

事件驱动架构 (EDA) 可以显著提高智能应用的性能和成本效益。EDA 通常与微服务一起实现，它们可以实时响应事件或状态变化，从用户交互到实时分析。

考虑一个用于个性化客户参与的智能应用。EDA 可以立即响应用户数据变化，触发适当的微服务，而不是设计应用程序持续检查用户数据变化。例如，如果用户修改了他们的偏好，一个事件可以触发一个由 AI 驱动的推荐微服务立即更新其建议。这种由 Azure Event Grid 等服务实现的实时响应能力，可以改善用户体验，并使智能应用更具适应性和主动性。

然而，值得注意的是，虽然 EDA 提供了显著的好处，但它们也可能引入独特的复杂性，例如维护事件一致性以及跨多个微服务的事件链中的调试问题。因此，重要的是要评估您的应用程序的需求，以便您了解它可以在哪里受益于 EDA。

结论

迁移到智能应用代表着在战略、架构和基础设施方面的转变。通过为基于云的基础设施进行设计和重构，您的应用程序将获得可扩展性、成本效益、强大的数据管理、对复杂 AI 工具的访问、增强的安全性以及降低的运营开销。

但是，这次转变远远超出了其技术组件。组织及其内部人员同样需要关注。您可以在《培育智能应用文化：组织准备和变革管理》中更深入地探讨这些方面。

生成式 AI 的力量已经到来，为向基于云的智能应用的迁移做准备将确保您的应用程序保持高性能和可扩展性，最重要的是，您的企业将为最新的应用创新时代做好准备。