如今，企业的体系架构朝着 Serverless 架构迈进了一大步。在一篇博文中，Jonas Bonér认为，尽管他坚信 Serverless 的趋势，但编程的模式不应只关注无状态函数，这会限制能支持的用户场景的范围。
Bonér 是Akka的发明者和Lightbend的创始人，他指出，根据他的经验，函数即服务（FaaS）经常与 Serverless 混淆，并指出 Serverless 完全是关于用户体验（UX）的，而 FaaS 只是众多实现中的第一个。
通过明确定义的输入和输出，函数可以组成更大的函数。Bonér 用乐高来做了个比较，函数就像乐高积木，可以组成更大的积木。但他指出，尽管函数非常适合处理数据，但是在超出预期范围的情况下，它们就受到严重的约束和限制。
限制之一，FaaS 的函数的特性是，启动快速，无状态，生命周期短暂。从性能和延迟的角度来看，丢失计算上下文、不得不始终在后端存储中加载和保存状态的成本太高了。对 Bonér 来说另一个限制是，它们缺乏直接的寻址能力，因此所有通信都必须通过发布订阅来完成，这意味着所有数据都必须通过缓慢、昂贵的存储机制来处理。这可能适用于事件驱动型的用户场景，但对于通用分布式计算问题来说，延迟太高了。
虽然函数是一个很好的工具，但 Bonér 指出，如果想要 Serverless 满足在无操作（ops-less）世界中的期望和愿景，同时仍允许我们构建以数据为中心的实时应用程序，它必须能处理分布式系统中最难的问题 – 状态管理。这也是他认为 Serverless 最有趣的机会。对他来说，Serverless 过于关注基础设施的自动化，因而忽略了对状态的处理。状态被移出了应用层，但随着应用程序变得越来越以数据为中心以及数据为驱动，这并不是可行的一个解决方案。对于许多应用程序来说，存储请求的数据的每个往返太昂贵了。它们需要以近乎实时的方式连续处理数据，从数据流中提取知识。这是从“静止数据”到“动态数据”的转变，导致了许多公司转向采用基于分布式流处理和基于事件驱动微服务的体系架构。
对于 Bonér 来说，Serverless 的 1.0 版本都在谈无状态的函数。2.0 必须关注状态，这样我们就可以构建分布式的通用应用程序，同时从 Serverless 的优势中获益。端到端的正确性、一致性和安全性对于不同的服务意味着不同的东西，还取决于不同的使用场景。因此，保证系统的稳定性是应用程序的责任，下一代 Serverless 实现必须支持最重要的问题 – 如何在云中可靠、大规模地管理数据。
在 2018 年纽约的Serverless会议上，来自Confluent的Gwen Shapira讨论了在无状态的基础设施上，构建数据处理架构时所面临的挑战。她指出，我们想要做的很多事情都需要考虑状态。因此，在 Serverless 的世界中，状态的管理仍旧很重要。因为函数的扩展性非常好，所以我们需要运行非常快的数据库，它的扩展性要和使用这些存储的函数一样好，还要有相同的付费模式。但是，在寻找替代方案时，她没有找到任何数据库具备所期望的自动扩展功能，也没有一个会使用按需付费（pay-for-use）的模式。她还指出，FaaS 模型类似流处理模型以及事件驱动设计，这意味着可以在这些模型中相互利用各自的模式，而且我们对它们很多的使用经验都是相关的。她建议我们更专注于应用程序的实际需求，充分利用更能准确反映真实世界的事件，而不是只关注所采取的函数。
MikeRoberts，来自Symphonia，在讨论无服务器架构的早期博客文章中指出，FaaS 的函数受限于本地的状态。即使状态存在，也不能保证它在多个调用之间、或在同一函数的不同调用之间的持久性。因此，它们通常被描述为无状态的。但对于他来说，更准确的说法是，任何必须持久化的状态都必须存在于函数的外部。可以选择使用一个快速的 NoSQL 数据库、一个对象或文件的存储，但他指出，它们会比本地内存或服务器上的持久层要慢得多。他还指出，不同方案的选择会对应用程序的体系架构产生很大的影响。
查看原文链接：In a Serverless World, We Still Need State
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论