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。
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 的开发教训，当初从事云信后端调度开发。