很多人初次接触无服务器，以为无服务器是针对微服务架构的。当第一个无服务器应用程序开始在AWS上构建时，最初的方法是“让我们构建微服务”，这意味着：构建一个API网关接口，其背后有一个Lambda函数，一个switch语句充当路由器。
每个API网关都成为一个服务接口，这似乎是合乎逻辑的。而且你可以构建一系列服务，然后彼此分开扩展，这在某些方面很有意义。
但是，无服务器是关于事件的！
无服务器，事件和触发器
Serverless系统本质上是事件驱动的系统，因此是事件驱动的体系结构。这改变了您开发，管理和架构的方式；而在微服务解决方案中，主要是API接口，这是与逻辑交互的主要机制；在无服务器解决方案中，主要是发生的事件，而API实际上只是一种生成事件的机制。
在作为无服务器生态系统中最成熟的AWS生态系统中，API不被视为主要接口，事件更重要。
看一下无服务器最佳实践，您将看到一些与构建微服务的不同方式：
主要关键是函数的单向还是双向的区别：大多数微服务倾向于使用请求 - 响应类型的双向体系结构，因为这是大多数Web应用程序倾向于运行的方式。无服务器应用程序中的功能往往更倾向于单向并使用队列作为断路器，因此并不是一种请求响应模式。
微服务往往以多种方式与设计良好的无服务器应用程序发生分歧，这意味着尽管可以使用无服务器后端构建微服务，但实际上在微服务和无服务器之间没有直接的直接路径。
从微服务到无服务器的路径
从微服务到无服务器的路径是什么？是否有直接的方法来学习基础知识，使其更容易从一个过渡到另一个，因为微服务是如此普遍？
一些工具告诉您，它们可以轻松构建无服务器应用程序，但最终成为您必须构建的平台。我不认为这会增加价值或让任何人更好地理解建筑风格。
我们敏锐地意识到，作为一个社区，我们正在谈论无服务器作为未来，但不一定能够轻松地从旧的架构风格过渡或在无服务器是正确（有时不是正确的）选择时明确。
这是有原因的。
转变一个人的想法并不容易。
构建Lambda函数很容易；但要构建一个架构良好的无服务器应用程序并不容易，因为它确实需要改变思维方式，而且相对较难。