微服务应用程序可以以多种方式运行，每种方式都有不同的权衡和成本结构。适用于跨几个服务的小型应用程序的方法可能不适用于较大的系统。从简单到复杂，这里有五种运行微服务的方式：单机多进程：购买或租用服务器，将微服务作为一个进程来运行。多台机器，多个进程：显而易见的下一步是添加更多服务器并分配负载，以提供更大的可扩展性和可用性。容器：将微服务封装在容器中可以更轻松地与其他服务一起部署和运行。这也是迈向Kubernetes的第一步。Orchestrators：诸如Kubernetes或Nomad之类的Orchestrators是完整的平台，旨在同时运行数千个容器。无服务器：无服务器让我们忘记进程、容器和服务器，直接在云端运行代码。场景1：一台机器上的多个进程在最基本的层面上，我们可以将微服务应用程序作为一台机器上的多个进程运行。每个服务在不同的端口上侦听并通过环回接口进行通信。微服务部署的最基本形式是使用一台机器。应用程序是一组与负载平衡相结合的进程。这种简单的方法有一些明显的好处：轻量级：没有开销，因为它只是在服务器上运行的一个进程。方便：这是体验微服务的好方法，无需学习其他工具。轻松排除故障：一切都在同一个地方，所以如果你有持续交付，当出现问题或恢复到工作配置时很容易发现问题。固定账单：我们知道每个月要支付多少钱。DIY方法最适合只有少量微服务的小型应用程序。除此之外，这还不够，因为：没有可伸缩性：一旦您用完了服务器的资源，就完了。单点故障：如果服务器宕机，应用程序也会随之宕机。脆弱的部署：我们需要自定义部署和监控脚本来确保服务正确安装和运行。没有资源限制：任何微服务进程都可以消耗任意数量的CPU或内存，可能导致其他服务饿死并使应用程序处于降级状态。此选项的持续集成(CI)将遵循相同的模式：[url=https://semaphoreci.com/blog/build-stage]build[/url]并在CI管道中测试工件，然后使用持续部署进行部署。这是学习微服务基础知识的最佳选择。您可以运行一个小型微服务应用程序来熟悉它。在您需要扩展之前，一台服务器可以让您走得更远，此时您可以升级到下一个选项。选项2：多台机器和进程此选项本质上是选项1的升级。当应用程序超出服务器的容量时，我们可以向上扩展（升级服务器）或向外扩展（添加更多服务器）。在微服务的情况下，水平扩展到两台或多台机器更有意义，因为我们可以获得更高的可用性作为奖励。此外，一旦我们有了分布式设置，我们总是可以通过升级我们的服务器来扩大规模。负载均衡器仍然是单点故障。为避免这种情况，多个平衡器可以并行运行。然而，水平缩放并非没有问题。超越单台机器会引入一些关键点，这些关键点会使故障排除变得复杂，并呈现出使用微服务架构所带来的典型问题。我们如何关联分布在许多服务器上的日志文件？我们如何收集合理的指标？我们如何处理升级和停机时间？我们如何处理流量高峰和低谷？这些是分布式计算固有的问题，一旦涉及到多台机器，您就会遇到（并且必须处理）问题。如果您有几台备用机器并希望提高应用程序的可用性，则此选项很有用。只要保持简单，使用或多或少统一的服务（相同的语言，类似的框架）就可以了。一旦您通过了某个复杂性阈值，您将需要容器来提供更大的灵活性。场景3：使用容器部署微服务虽然直接将微服务作为进程运行非常有效，但它是有代价的。必须使用必要的依赖项和工具仔细维护服务器。一个失控的进程会耗尽所有内存或CPU。部署和监控微服务是一个脆弱的过程。所有这些缺点都可以通过容器来缓解。容器是包含程序运行所需的一切的包。容器镜像是一个独立的单元，可以在任何服务器上运行，无需先安装任何依赖项或工具（容器运行时本身除外）。容器提供足够的虚拟化来独立运行软件。有了它们，我们获得了以下好处：隔离：所包含的进程彼此隔离，并与操作系统隔离。每个容器都有一个私有文件系统，所以依赖冲突是不可能的（只要你不滥用卷）。并发性：我们可以运行同一个容器镜像的多个实例而不会发生冲突。更少的开销：容器比虚拟机轻得多，因为它们不需要启动整个操作系统。免安装部署：安装容器只需下载并运行镜像即可。无需安装步骤。资源控制：我们可以对容器设置CPU和内存限制，这样它们就不会破坏服务器的稳定性。上述容器化工作负载需要CI/CD上的映像构建阶段。1.服务器上的容器这种方法用容器代替进程，因为它们给了我们更多的灵活性和控制力。与选项2一样，我们可以在任意数量的机器上分配负载。将微服务流程包装在容器中使它们更加便携和灵活。2.无服务器容器到目前为止描述的所有选项都是基于服务器的。但是软件公司不从事管理服务器的业务——必须配置、打补丁和升级的服务器——他们从事修复代码问题的业务。因此，许多公司更愿意尽可能避免使用服务器也就不足为奇了。AWSFargate和Heroku等容器即服务产品可以在不处理服务器的情况下运行容器化应用程序。我们只需构建容器镜像并将其指向云提供商，剩下的事情由它负责：配置虚拟机、下载、启动和监控镜像。这些托管服务通常包括一个内置的负载均衡器，这是为数不多的需要担心的事情之一。使用Fargate的弹性容器服务(ECS)，我们无需租用服务器即可运行容器。它们由云提供商维护。以下是托管容器服务的一些好处：无服务器：无需维护或修补服务器。轻松部署：只需构建一个容器镜像并告诉服务使用它。自动缩放：云提供商可以在需求高峰时提供更多容量，或者在没有流量时停止所有容器。然而，在开始之前，您必须了解一些主要缺点：供应商锁定：这是一个大问题。摆脱托管服务总是充满挑战，因为云提供商提供并控制着大部分基础设施。资源有限：托管服务强加了不可避免的CPU和内存限制。较少控制：我们没有与其他选项相同级别的控制。如果您需要您的托管服务不提供的功能，那您就不走运了。场景4：OrchestratorsOrchestrators是专门在一组服务器上分配容器工作负载的平台。最著名的编排器是Kubernetes，这是一个由Google创建并由CloudNativeComputingFoundation维护的开源项目。除了容器管理之外，Orchestrator还提供广泛的网络功能，例如路由、安全性、负载平衡和集中式日志记录——运行微服务应用程序可能需要的一切。Kubernetes使用pod作为调度单元。Pod是一组共享网络地址的一个或多个容器。使用Kubernetes，我们摆脱了自定义部署脚本。相反，我们使用清单来编码所需的状态，让集群处理其余的事情。持续部署管道将清单发送到集群，集群采取必要的步骤来完成它。Kubernetes得到所有云提供商的支持，是部署微服务的实际平台。所以你可能认为这是运行微服务的绝对最佳方式。许多公司都是如此，但有几点需要牢记：复杂性：协调员以其陡峭的学习曲线而著称。如果您不小心，搬起石头砸自己的脚并不少见。对于简单的应用程序，编排器是多余的。管理负担：维护Kubernetes安装需要大量专业知识。幸运的是，每个体面的云提供商都提供托管集群，让您无需进行所有管理。技能集：Kubernetes开发需要专门的技能集。了解所有活动部件并了解如何对失败的部署进行故障排除可能需要数周时间。在团队熟悉这些工具之前，过渡到Kubernetes可能会很慢并且会降低生产力。场景5：将微服务部署为无服务器函数无服务器函数与我们目前讨论的所有其他内容都不同。我们使用云来简单地按需运行代码，而不是服务器、进程或容器。AWSLambda和GoogleCloudFunctions等无服务器产品处理可扩展和高可用性服务所需的所有基础设施细节，使我们能够专注于编码。无服务器函数会自动扩展并按使用量计费。这是一个完全不同的范例，具有不同的优点和缺点。从好的方面来说，我们得到了：易用性：我们可以在不编译或构建容器镜像的情况下即时部署功能，这对于试验和原型制作非常有用。易于扩展：您获得（本质上）无限的可扩展性。云将提供足够的资源来满足需求。按使用付费：您根据使用量付费。如果没有需求，则不收费。然而，无服务器的缺点可能相当大，使得无服务器不适合某些类型的微服务：供应商锁定：与托管容器一样，您正在购买供应商生态系统。从供应商迁移可能要求很高。冷启动：不常用的功能可能需要很长时间才能启动。发生这种情况是因为云提供商缩减了附加到未使用功能的资源。资源有限：每个函数都有内存和时间限制——它们不能是长时间运行的进程。运行时间受限：只支持少数几种语言和框架。您可能被迫说一种您不习惯的语言。看不见的账单：因为成本是基于使用情况的，所以很难预测月底发票的大小。使用尖峰可能会导致令人讨厌的意外。无服务器为可扩展性提供了一种无需干预的解决方案。与Kubernetes相比，它无法为您提供那么多的控制权，但它更易于使用，因为您不需要专门的无服务器技能。无服务器对于小型、快速发展的公司来说是一个很好的选择，只要他们能忍受它的缺点和限制。结论运行微服务应用程序的最佳方式取决于许多因素。使用容器（或进程）的单个服务器是试验或测试原型的一个很好的起点。如果应用程序成熟并跨越许多服务，您将需要更强大的东西，例如托管容器或无服务器，随着应用程序的增长可能还需要Kubernetes。
