« 上一篇下一篇 »

什么是无服务器架构?无服务器架构如何实现

  Gartner最近的一份报告表明,到2020年,全球将有20%的企业部署无服务器架构。这说明无服务器架构不只是一个流行语,而是一种众所周知的云计算趋势,并且已经在软件世界掀起一场革命。大型厂商(如亚马逊、微软和谷歌)已经在无服务器架构领域重资投入,追赶革命的浪潮。与其名字相反,无服务器架构实际上并没有把服务器去掉。那么,究竟什么是无服务器架构?

什么是无服务器架构?
   无服务器架构是指应用程序使用第三方Function和服务,但不需要管理服务器。无服务器架构主要包含了两个方面:

 FaaS(Function as a Service,Function即服务):包含服务器端业务逻辑的无状态Function。这些Function运行在独立的容器里,基于事件驱动,并由第三方厂商托管,如AWS Lambda或者Azure Functions。
 
 BaaS(Backend as a Service,后端即服务):使用第三方服务(如Firebase、Auth0)来达成目的。使用BaaS的应用程序通常是富客户端应用程序,如SPA或移动App。客户端负责处理大部分的业务逻辑,其他部分则依赖外部服务,如认证、数据库、用户管理,等等。
 
无服务器架构包含了BaaS和FaaS,不过这篇文章着重关注FaaS。

无服务器架构的特点
不需要管理服务器;
无状态;
自动伸缩;
没有运营成本;
成本由事件驱动;
处理第一个事件需要一些启动时间;
因为运行时小,所以具有较高的安全性。
无服务器的生命周期
下图描述了一个Function的生命周期。


无服务器应用程序架构示例
假设有一个简单的线上汽车拍卖应用程序,用户可以登录并出价,拍卖时间结束时价高者得。

传统上,架构里会包含一个部署了应用程序和前端的单体服务器。


上述架构采用的是瘦客户端方式,所有的业务逻辑(如认证、回话管理、车辆管理等)都部署在服务器端。

那么,在一个无状态的微服务架构中,这个应用程序又会是什么样子?


原来的单体应用程序被拆分成了多个服务器端组件。

认证Function:这是一个用于管理用户认证(登录)的Function(Function,FaaS)。
车辆管理服务:一个处理与车辆相关操作的微服务,如列出车辆、查看车辆信息、比较车辆,等等。这个服务可以使用任意的语言或框架来开发,它与数据库通信,并且独立运行。
车辆出价Function:这是另外一个Function,也与数据库通信,录入用户出价记录。
API网关:所有服务的入口点和反向代理。来自客户端的请求会先到达网关,网关根据路由规则将请求重定向到特定的服务。
在将服务拆分成微服务或FaaS时,需要考虑到业务逻辑、负载、规模等方面的因素。

上述的例子描述了无服务器架构和基于无服务器架构设计微服务时的大致过程。

 

无服务器架构与PaaS
平台即服务(Platform as a Service)是另一个不需要开发人员管理服务器(包括硬件和软件)的架构莫斯。正因为如此,开发人员容易把无服务器架构和PaaS混为一谈。接下来,我们来看一看它们之间的相似点和不同点。

相似点
开发人员不需要管理服务器。
开发人员只要关注应用程序代码本身。

无服Web应用
在传统Web应用中,服务器是系统不可缺少的组成部分。尽管有时候服务器的前面还有负载均衡器或者专用Web服务器,但完成大部分工作的还是应用服务器。它完成一个应用所有的必要功能,包括存储用户数据、进行安全认证、控制流程等。应用的页面大部分仅仅只是为后端提供界面而已,尽管也会涉及一些控制导航的功能。使用这种许多人称之为多层架构的传统方式,系统一般会由浏览器、应用服务器和多个后端服务构成(见下图)。

使用无服的方式,可以移除所有这些层次架构,达到更直接的实现。与其仅仅把网页客户端当作应用服务器的界面展示,不如构建一个单页Web应用在浏览器中实现应用逻辑。这意味着你只需要一个简单的静态网页服务器,所有的交互都只不过是应用内容的传输而已,浏览器就像是一个应用容器。这样,最终的设计就是移除传统Web应用架构中所有的中间层次,允许浏览器直接连接到它所需要的服务上。
使用Facebook、Google和Twitter之类的OAuth 2.0身份认证服务商提供的服务,无须保存用户密码就可以创建用户身份。如果要存储数据,你可以在浏览器端直接使用Amazon DynamoDB之类的服务。在浏览器中无法执行的函数都可以使用Amazon Lambda微服务或者其他专门的Web服务来处理。除了能够简化架构,这种切换到Web服务作为后端的方式,还能让应用获得这些服务与生俱来的可用性和可扩展性优势。
你可能会好奇到底发生了什么,使这种方式成为可能。为什么现在在一个Web应用中,中间层的应用服务器变得可有可无呢?答案是,自从2015年以来,类似Amazon这样的云服务提供商开始对外提供服务的API,这使得无服务器的方式成为可能,Amazon本身也为如何使用他们的工具和基础设施提供了最好的示范。
基于Web标准搭建一个单页Web应用,而不是使用服务器端Web框架来完成,我们可以快速应用一些新兴技术。例如,我们不再需要将应用的数据模型绑定到任何一个对象层级或者数据同步机制上,因而能更方便地集成不同服务。既然我们所有的工作都倚赖于Web,就不必拘泥于以前搭建Web应用的成见,可以用目前最新的技术来搭建应用(见下图)。

无服设计的好处
如果你在寻找一种快速搭建低成本Web应用的方法,无服Web应用很可能就是一个解决方案。不需要花费时间和精力了解传统Web应用技术栈的各个层级,采用这种方式你能更专注于实现业务功能,有人会为你操心运行维护和可扩展性的问题。接下来让我们深入探讨无服设计的好处,帮助你在考虑下一个项目中是否使用这种方式时做出更明智的决定。
零服务器
无服设计最明显的好处就是不需要维护服务器(不管是物理的还是虚拟的)。你不需要担心打安全补丁、监控CPU和内存使用情况、回滚日志、磁盘空间不足或者其他在维护自有服务器时经常碰到的运维问题。和大多数平台即服务(PaaS)方式一样,无服设计能让你专注于应用开发,而无须担心基础设施的问题。
易扩展
这种设计方式的另一大好处是,你可以依靠云服务供应商来扩展自己的应用。在做水平扩容时,不需要忙不颠地在几个负载均衡应用服务器之间保持数据的一致性,你可以直接连接Web服务,而它们已经解决了数据一致性的问题。这意味着不管你的应用有几个用户、几百个用户,还是几十万个用户,只需要修改Amazon Web Services控制台的一些设置就可以保证完美的运行。
高可用
另外,使用这种设计能轻松实现高可用性。你不必为了升级而关闭应用服务器,或者为了实现“热”部署而扩建基础设施。不再会有服务的重启或者部署包在服务器间的拷贝。最妙的是,Amazon有一群训练有素的员工7×24小时守护着你的基础设施,一旦发现问题随时能够响应。
低成本
这些服务的成本可以非常低。使用无服的方式以及利用Amazon的免费套餐(Free Tier),一个月支付几美分就可以运行你的应用。一旦超过了免费额度,其费用经常也是随着你的用户量线性增长的(考虑费用最高的情况)。我们在这本书里构建的应用就算扩展到100万的用户,一天也只需要花费一杯咖啡的钱。
(微)服务友好
这种方式可以轻松适应微服务或者其他的面向服务架构。你可以在系统中引入特定的服务以实现自定义身份认证、验证或者异步数据处理。如果有必要,你甚至可以重新引入应用服务器,渐进式地重构应用。反之,如果一开始就使用一个中间层来控制所有的安全证书,就很难切换到需要认证的Web服务上。这些应用服务器没办法像无服应用一样,在应用层管理身份信息。
代码更少
在传统Web应用里,一些操作(比如导航)在Web客户端和服务器端都需要执行,造成了代码的重复。有时候,这种重复工作并不明显,尤其当服务器代码是用不同的语言写时。而在无服应用中,应用逻辑都移到了客户端,很容易保证应用内不再有重复的代码。将应用逻辑代码放在一个位置(以及用一种语言实现)帮助我们解决了这个问题。
此外,无服的方式更便于构建和排错,因为系统的组成部分变得更少了。Web应用天生就是分布式的,也就是说,正如CAP理论所述 ,它们在同一个网络的节点间传递消息(一般是以请求和响应的形式),限制它们的是实现方式。
有些应用会比其他应用更分散(more distributed)。一个系统越分散,就越难排错。移除应用中的中间层能减少其分散的程度。在我们这个简单的应用中,如果一个客户端需要从一个数据库中获取数据,就会直接连接数据库,而不是通过中间层连接。这就意味着系统中的网络节点更少,也意味着如果出现问题,需要定位的地方更少。
如上所述,构建一个无服应用的理由有很多。学完本书,你就会明白为什么这种方式如此强大。了解了无服应用的这些优点,我们再来看看它有哪些限制。
无服设计的限制
尽管无服架构有许多优点,但它也不是适用于所有类型的应用。为了享受这种设计带来的益处,你必须接受一系列的限制。如果你的应用不能适应这些限制,那么它很可能不是最合适的构建方式。所以在搭建应用之前,让我们一起看看这些限制。
供应商锁定
首先最大的限制就是你使用的Web服务必须支持第三方身份认证服务商,这样在云服务提供商的选择上就受到了限制。所以如果使用无服的方式,你就会依赖于第三方服务,供应商锁定也就成了一个问题。构建一个基于其他公司服务的系统,意味着这个应用的命运和供应商公司的命运绑在了一起。如果供应商公司被收购、破产或者改变商业模式,你的应用不下大力气修改就很难在其他地方运行。所以,评估服务提供商的业务目标和长期稳定性与技术选型是同样重要的。
奇怪的日志
所有运维关注的事情,比如应用日志,在你使用无服设计之后会呈现新的形态。当你把所有请求都通过一台服务器路由时,记录下所有信息以查看用户正在做什么是非常简单的事情。没有了这种中心化设计,日志的记录必须由每个支撑应用的不同Web服务来实现。这些日志格式跟大部分应用服务器日志都不同,记录的数据也很可能是你不熟悉的。我们在后面第8章的“分析S3日志”会深入探讨Web服务日志的分析。
不一样的安全模型
对于无服应用,有些常见的安全隐患不复存在,但你将会遇到一些不熟悉的新问题。比如,为了安全而验证用户数据,结果不能在浏览器中安全地实现。你需要假设有些恶意用户可能会在浏览器中劫持证书而使用该证书授权的Web服务。使用无服的方式,意味着你不能把浏览器中的应用验证逻辑和安全验证逻辑放在一起,必须分开实现。
Amazon提供的许多Web服务都能验证请求。你可以参考第5章的“数据访问和验证”一节内容利用DynamoDB来实现。然而,对于有些应用来说,很难只用Web服务提供的工具来实现充分的有效性约束。比如,在浏览器中直接编写文本时,你不可能放心地将写入的数据编码后存到数据库中,保证不会有跨站脚本攻击发生。因为攻击者不使用应用就能直接将这个数据添加到数据库。
这种情况下,你有(至少)两个选择。第一,可以假设某些用户可编辑的表可能包含未经验证的数据,然后针对性地设计系统的其他部分。比如,用户只能写入他们自己可读取的数据,这是可行的方式。第二,可以将某些写操作委托给自定义Web服务,比如可以使用Lambda函数来进行验证,并且以一种安全的方式写入数据。我们将会在第6章的“使用Lambda构建微服务”中详细介绍。
不一样的身份模型
外部身份管理是我们这本书构建的应用中的一个独特功能。使用Web服务来管理身份信息有很多好处,但对你来说这种机制可能有点陌生。与将用户信息和其他数据保存在一起的传统方式不同,这些用户资料会保存在一个独立访问的数据存储服务中。如果使用这种方式构建无服应用,一些在数据库中处理用户数据的方法(比如用一个ID关联一张User表)就没办法实现。
失去控制
此外,将所有请求路由到统一的中间层可以实现某种程度的控制,这在某些情况下是非常有用的。比如,拒绝访问攻击和其他一些攻击有时候可以在应用服务器上进行阻截。对你而言,放弃对身份认证的直接控制可能想一想都觉得可怕。我们后面在第7章会用一整章来专门探讨这些安全问题。
规模与成本的关系
最后,你需要了解这些服务的开销。虽然能够自动扩展应用这一点非常厉害,但易于扩展同时也意味着花钱更容易。你需要了解这些服务的定价策略以及当用户增加时这些价格的变化。我们后面会在第8章中深入讨论应用的成本。
既然你已经了解了无服Web应用的代价,我们可以开启这本教程,探索一下无服Web应用是如何实现的。在教程中,你可能会发现这种设计方式为你开发的Web应用带来的其他好处和限制。一旦知晓了无服应用的全貌,就可以判断下一个项目是否适合这种方式了。
使用自己的工作空间
为了学习无服Web应用的知识,我们将在本书中搭建一个Java编程解题应用作为示例,名字叫LearnJS。它会向用户展示一些简单的编程题,然后让他们用Java作答,并按下按钮检查答案是否正确。这个应用的样子如下图所示。

我们将会从后往前搭建这个应用。本章我们将会部署它,然后测试,再加入一些应用逻辑。在那之后,我们再来思考架构设计。
如果你对现代开发者们拥护的这种迭代增量式开发风格不熟悉(我本来想把它叫作敏捷开发,但是它和敏捷的涵义还有所不同),这套流程看起来是完全错误的。还没有构建好应用我们怎么部署呢?还不知道要让应用做什么,怎么先写自动化测试呢?还有,我们是不是应该在动手之前先考虑一下架构设计呢?
如果你对此有疑问,没关系,我们将会一步步实现这个流程。一旦完成之后,你将会理解,甚至是赞同这种方式。不仅因为它是学习新技术的绝佳途径,而且也是构建软件的有效方法:前进一小步,评估当前状态,不断重复此过程,直到客户满意。


不同点
PaaS提供了更为可控的部署方式,而无服务器的部署则更为严格。
无服务器架构可以自动伸缩,而PaaS的伸缩需要进行配置。
无服务器架构的成本是由事件驱动的,而PaaS是固定的。
PaaS应用程序在部署之后会一直运行,并马上开始处理请求,而无服务器需要等待第一个事件,具体取决于事件的发生频率。
用例
无服务器的应用应该不仅限于某个领域、业务或架构。在进行应用程序架构时,你需要考虑多个因素,这些因素同样适用于无服务器架构。

成本——无服务器架构非常节约成本,具体取决于实际的负载。
服务器管理——无服务器架构可以极大地降低用于管理服务器的运营成本。
伸缩——无服务器架构可以自动伸缩。
响应时间——FaaS需要一些初始化时间。如果负载很小(比如一个小时只有一个事件),每个请求都会经历冷启动,导致整体响应变慢。
更快的发布周期——因为这些Function都是很小的单位,发布周期就变得很短。


以下是一些常见的用例

Web应用程序;
批处理和调度;
移动和IOT后端;
聊天机器人。
为什么要采用无服务器架构?
使用无服务器架构和FaaS有以下这些好处。

减少服务器管理成本;
减少运营成本;
自动伸缩;
比不间断运行的服务更安全;
成本由请求或事件数来决定;
更简单的打包和部署流程;
缩短发布周期;
开箱即用的监控。
无服务器架构的限制
与其他任何一种技术架构一样,无服务器架构也存在同样的限制。

启动延迟;
厂商锁定,对服务器缺乏控制;
性能优化局限于代码内部;
执行时间限制(AWS Lambda的执行时间限制为15分钟);
成本不可预测;
开发环境和生产环境不一样;
测试和调试更为复杂。


总结
无服务器架构是一种架构风格,通过FaaS将业务逻辑从长期运行的组件中移到临时的Function里。它可以解决很多架构和运营问题,简化开发者和运维人员的工作。

与其他解决方案一样,无服务器架构并不是银弹。它无法直接取代现有的组件,在决定是否要采用无服务器架构之前需要先分析一下自己的业务和技术需求,通盘考虑各种优点和缺点。