在了解了何为 Serverless各种服务组件之後，如何将服务组件组合成完整的应用程序基于 Serverless 开发的应用架构什么样子？与传统非 Serverless 应用程序架构相比Serverless 有哪些优势？本文将回答这些問题

假设有这么一个应用程序，它是一个支持多用户的手机游戏具有以下高级要求：

友好的移动端交互界面；

具备用户管理和身份验證；

有一些基本的业务逻辑，比如游戏排行榜历史记录等。

我们暂时忽略游戏中可能会遇到的其他功能毕竟我们的目的不是实际开发┅个游戏，而是将 Serverless 程序架构与传统的非 serverless 架构进行比较

根据上面的要求，传统非 Serverless 架构看起来应该是这样的：

数据存储在关系型数据库比洳 MySQL 里面。

在这个架构中移动应用程序负责呈现游戏界面并处理来自用户的输入，但它将大多数实际逻辑删除到后端从代码的角度来看，移动应用程序简单轻便它使用 HTTP 调用后端 Java 应用程序提供的不同 API。

用户管理、身份验证和各种游戏操作都使用 Java 应用程序代码进行封装 后端应用程序还与单个关系数据库交互，以便维护正在进行的游戏的状态并存储已完成游戏的结果。

这个简单的架构似乎符合我们的要求那么为什么对它做改进呢？关键在于未来开发和运维方面带来的一系列潜在的挑战和陷阱

在构建游戏时，需要具备 iOS 和 Java 开发方面的专业知识以及配置，部署和操作 Java 应用程序服务器的专业知识还需要配置和操作关系数据库服务器。除了应用服务器和数据库也需要配置囷运行各自的主机，无论这些系统是基于容器还是直接在虚拟或物理硬件上运行我们还需要通过配置路由策略，访问控制列表等来确保系统组件之间以及用户端和服务端之间的网络连通性。

有了上面这些我们仍然只是提供最基本的让游戏可用的环境还没有涉及安全性、可扩展性或高可用性，这些都是现代生产系统的关键方面最重要的是，即使在简单的体系结构中也存在许多固有的复杂性，用来满足现实世界各种各样的需求构建系统并不难，但是当我们修复错误添加功能或尝试快速构建新的创新想法时，所有这些复杂性将会变荿强大的阻力

现在已经发现了传统架构的一些挑战，如何改变它让我们看看如何能够满足高级需求，并使用 Serverless 架构模式和组件来解决传統方法的一些挑战

在之前的文章已经说过了，Serverless 组件可以分为两类BaaS 和 FaaS。考虑到游戏的要求其中一些可以通过 BaaS 组件解决，一些可以通过 FaaS 組件解决

基于 Serverless 构建的游戏，架构看起来应该是下图这个样子的：

虽然用户界面仍是移动应用程序的一部分需要自己通过代码来实现，泹用户身份验证和管理可由 AWS Cognito 等 BaaS 服务处理这些服务可以直接从移动应用程序调用，以处理注册和身份验证等面向用户的功能其他后端组件可以使用相同的 BaaS 来检索用户信息。

现在由 BaaS 处理用户管理和身份验证后端 Java 应用程序的逻辑被简化了， 可以使用另一个组件 AWS API Gateway以安全、可擴展的方式来处理移动应用程序和后端游戏逻辑之间的 HTTP 请求。然后可以将每个不同功能的操作封装在 FaaS 函数中

这些后端 FaaS 功能可以与像 DynamoDB 这样嘚 NoSQL 数据库进行交互，以存储游戏的状态实际上，一个重大变化是不再在服务器端应用程序代码中存储任何会话状态而是将所有会话状態保存到 NoSQL 存储中。虽然这可能看起来很麻烦但它有助于扩展。

移动应用程序可以无缝访问同一个数据库以检索过去的结果和排行榜数據。这允许我们将一些业务逻辑移动到客户端实现而不是将其放到到后端实现。

这种新的 Serverless 架构看起来很复杂而且它比传统架构需要更哆的组件，但是由于我们使用完全托管的 Serverless 组件，已经消灭了很多因为管理应用程序基础设施和底层系统而带来的挑战

我们编写的代码現在几乎完全集中在游戏独特的业务逻辑上，更重要的是组件已经解耦和分离，因此可以非常快速地将它们切换出来或添加新逻辑，洏不会出现非无服务器架构中固有的阻力

扩展，高可用性和安全性也有所提升这意味着随着我们的游戏越来越流行，不需要担心购买功能更强大的服务器也不需要担心数据库是否会崩溃，或者排查防火墙配置故障

简而言之，我们降低了制作游戏的人工成本以及运荇游戏的风险和计算成本，它的所有组成部分都将灵活扩展当我们有一些新的想法，交付期会大大缩短可以开始获得反馈并更快迭代。

云计算的基础设施外包带来五大好处：降低人工成本、降低风险、降低基础设施成本、扩展性、交付时间 Serverless 同样也有这五大优点， 前四個都或多或少是关于成本节约的这就是 Serverless 更为人所知的：如何以更低的成本做以前做过的同样的事情。但是对我们来说，节省成本并不昰无服务器最令人兴奋的部分较大的好处是，它减少了从新的想法到实施上线的时间换句话说，它能够让你更快地创新

我们在之前說过，Serverless 本质上不再需要关心自己的服务器和进程 只需要关心应用程序的业务逻辑和状态，所有其他不必要的工作都交给平台来处理这裏的第一个明显好处是运维工作量减少， 您不再管理操作系统补丁级别，数据库版本升级等如果您正在使用 BaaS 数据库，消息总线或对象存储那么祝贺你，这些基础架构也都不要你来运维

通过其他 BaaS 服务，对于节省人工成本是比较直观的自己开发的逻辑更少了。我们已經多次讨论过身份验证的 BaaS 服务其中较大的好处是可以使用较少的代码来定义开发、测试、部署和运营，所有这些都减少了工程师时间成夲另一个例子是像 Mailgun 这样的第三方邮件 BaaS 服务，它消除了处理电子邮件发送和接收的大部分复杂工作

与传统方法相比，FaaS 还具有显著的劳动仂成本优势使用 FaaS 进行软件开发得以简化，因为大部分基础架构代码已移至平台这里的一个例子是 HTTP API 服务的开发，这里所有的 HTTP 级请求和响應处理都是由 API 网关完成的

配置。其他类型的操作活动也变得更加简单例如，由于不再关注“永远在线”服务器进程因此可以将监控限制为更多面向应用程序的指标。这些是统计信息例如执行持续时间和面向客户的指标，而不是可用磁盘空间或 CPU 使用率

当考虑软件应鼡风险时，我们经常考虑对故障和宕机的敏感程度我们的团队负责管理的不同类型的系统或组件的数量越多，发生问题的风险就越大峩们可以不是自己管理这些系统，而是像之前描述的那样让“外包”系统来解决这些问题。

虽然整体而言仍然面临应用程序发生故障的風险但我们选择以不同的方式管理风险 -- 我们现在依靠其他人的专业知识来解决其中的一些故障，而不是自己修复它们这通常来说是一個好主意，因为应用的技术栈中一些技术是平时很少发生变更的，当它们发生故障时修复时间和难度都不确定。通过 Serverless我们可以显著減少直接操作的技术栈数量，那些我们仍在自己管理的技术通常是我们非常熟悉并且频繁变更的，因此我们更有能力在失败时自信地处悝失败

例如，管理分布式 NoSQL 数据库一旦安装了组件，节点发生中的故障可能相对罕见但是当它发生故障时，会发生什么您的团队是否具备快速有效地诊断，修复和恢复问题的专业知识常常没有。相反团队可以选择使用 Serverless 的 NoSQL 数据库服务，例如 Amazon DynamoDB 虽然 DynamoDB 中的中断偶尔会发苼，但由于亚马逊拥有致力于此特定服务的整个团队因此它们发生故障的次数更少，并且能够更快的恢复

因此，我们说当使用 Serverless 技术时风险会降低，因为组件的预期宕机时间会减少并且修复它们的时间会更少。

通常当运行应用程序时，我们必须弄清楚它们将运行的底层主机类型和数量例如，数据库服务器需要多少内存和 CPU需要多少个不同的实例来支持扩展？或者如何支持高可用性（HA）

一旦规划叻我们需要的主机或资源，就可以分配应用程序的哪些部分将在哪些资源上运行最后，一旦我们开始准备部署应用程序就需要实际获嘚我们想要的主机，这是环境配置

整个环境配置过程很复杂，我们很少提前知道我们的资源要求是什么因此高估了我们的计划，这称為过度配置这实际上是正确的做法：拥有备用容量并保持应用程序运行比在负载下降低更好。对于某些类型的组件（如数据库）可能佷难在以后扩展，因此可能希望通过过度配置来承载未来预期的负载。

过度供应意味着我们总是为满足处理峰值预期负载所需的容量付費即使我们的应用程序没有遇到负载也是如此。最极端的情况是我们的应用程序处于空闲状态时，我们正在为服务器付费而事实上咜并没有做任何有用的事情。但即使我们的应用程序处于活动状态我们也不希望主机得到充分利用。相反我们希望留下一些空间，以應对意外的负载峰值

无服务器给这个领域带来的巨大好处是不需要计划，分配或配置资源让服务较精确地提供我们在任何时间点所需嘚容量，如果我们没有任何负载那么不需要任何计算资源，也不会支付任何费用如果我们只有 1 GB 的数据，我们不需要容量来存储 100 GB我们楿信当需要时，服务将按需扩展并且这同样适用于 FaaS 和 BaaS 服务。

除了消除资源分配带来的问题无服务器还使成本更加高效。对于负载不一樣的各种应用程序我们将通过使用无服务器来节省资源成本。例如如果我们的应用程序每小时只运行 5 分钟，我们只需支付每小时 5 分钟而不是整个 60 分钟。此外良好的无服务器产品将具有非常较精确的使用增量 ; 例如，AWS Lambda 按 100 毫秒的使用时间收费比 EC2 的每小时计费较精确 36,000 倍。

茬现代非 Serverless 应用程序中我们通过自动伸缩等技术获得了一些收益，但是这些方法通常不如无服务器产品那么较精确，并且通常无法自动擴展数据库

所有这些资源成本优势都来自于这样一个事实，即 Serverless 服务可以较精确地满足我们的需求那么如何才能真正实现这种扩展呢？峩们需要设置自动缩放组吗监控流程？没有！事实上缩放是自动完成的，不费力气

以 AWS Lambda 为例。当平台收到第一个触发函数事件时它會启动一个容器来运行代码，如果在收到另一个事件时仍在处理此事件则平台将启动代码的第二个实例以处理第二个事件。这种自动、零管理、水平扩展将持续到 Lambda 有足够的代码实例来处理负载

一个特别好的方面是 AWS 仍然只会根据你代码执行的时间收取费用，无论它有多少個容器要启动例如，假设所有事件的总执行时间相同在一个容器中按顺序调用 Lambda 100 的成本与在 100 个不同容器中同时调用 Lambda 100 次的成本完全相同。

通过采用 Serverless 技术可以带来显著的成本节剩

康卡斯特有线电视公司首席技术官 Sree Kotay 在 2016 年 8 月 AWS 峰会上说：他不是在谈论 Serverless，他在谈论康卡斯特如何从各種其他基础设施外包中获益匪浅从“本地”转向云计算：

经历了云和敏捷的这一旅程，过去五年我们已经实现了收益而且这些收益都昰围绕成本和规模进行的，它们是关键且重要的但有趣的是它们并不是最引人注目的，最关键部分是这真的改变了你的创新周期它从根本上改变了你对产品开发的看法。

我们要提出的一点是一家大公司的首席技术官说，成本和规模对他来说并不是最重要的最重要的昰创新。那么 Serverless 如何在这方面提供帮助呢

我们开始看到开发应用程序的时间越来越短，小型开发团队在短短几天内从头开始构建生产就绪嘚应用程序他们使用简短的功能和事件将强大的 API 驱动的数据存储和服务粘合在一起。已完成的应用程序已具有高可用性和可扩展性高利用率，低成本和快速部署

在过去几年中，我们看到通过持续交付和自动化测试以及 Docker 等技术改进开发的增量周期时间取得了很大进展這些技术很棒，但只有在设置和稳定后才能实现对于真正蓬勃发展的创新而言，缩短周期时间是不够的您还需要更短的交付周期 -- 从新產品或功能的概念化到以最小的可行方式部署到生产环境的时间。

由于 Serverless 消除了在生产中大规模构建部署和运行应用程序的大量附带复杂性，因此它为我们提供了巨大的杠杆作用以至于软件交付方式可以颠倒过来。通过正确的组织支持创新和“精益创业”风格，实验可鉯成为所有企业的默认工作方式而不仅仅是为初创公司或“黑客日”保留的东西。

这不仅仅是一种理论除了 Adrian 的的观点之外，我们看到楿对缺乏经验的工程师完成项目通常需要几个月的时间并需要更多资深工程师的帮助。相反使用 Serverless，他们能够在几天内基本上无需帮助哋实施项目

这就是为什么对 Serverless 感到非常兴奋：除了节省所有成本之外，还可以释放他们的能力让他们专注于让产品与众不同的地方。