无服务架构浅析

转载声明:
文章出处: Infoq

2009 年,业界提出DevOps理念。维基百科上解释为“DevOps 是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。”

2011 年,Forrester 发布报告“扩大 DevOps 至 NoOps”,预测在不久的将来,一些企业将越来与多地依赖于云,开发者将能更加自动地进行程序构建(building)、测试与部署等运维操作,最终达到 NoOps。虽然该术语表示这些公司将不再需要运维人员,但是报告的本意谈论的却是开发者将使用更加自动化的工具,而这些工具需要更少的人工干预。随后 PaaS 被视为是实现 NoOps 的最佳方式。

2014 年,云厂商 AWS 推出了“无服务器”的范式服务。

技术的世界变化太快,理念总是跑在太前面。DevOps 现在依然没有踏踏实实地完全落地,现在就又出现了无服务器架构体系。这究竟是怎么一回事?随之而来的影响,尤其对于运维内容的影响,会是什么呢?

无服务器体系的问世

最初,“无服务器”意在帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”,而是指由第三方供应商负责后端基础结构的维护,以服务的方式为开发者提供所需功能,例如数据库、消息,以及身份验证等。这种服务基础结构通常可以叫做后端即服务(Backend-as-a-Service,BaaS),或移动后端即服务(MobileBackend-as-a-service,MBaaS)。

但 Amazon 在 2014 年发布的 AWSLambda 让“无服务器”这一范式提高到一个全新的层面,为云中运行的应用程序提供了一种全新的系统体系结构。至此再也不需要在服务器上持续运行进程以等待 HTTP 请求或 API 调用,而是可以通过某种事件机制触发代码的执行,通常这只需要在 AWS 的某台服务器上运行一个简单的功能。

使用这一范式的开发者无需考虑服务器细节,只需要负责编写发生某些事件后所需执行的代码。云供应商将负责提供用于运行这些代码的服务器,并在必要时对服务器进行缩放。执行完毕后,承担这些功能的容器会立刻停用,并且执行过程以 100 毫秒为单位进行度量,用户只需为运行代码过程中所消耗的资源付费。一些人将这种模式叫做功能即服务(Function-as-a-Service,FaaS),另一种“即服务”(Yet-Another-as-a-Service,YassS),自从云计算技术登场后这样的称呼越来越多了。

Amazon 并不是唯一的 FaaS 供应商。其他厂商,例如 Google Cloud Functions、MicrosoftAzure Functions、IBM OpenWhisk,以及 Iron.io 和 Webtask 等各种开源实现都提供了类似的服务。

什么是无服务器架构?

Mike Robers 在 Martin Fowler 的博客网站上发布了一篇题为“无服务器架构”的文章,在该文章中,他认为无服务器是后端即服务 (BaaS) 和函数即服务 (FaaS) 的结合,并以 AWSLambda 产品为例探讨了 FaaS 的特点、什么不是无服务器及需要考虑的其他相关问题。他指出:

就像很多软件发展趋势一样,业界并没有对“无服务器”有一个明确的说法,即使它真的表示以下两个不同而又重叠的领域也不会对此有所帮助:

1. 无服务器先用来描述那些显著或完全依赖于第三方应用或服务(“在云端”)的应用程序。这些应用程序依赖于第三方来管理服务器端逻辑和状态,它们都是典型“富客户端”的应用程序(你可以想象为单一页面的 Web 应用程序或移动应用),并采用云平台提供的生态系统,包括可访问的数据库(如 Parse、Firebase)、认证服务(Auth0、AWSCognito)等。这些类型的服务以前被描述为“(移动)后端即服务”。我在文中会用“BaaS”缩写来代替这样的服务。

2. 无服务器还表示那些有服务器端逻辑的应用仍然需要由开发者来编写。不同于传统的架构,它运行在无状态计算的容器中,这些容器由事件触发的、是短暂的(也许仅仅只是一次调用)、并且完全由第三方管理。(感谢 ThoughtWorks 在他们最近的技术雷达的定义。)理解这个观点的另一种方式是“函数即服务(FaaS)”,其中 AWSLambda 是目前最流行的 FaaS 实现之一。

无服务器≠没有运维

不仅厂商积极跟进,业界还在伦敦、东京、纽约举办了 Serverlessconf,足见此概念的受关注度。

今年的 Serverlessconf London 2016 活动第一天起,人们就开始关注一个新兴的话题:“NoOps”无服务器平台为运维工作造成的前所未有的挑战。Patrick Debois 在开幕式主题演讲中提到了这一问题,并问及一系列有关无服务器技术是否会变得更好、更快速、更便宜(以及更安全)等问题。Debois 认为,诸如 AWS Lambda、Azure Functions,以及 Google Cloud Functions 等无服务器平台依然面临不小的挑战,尤其是在日志和监视等运维领域。

物理服务器和虚拟机可以进行抽象,但这并不意味着可以彻底省略基础架构配置工作,开发者往往会忽略底层持久机制所蕴含的巨大风险。

Honeycomb 的创始人 CharityMajors 当天所做的名为“无服务器,NoOps 和牙仙”的演讲。他对无服务器平台状态管理方面的问题尤为关注,并且强调到并不是说交由别人负责管理数据库,就意味着你没有责任且万事大吉。他对于运维有着极为宽广的定义:

运维是组织内部一系列围绕系统设计、构建和维护,软件发布,以及通过技术方式解决问题所需的技术能力、实践、文化价值的总称。

总体来说,虽然无服务器平台也许可以轻松满足初始部署和缩放等需求,但依然无法完全省略基础架构运维

无服务器运维的内容是?

需要考虑的两个重要事情:

首先,“运维”不仅仅意味着服务器管理。它也意味着监控、部署、安全、网络、备份和还原,也意味着一定的产品问题诊断和系统规模扩展。这些问题在无服务器应用中仍然存在,你依旧需要应对的策略。

其次,即使仍然发生系统管理的工作,你也仅仅是将它们外包给无服务器平台而已。虽然服务供应商的 Web 用户界面可以一种一次性的方式对这些内容进行配置(哪怕直接使用默认值),但是生产应用可能需要通过更成熟的方法进行配置管理,并需要能与应用程序代码基中其他方面的管理任务相互集成。

Rafal Gancarz 在 Serverlessconf London 2016 有关“企业领域的无服务器技术”讲话中不仅用实例介绍了如何使用 HashiCorp 的 Terraform 提供诸如最小特权安全策略等配置管理,以及如何将 Terraform 内部的基础架构配置作为函数代码共享给相同的持续集成(CI)流程。他还分享了他以前曾使用一台运行 Kibana 的服务器作为 Elasticsearch、Logstash 以及 Kibana(ELK)栈的一部分。这也意味着整个架构并非完全无服务器的。

与微服务更配

无服务器体系结构很适合搭配 NanoService 使用。如果说微服务(MicroService)是为了提供相对小规模的业务能力,那么可以认为 NanoService 提供的是这种能力的碎片。例如,可以通过微服务代表为某个客户执行所有 CRUD 操作所需的代码,而 NanoService 可以代表客户所要执行的每个操作:创建、读取、更新,以及删除。当触发“创建帐户”事件后,将通过 AWSLambda 函数的方式执行相应的 NanoService。但这种时候很少使用 NanoService 这样的称呼,大部分人更愿意将其称为微服务,或者就叫做“服务”。

在题为“什么比微服务更好?无服务器微服务”的网络直播中,Alan Williams(Autodesk)、AshaChakrabarty(Amazon)和 Alan Ho(Apigee)讨论了一个无服务器微服务的架构。其中,该微服务的构建使用了 AWSlambda 函数和运行在 AWS 上的 Apigee 端点。

据 Chakrabarty 介绍,无服务器是一种相对比较新的架构风格,其中的计算单元不是虚拟机,而是一个封装了待执行代码(事件触发)的函数。Williams 指出,无状态计算模型的主要特点是:“代码为主(codefocused)”、没有需要管理的服务器、没有需要配置和管理的 EC2 实例、无需人工扩展、没有空闲资源、没有 SSH 或 RDP。

下图简单地描述了一个由 Autodesk 实现的无服务器微服务的架构(点击查看大图):

该微服务有多个入口点作为 HTTP 端点(由 Apigee 管理)暴露。用户发起一个 HTTP 调用,并不知道其请求会由一个无服务器微服务提供服务。该服务由多个 Python 编写的 lambda 函数组成,这些函数之间通过 AWSSNS 异步通知进行通信。Lambda 函数是相互独立的,可以使用不同的语言开发,可以由不同的团队维护。

由于 lambda 不是短期的,所以它们需要将状态在某个地方持久化,其中一个选择是使用 DynamoDB 表。这些表的访问通过 IAM 角色控制,并且仅限于那些需要对它们进行读 / 写访问的函数。这可以避免将不需要的数据暴露给某个 lambda 函数,如果存在安全漏洞的话,这还可以缩小微服务的攻击面。Autodesk 之所以选择使用 DynamoDB 存储状态,是因为它简单,可以将数据作为 JSON 传递,不需要管理一个服务器实例,并且支持自动向上扩展。

上图底部的 DynamoDB 表(talr-taskstatus)将来自多个 lambda 函数的状态持久化,并在表被修改时产生流式事件。这些事件由另一个 lambda 函数监控(talr-validator),它会在必要时采取行动。

对于在 AWS 上实现一个无服务器架构,Williams 列举了如下好处。

  • 敏捷性:只需数周就可以实现。

  • 不需要管理基础设施,无需 EC2 或 ELB 实例,不需要打安全补丁。

  • 开发人员只需专注于他们编写的代码。

  • 通过无服务器框架管理代码的能力。

  • 成本。根据他们的经验,运行 lambda 解决方案的成本只是传统云解决方案的一小部分(约 1%)。由于不需要雇佣运维人员配置和监控 EC2 和 ELB 实例,所以成本还会进一步降低。

Williams 还提到,无服务器架构不适合运行长期工作负载或者第三方应用程序。在那些情况下,他认为容器更合适。

和 PaaS 的“爱恨情仇”

一些人认为 FaaS 就是另一种形式的 PaaS,但 IntentMedia 的工程副总裁 MikeRoberts 有自己的不同看法:

大部分 PaaS 应用无法针对每个请求启动和停止整个应用程序,而 FaaS 平台生来就是为了实现这样的目的。…FaaS 和 PaaS 在运维方面最大的差异在于缩放能力。对于大部分 PaaS 平台,用户依然需要考虑缩放,例如在使用 Heroku 时需要考虑到底需要运行几个 Dyno。但是对于 FaaS 应用,这种问题完全是透明的。就算将 PaaS 应用设置为自动缩放,依然无法在具体请求的层面上进行缩放(除非提供非常具体的流量塑形配置文件),而 FaaS 应用在成本方面效益就高多了。

同样,AWS 的 VP Adrian Cockcroft 曾经回答过“如果您的 PaaS 能够高效地在 20 分钟内启动运行半秒的实例,那么你可以称它为无服务器。”

Roberts 并不认为大家都需要抛弃 PaaS 转为拥抱 FaaS,他列举了几个原因有:“工具以及 API 网关的完善程度可能是最大的问题。此外 PaaS 中实施的 12-FactorApps 可能会使用应用内只读缓存以优化性能,这种情况就不适合使用 FaaS 功能。”