2022年即将来临。与DevOps浪潮中的大多数趋势一样，在Serverless和容器之间进行选择已经成为困扰无数从业者的应用部署问题。而且从目前的情况来看，这场决定软件开发思维的大讨论恐怕不会很快结束。然而，这种无服务器和容器比较的核心是什么？它是两者中更流行的一个，还是有人认为无服务器只是容器的替代品？而且，似乎有人认为Serverless只是一种适用于容器环境的通用技术。在这篇文章中，我们将对这两种技术进行详细的比较，希望能够真正展开竞争。但如果没有明确的赢家或输家，我们至少要弄清楚两者之间的共性和差异是什么，各自适合哪些应用场景。事不宜迟，让我们从一些背景信息开始。为什么我们需要无服务器计算？多年来，我们一直习惯于在大型服务器上部署应用程序。由此产生的资源管理或供应责任自然完全落在我们自己的肩上。这种方法带来了几个问题：即使根本没有负载需求，服务器也会持续运行，从而消耗大量不必要的资源。负责服务器维护和正常运行时间保证等日常任务。服务器有责任保持适当的安全更新。随着使用量的增加，我们需要自己管理服务器的扩展；随着工作量的下降，我们必须缩减规模。面对如此多的现实问题，中小企业乃至个人显然不愿意甚至无法投入相应的精力。此外，传统服务器模式的上述特点也会影响产品的整体上市时间和交付成本，而这些都是决定定制软件开发命运的核心因素。“无服务器计算”的概念应运而生。借助无服务器计算，我们可以获得一组执行模型，其中一段代码由云服务提供商（包括AWS、Azure或GoogleCloud）通过动态分配的资源来执行。作为用户，我们只需要承担应用代码运行所对应的资源使用成本。如果我们将此计算成本与传统服务器进行比较，我们会发现支出显着减少。这样，我们的整体计算体验将是“无服务器”的（管理服务器资源的成本更低）。因此，无服务器并不是没有服务器——基础设施仍然存在，只是不再困扰我们。为什么我们需要容器化？容器化的必要性在于它解决了一个重要的问题：保证软件在从一个计算环境迁移到另一个计算环境时仍然能够正确运行。容器化应用程序还允许不同的团队独立地处理应用程序的不同部分；只要组件的交互方式没有发生重大变化，每个团队都可以处理自己的部分。这样，整个软件开发过程变得更加容易，开发人员可以更快地测试任何潜在的错误。在敏捷、DevOps的世界里，上述能力的重要性不言而喻。容器帮助开发人员建立信心，相信他们的软件可以在任何环境中顺利运行。也正是容器化的趋势催生了同样流行的“微服务架构”。我们来看一下容器中常见的几种绑定元素：应用本体依赖库二进制文件配置文件但是为了管理这些容器，我们还需要依赖另一套专用的软件，比如DockerSwarm、Kubernetes等。这些软件帮助我们编排容器，将它们正确地推送到不同的目标设备，并让它们在那里平稳运行。如下图所示，就是容器化技术的基本工作原理：既然serverless和container都很重要，那么两者有什么区别呢？下面我们将它们在实际部署中的具体表现一一对比：1.寿命限制Serverless：你应该明白函数往往是“短命的”。这里的短路一般在5分钟以内。函数的这种短暂性意味着运行该函数的容器也会在一次执行后被清除。但也正是这种短暂的生命周期，让功能实现了极高的敏捷性，帮助开发者自由灵活地将应用推送到各种易于扩展的生产环境中。容器：容器的情况不同。容器一直在运行，执行后不会被销毁。这使得容器可以充分利用缓存性能，同时被迫放弃即时扩展的能力。2.Statepersistenceserverless：如前所述，函数总是临时的或“短暂的”，这也决定了它们的无状态属性。越是无状态的功能，越适合用来组合构建强大的整体解决方案。无状态计算的强大之处在于可以帮助开发者编写出许多强大且可重用的功能，并灵活组合。但也正是因为这种无状态，函数无法缓存任何东西供后续使用。没有缓存机制，延迟级别更高。容器：在容器这边，我们可以充分发挥缓存的优势。为了保证容器终止后数据仍能正常存储，我们需要一种存储机制来容纳容器外的数据。说到这里，可能有朋友会问，缓存有那么重要吗？为什么我们总是在讨论中提到缓存？这真的很重要，因为如果容器会在目标文件上生成对象之前出现，那么直接复用原来的结果，可以节省很多时间。而这些原始结果是要被缓存存储起来的。因此，在缓存的支持下，新容器可以达到极快的构建速度。3、无延迟和启动时间Serverless：函数的无状态和不可缓存的两大特点决定了它在待机期间一定不能有函数的副本继续运行，这必然会导致调用时间变长。所以该函数只有两种状态：1）“keepwarm”状态，即根据命令在15分钟内执行代码；除此之外的任何其他时期都属于2）冷启动状态。因此，无服务器计算必然会遇到具有许多并发用户的应用程序的延迟问题。为此，可以添加如下代码，让函数始终“温暖”。但这毕竟只是权宜之计，只适用于功能较少的场景。面对如此多的大型系统，我们根本无法妥善管理所有虚拟功能。所以，上述方法只适用于函数数量较少，不需要打乱整个容器的情况。容器：容器诞生于pre-serverless时代，当然没有serverless那么“昙花一现”。容器就在那里，准备接受我们的HTTPS请求并以低延迟甚至即时响应进行响应。有了缓存的优势，容器的启动速度非常快，不需要重复创建文件。仅缓存数据引用就足以定位和重用原始结构。4.可扩展性无服务器：在无服务器架构中，应用程序后端自动且固有地扩展以满足负载需求。另外，Serverless计算更像是一个供水系统：只要服务提供者打开了总闸门，消费者这边就一直有水可用，他们只需要为流出的水量付费。他们家的水龙头。相比之下，容器技术更像是瓶装饮用水送货上门，其可扩展性显然不如无服务器计算。容器：在使用基于容器的架构时，开发者需要根据需求提前部署相应数量的容器，以满足应用扩展应用。另外，随着需求的增加，我们往往需要部署更多的容器来应对负载的波动。当实际需求超出容器配置预期时，必然会出现可扩展性瓶颈，目前并没有很好的立竿见影的解决方案。5可移植性和迁移Serverless：假设你已经在使用AWS的多种不同服务，此时选择Lambda函数绝对是明智的，因为它可以与其他服务平滑集成，并且可以支持快速访问。即使您不使用AWS服务并且担心供应商锁定，您也可以通过域映射/DNS更改等确保代码中使用的所有API端点和URL始终在您的控制之下。这使我们能够断开连接随时访问特定服务并将它们重定向到您选择的其他端点（例如其他FaaS服务提供商）。这显然比在您无法控制或无法调整的端点中部署硬编码代码要安全得多。不过，考虑到市场上有很多FaaS服务商，大家对供应商锁定的担忧也是有道理的。以Lambda为例，如果它不能满足您所在地区的特定要求，您可以执行以下操作。所有Lambda处理程序代码都应保持隔离，仅以“垫片”的形式充当其他模块/类中的逻辑。这种方式不仅提高了复用性，也大大降低了重构时Lambda迁移的便捷性和直接性。另外，这种方式也有利于支持单元测试。让我们看一下瘦Lambda处理程序示例：说到迁移，关于如何将FaaS集成到现有的DevOps框架中仍然存在争论。组织可能一次编写数百个函数，但过了一段时间后，就不再清楚哪些函数包含哪些其他函数，以及有多少仍在使用。容器：如果选择基于容器的微服务架构，就可以享受到它带来的良好的可移植性。我们可以轻松地将程序代码从开发者的笔记本电脑转移到本地数据中心或不同云服务商的云计算平台，整个过程不费力气。随着企业创新压力越来越大，产品上市时间越来越短，微服务架构的加持可以帮助大家快速构建新版本的应用。因此，如果你出于降低迁移难度、使用丰富的容器技术栈等目的而决定从单体应用迁移到容器，那么微服务架构应该是一个理想的探索起点。然而，在云平台上运行容器时，仍然涉及到很多依赖关系。例如，代码升级需要协作规划，具体包括容器主机、容器镜像、容器引擎和容器编排。对于一些需要迁移到微服务形式的遗留应用，直接“容器化”的运维难度和成本往往低于重构单体应用。6、开发环境和语言支持Serverless：主流FaaS服务商支持的语言非常有限，主要有Node.js、Python、Java、C#和Go（以AWSLambda为例）。容器：容器可以为你提供一个良好的异构开发环境，让你可以使用所有你熟悉的技术栈。考虑到如今的开发者往往同时精通多种开发语言，这种广泛的支持在人才招聘方面往往是一个巨大的优势。如果你想为一个新项目雇用开发人员，容器可以让我们免于过多考虑微服务架构中的语言选择。不同的微服务可以独立部署和扩展，服务之间有清晰的模块边界。不同的服务可以用任何语言编写并由不同的团队管理。7、系统控制serverless：由于去掉了基础设施层的复杂性，AWSLambda等FaaS服务中的功能可谓是方便流畅。这样，大家就可以更专注于产品开发和业务成果的实现。也就是说，无服务器计算可以显着缩短上市时间，但容器不能。但是以AWSLambda为例，使用Serverless计算时有很多注意事项，一旦违反，就可能会出问题。容器：容器的挑战主要集中在集群配置上，而这些严峻的挑战需要我们有扎实的容器技术背景。好在微服务层面的管控难度不是很高，Kubernetes等编排框架也可以帮助我们提高架构的治理管控效率。基于容器的微服务架构让我们可以完全控制容器系统，实现策略设置、资源分配和管理。此外，我们还提供对安全和迁移服务的细粒度控制。有了这个全控的特性，我们可以随时通过容器系统查看容器内外的基本情况，进而跨多个环境、海量资源进行全面有效的测试调试。相比之下，我们无法验证功能的本地实现和测试，因此很难提前判断它们的性能。8.高强度资源处理让我们继续以AWSLambda为例。如果某个功能的处理时间超过5分钟，系统会要求我们将任务拆分成多个更小的任务。当然，类似的限制还有很多。您可以为单个功能分配最多1.5GB的内存，而部署包不能超过50MB。但在容器方面，我们可以根据应用的实际需求，自由分配计算资源。9.测试无服务器：通常很难测试基于无服务器的Web应用程序，因为开发人员通常无法在他们的本地环境中重现这个实际的后端环境。容器：由于每个容器都在部署它的同一平台上运行，因此在生产部署之前对基于容器的应用程序执行各种测试相对容易。10.维护无服务器：无服务器应用程序比大多数人想象的更容易维护。由于无服务器服务提供商（如AWSLambda）负责服务器管理和软件更新等日常任务，因此整体维护负担将保持在非常低的水平。容器：与帮助开发人员告别维护难题的无服务器不同，容器需要开发人员继续承担所有容器维护，从管理到更新。11、成本比较Serverless：前面提到，使用AWSLambda等Serverless功能进行应用部署，可以帮助你摆脱不必要的资源开销，保证应用代码只根据调用操作及时运行。这种形式与我们熟悉的无论是否使用都需要持续付费的地方基础设施系统完全不同。容器：容器在成本方面相对传统。它们还在没有人使用时保持运行，因此客户需要根据服务器空间向云服务提供商付费。12.部署时间Serverless：由于Serverless功能比容器化微服务更小，并且不捆绑任何系统依赖项，因此每个应用程序只需几毫秒即可部署。此外，无服务器应用程序可以在部署代码后立即上线。容器：虽然容器的初始设置需要更长的时间，但在设置完整配置后可以在几秒钟内完成后续部署。何时选择Serverless？：Serverless用例分析Serverless计算特别适合以下用例：如果你的流量模式自动变化，Serverless计算不仅可以自动吸收波动，还可以在没有流量时暂时关闭。如果您担心维护服务器的成本和应用程序消耗的资源，那么无服务器计算非常适合您。如果您不想花太多时间考虑代码运行的位置和方式，请选择无服务器。创作和部署无服务器网站和应用程序的过程不涉及任何基础设施设置。因此，我们可以在几天内使用无服务器计算构建一个功能齐全的应用程序或网站。无服务器架构允许您为您的应用程序构建各种强大的图像和视频服务。您可以使用这些服务来动态调整图像大小、为不同类型的目标设备执行视频转码等。何时选择容器？：容器用例分析以下应用程序部署需求特别适合选择容器技术：如果您想选择自己的操作系统并完全控制其中安装的编程语言和运行时版本。如果您计划使用某些软件的特定版本，容器也是最佳选择。如果您一直在使用传统的大型服务器来处理WebAPI、机器学习计算和各种其他长时间运行的业务流程，请尝试使用容器——它们的工作方式几乎相同，但成本低于传统服务器。如果您打算开发新的容器原生应用程序。如果您计划重构大型复杂的单体式应用程序，那么容器是最佳选择——容器更适合复杂的应用程序结构。一些组织还使用容器将现有应用程序直接迁移到更现代的环境。诸如Kubernetes之类的容器编排工具包括一组清晰的已知最佳实践，可以轻松管理大规模容器设置。Docker等容器编排平台可以通过自动伸缩解决流量不可预测的问题（但请注意，容器的伸缩过程不是瞬间完成的）。总结说了这么多，大家会做出怎样的选择呢？看来serverless和container各有优势。根据具体用例，可能是最佳解决方案也可能是最差解决方案，因此最好不要做出任何心理假设。如果您现有的应用程序很大并且在本地运行，那么最好先将其迁移到容器，然后再将一些组件转换为函数。如果您已经拥有一个完全基于微服务的应用程序并且不介意供应商锁定，那么直接使用无服务器也很好。不管怎样，serverless架构特有的性价比值得每一位朋友认真考虑。总而言之，我们不能说Serverless的出现就意味着容器技术的消亡，至少短期内不会。而且，container和serverless也在各自的道路上不断发展。两者相互竞争，不断演化出新的形态，这是我们消费者最愿意看到的未来。
