2015 年，第一个使用 AWS Lambda 和 API 网关的教程出现了，它主要关注的是如何复制微服务。但是，随着时间推移，那些大规模使用 AWS Lambda 的人越来越清晰地意识到，使用 AWS Lambda 的微服务存在严重的局限性。

我们先来聊聊为什么会有微服务

微服务之所以会出现，主要是因为单体应用程序存在不足。简单地说，单体就是把所有逻辑都塞进同一个逻辑代码库的应用程序。

在单服务器环境时代，多服务器价格十分昂贵。默认情况下，应用程序是按照单服务器的方式进行构建的。部署一个单体就是把应用程序的一部分或者整体部署到一台服务器上。

在部署单体时，必须确保不出任何问题。通常，一个很小的改动都会导致整个应用程序和服务器宕机。

在云服务出现之后，通过简单的操作就可以在几分钟而不是几天或者几周之内分配好服务器实例，这就为关注点分离提供了条件。

于是，拆分单体就成了一件势在必行的事情，微服务也就孕育而生。

你不再需要把所有逻辑都部署在同一个实例或服务器上，你可以把不同的部分放在不同的实例上，然后使用轻量级的通信协议（比如 HTTP API）把它们连接起来。

于是，应用程序架构就从单体转向了微服务。

微服务的价值在于，在做出修改时，你修改的不是整个代码库，而是其中的一个微服务，它只是整个应用程序的一部分。也就是说，改动不会造成整个应用程序宕机。

但这毕竟也只是一个美好的理论，一个比单体更好的理论，在现实中，它并不完美。

服务接口（通常是 HTTP 接口）是微服务的关键所在。这本没有什么问题，但是，当存在大量的服务时，要协调好它们就成了一个大问题。

向 Serverless 架构转变

AWS 上的第一个 Serverless 应用就是一个微服务：一个 API 网关接口，网关背后是 Lambda 函数和路由器。

每一个 API 网关都是一个服务接口，看起来似乎是合乎逻辑的。

你可以构建一系列的服务，每个服务都可以独立伸缩，某种程度上说，这样做非常合理。

但问题是，AWS Lambda 和 FaaS 不应该被当作实例或服务器看待。

因为底层使用了服务器（互联网上的很多东西都运行在服务器之上，但就是没有人指出“S3 也是有服务器的”、“BigTable 也是有服务器的”或者“Azure Active Directory 也是有服务器的”），所以我们假设你应该简单地把 FaaS 函数看成是服务，也就是有些人所谓的“minilith”。

但问题是，Serverless 的关键点是事件，而这一点往往被忽略掉。

Serverless、事件和触发器

Serverless 系统本质上就是事件驱动的系统，采用了事件驱动的架构。这种架构改变了 Serverless 系统的开发和管理方式。

微服务架构的主要目标是提供高度响应的 API，这也是服务间主要的交互机制。

Serverless 架构的主要目标是对发生的事件做出响应，API 是生成事件的唯一机制。

在 AWS 生态系统（最为成熟的 Serverless 生态系统）中，API 并不是主要的接口，事件变得更为重要。

这也就是为什么会有将近 50 个事件来触发一个 Lambda 函数。

如果可以不通过 API 网关来触发 Lambda 函数，就会更快、更高效，特别是在从其他 AWS 接口触发事件的时候。

这里有一些 Serverless 最佳实践。

其中最重要的是函数的单向性。大多数微服务采用的是请求 / 响应式的架构，这也是大多数 Web 应用程序的运行模式。Serverless 应用程序里的函数通常是单向的，并使用队列充当回路断路器，所以请求 / 响应式的架构就变得不那么常见了。

数据层的管理方式也不太一样。最好是可以使用多个函数，而不是使用一个带有切换开关的代理函数。

相比微服务架构，多函数还有另外一个好处。例如，如果一个函数出错，因为它是无状态的（或至少应该是），所以只会影响该函数本身，不会影响到应用程序的其余部分。

如果只是简单地从微服务转向 Serverless 架构，虽然确实会给你带来一些好处，但也会错失很大一部分 Serverless 应用程序的真正价值。

从很多方面来看，微服务与 Serverless 应用程序是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。

从微服务到 Serverless

那么，从微服务到 Serverless 需要经过怎样的路径？微服务已经相当普及了，那么是否存在一条简单的路径，可以直接从一方过渡到另一方？

我想，这也正是 Serverless 世界正在解决的问题。最近，Twitter 上有很多与这个话题相关的推文。这里引用其中的一条，看看社区都是怎么讨论这个话题的。

现在有很多工具声称它们会让 Serverless 应用程序的构建变得更容易，但实际上最终都是要去到它们的平台上。我不认为它们会带来额外的价值或者会让人们更好地理解什么是 Serverless 架构。

我们非常清楚地意识到，我们正在讨论的是 Serverless 架构的未来，但并没有说这会让从旧架构风格过渡到 Serverless 会变得更容易，或者断定 Serverless 是不是一个正确的选择（在某些情况下可能不是）。

这是有原因的。人的思维是不容易改变的。构建一个 Lambda 函数很容易，但构建一个真正的 Serverless 应用程序并不容易，它需要在思维上做出一系列改变，而这样做相对没有那么容易。

另外，我也经常说，我们不要只是简单地把人们带入到“hello world”，然后就撒手不管，有很多技术人认为这样做就够了。

我写了一个有关 Serverless 的最佳实践，是想帮助人们认识到他们不应该基于当前的知识框架去构建 Serverless 应用程序。

我们现在用来构建 Serverless 解决方案的工具就是我们用来构建云 1.0 应用程序的工具，它们并不完全符合我们的目标。

这些工具还不完美，我们会努力去改进它们。

英文原文

Serverless and Microservices: a match made in heaven?

创作场景

微服务和 Serverless 的天作之合