无服务器计算还是容器？无服务器计算和容器是用于减少云托管应用程序开销的两种架构。但它们在许多重要方面有所不同。容器比虚拟机“轻”，无服务器部署比容器“轻”，更容易扩展。在本文中，我们将讨论无服务器计算和容器之间的区别，以及如何选择。Serverless在传统的应用开发实践中，为了将程序部署到服务器上供用户使用，我们往往需要经历规划容量、购买硬件、安装软件、准备应用等步骤。这些通常需要一周到几个月的时间。再加上应用的初期运行，这可谓费时费力。随着按需云服务的广泛普及，我们解决问题的能力也越来越强。虽然资本支出(CAPEX)和运营支持(OPEX)仍会产生成本，但我们在容量规划、部署时间和硬件管理方面的支出将大大减少。其中，最典型的云计算应用就是Serverless。无服务器可以定义为一种方法。这种方法用短暂的计算能力取代了长期运行的计算配置机制。这种临时计算能力只按需存在，用完即消失。当然，serverless并不是说真的没有服务器，而是我们不需要去管理服务器。也就是说，由于我们在AWS、Google或Azure等云计算提供商提供的硬件上运行我们自己的服务，我们将服务器的维护委托给第三方（通常是云计算提供商），他们根据服务器分配资源按需提供，这样我们就可以专注于开发我们需要运行的服务。实际上，无服务器计算是一种执行模型。在此模型中，硬件由云计算提供商管理。Serverless不需要预定义硬件，只要在执行时触发并获取硬件资源，执行完成后停止获取的硬件，直到触发另一个动作。例如，内容管理应用程序允许用户将图像上传到他们撰写的文章中。如果我们在使用AWSLambda构建的无服务器架构中，图像将首先上传到S3存储桶并触发一个事件。触发器调用以多种编程语言编写的AWSLambda函数来调整和压缩图像以在各种设备上显示。可以看出，触发事件调用的AWSLambda代码或函数将在云计算提供商提供的硬件上执行。完成后硬件会处于停止状态，等待其他触发。FunctionasaService(Faas)为了动态地创建和管理服务器，开发人员需要以功能函数的形式编写应用程序代码。也就是说，根据无服务器计算的FaaS理念，软件开发者可以专注于编写和部署能够在毫秒级处理请求的单个功能、操作和业务逻辑，而无需编写基础设施代码。.并让云计算提供商提供和管理服务器，以及代表它执行的功能代码。值得注意的是，在部署功能时，我们需要以事件的形式调用它。此事件可以随时来自API网关（HTTP请求）、来自另一个无服务器功能的事件或来自另一个云（例如S3）的事件。无服务器供应商目前，大多数主要的云计算供应商都有自己的无服务器产品。其中，AWSLambda在2014年率先推出了第一个成熟的serverless框架，它不仅支持Node.js、Java、Python、C#等多种编程语言，还集成了很多其他AWS服务。当然，你也可以选择GoogleCloudFunctions、微软的AzureFunctions、IBM的OpenWhisk（一个开源的无服务器平台），以及Iron.io和Webtask。Serverless的优点和缺点我们先来看看Serverless可以为开发人员提供的优点：按使用量付费：由于我们只为在服务器上执行代码的那些时间付费，所以那些闲置的服务器时间是不计费的。弹性：使用无服务器架构，应用程序可以自动扩展以适应流量激增，并在用户较少时缩减。花费在管理上的时间和成本更少：正是因为云计算接管了基础架构和服务的扩展，所以用户不仅可以花费更少的时间和资源，还可以专注于自己的业务。缩短开发和上市时间：开发人员和组织有更多时间专注于构建产品并将其投放市场；云计算提供商负责保护和修补操作系统。微服务方法：通过微服务方法，开发人员可以构建模块化、特定于功能且松散耦合的软件。此类软件比单体应用程序更灵活、更易于管理。当然，无服务器计算也有以下缺点：供应商锁定和透明度降低：这是在云中转向无服务器的主要问题之一。由于后端完全由云提供商管理，一旦我们将现有功能迁移到其他云服务平台，将导致应用程序发生重大变化。这样的改变不仅是代码层面的，与之关联的其他服务，如数据库、访问管理、存储等，也会涉及到其他平台的移植和改变的问题。支持的编程语言：不可能支持所有语言，因为某些功能需要用相应的语言编写。例如：AWSLambda仅直接支持Java、C#、Python和Node.js(JavaScript)，GoogleCloudFunctions仅支持Node.js，MicrosoftAzureFunctions支持JavaScript、C#、F#、Python和PHP，IBMOpenWhisk仅支持JavaScript、Python、Java和Swift。不适合长时间运行的任务：由于此类函数本质上是基于事件的，因此它们不太适合长时间运行的任务。例如：Lambda的超时限制为15分钟。在其他无服务器平台上，时间限制范围为9分钟到60分钟。在实际应用场景中，长时间运行的进程用例有很多种，例如：视频处理、大数据分析、批量数据转换、批量处理事件、长时间同步请求、统计计算等。显然，这些情况都不适合无服务器计算。调试难：只有部分工具可以进行远程调试，Azure等服务仅提供镜像的本地开发环境。隐藏成本：函数调用的自动缩放通常意味着成本的自动缩放。这会使您难以衡量您的业务成本。需要更好的工具：为了跟踪大量已部署的功能，我们往往需要求助于一些更好的工具，例如：脚本、开发框架；用于诊断、本地运行时的逐步调试；以及云调试和可视化。用户界面、分析和监控。响应应用程序事件的高延迟：由于硬件在很长一段时间内处于空闲状态并且功能仅在触发时运行，因此服务器可能需要一段时间才能唤醒并为该功能提供服务。学习曲线：我们需要将传统的单体应用程序转换为微服务，然后将其编写为函数。这些都需要对架构及其工作原理有深刻的理解。容器容器是一种操作系统虚拟化方法，允许用户在资源隔离的进程中运行应用程序及其依赖项。其中，容器包含应用程序及其正常运行所需的所有依赖项，即：系统库、系统设置和其他文件。因此，无论应用程序托管在何处，容器化应用程序都可以以相同的方式在容器中运行。容器支持软件的可靠运行，因为它很容易从一个计算环境转移和部署到另一个计算环境。这种传输可能是从开发人员的笔记本电脑到测试环境，从暂存环境到生产环境，或者从数据中心的物理机到私有云或公共云中的虚拟机。由于容器需要硬件才能运行，因此我们有责任构建硬件并在其上部署容器。具体来说，容器通过在机器上开辟一个单独的用户空间，在每个环境中只运行一个应用程序。多个用户空间环境可以共享主机的内核和硬件。也就是说，主机的内核将负责为容器提供必要的内存、CPU和其他硬件。容器允许您轻松地将应用程序代码、配置和依赖项打包到易于使用的构建块中，从而提高环境一致性、运营效率、开发人员生产力和版本控制。容器可以精细地控制资源，从而提高整体架构的效率。容器增强的可移植性的优点：容器的主要优点是我们可以将应用程序及其所有依赖项组合成一个小包以在任何地方运行。这种灵活性和可移植性有助于将应用程序轻松部署到多个不同的操作系统和硬件平台。供应商中立：容器不依赖于云计算提供商。一旦我们创建了基础应用程序和依赖项的映像，我们就可以在任何地方运行它们。对应用程序的完全控制：由于团队负责打包应用程序及其依赖项，因此他们拥有完全的控制权。大型复杂的应用程序：我们可以将大型复杂的应用程序打包并在容器中运行。可扩展性：在我们的控制下，容器可以根据其基础设施最大限度地扩展。安全灵活性：我们在设置策略、管理资源和安全方面对容器具有完全的灵活性和控制权。更少的开销：与传统硬件或虚拟机环境相比，容器需要更少的系统资源，因为它们不包含任何操作系统的映像。一致的操作：无论部署在何处，DevOps团队始终可以确保应用程序在容器中的相同位置运行。更高的效率：容器允许更快地部署、修补或扩展应用程序。容器的缺点性能开销：容器不能以裸机速度运行。虽然容器比虚拟机更有效地使用资源，但考虑到它们覆盖的网络、容器和主机系统之间的接口，它们仍然会产生性能开销。不支持图形界面：Docker容器旨在用于部署不需要图形界面的服务器应用程序解决方案。虽然我们可以使用X11视频转发等创造性策略在容器内运行GUI应用程序，但这些解决方案效果不佳。管理：我们通过管理容器和配置来完成事情，但是如果没有编排工具，我们将很难轻松管理容器的扩展。安全性：安全性是容器最关心的问题。由于容器没有内核，它需要通过宿主机的内核与硬件进行通信。如果在容器内运行的应用程序存在缺陷，就会产生安全漏洞。并非所有应用程序都受益：通常，只有那些作为一组离散微服务运行的应用程序才能从容器模式中受益。监控：随着应用的发展，会加入越来越多的容器。而我们也很难对这些高度分散、不断变化的容器进行合理的监控。减慢开发过程：我们需要在每次更改代码库时打包容器，并确保所有容器在部署到生产环境之前能够正确通信。同时，我们还需要通过频繁的安全修复和其他补丁让容器操作系统保持最新。Serverlessvs.Container虽然Serverless和容器有很多共同点，但让我们看看它们之间的主要区别：服务器空间：由于Serverless计算实际上在服务器上运行，因此由云计算提供商决定是否需要服务器空间在不将特定机器分配给特定功能或应用程序的情况下配置和调整大小。另一方面，容器驻留在预先配置的、随时可用的机器上。部署：在无服务器计算中，云提供商负责部署和运行功能。每当需要触发和执行功能时，都会将其部署到提供者的已知服务器上。在容器中，开发人员负责部署容器并保持容器运行。弹性：根据负载情况，提供者会考虑在serverless中扩展相应的功能。对于容器扩容，需要人工干预，增加容器数量。随着容器编排（orchestration）平台的引入，kubernetes等编排引擎会根据负载的增加自动扩容容器。按使用付费：Serverless的优势在于价格。当一个功能被触发时，我们只需为执行该功能所需的时间和资源付费。另一方面，容器需要不断启动和运行，因此它们往往更昂贵。维护：在无服务器架构中，开发团队不管理后端，提供商在运行代码的服务器上管理和更新软件。对于容器，开发团队有责任对硬件进行更新、修补和维护。测试：我们很难在本地测试无服务器功能，因为很难在本地机器上复制后端环境。并且无论容器部署在何处，都可以在本地计算机上轻松测试和运行。扩展成本：容器技术可以按需扩展应用程序。无服务器有时会面临空间和内存限制。缓慢扩展：无服务器扩展由供应商完成，而容器扩展由应用程序开发团队拥有和定义。因此，与无服务器相比，容器的扩展速度较慢。对编程语言的支持：Serverless无法支持所有的编程语言。而且我们可以使用任何编程语言来构建容器。我们只是编写代码，将其与存储库打包，然后在容器中运行。长时间运行的任务：如前所述，无服务器计算不太适合长时间运行的任务。另一方面，容器可以运行任何类型的应用程序或任务。开发时间：有了serverless，我们只需要考虑编写代码，剩下的交给提供者。另一方面，容器还涉及构建镜像、移植等其他工作。监控：提供商使用工具来监控无服务器功能的执行和响应时间。在容器中，开发团队需要通过安装监控工具来抓取各种详细信息。选择哪种架构？总的来说，Serverless和Container不构成竞争关系。它们都属于云计算的动态架构，可以根据不同的需求部署微服务。什么时候应该使用容器？容器最适合长时间运行的流程。在这些过程中，您需要对环境进行高度控制，并需要足够的资源来设置和维护应用程序。同时，云容器也是迁移单一遗留应用程序的最佳方式。我们可以将这些应用分解为容器化的微服务，然后使用kubernetes或者swarm等引擎进行编排（orchestrate）。什么时候使用无服务器？Serverless适用于按需执行，但不需要维护任务运行的应用程序。当团队关注开发速度和最小化成本，而不是管理可扩展性和架构问题时，无服务器是理想选择。简而言之，当您需要灵活性或迁移遗留服务时，选择容器和容器编排。当您关心开发速度、自动扩展和显着降低运行时成本时，请选择无服务器。无服务器和容器可以一起工作吗？毫无疑问，Serverless和容器可以协同工作。两者相得益彰。我们可以使用基于容器的微服务架构来构建大型、复杂的应用程序并处理后端任务，如数据传输、文件备份、触发无服务器功能警报等。值得一提的是，Fargate是AmazonECS（ElasticContainerService）和EKS（ElasticKubernetesService）的计算引擎，让我们无需管理服务器即可运行容器。Fargate有效地将容器的便携性与无服务器的灵活性和易用性结合在一起。您无需添加、配置或扩展虚拟服务器即可运行容器。原标题：ServerlessComputingvsContainers:HowtoChoose，作者：JagadishManchala
