你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

将 AWS Lambda 工作负载迁移到 Azure Functions

将使用 Amazon Web Services (AWS) Lambda 的无服务器工作负荷迁移到 Azure Functions 需要仔细规划和实施。 本文提供帮助你的基本指南:

  • 对现有工作负荷进行探索性评估过程。
  • 了解如何执行关键迁移活动,例如预迁移规划和工作负荷评估。
  • 评估和优化已迁移的工作负荷。

范围

本文介绍如何将 AWS Lambda 实例迁移到 Azure Functions。

本文未解决以下问题:

  • 迁移到自己的容器托管解决方案,例如通过 Azure 容器应用。
  • 在 Azure 中托管 AWS Lambda 容器。
  • 组织的基本 Azure 采用方法,例如 Azure 登陆区 或云采用框架迁移方法中涉及的其他主题。

比较功能

本文将 AWS Lambda 功能映射到 Azure Functions 等效项,以帮助确保兼容性。

重要

可以选择在迁移计划中包括优化,但Microsoft建议执行双重过程。 首先迁移“类似”功能,然后评估 Azure 上的优化机会。

优化工作应该是连续的,并通过工作负荷团队的变更控制流程运行。 在迁移过程中添加额外功能会带来风险,并使过程不必要地延长。

工作负荷视角

本文重点介绍如何将 AWS Lambda 工作负载迁移到 Azure Functions,以及无服务器工作负荷的常见依赖项。 此过程可能涉及多个服务,因为工作负荷包含许多资源和用于管理这些资源的流程。 若要制定全面的策略,必须将本文中提供的建议与包含工作负荷中的其他组件和流程的大型计划相结合。

对现有工作负载执行发现过程

第一步是执行详细的发现过程来评估现有的 AWS Lambda 工作负载。 目标是了解工作负荷所依赖的 AWS 功能和服务。 使用服务专用的 SDK、API、CloudTrail 和 AWS CLI 等 AWS 工具来编译 AWS Lambda 函数的综合列表,以便评估 AWS 上的工作负载。 你应该了解 AWS Lambda 清单的以下关键方面:

  • 用例
  • 配置
  • 安全性和网络设置
  • 工具、监视、日志记录和可观测性机制
  • 依赖关系
  • 可靠性目标和当前可靠性状态
  • 拥有成本
  • 性能目标和当前性能

执行预迁移计划

在开始迁移工作负荷之前,必须将 AWS Lambda 功能映射到 Azure Functions,以确保兼容性并制定迁移计划。 然后,可以为概念证明选择关键工作负载。

还需要将 Lambda 依赖的 AWS 服务映射到 Azure 中的等效依赖项。

将 AWS Lambda 功能映射到 Azure Functions

下表将 AWS Lambda 概念、资源和属性与 Azure Functions 上的相应等效项(特别是 Flex Consumption 托管计划)进行比较。

支持的语言

程序设计语言 AWS Lambda 支持的版本 Azure Functions 支持的版本
Node.js 20、22 20、22
Python语言 3.9, 3.10, 3.11, 3.12, 3.13 3.9, 3.10, 3.11
爪哇岛 8, 11, 17, 21 8, 11, 17, 21
PowerShell 不支持 7.4
.NET .NET 8 .NET 8、.NET 9、.NET Framework 4.8.1
红宝石 3.2, 3.3 自定义处理程序
走吧 仅限 OS 的运行时 自定义处理程序
仅限 OS 的运行时 自定义处理程序

编程模型

功能 / 特点 AWS Lambda Azure Functions(Azure 功能服务)
触发器 通过事件源与其他 AWS 服务集成。 提供将 Lambda 函数与事件源链接的自动和编程方式。 基于特定事件触发函数,例如数据库中的更新或队列中的新消息。 例如,Azure Cosmos DB 触发器允许函数自动响应 Azure Cosmos DB 容器中的插入和更新。 此操作使能够对数据更改进行实时处理。

Functions 还与 Azure 事件网格集成,因此它可以处理来自 Azure 服务(例如 Azure 存储和 Azure 媒体服务)和外部事件源的事件。 事件网格充当集中式可扩展事件路由服务,可补充 Functions 触发器,并实现高可伸缩性和广泛的事件源覆盖范围。
绑定 没有绑定。 使用 Lambda 函数中的 AWS SDK 手动管理与其他 AWS 服务的交互。 绑定配置为输入或输出,用于实现与服务的声明性连接,从而最大程度地减少对显式 SDK 代码的需求。 例如,可以将绑定配置为从 Blob 存储读取、写入 Azure Cosmos DB 或通过 SendGrid 发送电子邮件,而无需手动管理集成。

事件触发器和绑定

AWS Lambda 触发器或服务 Azure Functions 触发器 DESCRIPTION
API 网关:HTTP 请求 HTTP 触发器 这些触发器允许你直接处理 HTTP 请求。
简单队列服务 (SQS) Azure 队列存储触发器Azure 服务总线触发器 这些触发器可以处理队列中的消息。
简单通知服务 (SNS) 事件网格触发器服务总线触发器 这些触发器启用通知处理。
Kinesis (数据流) 事件中心触发器 这些触发器消费数据流。
DynamoDB (表格变更) Azure Cosmos DB 更改源触发器 这些触发器侦听表中的更改。
CloudWatch Events 或 EventBridge Scheduler 计时器触发器 这些触发器处理计划或基于时间的函数。
S3 (对象事件) Blob 存储触发器 这些触发器对 Blob 存储中的事件做出反应。
Amazon Relational Database Service (RDS) Azure SQL 触发器 这些触发器对数据库更改做出反应。
Apache Kafka 的托管流式处理 (MSK) Apache Kafka 触发器 这些触发器对 Kafka 主题消息做出反应。
Amazon ElastiCache(亚马逊的内存缓存服务) Azure Redis 触发器 这些触发器对 Redis 中的消息做出反应。
Amazon MQ RabbitMQ 触发器 这些触发器对 RabbitMQ 中的消息做出反应。

权限

AWS Lambda Azure Functions(Azure 功能服务)
Lambda 执行角色授予 Lambda 函数与其他 AWS 服务交互的权限。 每个 Lambda 函数都有一个关联的标识和访问管理(IAM)角色,该角色在运行时确定其权限。 托管标识为函数应用提供一个标识,该标识允许它与其他 Azure 服务进行身份验证,而无需在代码中存储凭据。 基于角色的访问控制将适当的角色分配给Microsoft Entra ID 中的托管标识,以授予对所需资源的访问权限。
基于资源的策略语句:

- AWSLambda_FullAccess提供对所有 Lambda操作的完全访问权限,包括创建、更新和删除函数。

- AWSLambda_ReadOnlyAccess提供查看 Lambda 函数及其配置的只读访问权限。

- 自定义 IAM 策略。
基于资源的内置角色:

- 所有者角色提供完全访问权限,包括访问权限管理。

- 参与者角色可以创建和删除函数应用、配置设置和部署代码。 它无法管理访问权限。

- 监视读取者角色可以授予对监视数据和设置的只读访问权限。 它还可以分配自定义角色。

函数 URL

AWS Lambda Azure Functions(Azure 功能服务)
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (原始、全局默认主机名)

- <appname>-<randomhash>.<Region>.azurewebsites.net (新的唯一默认主机名)

网络

AWS Lambda Azure Functions(Azure 功能服务)
所有 Lambda 函数都在默认系统管理的虚拟私有云 (VPC) 内安全运行。 还可以将 Lambda 函数配置为访问自定义 VPC 中的资源。 函数应用可以受到网络保护,并且可以访问网络中的其他服务。 可通过服务终结点或专用终结点,将入站网络访问权限严格限定于防火墙 IP 列表及指定虚拟网络。 出站网络访问是通过虚拟网络集成功能启用的。 函数应用可以将其所有流量限制为虚拟网络的子网,还可以访问该虚拟网络中的其他服务。

可观测性和监视性

AWS Lambda Azure Functions(Azure 功能服务)
Amazon CloudWatch 通过收集和跟踪指标、聚合和分析日志、设置警报、创建自定义仪表板以及实现对资源性能和指标更改的自动响应来帮助监视和可观测性。 Azure Monitor 为 Azure Functions 提供全面的监视和可观测性,特别是通过其 Application Insights 功能。

Application Insights 收集遥测数据,例如请求速率、响应时间和失败率。 它可视化应用程序组件关系、监视实时性能、记录详细诊断并允许自定义指标跟踪。 这些功能有助于维护 Azure Functions 的性能、可用性和可靠性,同时启用自定义仪表板、警报和自动响应。
AWS Lambda 从函数调用生成遥测数据,并且可以使用 OpenTelemetry 语义导出此数据。 可以将 Lambda 函数配置为将此遥测数据发送到任何符合 OpenTelemetry 的终结点。 此操作允许关联跟踪和日志、标准化一致的遥测数据,以及与其他支持 OpenTelemetry 的可观测性工具进行集成。 将 Functions 应用配置为以 OpenTelemetry 格式导出日志和跟踪数据。 可以使用 OpenTelemetry 将遥测数据导出到任何合规的终结点。 OpenTelemetry 提供跟踪和日志关联、基于标准的一致遥测数据以及与其他提供程序的集成等优势。 可以在主机配置和代码项目中的函数应用级别启用 OpenTelemetry,以优化函数代码中的数据导出。 有关详细信息,请参阅将 OpenTelemetry 与 Azure Functions 配合使用

缩放和并发

AWS Lambda Azure Functions(Azure 功能服务)
AWS 使用按需缩放模型。 根据需求自动缩放函数运算规模。 并发或实例处理的请求数始终为 1。 实例根据传入事件数以及为每个实例配置的并发数动态添加和删除。 可以将 并发设置 配置为所需的值。
并发始终为 1。 并发是可配置的(>1)。
支持缩放到 0。 支持缩放到 0。

冷启动保护

AWS Lambda Azure Functions(Azure 功能服务)
预配的并发可减少延迟,并通过预先初始化请求的函数实例数来确保可预测的函数性能。 预配的并发适合对延迟敏感的应用程序,并且定价独立于标准并发。 函数应用允许为每个实例配置并发,从而驱动其规模。 多个作业可以在应用的同一实例中并行运行,实例中的后续作业不会产生初始冷启动。 函数应用也有始终就绪的实例。 客户可以指定多个预热实例,以消除冷启动延迟并确保一致的性能。 函数应用还可以按需扩展到更多实例,同时维护始终就绪的实例。
保留并发指定函数可以拥有的最大并发实例数。 此限制可确保专门为该函数预留帐户的并发配额的一部分。 即使设置了预留并发,AWS Lambda 也会动态横向扩展以处理传入请求,前提是请求不超过指定的预留并发限制。 AWS Lambda 中保留并发的下限为 1。 AWS Lambda 中保留并发的上限取决于帐户的区域并发配额。 默认情况下,此限制为每个区域的 1,000 次并发操作。 Azure Functions 没有与保留并发等效的功能。 若要实现类似的功能,请将特定函数隔离到单独的函数应用中,并为每个应用设置最大横向扩展限制。 Azure Functions 在设置的横向扩展限制内动态横向扩展或添加更多实例,并缩减或删除实例。 默认情况下,在 Flex Consumption 计划中运行的应用从可配置的 100 个整体实例的限制开始。 最小最大实例计数值为 40,支持的最大实例计数值为 1,000。 区域订阅内存配额 还可以限制可横向扩展的函数应用数量,但可以通过调用支持来增加此配额。

定价

AWS Lambda Azure Functions(Azure 功能服务)
- 按使用情况付费,包括每个实例的调用总次数和每秒千兆字节(GB/s),并行度固定为 1。

- 1 ms 增量

- 400,000 Gbps 免费层
- 为每个实例的总调用计数和每个实例的 GB/秒(具有可配置的并发调用)的每次使用付费

- 100 ms 增量

- 100,000 Gbps 免费层

- 基于消耗的成本

源代码存储

AWS Lambda Azure Functions(Azure 功能服务)
AWS Lambda 在其自己的托管存储系统中管理函数代码的存储。 无需提供更多存储。 Functions 需要客户提供的 Blob 存储容器来维护包含应用代码的部署包。 可以将设置配置为使用相同或不同的存储帐户进行部署,并管理用于访问容器的身份验证方法。

本地开发

AWS Lambda 功能 Azure Functions 功能
- SAM CLI

- LocalStack
- Azure Functions Core Tools

- Visual Studio Code

- Visual Studio

- GitHub Codespaces

- VSCode.dev

- Maven

- 在本地编写代码并测试 Azure Functions

部署

功能 / 特点 AWS Lambda Azure Functions(Azure 功能服务)
部署包 - ZIP 文件

- 容器映像
ZIP 文件(对于容器映像部署,请使用专用或高级 SKU。
ZIP 文件大小(控制台) 最大 50 MB ZIP 部署的最大容量为 500 MB
ZIP 文件大小 (CLI/SDK) 最大 ZIP 部署大小为 250 MB,最大解压后大小为 500 MB。 ZIP 部署的最大容量为 500 MB
容器映像大小 最大 10 GB 通过 Azure 的灵活存储实现的容器支持
大型文物处理 使用容器映像来进行较大规模的部署。 附加 Blob 存储或 Azure 文件共享以从应用访问大型文件。
将常见依赖项打包到函数 图层 部署 .zip,从存储中按需部署或使用容器部署(仅限 ACA、专用和 EP SKU)
蓝绿部署或函数版本化 使用函数限定符通过版本号或别名引用函数的特定状态。 限定符号可以实现版本管理和渐进式部署策略。 使用持续集成和持续交付系统进行蓝绿部署。

超时和内存限制

功能 / 特点 AWS Lambda 限制 Azure Functions 限制
执行超时值 900 秒 (15 分钟) 默认超时为 30 分钟。 最大等待时间不受限制。 但是,在缩减期间为函数执行提供的宽限期为 60 分钟,而在平台更新期间为 10 分钟。 有关详细信息,请参阅 函数应用超时持续时间
可配置内存 128 MB 到 10,240 MB,增量为 64 MB 函数支持 2 GB 和 4 GB 实例大小。 给定订阅中的每个区域对于所有应用实例的内存限制为 512,000 MB,可以通过调用支持来增加这些限制。 区域中所有函数应用的所有实例的总内存使用量必须保持在此配额范围内。

尽管 2 GB 和 4 GB 是实例大小选项,但每个实例的并发可能高于 1。 因此,单个实例可以处理多个并发执行,具体取决于配置。 适当配置并发有助于优化资源使用情况和管理性能。 通过均衡内存分配和并发设置,可以有效地管理分配给函数应用的资源,并确保高效性能和成本控制。 有关详细信息,请参阅区域订阅内存配额

机密管理

AWS Lambda Azure Functions(Azure 功能服务)
AWS 机密管理器允许存储、管理和检索机密,例如数据库凭据、API 密钥和其他敏感信息。 Lambda 函数可以使用 AWS SDK 检索机密。 建议使用无机密方法(如托管标识)启用对 Azure 资源的安全访问,而无需硬编码凭据。 当需要机密(例如合作伙伴或旧系统)时,Azure Key Vault 提供了一个安全的解决方案,用于存储和管理机密、密钥和证书。
AWS Systems Manager 参数存储是存储配置数据和机密的服务。 可以使用 AWS KMS 对参数进行加密,并使用 AWS SDK 检索 Lambda 函数。
Lambda 函数可以将配置设置存储在环境变量中。 可以使用 KMS 密钥对敏感数据进行加密,以便进行安全访问。
Azure Functions 使用应用程序设置来存储配置数据。 这些设置直接映射到环境变量,以便在函数中易于使用。 这些设置可以加密并安全地存储在 Azure 应用服务配置中。
对于更高级的方案,Azure 应用配置提供了用于管理多个配置的可靠功能。 它支持功能标记并支持跨服务动态更新。

状态管理

AWS Lambda Azure Functions(Azure 功能服务)
AWS Lambda 使用 Amazon S3 等服务来处理简单的状态管理,DynamoDB 等服务用于快速且可缩放的 NoSQL 状态存储,以及用于消息队列处理的 SQS。 这些服务可确保跨 Lambda 函数执行的数据持久性和一致性。 Azure Functions 使用 AzureWebJobsStorage 来通过 Azure 存储服务(如 Blob 存储、队列存储和表存储)启用绑定和触发器,以管理状态。 它允许函数轻松读取和写入状态。 对于更复杂的状态管理,Durable Functions 使用 Azure 存储提供高级工作流业务流程和状态持久性功能。

处于监控状态的业务流程

AWS Lambda Azure Functions(Azure 功能服务)
没有本机状态业务流程。 将 AWS 步骤函数用于工作流。 Durable Functions 通过提供持久化工作流编排和有状态实体来帮助管理复杂状态。 它支持长时间运行的操作、自动检查点机制和可靠的状态持久性。 这些功能使构建复杂的工作流可确保有状态应用程序的容错和可伸缩性。

其他差异和注意事项

功能 / 特点 AWS Lambda Azure Functions(Azure 功能服务)
GROUPING 函数 每个 AWS Lambda 函数都是独立的实体。 函数应用充当多个函数的容器。 它为包含的函数提供共享执行上下文和配置。 将多个函数视为单个实体可以简化部署和管理。 Azure Functions 还使用每个函数的扩展策略,其中每个函数都独立扩展,HTTP、Blob 存储和 Durable Functions 触发器除外。 这些触发的函数在其自己的组中横向缩减。
自定义域 通过 API 网关启用 可以直接在函数应用或 Azure API 管理上 配置自定义域
自定义容器支持 支持通过 Lambda 容器映像自定义容器 Azure Functions 支持 在容器应用环境中运行的自定义容器

创建迁移计划

  1. 为概念证明选择关键工作负载。

    首先,从总清单中选择一到两个中等大小的非关键工作负荷。 这些工作负载是概念证明迁移的基础。 可以测试该过程并确定潜在的挑战,而不会带来对操作造成重大中断的风险。

  2. 以迭代方式测试并收集反馈。

    在扩展到更大的工作负荷之前,使用概念证明来收集反馈、识别差距并微调流程。 这种迭代方法可确保在迁移到全面迁移时解决潜在挑战并优化流程。

生成迁移资产

此步骤是过渡性开发阶段。 在此阶段,你将生成源代码、基础结构即代码(IaC)模板和部署管道来表示 Azure 中的工作负荷。 必须先根据兼容性和最佳做法调整函数代码,然后才能执行迁移。

将函数代码、配置文件和基础结构调整为代码文件

更新 Azure Functions 运行时要求的代码:

以下代码片段是常见 SDK 代码的示例。 AWS Lambda 代码映射到 Azure Functions 中的相应触发器、绑定或 SDK 代码片段。

从 Amazon S3 与 Azure Blob 存储读取数据

AWS Lambda 代码 (SDK)

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

exports.handler = async (event) => {
const params = {
Bucket: 'my-bucket',
Key: 'my-object.txt',
};
const data = await
s3.getObject(params).promise();
console.log('File content:',
data.Body.toString());
};       

Azure Functions 代码(触发器)

import { app } from '@azure/functions';

app.storageblob('blobTrigger', { 
path: 'my-container/{blobName}',
connection: 'AzureWebJobsStorage',
}, async (context, myBlob) => { 
context.log(`Blob content:
${myBlob.toString()}`);
});

写入 Amazon Simple Queue Service (SQS) 与 Azure 队列存储

AWS Lambda 代码 (SDK)

const AWS = require('aws-sdk');
const sqs = new AWS.SQS(); 

exports.handler = async (event) => {
const params = {
QueueUrl:
'https://sqs.amazonaws.com/123456789012/MyQueue',
MessageBody: 'Hello, world!',
};
await
sqs.sendMessage(params).promise();
};

Azure Functions 代码(触发器)

import { app } from '@azure/functions';

app.queue('queueTrigger', { 
queueName: 'myqueue-items',
connection: 'AzureWebJobsStorage',
}, async (context, queueMessage) => {
context.log(`Queue message: 
${queueMessage}`);
}); 

将数据写入 DynamoDB 与 Azure Cosmos DB 的比较

AWS Lambda 代码 (SDK)

const AWS = require('aws-sdk'); 
const dynamoDb = new AWS.DynamoDB.DocumentClient();   

exports.handler = async (event) => { 
const params = { 
TableName: 'my-table', 
Key: { id: '123' }, 
}; 
const data = await dynamoDb.get(params).promise(); 
console.log('DynamoDB record:', data.Item); 
}; 

Azure Functions 代码(触发器)

import { app } from '@azure/functions';  

app.cosmosDB('cosmosTrigger', { 
connectionStringSetting: 'CosmosDBConnection', 
databaseName: 'my-database', 
containerName: 'my-container', 
leaseContainerName: 'leases', 
}, async (context, documents) => { 
documents.forEach(doc => { 
context.log(`Cosmos DB document: ${JSON.stringify(doc)}`); 
}); 
}); 

Amazon CloudWatch 事件与 Azure 计时器触发器

AWS Lambda 代码 (SDK)

exports.handler = async (event) => {
console.log('Scheduled event:', event); 
}; 

Azure Functions 代码(触发器)

import { app } from '@azure/functions'; 

app.timer('timerTrigger', { schedule: '0 */5 * * * *', // Runs every 5 minutes }, async (context, myTimer) => { if (myTimer.isPastDue) { context.log('Timer is running late!'); } context.log(Timer function executed at: ${new Date().toISOString()}); });

Amazon Simple Notification Service (SNS) 与 Azure 事件网格触发器

AWS Lambda 代码 (SDK)

const AWS = require('aws-sdk'); 
const sns = new AWS.SNS();   

exports.handler = async (event) => { 
const params = { 
Message: 'Hello, Event Grid!', 
TopicArn: 'arn:aws:sns:us-east-1:123456789012:MyTopic', 
}; 
await sns.publish(params).promise(); 
}; 

Azure Functions 代码(触发器)

import { app } from '@azure/functions'; 

app.eventGrid('eventGridTrigger', {}, 
async (context, eventGridEvent) => { 

context.log(`Event Grid event: 
${JSON.stringify(eventGridEvent)}`); 

}); 

Amazon Kinesis 与 Azure 事件中心触发器

AWS Lambda 代码 (SDK)

const AWS = require('aws-sdk'); 
const kinesis = new AWS.Kinesis();   

exports.handler = async (event) => { 
const records = 
event.Records.map(record => 
Buffer.from(record.kinesis.data, 
'base64').toString()); 
console.log('Kinesis records:', records); 
}; 

Azure Functions 代码(触发器)

import { app } from '@azure/functions'; 
app.eventHub('eventHubTrigger', {  
connection: 'EventHubConnection',  
eventHubName: 'my-event-hub',  
}, async (context, eventHubMessages) => 
{  
eventHubMessages.forEach(message => 
{  
context.log(`Event Hub message: 
${message}`);  
});  
});

请参阅以下 GitHub 存储库来比较 AWS Lambda 代码和 Azure Functions 代码:

调整配置设置

确保函数的超时和 内存 设置与 Azure Functions 兼容。 有关可配置设置的详细信息,请参阅 Azure Functionshost.json 参考

遵循有关权限、访问、网络和部署配置的建议最佳做法。

配置权限

在为函数应用设置权限时,请遵循最佳做法。 有关详细信息,请参阅 使用托管身份验证配置存储帐户和函数应用

main.bicep

// User-assigned managed identity that the function app uses to reach Storage and Service Bus
module processorUserAssignedIdentity './core/identity/userAssignedIdentity.bicep' = {
  name: 'processorUserAssignedIdentity'
  scope: rg
  params: {
    location: location
    tags: tags
    identityName: !empty(processorUserAssignedIdentityName) ? processorUserAssignedIdentityName : '${abbrs.managedIdentityUserAssignedIdentities}processor-${resourceToken}'
  }
}

有关详细信息,请参阅 rbac.bicep

配置网络访问

Azure Functions 支持 虚拟网络集成,使函数应用能够访问虚拟网络中的资源。 集成后,应用通过虚拟网络路由出站流量。 然后,应用可以使用仅允许来自特定子网的流量的规则访问专用终结点或资源。 如果目标是虚拟网络外部的 IP 地址,则源 IP 地址是应用属性中列出的地址之一,除非配置 NAT 网关。

为函数应用启用 虚拟网络集成 时,请遵循 TSG 中的最佳做法,实现 Web 应用和函数应用的虚拟网络集成

main.bicep

// Virtual network and private endpoint
module serviceVirtualNetwork 'app/vnet.bicep' = {
  name: 'serviceVirtualNetwork'
  scope: rg
  params: {
    location: location
    tags: tags
    vNetName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
  }
}  

module servicePrivateEndpoint 'app/storage-PrivateEndpoint.bicep' = {
  name: 'servicePrivateEndpoint'
  scope: rg
  params: {
    location: location
    tags: tags
    virtualNetworkName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
    subnetName: serviceVirtualNetwork.outputs.peSubnetName
    resourceName: storage.outputs.name
  }
}

有关详细信息,请参阅 VNet.bicepstorage-PrivateEndpoint.bicep

配置部署设置

部署遵循单个路径。 生成项目代码并将其压缩到应用程序包后,将其部署到 Blob 存储容器。 启动后,应用会获取包,并从中运行函数代码。 默认情况下,存储内部主机元数据的同一存储帐户(例如 AzureWebJobsStorage)也用作部署容器。 但是,可以使用备用存储帐户,也可以通过配置应用的部署设置来选择首选的身份验证方法。 有关详细信息,请参阅 部署技术详细信息配置部署设置

生成 IaC 文件

  • 使用 Bicep、Azure 资源管理器模板或 Terraform 等工具创建 IaC 文件来部署 Azure 资源。

  • 在 IaC 文件中定义 Azure Functions、存储帐户和网络组件等资源。

  • 请使用此 IaC 示例存储库获取有关 Azure Functions 建议和最佳实践的示例。

使用重构工具

使用 VS Code 中的 GitHub Copilot 等工具来帮助进行代码重构、手动重构特定更改或其他迁移帮助。

注释

在 VS Code 中的 GitHub Copilot 中使用 代理模式

以下文章提供了特定的示例和详细的步骤,以方便迁移过程:

为第 0 天迁移开发分步过程

为你的迁移制定故障转移和故障回复策略,并在预生产环境中对其进行全面测试。 建议在最终从 AWS Lambda 过渡到 Azure Functions 之前执行端到端测试。

  • 验证功能

    • 在本地编写代码并测试 Azure Functions

    • 彻底测试每个函数,以确保其按预期工作。 这些测试应包括输入/输出、事件触发器和绑定验证。

    • 使用 VS Code 上的 curl 或 REST 客户端 扩展等工具发送 HTTP 触发的函数的 HTTP 请求。

    • 对于其他触发器(如计时器或队列),请确保触发器正确触发,并且函数按预期运行。

  • 验证性能

    • 执行性能测试,将新的 Azure Functions 部署与以前的 AWS Lambda 部署进行比较。

    • 监视响应时间、运行时和资源消耗等指标。

    • 在测试阶段使用 Application Insights 进行 监视、日志分析和故障排除

  • 使用诊断和解决问题功能进行故障排除

    使用 Azure 门户中的 诊断和解决问题 功能对函数应用进行故障排除。 此工具提供了一组诊断功能,可帮助你快速识别和解决常见问题,例如应用程序崩溃、性能下降和配置问题。 按照该工具提供的引导性故障排除步骤和建议来解决所识别的问题。

评估已迁移工作负荷的最终状态

在 AWS 中解除资源授权之前,需要确信平台满足当前的工作负荷预期,并且不会阻止工作负荷维护或进一步开发。

部署和测试函数以验证其性能和正确性。

部署到 Azure 云

使用 VS Code 发布功能部署工作负载。 还可以使用 Azure Functions Core ToolsAzure CLI 从命令行部署工作负荷。 Azure DevOpsGitHub Actions 也使用一个部署。

探索示例迁移方案

使用 MigrationGetStarted 存储库 作为模板开始概念验证。 此存储库包括一个现成部署的 Azure Functions 项目,其中包含基础结构和源代码文件,可帮助你入门。

如果希望使用 Terraform,请改用 MigrationGetStarted-Terraform

优化和监视 Azure 上的应用程序性能

迁移工作负荷后,建议浏览 Azure 上的更多功能。 这些功能可以帮助你满足未来的工作负载要求,并帮助缩小差距。

使用 Application Insights 进行监视和故障排除

为函数应用启用 Application Insights 以收集详细的遥测数据,以便进行监视和故障排除。 可以通过 Azure 门户或在函数应用的 host.json 配置文件中启用 Application Insights。 启用 Application Insights 后,可以:

  • 收集遥测数据。 Application Insights 提供各种遥测数据,例如请求日志、性能指标、异常和依赖项。

  • 分析日志和指标。 从 Azure 门户访问 Application Insights 仪表板,以可视化和分析日志、指标和其他遥测数据。 使用内置工具创建自定义查询并可视化数据,以便深入了解函数应用的性能和行为。

  • 设置警报。 在 Application Insights 中配置警报,以通知严重问题、性能下降或特定事件。 这些警报可帮助你主动监视并快速响应问题。

针对成本和性能进行优化

  • 缩放和性能优化:

    • 使用自动缩放功能高效处理不同的工作负荷。

    • 通过减少运行时、优化依赖项和使用高效的编码做法来优化函数代码以提高性能。

    • 实现缓存策略,以减少频繁访问数据的重复处理和延迟。

  • 成本管理:

    • 使用 Microsoft成本管理工具 监视和分析 Azure Functions 成本。

    • 设置预算和成本警报,以有效管理和预测费用。