亚马逊云服务AWS上的Serverless架构技术优缺点详细介绍 以及如何构建无服务器应用程序

   07/03/2016 5:43 pm   大 中 小 简体 繁體 字体:
1 颗星2 颗星3 颗星4 颗星5 颗星 Rating: 5.00/5, 1 votes
    760人参与

如果你问软件开发人员何谓软件架构,可能会得到五花八门的答案:软件架构“是蓝图或计划”、“概念模型”或“大局”,不一而足。毫无疑问,架构或缺少架构关系到软件的成败。良好的架构有助于扩展Web或移动应用程序,而糟糕的架构可能导致严重问题,势必需要重写、花费高昂成本。了解架构方面的选择带来的影响,并且能够提前规划,这对于构建高效、高性能、最终成功的软件系统来说极为重要。

利用无服务器架构,您无需管理基础设施即可构建和运行应用程序及服务。您的应用程序仍在服务器上运行,但所有服务器管理工作均由 AWS 来完成。您无需再预置、扩展和维护服务器即可运行您的应用程序、数据库和存储系统。

Serverless架构或Serverless计算是软件架构风格向分布式系统发展结果,而当前建立一个系统的标准是面向服务架构(SOA)或者是SOA之微服务架构。

在微服务架构中,应用/服务被开发出来然后部署,每个服务组相关一些函数,在Serverless架构中,函数是被开发并部署到独立的平台,这个平台会照顾执行这些函数响应一些事件,举例:当有HTTP请求访问时,也许有一个函数计算计算出一个响应结果,或当一些东西写入到数据库式,会有一个专门函数来执行。

乍一看,这就让人想起了传统的存储过程,与存储过程相反,Serverless架构中的函数不仅仅限制于数据库操作事件,每个函数能够被不同编程语言实现,更远,也没有保证同样函数总是在同一个服务器上运行。

下面看看Serverless的目标和优缺点权衡。

低运营成本
微服务架构中的服务需要一直运行,实际上,在高负载情况下每个服务都不止一个实例,这样才能完成高可用性,在Serverless架构中则是没有事件发生时不会有服务运行,主机平台会只有在需要时才会执行相应的函数,按照云计算pay-as-you-go原则,如果没有东西运行,你就不必付款。

在Serverless架构中,扩展和自动扩展是没有问题的,当负载增加,会让受影响的函数以并行方式运行得更频繁。

弹性配置也在Serverless架构中很有效率,对于传统的云计算环境你会说:
“我愿意买3G内存,然后以后暂时就不需要再扩展了”。
而现在你会说:
“我会为X类型的30000个事件付费,为Y类型的5000个事件付费,然后以后暂时就不需要再扩展了”。

很明显,Serverless计算针对资源的使用是有效率的,特别具有运营的可操作性。

厂商锁定

平台会提供Serverless架构给大玩家,比如AWS Lambda,运行它需要使用AWS指定的服务,比如API网关,DynamoDB,S3等等,一旦你在这些服务上开发一个复杂系统,你会粘牢AWS,以后只好任由他们涨价定价了。

复杂性和低聚合

多少年来,软件工程师为高聚合和低复杂性奋斗,领域驱动设计和微服务是完美的配合,因为他们总结过去多少年的软件工程经验。

如果开发者忽视这些经验教训是会有风险的,特别是在构建Serverless架构时,它们会遭遇不可维护的函数地狱,在这个情况下,低运营成本优势也许会被更高维护成本超过。

这篇文章阐述了为什么我们认为,无服务器架构对软件开发人员和解决方案架构师来说是改变行业规则的技术。它介绍了AWS Lambda之类的关键服务,还介绍了无服务器架构的几个原则,帮助你了解什么造就真正的无服务器系统。

名称中有什么?

在我们开始探讨正文之前,应该提到无服务器这个词有点用词不当。无论你使用AWS Lambda之类的计算服务来执行代码还是与API进行交互,仍然有服务器在后台运行。区别在于,这些服务器隐藏起来,我们是看不见的。我们不需要考虑基础设施,也无法调整/改动底层操作系统。别人负责基础设施管理的基本细节,那样我们可以腾出时间处理其他事情。无服务器技术是指,在计算服务中运行代码,并与服务和API进行交互,以完成任务。

我们如何走到今天这一步?

如果你看一看支持如今大多数具有Web功能的软件的系统,就会发现后端服务器执行各种各样的计算任务,而客户端前端为用户提供界面,以便通过浏览器、移动设备或桌面设备进行操作。

在一个典型的Web应用程序中,服务器接受来自前端的HTTP请求,处理请求。数据在保存到数据库之前可能经过无数个应用层次。最后,后端生成响应――可能采用JSON或完全呈现的标记这种形式,响应被发回给客户端(图1)。当然,一旦将其他元素考虑进来,比如负载均衡、事务、集群、缓存、消息传递和数据冗余,大多数系统比较复杂。大多数这种软件需要服务器在数据中心或在云端运行,这些服务器需要加以管理、维护、打补丁和备份起来。

亚马逊云服务AWS上的Serverless架构

亚马逊云服务AWS上的Serverless架构图1:这是一种基本的请求/响应(客户端/服务器)消息交换模式,大多数开发人员对此很熟悉。该图中只有一台Web服务器和一个数据库。大多数系统要复杂得多。

服务器的配置、管理和打补丁是一项很耗费时间的任务,常常需要专门的操作人员。很难搭建并高效地运行一个重大的环境。基础设施和硬件是任何IT系统的必要组成部分,但它们也常常让人容易分心,忽视最重要的事情:解决业务问题。

过去这几年出现了平台即服务(PaaS)和容器等技术,这些解决方案有望解决这个头痛的问题:基础设施环境不一致、冲突和服务器管理开销。PaaS是一种云计算,它为用户提供了运行软件的平台,同时把一部分底层基础设施隐藏起来。为了有效地使用PaaS,开发人员需要编写针对该平台相应功能特性的软件。由于大多数PaaS实现方法具有短暂性,把当初被设计成在独立服务器上运行的老式应用程序迁移到PaaS服务,需要额外的开发工作。不过,如果面临选择,许多开发人员会决定使用PaaS,而不是更传统、更手动化的解决方案,那是由于PaaS减少了维护和平台支持方面的要求,这可以理解。

容器化是一种隔离应用程序的方法,让应用程序有自己的环境。这种轻量级方法可替代全面的虚拟化。容器是孤立的、轻量级的,但它们需要部署到服务器上,无论在公共云上、在私有云中还是在现场。如果依赖关系明确,容器是一种出色的解决方案,不过它们在内务处理(housekeeping)方面有各自的挑战和复杂性。它们并不是与仅仅能够直接在云端运行代码来得一样容易。

最后,我们迎来了Lambda,这是亚马逊网络服务(AWS)提供的一种计算服务。Lambda能够以一种大规模并行方式执行代码,以响应事件。Lambda拿来你的代码后即可运行,根本不需要配置服务器、安装软件、部署容器,或者是为低层细节而操心。AWS负责配置和管理运行实际代码的弹性计算云(EC2)服务器,并提供开发人员不需要考虑的一套高可用性计算基础设施,包括容量配置和自动扩展机制。无服务器架构这个词是指这些新型的软件架构:不需要直接访问服务器就能运行。通过采用Lambda,并充分利用各种功能强大的单一用途的API和Web服务,开发人员就可以迅速构建松散耦合、可扩展、高效的架构。无服务器架构的最终目的就是,远离服务器和基础设施方面的问题,让开发人员可以主要专注于代码。

面向服务的架构和微服务

在许多不同的系统和应用程序架构当中,面向服务的架构(SOA)在软件开发人员当中具有很高的知名度。这种架构清楚地使这个想法概念化:系统可以由许多独立的服务组成。SOA方面的文章已写了不少,可是由于开发人员常常把设计理念与具体的实施和属性混为一谈,所以它仍存在争议和误解。

SOA没有硬性规定使用任何特定的技术。相反,它鼓励这样一种架构方法:开发人员创建自治服务,这些服务通过消息传递来进行联系,常常有一种模式(schema)或契约(contract),定义了消息是如何创建或交换的。服务的可重用性、自主性、可组合性、细粒度和可发现性,这些都是与SOA有关的重要原则。

微服务和无服务器架构在核心思想上与面向服务的架构一脉相承。它们保留了许多上述原则和理念,同时试图消除老式的面向服务架构具有的复杂性。

最近出现的一股趋势是,使用微服务架构来实施系统。开发人员往往把微服务考虑成小型、单独、完全独立的服务,它们围绕一个特定的业务用途或功能而建。微服务可能有一个应用程序层,有自己的API和数据库。

理想情况下,微服务应该易于替换,每个服务用一种适当的框架和语言编写而成。微服务可以用不同的通用语言或特定领域语言(DSL)来编写,光这一点就让许多开发人员为之着迷。虽然可以通过使用合适的语言或针对相应任务的一套专用库来获得一些好处,但这也常常是个陷阱。如果拥有多种语言和框架,支持起来有难度;要是没有一套严格的准则,会在将来导致混淆和困难。

每个微服务可能保持其状态、存储数据,这增加了系统的复杂性。一致性和协调性管理也可能成为一个问题,因为状态必须常常跨不同的服务来加以同步。微服务可以通过消息总线间接联系,也可以通过将消息发给对方来直接联系。

可以说,无服务器架构同样体现了来自微服务的许多原则。毕竟,每个计算函数都可以被认为是其自己的独立服务,这取决于你如何设计系统。然而,你不需要完全接受微服务口号,就可以围绕某个特定的业务用途来开发每个函数或服务,保持状态,等等。

无服务器架构的好处在于,你想运用几个微服务原则,就可以随意运用几个,不会迫使你只有华山一条道。

软件设计

软件设计已从昔日代码在大型机上运行,变成如今在多层系统上运行:在许多设计中,表示层、数据层和应用/逻辑层具有重要地位。在每层里面,可能有多个逻辑层次处理某一功能或领域的特定方面。还有可能跨众多层次的横切组件(cross-cutting component),比如日志或异常处理系统。青睐分层可以理解。分层让开发人员得以将关注点分离开来,开发出更易维护的应用程序。

但是,反过来也可能如此。层次太多可能导致效率低下。一个小小的变化常常带来连锁反应,导致开发人员修改整个系统中的每个层次,把大量的时间和精力花费在实施和测试上。层次数量越多,久而久之系统会变得越复杂、越笨拙。图2显示了具有多个层次的分层架构的一个例子。

亚马逊云服务AWS上的Serverless架构技术

图2:一个典型的三层应用程序通常由表示层、应用层和数据层组成。

在每个层中,可能有多个层次,它们有特定的职责。开发人员可以选择各层次彼此如何联系。这可以是严格的自上而下的方式,也可以是一种松散的方式:各层次可以绕过紧邻的层次,与其他层次对话。层次的联系方式将影响性能、依赖项管理和应用程序的复杂性。然后还有横跨多个层次的功能――这叫作横切关注点(cross-cutting concern)。

1 2 下一页

关键词: , , , , , , , , , , , 

最多人阅读内容