部署：无服务器部署模式

背景

你已经采用了微服务架构并且将你的系统架构为一组服务。每个服务为了吞吐量和可用性，部署为一组服务实例。

问题

怎样将服务打包和部署？

限制

• 服务采用不同语言，不同框架，不同框架版本编写
• 每个服务为了吞吐量和可用性，存在多个服务实例
• 服务必须独立部署和扩展
• 服务实例彼此之间应该隔离
• 你需要可以快速的构建和部署服务
• 你需要可以限制服务消费的资源（CPU和内存）
• 你需要监控每个服务实例的行为
• 你想要可靠部署
• 你必须尽可能小成品的部署应用程序

解决方案

采用一种隐藏了任何服务器概念-物理机，虚拟机，容器-的基础设施（例如，预留资源或者预分配资源）。这个基础设施获取你的代码并运行。根据每个请求的资源消耗向你收费。

使用这种方法部署你的服务，你将代码打包（例如，打包成ZIP文件），将它上传到部署基础设施，并描述期待的性能特点。

部署基础设施是公有云提供商操作的工具。它通常采用容器或者虚拟机隔离服务。然而，这些细节对你是隐藏的。不止是你，你的公司的其他任何人都无须对操作底层基础设施，例如操作系统，虚拟机等等负责。

示例

有少数几个不同的无服务器部署环境：

• AWS Lambda
• Google Cloud Functions
• Azure Functions

他们提供类似的功能，但是AWS Lambda有更丰富的特性。一个AWS Lambda是个无状态组件，执行和处理的事件。创建AWS Lambda函数，你需要打包你的NodeJS，Java或者Python代码为ZIP文件，上传到AWS Lambda。你还需要指定函数名字和资源限制。

当一个事件触发，AWS Lambda找到函数的一个空闲实例，如果没有可用的就启动一个，然后调用函数。AWS Lambda运行足够多的实例来应对负载。隐藏的细节是，它用容器来隔离lambda function的实例。像你可能期待的那样，AWS Lambda在EC2实例上运行这些容器。

有四种方法可以运行lamda函数。一个选择是配置你的lamda函数在AWS服务，例如S3，DynamoDB或者Kinesis产生事件时调用。事件的例子包括如下几种：

• S3 bucket里创建了一个对象
• DynamoDB表里，一个对象被创建，更新或者删除
• Kinesis流里，一个消息可以阅读
• 简单邮件服务里，收到了一封邮件

另外一种执行lambda函数的方法，是配置AWS Lambda网关，将HTTP请求路由到你的lambda。AWS网关将HTTP请求转换为事件对象，执行lambda函数，从lambda函数返回结果中生成HTTP响应。

你可以通过AWS Lambda Web Service API直接执行你的lambda函数。你的应用提供一个JSON对象，传递到lambda函数。Web Service返回lambda返回的结果。

第四种方法是通过cron类似的机制定时调用。举个例子，你可以让AWS每五分钟执行你的lambda函数。

每种执行方式的开销，是函数执行的时间，以100毫秒增量度量，和内存消耗。

结果

无服务器部署的优势包括：

• 它不用花费时间去管理低级别的基础设施。相反，你可以更关注你的代码。
• 无服务器部署基础设施极其弹性。它可以自动基于复杂扩展你的服务。
• 你为每次请求付费，而不是提供虚拟机和容器

无服务器部署的弊端包括：

• 重要的限制和约束 - 无服务器部署环境通常比基于虚拟机或者容器的基础设施有更多约束。比如，AWS Lambda仅支持少数几种语言。仅仅适合于部署基于请求响应模式的无状态服务。你不能部署一个长时间运行的状态服务，比如数据库或者消息队列。
• 限制了“请求来源” - lambda仅能响应少数的请求来源。AWS Lambda不打算运行，举个例子，从RabbitMQ消费消息的服务。
• 应用必须启动快速 - 如果你的服务需要长时间启动，无服务器部署并不适合
• 高延迟的风险 - 基础设施花费在准备实例和初始化函数的时间，会带来明显的延迟。而且，无服务器部署仅仅可以在运行时响应并扩容。你不能主动的提前准备容量。后果是，当你的应用遇到突然大量的请求高峰时，会遇到高延迟。

部署基础设施将在内部采用其他一种模式部署你的应用。它很可能采用每主机单个服务实例。

相关模式

• 每主机多服务实例模式是个可替代的解决方案
• 每主机单个服务实例模式是个可替代的解决方案