Serverless五大优点，成本和规模不是最重要的，这点才是

导读：近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is Serverless》一书的部份内容，能够说是对Serverless科普与观察的上佳素材。
在了解了何为Serverless，各类服务组件以后，如何将服务组件组合成完整的应用程序？ 基于Serverless开发的应用架构什么样子？与传统非Serverless应用程序架构相比，Serverless有哪些优点？本文将回答这些问题。
原著：
《What is serverless : understand the latest advances in cloud and service-based architecture》
做者：Mike Roberts & John Chapin
译文来源：深刻浅出谈架构（ID：deep-easy-arch）
译者：灵雀云邵明岐
假设有这么一个应用程序，它是一个支持多用户的手机游戏，具备如下高级要求：
友好的移动端交互界面
具有用户管理和身份验证
有一些基本的业务逻辑，好比游戏排行榜，历史记录等
咱们暂时忽略游戏中可能会遇到的其余功能，毕竟咱们的目的不是实际开发一个游戏，而是将Serverless程序架构与传统的非serverless架构进行比较。

传统非Serverless架构

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

Native Mobile App 是iOS或者安卓客户端。
Java Application Server是Java代码编写的应用逻辑，运行在Tomcat或者JBoss这类应用服务器里面。
数据存储在关系型数据库，好比Mysql里面。
在这个架构中，移动应用程序负责呈现游戏界面并处理来自用户的输入，但它将大多数实际逻辑删除到后端，从代码的角度来看，移动应用程序简单轻便，它使用HTTP调用后端Java应用程序提供的不一样API。
用户管理、身份验证和各类游戏操做都使用Java应用程序代码进行封装， 后端应用程序还与单个关系数据库交互，以便维护正在进行的游戏的状态，并存储已完成游戏的结果。

为何要改变架构？

这个简单的架构彷佛符合咱们的要求，那么为何对它作改进呢？ 关键在于将来开发和运维方面带来的一系列潜在的挑战和陷阱。

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

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

如何改变？

如今已经发现了传统架构的一些挑战，如何改变它？ 让咱们看看如何可以知足高级需求，并使用Serverless架构模式和组件来解决传统方法的一些挑战。
在以前的文章已经说过了，Serverless组件能够分为两类，BaaS和FaaS。 考虑到游戏的要求，其中一些能够经过BaaS组件解决，一些能够经过FaaS组件解决。

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

虽然用户界面还是移动应用程序的一部分，须要本身经过代码来实现，但用户身份验证和管理可由AWS Cognito等BaaS服务处理，这些服务能够直接从移动应用程序调用，以处理注册和身份验证等面向用户的功能，其余后端组件可使用相同的BaaS来检索用户信息。
如今由BaaS处理用户管理和身份验证，后端Java应用程序的逻辑被简化了， 可使用另外一个组件AWS API Gateway，以安全、可扩展的方式来处理移动应用程序和后端游戏逻辑之间的HTTP请求。 而后能够将每一个不一样功能的操做封装在FaaS函数中。

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

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

Serverless架构优点

这种新的Serverless架构看起来很复杂，并且它比传统架构须要更多的组件，可是，因为咱们使用彻底托管的Serverless组件，已经消灭了不少由于管理应用程序基础设施和底层系统而带来的挑战。

咱们编写的代码如今几乎彻底集中在游戏独特的业务逻辑上，更重要的是，组件已经解耦和分离，所以，能够很是快速地将它们切换出来或添加新逻辑，而不会出现非无服务器架构中固有的阻力。

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

简而言之，咱们下降了制做游戏的人工成本，以及运行游戏的风险和计算成本，它的全部组成部分都将灵活扩展。 当咱们有一些新的想法，交付期会大大缩短，能够开始得到反馈并更快迭代。

云计算的基础设施外包带来五大好处：下降人工成本、下降风险、下降基础设施成本、扩展性、交付时间 。Serverless 一样也有这五大优势， 前四个都或多或少是关于成本节约的，这就是Serverless最为人所知的：如何以更低的成本作之前作过的一样的事情。可是，对咱们来讲，节省成本并非无服务器最使人兴奋的部分，最大的好处是，它减小了重新的想法到实施上线的时间，换句话说，它可以让你更快地创新。

下降人工成本

咱们在以前说过，Serverless本质上再也不须要关心本身的服务器和进程 ，只须要关心应用程序的业务逻辑和状态，全部其余没必要要的工做都交给平台来处理。这里的第一个明显好处是运维工做量减小， 您再也不管理操做系统，补丁级别，数据库版本升级等。若是您正在使用BaaS数据库，消息总线或对象存储，那么祝贺你，这些基础架构也都不要你来运维。

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

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

使用FaaS进行部署更容易，由于咱们只是上传打包成Zip格式(若是是 JS或者Python脚本语言)的基本代码，或者若是是Java的话，则上传普通的JAR文件，没有要管理的Puppet，Chef，Ansible或Docker配置。其余类型的操做活动也变得更加简单，例如，因为再也不关注“永远在线”服务器进程，所以能够将监控限制为更多面向应用程序的指标。 这些是统计信息，例如执行持续时间和面向客户的指标，而不是可用磁盘空间或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，他在谈论康卡斯特如何从各类其余基础设施外包中获益匪浅，从“本地”转向云计算：

经历了云和敏捷的这一旅程，过去五年咱们已经实现了收益，并且这些收益都是围绕成本和规模进行的，它们是关键且重要的，但有趣的是它们并非最引人注目的，最关键部分是这真的改变了你的创新周期，它从根本上改变了你对产品开发的见解。
Sot Kotay
复制代码咱们要提出的一点是，一家大公司的首席技术官说，成本和规模对他来讲并非最重要的，最重要的是创新。 那么Serverless如何在这方面提供帮助呢？
Adrian Cockcroft（AWS云架构战略副总裁，Netflix前云架构师）谈到：

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

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

因为Serverless消除了在生产中大规模构建，部署和运行应用程序的大量附带复杂性，所以它为咱们提供了巨大的杠杆做用，以致于软件交付方式能够颠倒过来。经过正确的组织支持，创新和“精益创业”风格，实验能够成为全部企业的默认工做方式，而不只仅是为初创公司或“黑客日”保留的东西。
这不只仅是一种理论。 除了Adrian的的观点以外，咱们看到相对缺少经验的工程师完成项目一般须要几个月的时间，并须要更多资深工程师的帮助。 相反，使用Serverless，他们可以在几天内基本上无需帮助地实施项目。

这就是为何对Serverless感到很是兴奋：除了节省全部成本以外，还能够释放他们的能力，让他们专一于让产品不同凡响的地方。