AWS Serverless 服务是一种对应用工程师来讲无服务器的计算方式，基础概念是将运行服务所需的基础设施交由 AWS 管理。使用 AWS Serverless 服务的工程师能够专一于面向客户逻辑服务层的开发，而不须要在基础设施的构建、管理、扩容等任务上分散过多精力。AWS Serverless 开发的核心是名为 Lambda 的计算服务。后端
今天咱们将围绕 Lambda ，介绍在不一样的应用场景下Lambda与各类 AWS 服务的不一样组装模式，来初步探讨基于 AWS Serverless 的开发和部署。安全
What？
首先介绍一下什么是 Serverless 开发。服务器
和经典的开发、编译、部署运行方式不一样，使用 AWS Serverless 计算服务 Lambda，仅须要上传源文件，选择执行环境并执行，便能获得运行结果。在这过程当中，服务器部署、runtime 安装、编译、都由 AWS Serverless 计算平台管理执行。对开发人员来讲，只须要维护源代码和 AWS Serverless 执行环境的相关配置便可。架构
Why？
为何要选择 Serverless 呢？并发
对开发人员来讲，使用 AWS Serverless 服务可以节省大量管理基础设施架构的精力，并更好地专一于业务逻辑的开发。而对服务而言，AWS 自己的服务性质使得它能很好的支持弹性扩展和高并发场景。此外基于 AWS Serverless 的开发每每拥有快速更新、快速部署的优势，其按需收费（on-demand）的收费方式，在如轻量部署测试环境、快速验证等应用场景下对削减开支也有优点。负载均衡
How？
那么，咱们来看一下如何用 AWS Serverless 的相关服务迅速组装一个简单的 Web Service。less
AWS Serverless 提供了丰富的服务目录，以覆盖各类功能的使用需求。搭建 Web Service 服务除了核心的计算服务 Lambda 以外，经常还须要和请求入口路由（API Gateway）、持久化存储（S3）、CDN（CloudFront）、防火墙（WAF）、域名解析（Route 53）等服务组合使用。若是须要支持 https 协议，还可使用证书管理服务（ACM）实现。异步
将上述服务组装好以后，一个完整的响应请求流程将会是这样的：函数
- 用户请求经由域名解析到达 CloudFront，由 WAF 进行频率控制、IP 过滤、header 验证等安全性保障后，经过 API Gateway 路由转发给核心的 Lambda 计算服务。
- Lambda 会对请求进行处理，处理时如若须要会从持久化存储 S3 中读取或存储数据，而且最终将处理结果经过 API Gateway 返回给用户端。
- Lambda 在逻辑计算时产生的日志会输出到 CloudWatch 提供的日志管理服务中以便往后查询。此外，还能够进行额外的优化，好比配置 CloudFront 直接从 S3 中加载静态资源，以减轻时间和计算开销。
Lambda 的启动方式
在刚刚的 Web Service 的例子中，Lambda 的执行是由 API Gateway 服务唤起（Invoke）的。实际上 Lambda 执行可由多种方式唤起。首先 AWS 自己的服务中，经常会和 Lambda 结合使用的有消息发布（SNS）、消息队列（SQS）、负载均衡器（ALB）、状态机（Step Function）等服务。微服务
固然经过 SDK、Command Line 或者 API 接口，也能够启动 Lambda 函数的执行。执行模式分为同步和异步两种：
- 同步模式的调用：须要等待 Lambda 函数执行完毕才会返回结果
- 异步模式的调用：在调用 Lambda 的执行接口以后会当即返回，Lambda 函数的执行结果须要经过其余途径获取。
这两种调用模式可供不一样场景灵活选择使用。
消息驱动的例子
咱们再看一个消息驱动的报警处理系统中使用 AWS Serverless 服务的例子。
好比咱们有一个运行中的系统，设定异常报警发生时会将报警消息发送给 SNS 服务。SNS 服务是一个消息的 Pub/Sub 服务，对报警消息执行一个基础的 fan-out 发布操做，一方面经过电话、邮件通知负责人，另外一方面同时调用 Lambda，Lambda 中能够进行一些对报警的自动化处理。这就是一个最简单的报警处理系统。
可是在这里要注意，SNS 服务自己不存储消息。SNS 接收到消息后，会立刻进行发布消息。若是此时没有消息的接受者，那么这条消息就会被丢弃。除此以外，消息传递成功，即调用 Lambda 的接口成功以后，不管处理结果如何，消息都会被丢弃。若是 Lambda 由于一些内部逻辑错误、或者外部依赖系统故障等缘由，处理过程执行失败了，那么对已经丢失的消息是没法进行重试操做的。要提升消息处理的可靠性，能够经过在 SNS 和 Lambda 之间加入消息队列服务（SQS）来实现。
SQS 标准队列提供一个无序可靠、支持高并发的队列服务，能够存储消息长达14天。SNS 将消息发布至 SQS，消息首先会被存储在 SQS 中。此时，再设置 SQS 为 Lambda 的事件源（event source），那么消息就会被发送至 Lambda 进行下一步处理。SQS 唤起 Lambda 能够配置为一个同步的过程，也就是说，若是 Lambda 执行失败并返回错误，SQS 就不会从队列中删除这条消息。处理失败的消息暂时会被标记为不可见，在一段隐藏期限事后，SQS 将会再次重复唤起 Lambda 来处理这条消息。这种方式能够大大提升消息处理的可靠性。
可是上述方式同时也引入了异常消息大量堆积而下降正常消息执行效率的问题。为了解决这个新问题，咱们能够为消息队列配置一个 Dead-Letter Queue。若是某条消息通过屡次处理依然不成功，可被从原来的队列中删除，而且转移到 Dead-Letter Queue中。标准队列的 Dead-Letter Queue 本质上也是标准队列，一样能够继续对其中的“废弃”消息进行其余后续处理。
标准队列可以较好地支持高并发场景。一个标准队列可以同时接受大量消息，并发地唤起大量 Lambda 实例进行处理。与此对应，标准队列服务不能保证消息投递的顺序，同一条消息也可能重复投递。因此在使用 SQS 标准队列时，须要考虑消息的去重、处理逻辑的幂等性等问题。除了标准队列，SQS 还有另外一种先进先出型（FIFO）队列。FIFO 牺牲了并发性能，来保证消息投递的顺序性和惟一性。在不一样应用场景下，能够根据具体需求来灵活选择使用不一样的队列类型。
总结
AWS Serverless 服务在解耦合、弹性扩展、跨区域部署等方面有自然的优点，但同时也有局限性：
- 单次 Lambda 的执行上限为15分钟，对长时间工做支持性较差。
- 构筑在 Serverless 架构上服务的可用性很是依赖于 AWS 可用性。
- 基于 Serverless 的开发会产生对 AWS 系统的学习成本，调试、故障处理的难度也会变高。
在实际生产活动中，须要全面考虑需求，平衡好成本与效果。在某些适合微服务的应用场景下，特别在执行短状态、临时性等任务时，基于 AWS Serverless 的开发能够成为十分便利的开发手段。
以上就是本次分享的所有内容，关于本次分享的视频，也能够点击【这里】进行查看。
做者介绍
葛馨霓，网易云信后端开发工程师，在海外有基于 AWS Serverless 的开发经验，如今从事云信后端调度开发。