论无服务器架构的特征

Wisen Tanasa 在最近的博文当中提到，在目前关于无服务器架构的文献当中，有相当一部分由云服务供应商提供赞助，因此在内容上存在单纯强调优势的倾向。但 Tanasa 认为，每当有新的技术出现时，最重要的是全面了解其意义，因此我们应该从客观角度出发探讨无服务器架构的特性。

作为 Thoughtworks 首席开发者，Tanasa 表示他更倾向于使用“特质（trait）”、而非特性，因为他认为这些属于无服务器架构的固有元素，我们无法像处理其它可塑特性那样做出调整。特质是天然存在的，所以我们必须接受，而非与其针锋相对。

无服务器架构拥有较低的入门门槛；大家能够遵循教程轻松了解如何上手。但 Tanasa 指出，虽然开发人员面对的初步学习曲线比较平缓，但随着项目变得更为复杂，曲线也会迅速呈现出陡峭的态势。在无服务器的世界中，代码、日志记录以及监控等基础设施仍然必不可少。此外，他还注意到开发人员在面对无服务器架构时往往有忽略代码设计的倾向——很多人认为自己只是在直接使用函数。他强调称，对于最重要的构建原则，我们在无服务器世界中同样不应忽视。无论是 SOLID 这类设计概念，还是持续交付原则，都将在无服务器领域继续发挥重要作用。

在无服务器的世界里，不存在 主机 的概念——我们完全不需要面对任何服务器。由此带来的一大优势，在于显著减少了运营开销——不需要升级服务器、也不必考虑应用程序所必需的安全补丁。但与此同时，这也意味着我们需要对应用程序中的不同度量标准进行监控，换言之我们必须重新学习如何调整整个架构。Tanasa 强调称，尽管能够自动添加安全补丁，但应用程序安全实践在无服务器环境仍然适用。一个典型的例子就是不要在代码当中存储密码，这实际上跟无不无服务器没有关系。

函数即服务（FaaS）具有临时性，这意味着无服务器本身是 无状态 的。由于状态不会被存储在应用程序当中，因此横向扩展就变得非常简单——只需要直接启动更多实例即可。另外，无状态也意味着发生错误的空间大大减少。但是，无状态也意味着我们无法利用众多有状态技术进行应用程序开发；例如，我们将无法使用 HTTP 会话。

再有，无主机也意味着架构本身具有 弹性 。换言之，我们不必手动管理资源，资源分配方面的很多原有难题也将随之消失。一般来讲，这还意味着我们只需要为实际使用的资源付费。但在与遗留系统相集成时，这种弹性也有可能带来新的挑战。Tanasa 指出，除非传统系统能够像无服务器组件那样轻松扩展，否则我们必须限制负载以防止其因过载而发生故障。

在默认情况下，无服务器架构当中包含大量通过网络进行 分布式 集成的组件。持久性由后端即服务（BaaS）负责实现，代码则以多项函数的形式运行，其它服务用于实现身份验证与队列等功能。分布式特质也为架构带来了高可用性。如果当前可用区存在问题，则架构可以使用另一可用区。不过分布式应用程序在一致性方面需要做出权衡，最典型的两种选项就是写入后读取以及最终一致性；我们在更新以及读取数据时，必须考虑到这些具体情况。

由于利用 BaaS 支持事件，因此无服务器架构还具有 事件驱动 特质。Tanasa 指出，这并不是说开发者必须完全接受事件驱动型架构，但事件驱动确实能够带来诸多优势。举例来说，事件驱动能够显著降低各组件之间的耦合水平。但这同时也会带来无法建立系统整体视图的风险，并提高排除系统故障的难度。

Tanasa 最后指出，无服务器架构带来了一种有趣的范式转变。其改进了软件开发当中的诸多方法，同时也引入了一系列需要由开发人员以及团队加以适应的全新挑战。

在另外两篇博文中，来自 Symphonia 公司的 Mike Roberts 描述了他对于 无服务器的定义 。在他看来，无服务器应用程序是一类利用无服务器服务实现的应用程序，且此类服务必须具有以下五点共通特质：

• 不需要管理服务器主机或者服务器进程。
• 根据负载进行自动规模伸缩与自动配置。
• 根据使用情况决定实际成本。
• 性能容量以不同于主机规模或数量的其它术语进行定义。
• 具备隐含的高可用性。

Jonas Bonér 在今年早些时候的一篇博文中也提到，虽然他力挺无服务器这波浪潮，但编程模型 不应只关注无状态函数 ，因为这同时也会严重限制所能支持的用例类型。

另外，在 2017 年的一篇博文中，Martin Fowler 提到了事件通知的风险，并指出 虽然事件通知模式非常实用，但也增加了大规模流量长期处于监控之外的风险 。