Serverless架构设计指南，你关心的都在这里

原文：The Comprehensive Guide to Serverless Architecture
作者：Jignesh Solanki
翻译：雁惊寒

摘要：本文详细介绍了无服务器架构及其优缺点，给正处于架构设计阶段的开发者们一个特别的设计思路。以下是译文。

“无服务器就像是个巫术！

我可没有这样说过！等一下！

上个周末，我们的一个客户，一家创业公司的CTO，告诉了我无服务器架构是如何改变他的生活的！

“我还记得曾经为某个生产系统构建一个原型是多么的艰难，持续集成和开发过程的管理不善，一个由一年前离开的实习生创建的缺陷管理系统，这个原型甚至还没做完就发布了。

但是现在，归功于无服务器的设计理念，我可以很自然地提出一个想法，然后将这个想法转移到一个可扩展的解决方案中，并付诸于商业决策，这整个过程就像是在练习一个巫术一样！”

听起来很有趣吧！但这的的确确是真的！

编写代码，然后可以在任何需要的时候进行执行！简单轻松的部署，永远都不用担心扩展问题。 你永远都不需要再管理任何东西！

它！每！次！都！能！顺！利！运！行！

你说这是巫术？不，这不是巫术，这是真实存在的！

不管怎么说，我正在无服务器系统上撰写这个介绍性的博客，这样，我就可以从中发现一些秘密以及古老的咒语，告诉那些对这个巫术感兴趣的人们！

尽管如此，无服务器将是相当长一段时间内最热门的话题之一。目前已经有很多相关的书籍、开源框架，以及多个供应商可供选择，并且还有一个专门的会议！

什么是“无服务器”，为什么你应该或不应该考虑它呢？它有什么优点和缺点？什么是FaaS？谁在使用无服务器架构？

是不是所有这些问题都出现在你的脑海里了？冷静！在这篇文章中，我将跟大家介绍这些！

准备好了吗？让我们开始吧！

什么是无服务器？

“无服务器计算不仅能从根本上改变后端计算经济，更将成为未来分布式计算的核心。”微软首席执行官Satya Nadella这么说。

即使随着云计算的兴起，这个世界仍然会围绕着服务器转。但这并不会持续太长的时间。云应用正在向无服务器的方向发展，这必将会为创建和分发软件和应用方面带来巨大的改变。

曾经的服务器时代

在云计算出现之前，服务器是开发人员在构建应用或软件时的主要部分之一。你需要一个预算、好的计划、网络、电力，以及一栋房子。你必须购买或租用服务器，准备好电源、耗材、空调、布线，然后在数据中心或托管中心搭建所有的服务器。随着时间的推移，托管机房开始提供额外的设施，如机架、电源、互联网接入等，但这还是不够。还需要大量详细的计划、时间，以及最重要的金钱。因此，转变是不可避免的！

迈入云时代

基础架构即服务（IaaS）来了！

在过去的两年里，我们的计算方式已经发生了巨大的变化，已经不仅仅是“为什么要用云”或者“如何使用云”的问题了。

IaaS为成本控制、敏捷性和可扩展性提供了完美的解决方案。由于虚拟机可以不限量的供应，以及前期不需要任何成本，开发人员只需要花一点点的功夫就能够任意选择某个操作系统来启动服务器，而且还能离线运行。

此外，总的拥有成本也将大幅降低。

我记得我曾经在第一家公司花了数百美元来购买服务器，并投入了大量的维护工作。对于第二家公司，虽然我租用这些服务器已经有好几年了，但维护工作还是相当得大。对于第三家公司，我按月租赁了服务器。对于我现在的公司，我已经能够按需租用服务器的小时数。

但是，这是从架构和价格的角度来看的。无论如何，云上的“应用/软件”这个概念正在迅速发展。它不再是指把应用搭建在网络上，这更多的是在云中构建一个低耦合的分布式系统。

用户应用程序和后端数据存储仍然是占主导地位，但是相应的处理过程则越来越多地发生在应用程序框架之外。因此，整个行业正围绕着任务和流程进行发展，而不是应用程序和服务器。

此外，计算周期的单位是秒和分，而不是小时。总之，应用正朝着无服务器的方向发展。

对无服务器的思索

在过去的14个月里，我一直都在研究无服务器技术，我可以明确的告诉你，这与我们常规构建软件/应用和部署的方式相去甚远。

但“无服务器”这个词并不意味着完全不涉及服务器。它只是说开发人员不必再为管理服务器操心。在不考虑维护的情况下，计算资源就被当做服务来使用。

无服务器可以理解为以下两点的融合：

#1. BaaS：无服务器的第一个含义是指通过第三方的服务/应用（在云上）来处理服务器端逻辑和状态。例如，一个具备云数据、认证服务等生态系统的移动应用程序。

#2. FaaS：无服务器的第二个含义是指使用第三方无状态计算容器来处理服务器端逻辑。这些容器是事件触发的，可能只持续一次性的调用，即非常短暂的。

在本文中，你会经常遇到FaaS，因为它是一种新技术，是无服务器的核心概念，它促使着我们思考技术架构的方式发生重大的变化。

但是，BaaS和FaaS又是相互关联相互重叠的。例如，Auth0最开始是BaaS的“身份验证即服务”，但Auth Webtask已经进入了FaaS领域。

FaaS：功能即服务

FaaS是构建和部署服务器软件的一种新方法，它更侧重于部署单独的功能或操作。

从FaaS你可以听到很多有关无服务器的东西。我记得我们的一位开发人员说过，事实上，无服务器就是FaaS。如果你也这么想，那么我就要纠正你，你是在管中窥豹。

不管怎么样，让我们回到什么是“功能即服务”上来？

FaaS本质上是一种事件驱动的方法。下面，我们将通过一个例子来更好地理解这句话。

当我们进行传统意义上的部署服务器端应用程序的时候，我们可以先从部署微服务开始。再进一步，我们先从部署主机实例开始，通常是虚拟机实例或容器。

然后，在主机中部署应用程序。如果主机是虚拟机或容器，那么应​​用程序就是一个操作系统进程。通常，应用程序包含了多个相关操作的代码，如下图所示。

FaaS改变了这种部署模式。我们将把注意力从模型的主机实例和应用程序进程转移到用来表示应用程序逻辑的单个操作或函数上来，并将这些功能上传到供应商提供的FaaS平台上去。

这些函数在服务器进程中并不是一直处于活动状态，而是处于空闲状态，直到需要像在传统系统中那样运行为止。

相反，FaaS平台被配置成对每个操作的特定事件进行响应。当发生该事件时，供应商平台就会启动并调用该功能来触发事件。

一旦功能执行结束，* FaaS平台就可以将其卸载*。或者，作为一个改进，它可能会保留一段时间，直到有另一个事件被处理。

正如我刚才所说的，这是一个事件驱动的方法。此外，FaaS供应商除了提供一个平台来托管和执行代码之外，还集成了各种同步（HTTP API网关）和异步（托管消息）事件源。

微服务

我相信你一定想知道微服务将如何发展。

这种“整体 -> 微服务 -> 无服务器”的转变是因为受到了更高的敏捷性和可扩展性要求的驱动。为了跟上竞争的步伐，各个机构需要快速加强自己的技术实力，最终使软件成为互相之间差异化的重要因素。

因此，微服务体系架构已经成为能向开发团队提供灵活性和其他好处的关键方法，例如，使用基础架构即服务（IaaS）和平台即服务（PaaS）环境来实现极速交付的能力。

微服务是把单个应用程序分解成更小的服务，每个服务都有自己的业务逻辑。如果采用整体架构的话，只要有一个服务出现故障就可能会导致整个应用服务器及其运行的所有服务都发生中断。

在微服务中，每个服务都在自己的容器中运行，因此，应用程序架构师可以独立开发、管理和扩展这些服务。

多个微服务可以分别的进行伸缩和部署，并使用不同的编程语言编写。但是许多机构在部署微服务架构时所面临的关键问题是需要在IaaS和PaaS之间进行选择。

微服务涉及到源代码管理、构建服务器、代码存储库、映像存储库、集群管理器、容器调度程序、动态服务发现、软件负载平衡器和云负载平衡器。它还需要一个敏捷开发和DevOps团队来支撑持续交付。

正如前面所解释的那样，FaaS在使应用程序进一步细化到功能和事件级别方面迈出了更大的步伐。因此，工作单元正变得越来越小。

我们已经从整体应用转变到微服务，然后到功能。 FaaS也优化了PaaS模型的缺陷，例如，开发和运维之间的矛盾。

扩展在PaaS上托管的微服务很复杂，很有难度。因为这种架构可能是由多种不同的编程语言编写的，可能部署在本地以及多个云环境上，可能运行在不同的容器上。

当对应用程序的需求出现增加时，所有的基础组件都必须协同起来扩展，或者确定哪些组件可以独立地扩展以解决需求激增的问题。

即使将PaaS应用程序设置为自动扩展，那么除非知道流量的趋势，否则你也不会因为个别请求而进行扩展。所以，FaaS应用程序在成本方面为用户考虑的更多。

但是，微服务和FaaS将会永远共存，因为存在一些你根本无法完成的功能。例如，API/微服务总是响应得更快，因为它可以保持与数据库或其他系统的连接，并时刻做好准备。

此外，还有一点需要注意的是，在API网关之后将多个函数组成一组，你就创建了一个微服务。这表明，这两者之间可以以一种很好的方式共存。

微服务在高层次上的流程与传统方法是一致的。关键的区别在于，对于功能来说，容器是FaaS平台根据一定的算法来创建和销毁的，运维团队无法自己控制。

但是，随着功能的简化和成本的降低，应用却越来越复杂，我们将在后面讨论这个问题。

无服务器应用程序如何工作？

无服务器可能看起来似乎非常的不错，但其实并不是那么回事。它对应用程序的架构带来了很大的变化。

而且，无服务器的发展并不是渐进的，而是存在着跳跃。 FaaS通过基本的事件驱动模型推动着一种与传统架构完全不同、部署形式更加精细的应用程序架构向前发展。

所以：

• 无服务器应用程序实际上是如何工作的？
• 无服务器架构是什么样的？
• 无服务器架构与非无服务器架构有什么不同？

这是我们要在本章中要解决的问题。下面我们将深入了解无服务器架构及其工作原理。

示例应用

我们来对这个示例应用做一些假设：

• 这是一个多用户应用程序。
• 它有一个对移动端友好的用户界面。
• 具备用户管理和认证功能。

我们忽略了一些在基本应用程序中可能会遇到的其他功能，但是这个示例的重点不是构建一个实际的应用程序，而是将无服务器应用程序架构与传统的非服务器架构进行对比。

整体架构

鉴于这些要求，整体架构的应用程序如下图所示。

• 适配iOS或Android的原生移动应用程序
• 后端是用Java和HTML编写的
• 关系型数据库

在这个架构中，移动应用程序负责处理来自用户的输入，然后它将大多数实际的逻辑委托给后端处理。从代码的角度来看，移动应用程序是轻量级的，并且非常简单。它通过HTTP报文向后端Java应用程序提供的API接口发出请求。

认证和用户管理用Java开发的。此外，它还与关系型数据库交互以存储用户数据。

为什么要改变？

你可能会说：“我这个架构非常好，也符合我所有的要求，为什么我要改用其他的呢？”

对此，我会说，我将在本节中讨论你可能涉及的多个问题和运维上的陷阱。下面我们将继续！

在构建这个应用程序的时候，你需要iOS和Java方面的实践经验。除此之外，你还需要在配置、部署和运行Java应用程序服务器以及关系型数据库方面具备丰富的经验。而且，还需要主机系统方面的经验，不管是基于容器还是直接在虚拟或物理硬件上运行？

我们还没有涉及到可扩展性、安全性或高可用性。所有这些都是现代生产系统的关键。在某个时间点，在你修复错误、增加功能或希望快速创建新构思的原型的时候，所有这些关键因素的复杂性都将成为拦路虎。

因此，你需要改变！

无服务器架构

基本应用程序的无服务器架构如下图所示。

根据这个架构示意图所示，虽然用户界面仍然是原生移动应用程序的一部分，但用户身份验证和管理将由AWS Cognito等BaaS服务处理来处理。这些服务可以直接被移动应用程序所调用来处理面向用户的任务，如注册和身份验证。

而且，其他后端组件可以使用同一个BaaS来检索用户信息。

现在，用户管理和认证由BaaS来处理，这个以前是由后端Java应用程序处理的逻辑得到了简化。你可以使用另一个非常不错的无服务器组件AWS API Gateway来处理移动应用与后端之间的HTTP请求的路由，这个组件的特点是安全而又可扩展性强。

每个不同的操作可以封装在一个功能中。诸如AWS Lambda之类的FaaS平台将这其中的每一个功能部署在并行运行“容器”中，并可以分别进行监控和扩展。

这些后端FaaS功能可以与AWS DynamoDB这样的NoSQL BaaS数据库无缝连接。事实上，这将产生一个巨大的变化，即我们将不再把任何会话状态存储在服务器端应用程序中，而是存储到NoSQL存储中。

有什么更大的优点吗？

你可能会说：“在复杂性方面，无服务器架构并没有太大的优势，而且相比我们传统的整体架构有着更复杂的应用组件”

对此，我会说：“我们现在写的代码将只专注于应用程序本身的逻辑。”另外，现在的组件是解耦的分离的，因此，我们可以非常快速地在它们之间进行切换，或者添加新的逻辑，而不会出现在非无服务器体架构中存在的问题。

扩展性、高可用性和安全性都属于无服务器架构的备份领域。这意味着随着应用程序用户规模的增长，你不必为租用功能更强大的服务器、数据库故障、排除一个防火墙配置故障而操心。

总之，劳动力成本得到了降低，运行的风险和资源成本也大大降低。各个组件都能灵活扩展。更重要的是，如果你想到一个新功能，那么开发者的交付时间也会大大减少。

很兴奋，是不是？！

下面，我们将通过无服务器架构案例研究来了解更多相关内容。

案例研究：剖析无服务器架构

PhotoVogue是2011年推出的“Vogue Italia”的一部分，它并没有准备好成为下一个白手起家的在线摄影平台。

在一年之内，该网站的人气急剧上升，而暴涨的流量压倒了这家位于意大利的公司。而且，用户体验变得毫无新意，其现存的后端限制了该网站的可扩展性。

Conde Nast Italia公司的数字开发主管Marco Vigano使用这个网站直播心内直视手术，仅仅在3个月内就被迫从本地服务器紧急迁移到AWS上。PhotoVogue快速切换到无服务器的举措避免了它因为坚守本地服务器而可能导致的倒闭。

这一趋势进一步缩短了应用发布的时间，并为Uber、口袋妖怪围棋、Airbnb，“Clash of Clans”以及众多有着大量用户群和实时数据为特征的应用提供了必要的扩展。伴随着超过400万的应用程序在苹果的App Store和Google Play Store上苦苦挣扎，开发人员正在转向无服务器架构以期望能获得竞争优势。

这个故事听起来很迷人吧，让我们来仔细看看是怎么回事！

平台

PhotoVogue是一个在线摄影平台。它是Conde Nast Italia拥有的Vogue Italia的一部分。它允许摄影师们展示他们的作品。

这也让他们有机会将自己的照片发布在Vogue上或者被摄影机构收录。每张图片都由Vogue的编辑进行筛选，以确保是最高质量的照片出现在网上。

难题

让我们来看看PhotoVogue团队面临的一些关键难题。

• 目前展示了来自世界各地的13万摄影师的照片。这个庞然大物收藏了超过40万张图片，每张图片最大不超过50MB。
• 随着需求的增长，它已无法满足用户的所有需求。此外，原有的IT基础架构限制了网站的发展。
• 已经无法再为摄影师和编辑人员提供更好更快的使用体验。

解决方案

Vigano将AWS确定为能够满足公司需求的优秀的云提供商。

• 与支撑PhotoVogue的原先就存在的物理基础架构相比，它具有可扩展性、可维护性和成本效益等方面的特点。
• 目前，该公司使用亚马逊的简单存储服务（Amazon S3）来存储所有的照片，用户能通过一个URL来快速地上传照片。

那么，他们使用FaaS了吗？或者使用某个无服务器的组件了吗？是的！

• 从Amazon S3开始，有一个AWS Lambda函数会自动将上传的图像转换为多种数字格式（例如GIF、JPEG、PNG和TIFF），并允许PhotoVogue的员工对图像进行编辑。
• Amazon API网关用作REST API的缓存层，而Amazon CloudFront则为内容分发网络（CDN）提供了便利。

优势

“在使用了Amazon API Gateway和AWS Lambda之后，使用的速度提高了90％，包括摄影师上传图片和编辑团队处理图片的速度。” 数字开发部负责人Marco Viagano说。

不仅如此，他还有更多的东西要说！

• 更快支撑资源的增长。“现在只需要几个小时就能完成原来使用传统架构需要几天才能完成的任务。IT不再是业务发展的绊脚石，实际上，我们可以成长得更快。”
• 节约成本、实现创新、增加收入。 “我们已经削减了大约30％的IT成本。我们过去花费了更多的时间来维护这些基础设施，现在已经大大减少了，因此我们可以开发新的业务。”
• 成功的活动进一步推动了在线平台的发展。 2016年11月，PhotoVogue在米兰举办了一场活动。 “在活动期间，我们的上传流量比平常增加了大约20％，我们无感知地处理了这个问题。”

哇！太棒了！

无服务器的优势

现在是时候看看无服务器带来的好处了。由于无服务器架构仍在发展之中，我们目前考虑的一些优势可能在两年后将不复存在。

降低基础设施的成本

在安装服务器之前，你需要考虑各种各样的事情，包括：

• 服务要在哪种类型的主机上运行？
• 数据库需要多少CPU和RAM？
• 为了支持扩展，需要有多少个实例？
• 是否具有高可用性？

一旦弄清楚了所有这些事情，就到了规划、分配和配置的时候了。

大多数时候，我们可能会对将来要使用的资源预估的太高，导致最终支付的资源大量浪费。

无服务器带来的巨大好处是我们无需再计划、分配或提供资源。我们可以让供应商再任何一个时间点准确地为我们提供所需的容量。

如果系统没有任何负载，则我们根本没有使用系统，因此，我们无需为此付费！就这么简单！如果只有1TB的数据，那么不需要100TB容量的存储。我们相信供应商会按需提供服务，FaaS和BaaS服务也同样如此。

例如，AWS Lambda的使用时间按100毫秒计，比EC2的小时计费的精确度高出36000倍。

灵活的伸缩性

无服务器的横向伸缩是完全自动的、弹性的、是由提供商管理的。但是，这一切是如何发生的呢？举个例子吧！

当你的平台收到第一个触发某个功能的事件时，它就会启动一个容器来运行代码。如果另一个事件在前一个事件仍在进行中时被触发，它将启动另一个容器来运行代码。平台将自动持续进行横向缩放，直到有足够的容器来运行代码为止。

非常灵活，对吧？

降低伸缩成本

这种随需付费的模式通过高可用性能帮你节约很多成本。

#1. 不频繁的请求：

如果你使用的是服务器应用程序，每隔一分钟处理2个请求，并花费100毫秒来处理每个请求。那么就是说，一个小时内你的CPU使用率是0.1％，这是非常低效的。你只能期望有其他应用程序也来使用你的服务器。

但无服务器可以提高效率，并为你降低成本。在这种情况下，你就只需支付每分钟200ms的计算时间，即总时间的0.15％。

#2. 起伏的流量：

假设你网站的流量曾经一度爆发。网站白天的流量一般大约是10个请求/秒。但是某次突然增加了10倍，达到100个请求/秒。每5分钟，持续10秒。

假设在忙时你的服务器耗尽了，但同时你又不想降低响应时间。有什么解决方案呢？我有。

如果你的系统是在传统环境中运行，则可能需要将硬件升级10倍，以处理突然增加的流量。

自动伸缩在这里并不是一个很好的选择，因为它无法预测服务器的新实例启动所花费的时间，而且当这些服务器准备独就绪时，流量峰值可能就快结束了。

然而，这对于无服务器来说似乎并不是一个问题。无论流量是平稳的还是有波峰，你都无需做任何事情。你所要做的就是在高峰处支付额外的计算能力。因此，这对你的公司来说节约了一笔巨大的成本。

可是，等等！只有在流量有巨大波动的情况下，你才能获得显著的经济效益。如果流量稳定，而且使用的是FaaS，那么你最终可能会支出的更多。

轻松的运维管理

#1. 自动伸缩的优点

假设你是手动来管理应用服务器的，那么你需要一个特定的人来添加和删除服务器阵列中的一个实例。而对于FaaS来说，你不必担心，因为供应商会替你做这些事情。

此外，这可以让你不必担心在内存消耗完之前你可以处理多少个并发请求。

#2. 降低部署复杂度

打包和部署API网关并不简单，这个我承认！但是，与部署整个服务器相比，FaaS功能算是非常简单的了。如果你刚开始使用FaaS，那么只需要在代码编写器中编写代码，然后就可以开始运行了！

降低失败的风险

当团队在管理多个系统和组件时，出现问题的可能性会大大增加。但是，无服务器的情况并非如此。对于无服务器来说，你把管理和运维外包了出去，同时还将这些系统出问题时的解决方案外包了出去。

这会带来额外的好处，因为你能依靠别人的专业知识来解决不可预知的问题，而不是自己闷头解决问题。出现问题时，我们可能并不知道如何解决，从而导致长时间并且不确定的停机。

对于无服务器的来说，你直接管理的次数将大大减少。而且，你处理的是日常经常用到的那些操作，这样更容易处理。

因此，在你使用无服务器的时候，失败的几率会少很多。

无服务器的缺点

固有的缺点

#1. 服务供应商问题：

无服务器意味着将你的服务外包给第三方供应商，这意味着你无法控制系统的停机时间、API的强制升级升级，以及功能的确实等许多关键问题。这是无服务器应用程序要面临的固有限制。

如果你想从一个供应商转移到另一个供应商，就需要更新所有的操作工具，修改代码，甚至可能需要改变架构。这是无服务器的最重要的缺点之一。

#2. 无状态：

这是一个很好的优点，并发方面扩展起来很轻松，但管理起来相当棘手。此外，还存在性能不一致的缺点，后面我们会讨论这个。

除了设计用于存储数据的组件之外，大多数的无服务器组件是无状态的。因此，当我们需要考虑这些组件与另一个组件之间的交互时，就会产生一定的复杂性。

#3. 本地测试：

这是无服务器应用程序架构中最令人头痛的难题之一。对于非无服务器应用程序，开发人员可以在本地测试应用程序。但是，对于无服务器架构来说，应用程序的端对端测试相当困难。

因为目前大多数供应商都没有提供本地的实现，这意味着只能远程测试所有的集成组件。

#4. 安全性：

一旦你考虑使用无服务器的架构，就会遇到全新的安全问题，可以归纳为以下几点：

• 对于无服务器来说，数据在各种功能模块之间传输。每次我们将数据从一个地方传输到另一个地方时，由于传输路径的增加，数据泄漏和篡改的机会也跟着增加。
• 随着灵活性的提高，攻击者侵入系统的概率也越高。解决这个问题唯一的方法就是用自己的安全协议来处理每个功能。

总结

本文的目的是为了让大家知道什么是无服务器、无服务器有什么优缺点。但我相信，所有渴望拥抱和尝试新技术的开发者都会爱上这个架构！

尽管无服务器架构可能不会成为解决所有问题的完美解决方案，但它肯定会减少现存的问题。但在你陷入无服务器和FaaS的世界之前也需要小心谨慎。

从商业的角度来看，我所能看到的最好的好处就是缩短了新功能发布的时间，这是当今世界新技术发布最关键的一点。

无服务器系统尚处于起步阶段，看到它如何解决和适应我们的架构需求将是一件非常美妙的事情。