什么是无服务器架构

DEDAO

来源：高效开发运维

原文：http://t.cn/RMbZXOY

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功能。”

-END-

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。