在亚马逊云科技上打造无服务器 Serverless 应用

专题摘要

本文是“在亚马逊云科技上围绕 Amazon VPC 打造内外兼修的合适架构”系列主题的第六部分，在前面的部分，我们分析了亚马逊云科技中客户 VPC 内部资源，客户 VPC 内部资源和外部托管服务之间的交互访问。随着越来越多的无服务器服务的出现，基于这些服务打造无服务器的应用也成为了很多客户倾向的选择。

无服务器是亚马逊云科技创新和发展的趋势，亚马逊云科技提供了很多的无服务器服务。本文提供了无服务器应用的几个重要实验场景，并对通过无服务器服务打造应用的一些要点进行了总结。

本系列专题由如下几部分组成：

背景简介

亚马逊云科技的服务在不同层次提供托管功能，无服务器服务让客户可以在不考虑服务器的情况下构建并运行应用程序务。这减少了客户基础设施管理任务，可以将更多的精力投入到应用的构建，利用无服务器服务的可扩展性，尽快实现业务价值。

无服务器的架构能够适应大多数类型的应用负载。特别是在基于事件驱动架构 EDA（Event Driven Architecture）的设计中，无服务器设计具有其独特优势。在这种设计中，服务和服务之间采用松耦合的方式，通过与技术无关的 API 进行交互。这些松散耦合组件之间的集成，也通常使用异步消息收发完成。下表是在构建此类无服务器应用中用到的核心服务。

类别	名称	功能和场景	使用方式
计算	Amazon Lambda	在托管平台上运行无状态的无服务器应用程序	调用服务 HTTPS API
API 代理	Amazon API Gateway	在任何规模下创建、发布、维护、监控和保护 API	调用服务 HTTPS API
消息收发和集成	Amazon SNS	消息发布/订阅服务	调用服务 HTTPS API
编排	Amazon SQS	消息队列服务	调用服务 HTTPS API
	Amazon EventBridge	无服务器事件总线	调用服务 HTTPS API
	Amazon Step Functions	可视化工作流程编排	调用服务 HTTPS API
存储	Amazon S3	对象存储服务	调用服务 HTTPS API
	Amazon DynamoDB	键/值和文档数据库	调用服务 HTTPS API

除了上述这些核心的无服务器服务，还有很多其他的不同类别，用途更广泛的无服务器服务，一些重点的代表服务，如下表所示（部分服务在中国区内还没有提供）。

类别	名称	功能和场景	使用方式
数据存储	Amazon Aurora Serverless v1	兼容 MySQL 和 PostgreSQL，自动可扩展的关系数据库	JDBC 或调用 HTTPS Data API
机器学习	Amazon Rekognition	使用机器学习自动执行图像和视频分析	调用服务 HTTPS API
	Amazon Translate	流畅准确的机器翻译	调用服务 HTTPS API
	Amazon Textract	从文档中自动提取打印的文本、手写字和数据	调用服务 HTTPS API
	Amazon Polly	文字转语音	调用服务 HTTPS API
数据分析处理	Amazon Redshift Serverless	无服务器的数据仓库	JDBC 或 Redshift Data API
	Amazon OpenSearch Serverless	用于日志存储或者文本搜索的服务	调用服务 HTTPS API Operation
	Amazon EMR Serverless	多种开源框架的无服务器分析平台	调用服务 HTTPS API
	Amazon Athena	交互式查询服务	调用服务 HTTPS API
	Amazon Kinesis	原生流数据服务	调用服务 HTTPS API
数据集成	Amazon Glue	无服务器 ETL 工具	调用服务 HTTPS API
物联网	Amazon IoT Core	安全地连接设备到云端	HTTP、MQTT、WebSockets 和 LoRaWAN
媒体	Amazon Elastic Transcoder	媒体文件格式转换	调用服务 HTTPS API

利用核心的无服务器服务，并结合其他的无服务器服务，可以构建各种场景下的应用，包括 Web 应用，数据处理，批处理或者数据摄取应用等。

这些无服务器的服务，通常都运行在自己专属的亚马逊云科技的 VPC 当中。服务之间通过标准的 HTTPS API 进行交互，确保传输加密。其访问时的网络连接由亚马逊云科技控制，且不会离开亚马逊云科技的网络环境。特别需要指出的是，Amazon Aurora Serverless v1 和 Amazon Redshift Serverless 除了支持传统的 JDBC 等访问方式，还直接支持 Data API 供用户调用，因而无需专门的驱动就可以直接通过 API 访问数据库，这使得将关系数据库应用到无服务器架构中变得更加容易，整个实现并不需要构建客户 VPC。

在无服务器的架构中，服务的相互访问都是通过权限策略（IAM Policy）来限定的。控制这些服务之间交互的一个重要原则就是最小化权限策略。

如上图所示，以 Amazon Lambda 为例，Lambda 的两侧均可受 IAM 策略保护。在左侧，通过 Lambda 的资源策略（Resource Policy），对可以调用该 Lambda 函数的事件源进行限制。在右侧，执行角色（Execution Role）限制了 Lambda 函数可访问的其他服务，例如访问 DynamoDB。

如下的 Lambda 资源策略限制了 Lambda 只能被 Amazon SNS 服务触发。

{
    "Sid":"sns",
   "Effect":"Allow",
   "Principal":{
        "Service":"sns.amazonaws.com"
    },
   "Action":"lambda:InvokeFunction",
   "Resource":"arn:aws-cn:lambda:cn-north-1:123456789012:function:my-function"
}

如下的 Lambda 执行角色中的策略赋予了访问 S3 存储桶“lambda_bucket”写入对象的权限，而且策略本身对 Lambda 进行了限制。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LambdaAccessBucket",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws-cn:s3:::lambda_bucket/*",
            "Condition": {
                "ArnEquals": {
                    "lambda:SourceFunctionArn": "arn:aws-cn:lambda:cn-north-1:123456789012:function:my-function"
                }
            }
        }
    ]
}

严格的权限设置，可以让 Serverless 架构中不同服务的相互访问更加安全。当然，Serverless 架构仍然还需要考虑其他的因素，包括应用的认证和权限，代码和配置的安全，数据安全，来自互联网的网络攻击防护，日志和监控等。

实验场景

本文重点讲述两个实验场景，这两个实验都在亚马逊云科技全球区域进行。“创新岛主题公园”实验基于微服务的理念，构建了包括前后端的无服务器应用。而“Serverlesspresso”实验是为会议活动搭建的咖啡预定应用，参会者可以通过移动端扫码预定咖啡饮料。

场景一：构建无服务器应用 – 创新岛主题公园（The Innovator Island Workshop）

该场景是为一家建在创新岛上并提供过山车等游乐项目的主题公园打造的数字化应用。该应用支持多种语言，游客可以在手机上浏览项目以及查看排队时间，以便合理安排时间。游客还可以在游乐项目中进行照片合成等体验。

访问创新岛主题公园实验链接请点击这里。该场景的无服务器架构，如下图所示：

前端架构

前端 Web 应用程序，是一个 JavaScript Web 应用程序。该应用程序由 Amazon Amplify Console 管理，与后端服务交互。Amplify 托管静态 Web 资源，包括用户浏览器中的 HTML、CSS、JavaScript 和图像文件等。

后端架构

后端应用程序架构使用 Amazon API Gateway，Amazon Lambda，Amazon S3，Amazon DynamoDB 和 Amazon Cognito 服务。在前端浏览器应用程序中运行的 JavaScript 向使用 API Gateway 和 Lambda 构建的后端 API 发送请求并接收数据。 DynamoDB 提供了一个持久性数据存储层，供 Lambda 函数访问，而 Cognito 提供应用的登录认证服务。

场景二：利用无服务器架构构建事件驱动的 Serverlesspresso 咖啡店应用

Serverlesspresso 是一家临时搭建的咖啡店，在会议和活动中提供优质咖啡饮料。通过构建一个无服务器事件驱动的应用程序，以帮助会议主办方能够在线接受订单，并在饮料准备好时通知顾客。该解决方案需要有足够好的可扩展性，能够处理饮料订单的工作流程，并对顾客进行身份验证。咖啡吧的订购流程如下：

咖啡店上方的显示器显示一个二维码，该二维码每 5 分钟更换一次。客户可以通过手机扫描此二维码下订单。每个二维码最多只允许订阅 10 杯饮料，一旦订满，二维码就会从屏幕上消失，需要等到下一个有效二维码的出现。这种设计主要是为了防止咖啡师工作量过载。
客户通过二维码访问应用，创建订单，后端验证并生成订单号，将其提供给咖啡师。
咖啡师可以在自己的应用程序上看到订单队列，可以更改订单的状态，比如“开始制作”、“制作完成”或者是“取消订单”。
客户在其手机上可以实时看到咖啡订单的更新信息。咖啡店上方的显示器上，也会实时显示已完成的饮料和即将完成的饮料等状态信息。

访问 Servelesspresso 实验连接点击这里。该场景的无服务器架构设计图如下所示：

本场景应用了事件驱动的设计架构。通过创建各种微服务，将现有前端与后端无服务器应用程序集成。使用 Amazon EventBridge 来处理事件响应，用 Amazon Step Functions 对微服务工作流进行编排。

前端架构

前端架构分为三个部分：

信息发布应用（显示器）：为顾客提供扫描下单的二维码，并显示即将完成和已经完成的实时队列信息。
订单制作应用（平板电脑）：咖啡师使用平板电脑上的应用程序更改咖啡订单的状态，或在必要时取消订单。该应用程序的更新信息会发布给显示器中的信息发布应用和客户手机移动端的下单应用。
下单应用（手机）：顾客在移动端下订单的应用程序。

后端架构

后端应用程序架构使用了 Amazon API Gateway，Amazon Lambda，Amazon Step Functions，Amazon EventBridge，Amazon S3，Amazon DynamoDB 和 Amazon Cognito 等服务。
前端浏览器中的 JavaScript 通过 API Gateway 向后端发送和接收数据。DynamoDB 提供了一个持久性数据存储层。后端发布的事件使用 Amazon IoT Core 和 Lambda 反馈给前端应用。