什么是无服务器架构.doc

无服务器架构是最近一个比较热的话题。我们也看到有很多的书籍、开源框架和大量的产品在不断涌现，在一些技术大会上也有专门的主题。6月17日，MikeRobers在MartinFowler的博客网站上发布了一篇题为“无服务器架构”的文章，引起了业界的诸多关注。在该文章中，他认为无服务器是后端即服务(BaaS)和函数即服务(FaaS)的结合，并以AWSLambda产品为例探讨了FaaS的特点、什么不是无服务器及需要考虑的其他相关问题。他指出：就像很多软件发展趋势一样，业界并没有对“无服务器”有一个明确的说法，即使它真的表示以下两个不同而又重叠的领域也不会对此有所帮助：无服务器先用来描述那些显著或完全依赖于第三方应用或服务（“在云端”）的应用程序。这些应用程序依赖于第三方来管理服务器端逻辑和状态，它们都是典型“富客户端”的应用程序（你可以想象为单一页面的Web应用程序或移动应用），并采用云平台提供的生态系统，包括可访问的数据库（如Parse、Firebase）、认证服务（Auth0、AWSCognito）等。这些类型的服务以前被描述为“（移动）后端即服务”。我在文中会用“BaaS”缩写来代替这样的服务。无服务器还表示那些有服务器端逻辑的应用仍然需要由开发者来编写。不同于传统的架构，它运行在无状态计算的容器中，这些容器由事件触发的、是短暂的（也许仅仅只是一次调用）、并且完全由第三方管理。（感谢ThoughtWorks在他们最近的技术雷达的定义。）理解这个观点的另一种方式是“函数即服务（FaaS）”，其中AWSLambda是目前最流行的FaaS实现之一。Mike主要分析了第二个领域，并用FaaS作为文中“无服务器”的代言词。他认为第二个领域相对较新，并且它和我们平常如何考虑技术架构的方式有显著的区别，也推动了无服务概念周边很多的炒作。他也提到了其实这些概念是相互关联的，并在不断合并。文中他给出了UI驱动的应用和消息驱动的应用两个例子解释了无服务架构的设计以及不同。通过解读AWSLamda产品描述，Mike在文中分享了他对于FaaS的几个理解：从根本上说，FaaS是关于无需管理自己的服务器系统或者服务器应用，就能够运行后端代码的。FaaS不需要基于一个特定的框架或类库进行编码。无服务器应用程序的运行部署与传统系统非常不同-我们将代码上传到FaaS服务提供商，它会帮我们做所有其他事情。水平扩展是完全自动的、弹性的，并且由服务提供商进行管理。FaaS中的函数是由服务提供商定义的事件类型触发的。大多数服务提供商还允许函数被HTTP请求响应触发，通常在某种API网关里。他同时也探讨了FaaS在状态、执行时长、启动延时、API网关、工具和开源等方面的表现。他提到了FaaS在本地状态的显著约束，并可以这样简单来理解：对于任何的函数调用，你所创建的进程或者主机状态不会有一个对随后的调用可用，这包含了你写到内存和硬盘上的状态。换句话说，从部署单元角度来看，FaaS的函数是无状态的。这对应用架构产生了巨大的影响。这通常意味着FaaS要么是纯粹无状态的，即提供输入的纯函数转换；要么是利用数据库、跨应用缓存（如Redis）或者网络文件存储（如S3）的方式来存储跨请求的状态或处理请求需要的进一步输入。而对于执行时间而言，FaaS函数的每次调用是有时间限制的。当前AWSLamda函数不允许超过5分钟，超过就会被中断。这意味着长任务并不适合FaaS，除非重新设计架构。另外，FaaS函数的响应时长取决于很多的因素，也许会从10毫秒到2分钟。Mike认为如果你编写一个低延迟交易应用，那么不管你使用什么语言实现，可能都无法使用FaaS系统。那么Paas是无服务器吗？在文中Mike引用了AdrianCockcroft的回答如果您的PaaS能够高效地在20分钟内启动运行半秒的实例，那么你可以称它为无服务器。Mike认为：绝大多数PaaS应用并不是着眼于将整个应用的每个请求都来回切换，而FaaS平台做的正是这一点。FaaS和PaaS之间的主要操作差异在于扩展。对于大多数的PaaS来说，你仍然需要考虑规模，例如在Heroku你想运行多少Dynos。而如果是FaaS的应用，这完全是透明的。即使你将你的PaaS应用程序设置为自动扩展，你也不会对单个请求进行同样的配置（除非你有一个非常特殊的流量描述文件），所以当涉及到成本的时候，FaaS应用会更高效。同时他也指出这并不意味着没有运维。这里要考虑两个重要的事情：首先，“运维”不仅仅意味着服务器管理。它也意味着监控、部署、安全、网络，也意味着一定的产品问题诊断和系统规模扩展。这些问题在无服务器应用中仍然存在，你依旧需要应对的策略。其次，即使仍然发生系统管理的工作，你也仅仅是将它们外包给无服务器平台而已。最后Mike对存储过程即服务的另一话题也进行了探讨，他认为:这可能来自于一个事实，即FaaS函数的许多例子（包括一些我在本文中使用的）都是少量访问数据库的代码。如果这就是我们可以使用FaaS的所有场景，那么我认为这个名字是有帮助的。然而它实际上只是FaaS能力的一个子集。如果仅仅因为这个原因就形成这样观点的话，那这限制是不合理的。同