本文是为OTUS教育项目中的DevOps实践和工具课程的学生准备的。

当2015年第一批教程开始使用AWS Lambda和Gateway API时，它们主要专注于复制微服务架构就不足为奇了。 但是对于那些大规模使用AWS Lambda的人来说，随着时间的流逝，很明显，将微服务方法应用于AWS Lambda存在着很大的限制... 至少对于大多数人所说的适当构建微服务意味着什么。

让我们谈谈为什么要使用微服务

微服务的出现主要是由于对整体应用程序的不满。 Monolith是一种应用程序，其中所有逻辑都在一个逻辑代码库中。

有时，由于服务器成本高昂，通常将整个应用程序部署在单个服务器上。 部署整体意味着在服务器上部署部分或全部应用程序。

此外，部署整体意味着您必须确保不会破坏任何东西。 通常，小的更改会导致整个服务器和整个应用程序的故障。

因此，当出现能够在几分钟（而不是几天或几周）内单击一次实例的云时，任务分离的可能性就变得显而易见。
整体的破坏成为一个显而易见的想法，微服务的想法由此诞生。

您可以将应用程序的各个部分放置在不同的服务器上，然后使用某种轻量级协议（通常是HTTP API）将它们连接在一起，而不必在一个服务器/实例上创建具有所有逻辑的整体。

因此，应用程序架构已从整体式服务转移到微服务。

虽然，我不知道为什么？ 这种方法的价值在于，在编辑代码时，您更改的不是整个应用程序的代码库，而是微服务-仅更改应用程序的组成部分。 这意味着您无法破坏整个应用程序。

尽管这只是理论上的，但该理论比理想的要好，尽管它并不理想。

每项服务的关键要素是...

服务介面

这通常是某种形式的HTTP接口（至少这是最常见的方法）。 通常，这不是问题，除非您拥有大量服务，并且可能存在服务协调问题。

迈向无服务器架构

因此，在AWS上构建无服务器应用程序的最初方法是“让我们创建微服务”。

这意味着创建一个带有Lambda函数和一个充当路由器的switch语句的Gateway API。

每个网关API都变成了服务接口，这似乎是合乎逻辑的。

您可以使多个服务相互独立扩展，这在某些情况下可能非常重要。

除非您意识到通常不应将AWS Lambda和FaaS函数视为实例/服务器，否则这没有任何意义。

因为尽管它们在后台具有服务器（嘿，在大多数可以在Internet上运行的事物下都有服务器，但是没有人说“ S3仍然有服务器”或“ BigTable仍然有服务器”或“ Azure Active Directory全部仍然有服务器“ ...”，有人认为您应该将FaaS功能与服务...“ minilith”相同，有人称之为。

问题在于，我认为这是无服务器体系结构的关键所在：

无服务器架构与事件有关

无服务器架构，事件和触发器

无服务器系统本质上是事件驱动系统，因此是事件驱动体系结构的代表。 它改变了您的设计，管理和架构方法。

对于微服务而言，最重要的是响应接口-这是与逻辑进行交互的主要机制。

无服务器解决方案是关于事件的响应，而API实际上只是一种生成事件的机制。

作为最成熟的无服务器解决方案AWS生态系统的一部分，API不被视为主要接口。 事件更为重要。

这就是为什么大约有50个事件可以触发其他AWS服务中的Lambda函数。

提示是，如果您无需运行Gateway API就可以运行Lambda函数，它将比使用Gateway API更快，更高效，尤其是从另一个AWS界面运行它时。

看一看Serverless Best Practices ，您会发现许多点与多少个设计微服务不同。

首先，单向功能。 大多数微服务通常使用请求-响应架构，因为大多数Web应用程序都是以这种方式工作的。 通常，无服务器应用程序中的功能是单向的，并且队列用作“断路器”，因此请求响应变得不那么普遍了。

数据层也以不同的方式进行管理和理解。 最佳实践是具有多个功能，而不是具有switch语句的一个代理功能。

与微服务相比，多功能的思想还提供了其他优势。 如果一个函数抛出一个错误，那么这只会影响这个函数，而不会影响应用程序的其余部分，因为该函数没有状态（至少应该是！）。 这是不做“小事”的一个很好的理由！

因此，尽管构建微服务的经验在设计无服务器解决方案时为您带来了一些优势，但实际上，您会错过使无服务器应用变得有价值的大部分原因。

微服务通常在几个方面与精心设计的无服务器应用程序不同。 这意味着，尽管您可以使用无服务器后端创建微服务，但实际上并没有从微服务到无服务器架构的直接路径。

从微服务到无服务器架构的道路

那么，从微服务到无服务器解决方案的路径是什么？ 由于微服务已广泛使用，有没有一种快速的方法来学习基础知识以简化从一种过渡到另一种的过渡？

我认为这是无服务器世界所困扰的。 最近，在Twitter上进行了大讨论 ，我们讨论了这个话题。 如果仅查看社区在谈论什么，那么这里值得一提（查看各种答案，尽管没有人直接提及微服务，但您会看到很多关于该主题的意见）。

他们谈论了一些工具，这些工具将被用来促进无服务器应用程序的创建，但最终它们将成为您构建所有内容的平台。 我认为这不会帮助或帮助人们更好地理解建筑风格。

作为一个社区，我们了解无服务器架构是未来。 但是，即使无服务器架构是正确的（有时不是正确的）选择，从旧的体系结构样式过渡也不总是那么容易。

这是有原因的。 改变一个人的想法并不容易。 构建Lambda函数很容易。 但是创建设计良好的无服务器应用程序并不容易。 因为它需要改变思维方式，并且相对困难。

正如我多次说过的，我们必须停止教人们“ hello world”应用程序，并停止这样做，因为许多人认为这对于他们来说就足够了。

我写《 无服务器最佳实践 》的原因是为了帮助人们理解，他们不应基于当前的知识对如何构建无服务器应用程序做出假设。

我们现在用于创建无服务器解决方案的工具与用于创建“ cloud 1.0”应用程序的工具相同，但是它们并不完全适合这些目的。 这些工具并不完美，但是我们正在尝试解释并使其尽可能好。

我们需要您什么

我认为社区实际上非常开放，可以帮助人们进行培训和开发，以创建无服务器解决方案。

因此，作为一个社区，我们需要您提出以下问题：
-你有什么困难？
-差距在哪里？
-缺少哪些教程？

诸如此类。

我已准备好帮助公司实现这一过渡。 我与高级管理层，CTO和CEO一起工作，以帮助确定使用无服务器方法为公司创造的价值，并且很高兴为其他公司提供帮助。

我很乐意提供帮助。 在此处联系领英。