无服务器应用程序的迁移模式

无服务器框架因其成本效益、可扩展性和快速开发能力而越来越受欢迎，越来越多的公司认为计算的未来是无服务器的。

无服务器架构代表一种无需直接管理基础设施即可创建和运行应用程序和服务的方法。尽管无服务器应用程序最终在服务器上执行，但监督这些服务器的责任已转移到特定服务提供商，例如使用“lambda 函数”的 Amazon Web Services (AWS) 或通过“云函数”的 Google Cloud Platform。

有效的迁移对于释放无服务器架构的优势至关重要。在无服务器环境中迁移现有应用程序或开发新应用程序具有可扩展性、成本效益和简化管理等优势。但是，如果没有精心规划和执行的迁移策略，组织可能难以实现这些优势。有效的迁移可确保平稳过渡，最大限度地减少中断，并最大限度地发挥无服务器计算的潜力，以实现灵活性、节省成本和提高性能。

本文的主要目的是介绍与无服务器应用程序最相关的迁移策略。了解所有迁移策略至关重要，在决定哪种策略最适合迁移之前，需要考虑几个因素并回答几个问题。

请注意，本文中介绍的迁移模式是常见模式，应被视为任何迁移的良好起点，因为它们涵盖了许多无服务器应用程序的基础。

无服务器基础知识

为了给文章提供更多背景信息，让我们深入探讨无服务器应用程序的主要优势以及一些常见用例：

“无服务器”到底是什么意思？

• 无需服务器管理

• 灵活扩展

• 自动化高可用性

• 无闲置产能

无服务器计算的五大用例

• 媒体处理

• 事件驱动的应用程序

• 构建 API

• 聊天机器人

• Webhook

迁移挑战 www.cqzlsb.com

虽然无服务器计算具有许多好处，但它也有一些挑战，在取得成功之前必须承认或解决这些挑战。本文的目的是简要介绍这些挑战。重要的是要理解，这些考虑不仅与架构问题有关，安全性和合规性也是重要主题。

• 冷启动延迟：无服务器函数在首次调用时会出现延迟，称为“冷启动延迟”。

• 供应商锁定：每个无服务器提供商都提供其独特的服务和工具，从特定提供商转型可能会很困难且成本高昂。

• 遗留系统集成：从传统系统迁移到无服务器可能需要与遗留系统集成。这会增加自定义层，从而增加复杂性和维护难度。

• 资源限制：不同的无服务器平台会施加资源限制，例如执行时间和内存。在某些情况下，限制适用于不同的区域。大规模项目可能会在性能方面受到影响。

• 安全问题：确保无服务器环境中的数据安全是一项巨大的挑战。开发人员必须仔细配置安全设置和访问控制，以防止未经授权的访问和数据泄露。

• 成本管理：功能配置错误或过度使用可能会导致意外开支。

• 合规性和数据驻留：在受监管的行业中，当数据分布在无服务器功能和服务中时可能会很复杂。

• 监控和调试：识别问题和性能瓶颈可能需要专门的工具。

迁移过程

初步方法

在完成迁移并确定策略之前，应该先解决 3 个初步问题：

• 计算基础设施是如何实现的？

• 如何进行应用程序开发？

• 如何进行应用程序部署？

需要完全或部分回答这 3 个范例才能决定策略。至少应考虑并评估所有 3 点。

基础设施抽象

了解主要的基础设施抽象和架构现代化使我们能够对不同的策略进行分组，并可以回答初始方法中引入的部分问题。对于本项目的范围，考虑了 3 个抽象：

基于服务器

定义：

也称为以服务器为中心的基础设施，是一种 IT 架构，其中中央服务器或多个服务器在为客户或最终用户提供服务、管理资源和存储数据方面发挥着关键作用。

注意事项：

• 单片

• 单一 Artifact 发布

• 通常有一些手动部署

• 单一技术堆栈

• 将应用程序迁移到云端的影响降到最低

集装箱化

定义：

容器是轻量级、可移植且隔离的环境，它封装了应用程序及其运行所需的所有库、运行时组件和配置设置。这种方法在效率、可扩展性和易管理性方面具有多种优势

注意事项：

• 平台独立性

• 环境平等

• 简单的部署

• 可移植性

• 容器镜像和运行时的安全策略

API 和微服务

定义：

API 和微服务是两个相互关联的概念，在现代软件开发和架构中发挥着至关重要的作用。它们通常一起使用来构建可扩展、灵活且可维护的应用程序。API 是一组规则和协议，允许一个软件应用程序或组件与另一个软件应用程序或组件进行交互，而微服务将应用程序构建为这些组件，成为一组小型独立服务的集合。

注意事项：

• 事件驱动的微服务

• 采用多语言技术栈的 CI/CD

• 频繁发布。

• 应用程序需要重写。

迁移模式

蛙跳

顾名思义，通过跳跃模式，您可以绕过中间步骤，直接从本地遗留架构转到无服务器云架构。

示例场景：图像处理

传统设置：

• 您有一个在专用服务器上处理图像的 Web 应用程序。

• 服务器维护、扩展和成本管理都是挑战。

无服务器迁移：

• 将图像处理代码重写为无服务器函数（例如 AWS Lambda）。

• 配置 AWS API Gateway 以向 S3 公开触发“UploadImage”Lambda 函数的 HTTP 端点。

• 每当图像上传到 S3 存储桶时都会触发此功能。

提升和转变

在这种模型中，现有的应用程序最初保持完整。

开发人员在日志处理或计划任务等低风险内部场景中尝试使用无服务器工具（例如云函数）。逐渐地，其他无服务器组件被采用来执行数据转换和流程并行化等任务。

在采用过程的某个阶段，建议从战略角度考虑更多无服务器和微服务基础设施如何满足不同的业务目标。

然后，创建一个生产工作负载作为试点，并借助之前采用无服务器的小流程中的初步成功和经验教训，将更多的应用程序逐步迁移到无服务器。

示例场景：内容管理系统 (CMS) 迁移

传统设置：

• 您有一个在虚拟服务器或本地基础架构上运行的传统 CMS。

• CMS 提供内容、管理用户帐户并处理用户生成的内容。

直接迁移至无服务器：

• 确定一个无服务器平台，例如 AWS Amplify 或 Firebase 等完全托管的云服务。

• 使用此平台创建无服务器应用程序。

• 在此无服务器环境中复制现有 CMS 的功能。

• 将您的内容、用户数据和用户生成的内容迁移到新的无服务器应用程序。

• 调整 DNS 设置或路由以将流量引导至新的无服务器应用程序。

• 执行测试以确保新的无服务器 CMS 正常运行并按预期提供内容。

绞杀者

利用绞杀模式，组织可以通过创建 API 和构建事件驱动组件来逐步、系统地分解单片应用程序，从而逐步替换遗留应用程序的组件。

与新组件相比，不同的 API 端点可以指向旧组件，而安全的部署选项（例如金丝雀部署）可让您以极小的风险指向旧版本。

新的功能分支可以首先实现无服务器，并且旧式组件可以在被替换时退役。

示例场景：传统电子商务

传统设置：

• 您有一个在单片服务器上运行的旧式电子商务应用程序。

• 维护和更新旧的代码库具有挑战性。

Strangler 迁移到无服务器：

• 首先在单片应用程序中确定一个特定的功能，例如产品图像调整大小。

• 将此函数重写为无服务器微服务（例如，AWS Lambda）。

• 通过 API 网关端点公开此微服务。

• 逐渐将新的产品图像调整大小请求路由到无服务器微服务，同时电子商务应用程序的其余部分仍保留在单片服务器上。

• 随着时间的推移，以类似的方式重构和迁移其他功能。

• 最终，整个应用程序被分解为无服务器的微服务。

• 优点：无需完全重写系统即可实现渐进式现代化、降低风险并提高灵活性。

您需要回答的最重要的迁移问题：

尽管移动复杂应用程序的最常见迁移模式是绞杀模式，即使用无服务器重构和重写应用程序的各个部分，但在许多情况下，移动到无服务器与分解整体同时进行，以实现事件驱动的微服务。

就这篇文章的范围而言，给出一些需要回答的问题的例子是很有趣的：

• 该应用程序的作用是什么以及它的组件是如何组织的？

• 应用程序如何扩展以及哪些组件可满足您所需的容量？

• 您有基于计划的任务吗？

• 您有工人在听队列吗？

• 在不影响当前实现的情况下，您可以在哪里重构或增强功能？

• 运行工作负载的基础设施成本/预算是多少？

• 一旦应用程序投入生产，您的团队需要花费多少时间/成本来维护它。