容器 vs 无服务器:你会选择哪个,以及何时选择?

容器和无服务器部署和开发模型都是具有可扩展架构的文化的一部分,根据应用程序的使用情况可用。这使得选择两者之间变得困难,这正是我们在本文中要讨论的。

什么是容器?

容器不仅提供了克服传统虚拟化某些限制的可能性,而且为理解服务的开发和生命周期方式的根本变革奠定了基础。

容器的理念并非诞生于Linux世界,而是源于一种被称为FreeBSD jail的技术,于2000年出现,它允许将FreeBSD系统分区为子系统(jail),这些子系统彼此之间和彼此之间与基础系统隔离,通过扩展chroot的概念实现。

这一概念在Linux世界中通过Linux Vserver项目引入,并在接下来的几年中与新技术(包括cgroup、systemd和Linux内核命名空间)整合,从而勾勒出Linux容器(LXC)项目。

在2008年,随着Docker的到来,添加了新工具和新思想,例如创建分层镜像的可能性(即多个镜像的合并结果)和引入镜像注册表。因此,Linux世界的容器项目得到了新的推动,导致了开放容器倡议的诞生,该倡议的成员,包括Docker和Red Hat,合作定义容器技术的开放和共享标准。

有了这些前提和可用的工具,我们自然会质疑自己,以了解是否存在替代传统虚拟化的选择。

除了更严格的技术方面之外,Linux容器是与系统的其余部分隔离的一个或多个进程的集合,它们具有:

  • 标准的管理接口(用于启动、停止、环境变量)
  • 相对于虚拟机优化资源使用
  • 简化更大型应用程序的管理(分布在多个容器中)

标准化机构提出的标准的存在还可以保证互操作性和在不同云之间编排容器的可能性。

图像的概念以及构建和聚合图像的方式构成了最重要和创新的方面,不仅从技术角度来看,而且对开发和运营管理产生了影响,从而影响了对业务的理解方式。

图像是不可变的,这意味着从同一图像执行的每个容器都与其他容器相同,不包含任何状态信息或持久数据。持久性委托给其他工具,如external databases和文件系统。这首先确定了应用程序的运行时环境与其操作的数据之间的明确区别,引入了功能分离逻辑,带来了清理、进程管理和安全性方面的好处。

在开发过程和应用程序生命周期中的真正创新在于,一旦在一个或多个图像上创建了一个完整一致的操作环境,该环境与其操作的数据分开,它可以在从开发到生产的所有阶段中都不会发生变化。

什么是无服务器?

容器虽然相比虚拟机能够改善资源分配,但实际上并不能实现零缩放和线性增长:当容器不提供服务时,它仍然作为一个进程保持活动状态。对这一需求的回答可以来自serverless approaches

真正高效的资源分配要求所有计算能力只在需求时实际实例化,并在使用后立即释放。

谷歌在2008年引入谷歌应用引擎,迈出了这方面的第一步,但真正的推动是亚马逊在2014年引入的第一个真正的FaaS模型。随后,其他供应商提出了其他替代方案:微软的Azure Functions、IBM和谷歌的Cloud Functions。开源世界也朝着这个方向发展,推出了诸如Apache OpenWhisk、OpenLambda和IronFunctions等产品。


来源:epsagon.com

Serverless computing是云环境中分发服务的一种方式,它在不需要任何对基础设施的可见性的情况下执行应用程序或更正确地说是函数,只有在面对实际请求和需求时才会自动和线性地进行配置、扩展和管理。因此,服务器无的术语不是指服务器的“缺失”,而是指开发人员和用户从系统角度的透明性。

这个特性意味着在使用容器化技术时典型的“锅炉板”被放弃,重新建立了基础设施和应用组件之间的新的、更清晰的区分,引入了云世界中的两个新概念:

– FaaS(函数即服务)允许开发人员为其应用程序(无论是C#、Java、Node.js、Python等)提供一个仅在特定事件发生时实例化的执行环境。
– BaaS(后端即服务)允许将应用程序的典型功能委托给第三方,而无需亲自实现它们(例如Auth0提供的身份管理和身份验证功能)。

市场上有许多可用的选项。

Serverless和容器之间的主要区别

容器对于Serverless架构随着时间的推移变得非常重要,主要是因为它融入了不再使用旧的虚拟机和经典服务器的概念和文化。一切都可以在本地或云端托管,没有复杂性和困扰。

使用FaaS和容器的Serverless架构之间的最大区别在于不需要关注运行在操作系统级别的进程。即使像Docker这样的服务提供了与容器技术类似的抽象能力,尤其是在与Kubernetes一起使用时,Serverless架构和FaaS允许更大程度的应用开发抽象。在使用FaaS的Serverless架构中,应用程序的可扩展性由系统自动和透明地管理,还具有高粒度的服务能力以实现最佳性能。而使用容器的平台需要手动管理这种配置,即使使用了自动化工具。

最终,应用程序的风格和可用的基础设施将决定两种部署方式中哪种最合适。Serverless架构具有高度的操作系统处理抽象级别,而容器正在发展和开发自动扩展和可用性的方式。

如何在Serverless和容器之间选择?

在这个概述中,我们试图强调近年来IT服务领域所经历的根本变革,重新定义基础设施、开发模型甚至商业模式。

然而,新技术替代旧技术似乎是一种演进过程,实际上并不是一个线性的路径:在某些情况下,可能会存在只能应用其中一种技术的场景,也可能存在需要集成它们并找到各自空间的场景。

并非所有的工作负载都可以在容器中移植:在某些情况下,可能需要重新设计和重写应用程序。并不一定总是可行,因此仍然存在虚拟机允许进行系统控制或灵活性的情况,这使得它们不可或缺。

容器和无服务器用例

Containers在复杂应用程序中找到它们的理想用途,这些应用程序需要对操作环境进行高级控制,可能需要长时间进行处理,并且同时适合在容器化环境中实施。

虽然资源利用效率不如无服务器方法高效,但平均性能要好,因为至少第一个容器始终处于活动状态,不需要从头开始实例化。

由于存在共享框架和标准,设计、开发和管理可以更简单,允许在不同供应商的云之间进行编排,比虚拟服务器更容易进行扩展。

相反,在容器中对各个函数进行修改需要创建和部署新的映像,这会导致发布时间的延长和出错的可能性。随着实例数量的增加以应对负载增加,由于保证数据持久性的组件的速度限制,会导致监视困难和可能的性能问题。

一个典型的使用示例可能是一个大型电子商务网站,由许多部分组成,例如价格表、warehouse management和支付,每个部分都可以封装在一个容器中,执行时间和内存限制不构成问题。

无服务器方法在微服务上下文和需要仅在特定事件发生时调用某些函数而不是作为始终开启的服务的情况下非常理想。

作为一种严格的按使用付费模式,它允许成本优化,特别是在难以进行先验大小调整或预测将要面对的负载的情况下。

设计困难和缺乏标准在许多情况下导致供应商锁定的问题,仍然是使用领域的一大限制。

最后的话

总之,并没有绝对意义上的一种技术比另一种更好:每种技术都是针对特定需求而设计的。它们可以共存并集成到一个项目中,根据需要进行选择。因此,最好的方法不是事先确定应用程序开发的路径,而是从仔细分析特性和要求开始,选择最合适的架构。

类似文章