@sambodhi
2017-01-22T19:10:19.000000Z
字数 4207
阅读 4792
作者Asaf Yigal是AI-powered日志分析平台Logz.io的联合创始人和产品副总裁。Asaf共同创立了Currensee，一个社交交易平台，后来被OANDA于2013年收购。在创立Currensee之前，Asaf在Akorri发挥了执行角色，开发了一个端到端的性能监控平台，在Onaro开发存储资源管理平台。后来Akorri和Onaro都被NetApp收购。
Asaf撰写了一篇博文，阐述了是否应该使用无服务器架构，以及分析它的利弊得失。
业界有一种观点，无服务器的说法并不太确切，服务器怎么可能不存在呢？这里提到的服务器，其实就是一种立足于云基础设施上建立的新抽象层，让开发者无需再为服务器乃至云中的各类虚拟资源分神。
目前在无服务器概念最具知名度的是Amazon AWS Lambda。Amazon表示：“一旦将代码上传至Lambda，该服务会处理基础设施的全部容量、规模伸缩、补丁安装以及管理工作，从而为代码运行提供必要环境。”
经作者Asaf Yigal授权，InfoQ翻译、整理了Asaf的博文的观点，分享给广大读者。
当2014年Amazon发布AWS Lambda时，“无服务器”术语开始得到普及。从那时起，我们看到这术语在使用和参考呈指数级增长，更多的应用上带着他们自己的解决方案进入市场（例如，Azure最近提供的带函数的遗传算法（Genetic Algorithms，GA）。
“无服务器”究竟是指什么呢？这种新趋势如何影响人们编写和部署应用的方式？“无服务器”是一种范式转变呢，还是仅仅是基础架构即服务（Iaas）和平台即服务（Pass）的自然演进呢？在这篇文章中，Asaf将讨论究竟什么是“无服务器”，以及与现有的PaaS解决方案相比，它是如何形成的。
“无服务器”是一种特殊类型的软件体系结构，在没有可见的进程、操作系统、服务器或者虚拟机的环境中执行应用逻辑。值得一提的是，这样的环境实际上运行在操作系统之上，并使用物理服务器或者虚拟机，但是，提供和管理基础设施完全是服务提供商的责任。因此，软件开发人员才能专注于编写代码。
换句话说，开发者要考虑彼此之间以及与外部通信的服务或功能。实施这些服务后，开发人员使用传统方法时将它们组合成多个分布式进程：安装、运行、监视和更新特定操作系统上运行的特定服务器或虚拟机的这种进程。在“无服务器”方法中，第三方服务提供商包揽了一切：从进程，到操作系统，再到服务器。
当第三方服务提供商负责底层IT基础架构时，开发人员不再负责购买专用服务器或虚拟机。同时，服务提供商可以自由决定如何有效地利用其基础设施来满足其所有客户端的请求。做为结果，服务提供商通常不需要为特定客户端运行永久工作负载；相反，软件同时处理来自所有客户的要求，只花费有限的时间来处理来自特定客户的每个请求。因此，这样的提供商通常基于请求的总数，在指定时间段内的请求的频率或为来自客户的所有请求所花费的总时间来对他们的客户收费。
同样的方法适用于不同类型的负载，因为第三方服务提供商通常具有弹性、可扩展的服务。当客户开始使用第三方服务时，与在本地或云中购买、配置和管理自己的基础设施相比，预期的请求数量可能较少，客户支付的费用显著降低。对于大量的请求（预期或意外的负载峰值），客户不需要添加服务器来横向扩展其应用程序。相反，服务提供商确实关心增加的负载。当然，处理更多请求的成本会更高，但在大多数情况下，它仍然比使用专用IT基础设施更有效。
通常与无服务器一起提到的两种方法是后端即服务(BaaS)和函数即服务(FaaS)。
越来越多的实现所需功能，提供服务器端逻辑并管理其内部状态的第三方服务导致应用程序没有特定应用程序，服务器端逻辑，并使用第三方服务的一切。在这方面，这样的应用是无服务器的。
第三方服务的一些示例包括身份认证即服务（Auth0、AWS Cognito），日志即服务（Loggly、Logsense、Amazon Elasticsearch Service）和分析即服务（Amazon Kinesis、Keen IO）等等。
当应用程序仍需要特定的服务器端逻辑时，开发人员可以使用传统架构的现代替代方案：FaaS。通过这种方法，开发人员专注于实现由事件触发的短期无状态函数，并且可以与对方和外部世界进行通信。FaaS提供者进行休息配置，以处理所有请求所需的功能的多个实例，终止不再需要的实例，监视所有这些实例并提供身份和日志服务。FaaS是微服务架构的理想之选，因为FaaS提供了组织运行微服务所需的一切。
Auth0 Webtask、AWS Lambda、Google Cloud Functions和Azure Functions是FaaS实现的示例。IronFunctions是一个来自Iron.io的雄心勃勃的计划，目标是在最受欢迎的云提供商以及内部部署上运行AWS Lambda功能。
无服务器和PaaS之间的主要区别在于传统的PaaS提供程序（如Heroku或OpenShift）通常缺少自动缩放功能。传统PaaS的用户必须为应用程序指定资源量，例如Heroku的Dyno或OpenShift的Gear。仍然可以通过更改分配的资源数量手动缩放应用程序，但大多数情况下这是开发人员或系统管理员的责任。
InfoQ注：
Gear，也称之为application container，是OpenShift的计量单位，每账户3个。每个Gear就是一个由软硬件资源构成的容器，放置着用户应用代码和所使用的cartridge实例。
Dyno，是Heroku的一个度量标准，定义为“在Heroku平台上运行的、任何类型的单一进程。”Heroku以此为依据收取服务费用。
第二个区别是传统的PaaS设计用于长期运行的服务器应用程序。使用这样的设计，应用程序应始终运行以处理传入请求。如果用户把应用程序关闭，它显然不会提供请求。使用FaaS，用户的函数开始提供请求，并在处理请求时终止。理想情况下，当没有传入请求时，用户的函数不应该消耗提供程序资源（另请参阅下面的“冷启动”问题）。
根据这个术语的严格定义，传统的PaaS实现不是“无服务器”，因为它们没有自动扩展，并且要求服务器端应用程序始终运行，以便可以提供请求。由于同样的原因，传统的容器管理平台也不是“无服务器”。
另一种了解提供商是否允许无服务器方法的途径，是识别两个责任区域之间的边界：提供商的消费者和提供商本身。在“无服务器”中，边界在应用程序代码之间，以及如何在物理服务器上实际部署和运行该代码。在容器平台中，平台的消费者仍然负责使用操作系统级别来定义诸如将在哪个容器中运行的进程，以及每种类型的多少容器将运行的事务。
尽管如此，容器和无服务器之间存在固有的相似之处。例如，Kubernetes（一个开源容器编排平台）允许使用应用程序提供的指标（如并发请求数）自动扩展容器。AWS Lambda实际上为每个函数运行一个容器。
换句话说，容器和容器编排可以提供实现FaaS的有效方式，而FaaS提供了隐藏特定进程的附加抽象级别，它隐藏来自开发人员的特定进程、操作系统和容器，并允许他们专注于代码。
正如我们已经提到的，“无服务器”具有以下主要优点：
同时，“无服务器”具有以下缺点：
在实践中，可扩展的无服务器平台需要一些时间来处理用户的函数的第一个请求。这个问题被称为“冷启动”：因为平台需要初始化内部资源（例如AWS Lambda需要启动容器）。如果长时间没有对用户的函数发出请求，平台也可以释放这些资源（例如停止容器）。避免冷启动的一个选项是通过向函数发送定期请求来确保函数保持活动状态。
一些FaaS实现（例如AWS Lambda）不提供开箱即用的工具在本地测试函数（假设开发人员使用相同的云进行测试）。这不是一个理想的决定，特别是考虑到用户将为调用每个函数支付费用。因此，一些第三方解决方案正在努力填补这一空白，使用户能够在本地测试函数。
无服务器架构是编写和部署应用程序的一种新方法，它允许开发人员专注于代码。这种方法可以减少交付时间、运营成本和系统复杂性。尽管无服务器利用第三方服务（例如AWS Lambda）来消除设置和配置物理服务器或虚拟机的要求，它还捆绑在应用程序及其架构中的特定服务提供商。在将来，我们可以期待更多的趋向于统一FaaS API或框架，如IronFunctions，将有助于避免被提供商捆绑，使我们能够在不同的云提供商或甚至内部运行无服务器应用程序。