对接Serverless：从了解无服务器架构原则开始

Posted 2021-04-30 前沿技墅

市场机会转瞬即逝，爆款压力突如其来，而创业团队却被架构的扩展性和基础设施的规划运维束缚手脚，疲于应付。除提升团队自身的架构和运维能力外，还要想办法降低基础设施运维的门槛。Serverless也许就是希望——采用无服务器技术架构后，开发者使用现成的第三方服务并专注于应用的业务功能代码开发，不用再关心以服务器为代表的基础设置的规划、配置和维护。而应用运行时使用的服务完全是按需分配的，一旦出现吞吐量的激增，这些服务会自动快速扩展到达可用性的要求。而应用使用的服务都是按照实际的使用量来计费的，这将大大降低基础设施投入的成本。在基础设施即服务、容器即服务和平台即服务的基础上，无服务器架构对云计算进行了更高层次的抽象，大大降低运维的门槛和成本。

本文定义了无服务器架构的五大原则，描述了应该如何构建一个理想的无服务器系统。在构建无服务器架构时，可以运用这些原则帮助你做出决定。

1. 根据需要使用计算服务执行代码（没有服务器）。

2. 编写单一用途的无状态函数。

3. 设计基于推送的、事件驱动的管道。

4. 创建更厚更强大的前端。

5. 拥抱第三方服务。

接下来让我们更详细地看下一每一条原则。

根据需要使用计算服务执行代码

无服务器架构是 SOA 概念的自然延伸。在无服务器架构中，所有自定义代码作为孤立的、无依赖的而且通常是细粒度的函数来编写和执行，这些函数运行在 AWS Lambda之类的无状态计算服务中。开发者可以编写函数来执行几乎所有常见的任务，比如读取和写入数据源、调用其他函数以及执行计算。在比较复杂的情况下，开发者可以构建更复杂的管道，编排多个函数的调用。仍需要服务器来处理一些事情的场景可能依然存在。然而，这种情况并不多见，作为开发者，应该尽量避免与服务器发生关系和交互。

那么，Lambda 究竟是什么？

Lambda 是一种计算服务，它在 AWS 基础设施上执行用 javascript（node.js）、Python、C# 或 Java 编写的代码。源代码（Java 或 C# 的话就是 JAR 或DLL）将被打包并部署到孤立的容器上，该容器有单独分配的内存、磁盘空间和处理器。代码、配置和依赖项的组合通常被称为 Lambda 函数。Lambda 运行时环境可以并行多次调用某个函数。Lambda 支持操作的推送事件模型和拉取事件模型，并能和大量的 AWS 服务进行整合。第 6 章中会更详细地介绍Lambda，包括它的事件模型、调用方法以及设计相关的最佳实践。不过要注意的是，Lambda 并不是唯一的计算服务，Microsoft Azure Functions、IBM Bluemix OpenWhisk 和 Google Cloud Functions 可能是你应该关注的其他计算服务。

编写单一用途的无状态函数

作为软件工程师，你在设计函数时应该尽量运用单一职责原则（Single Responsibility Principle，SRP）。仅处理某一项任务的函数更容易测试、更加健壮，而且错误和意外的副作用也更少。通过一种松散编排的方式将函数和服务组合起来，就能构建易于理解、易于管理的复杂后端系统。拥有明确定义接口的细粒度函数也更有可能在无服务器架构里面被重复使用。

为 Lambda 等计算服务编写的代码应该以无状态方式来创建。不能想当然地认为本地资源或进程会在当前会话之后生存下去。无状态性非常强大，因为它让平台可以迅速扩展，来处理数量不断变化的传入事件或请求。

设计基于推送的、事件驱动的管道

可以构建无服务器架构以满足任何用途。系统可以从一开始就构建成无服务器架构 ；现有的单体应用程序也可以逐步重新设计，以便充分发挥这种架构的优势。最灵活、最强大的无服务器设计是事件驱动型的。比如在第 3 章中，你会建立一个事件驱动的、基于推送的管道，然后你会看到如何快速整合出一个系统来将视频编码为不同的比特率和格式。我们通过将 Amazon 的 Simple Storage Service（S3，简单存储服务）、Lambda 和 Elastic Transcoder 连接在一起，来实现该目标所示）。

图-基于推送的管道设计风格与无服务器架构非常搭配。在这个例子中，用户上传一段视频，它会被转码成不同格式。

构建基于推送的事件驱动系统常常可以降低成本和复杂性（不需要运行额外代码来轮询变更），同时可能让整个用户体验更流畅。当然，虽然基于推送的事件驱动模式是一个美好的目标，但它们并非在所有情况下都是适合的或可以实现的。有时候，不得不实现一个 Lambda 函数来轮询事件源或定期运行。在后面的章节中，我们将介绍不同的事件模型，你也将完成相关的案例练习。

创建更厚、更强大的前端

要记住很重要的一点，在 Lambda 中运行的自定义代码应该执行得很快。越快终结的函数成本越低，因为 Lambda 定价基于请求数量、执行时间长短以及分配的内存量。在 Lambda 中做的事情越少越省钱。此外，建立能直接调用第三方服务的富前端（作为复杂后端的替代品）有利于更好的用户体验。在线资源之间更少的跳和更低的延迟会得到更好的应用程序性能和可用性。换句话说，你不需要通过计算服务来路由到每个地方。你的前端应该可以直接与搜索提供商、数据库或其他有用的 API 进行通信。

数字签名的令牌让前端可以与不同的服务（包括数据库）以安全的方式直接进行通信。与其相反，在传统系统中，所有通信都通过后端服务器来实现。然而，不是一切都可以或者都应该在前端执行。总有些秘密无法透露给客户端设备。处理信用卡或向订阅用户发送电子邮件只能由不受最终用户控制的服务来完成。在这种情况下，就必须通过计算服务来协调操作、验证数据，并保证安全。

另外要考虑的重要一点是一致性。如果前端负责写入到多个服务，可是中途出现故障，就会导致系统处于不一致的状态。在这种情况下，就应该使用 Lambda 函数，因为它被设计成可以优雅地处理错误，并且重新尝试失败的操作。

拥抱第三方服务

如果第三方服务能产生价值、减少定制代码，那自然欢迎它们加入。然而，不言而喻的是，当考虑第三方服务时，必须评估诸如价格、能力、可用性、文档和支持等因素。对于开发者来说，花时间解决他们领域独有的问题比重新创建别人已经实现的功能要有用得多。如果有可用的第三方服务和 API，不要为构建而构建。请站在巨人的肩膀上以达到新的高度。附录 A 列出了我们觉得很有用的 AWS 以及非AWS 服务的一个简短清单。在阅读本书的过程中，我们将更详细地介绍这些服务的内容。

————

本文摘自新书《Serverless架构：无服务器应用与AWS Lambda》。作者作为最早实践无服务器架构的开发者之一，总结了Serverless常见使用场景和架构模式，介绍了身份认证和授权、函数计算、网关、对象存储以及数据库等重要内容，并总结了一些值得关注的工具、实践和趋势。直击下方阅读原文，即可提早聆听创业者福音，快速对接Serverless。

内容简介：无服务器是软件架构世界中的热门新话题，它充分利用大量的云平台服务，让开发者只需关注核心业务逻辑的实现。同时，它按需分配和使用资源的运行方式，在降低基础设施成本的同时还能获得强大的弹性。本书的作者 Peter Sbarski 是完全拥抱无服务器架构的早期开发者之一，他将自己在应用无服务器架构中获得的宝贵经验总结成本书，呈现给广大的读者。更难能可贵的是，全书贯穿了 AWS Lambda 实例和大量相关的练习。读者一边阅读，一边动手完成练习，就可以循序渐进地掌握无服务器架构的核心技术。无论你是软件开发新手，还是架构师老兵，本书都是不可多得的了解无服务器架构的最佳读物。

长按二维码，关注“前沿技墅”，抢先接收新知、了解书讯、结识大咖。

任何伟大，无不起步于不经意间，你可以选择不经意错过，或不经意开始……