部署微服务的5个选项

微服务应用程序可以以多种方式运行，具有不同的权衡和成本结构。让我们回顾一下部署微服务的5种主要方式

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，评论，加?关注?，你的?支持?是我?最大?的?动力?。

微服务是开发软件的最可扩展的方式。但是，除非我们选择正确的方式来运行它们，否则这没有任何意义: 进程还是容器？在我的服务器上运行还是使用云？我需要库伯内特吗？当涉及到微服务体系结构时，有如此丰富的选项，很难知道哪个是最好的。

正如我们将看到的，托管微服务应用程序的理想场所在很大程度上取决于其大小和伸缩性需求。因此，让我们来看看部署微服务的5种主要方式。

运行微服务的5种方式

微服务应用程序可以以多种方式运行，每种方式都有不同的权衡和成本结构。适用于跨越少数服务的小型应用程序的方法可能不足以适用于大规模系统。

从简单到复杂，以下是运行微服务的五种方式:

1. 单台机器，多个进程: 购买或租用一台服务器，并将微服务作为进程运行。

2.多台机器，多个进程: 显而易见的下一步是添加更多的服务器和分配负载，提供更多的可伸缩性和可用性。

3.容器: 将微服务打包在容器中可以更容易地与其他服务一起部署和运行。这也是迈向库伯内特家族的第一步。

4. Orchestrator: Orchestrator，如 Kubernetes 或 Nomad，是设计用于同时运行数千个容器的完整平台。

5. Serverless: Serverless 允许我们忘记流程、容器和服务器，直接在云中运行代码。

前面有两条路: 一条是从流程到容器，最终到达 Kubernetes，另一条是无服务器路线

让我们更详细地看看每一个。

选项1: 单机，多进程

在最基本的层次上，我们可以将微服务应用程序作为单台计算机上的多个进程运行。每个服务侦听一个不同的端口并通过一个环回接口进行通信。

微服务部署的最基本形式是使用单台计算机。应用程序是一组与负载平衡相耦合的进程

这种简单的方法有一些明显的好处:

Lightweight 轻量级的: 没有开销，因为它只是在服务器上运行的进程

Convenience 方便: 这是一种体验微服务的好方法，而不像其他工具那样需要学习曲线

Easy troubleshooting 很容易排除故障: 所有东西都在同一个地方，所以如果你有持续交付，发现问题或者在遇到问题时恢复工作配置是非常简单的

Fixed billing 固定账单: 我们知道每个月要付多少钱

DIY 方法最适用于只有少量微服务的小型应用程序。除此之外，它的不足之处在于:

No scalability 没有可伸缩性: 一旦您最大化了服务器的资源，这就是它

Single point of failure 单点故障: 如果服务器关闭，应用程序也会随之关闭

Fragile deployment 脆弱的部署: 我们需要自定义部署和监视脚本，以确保服务的安装和正确运行

No resource limits 没有资源限制: 任何微服务进程都可能消耗任何数量的 CPU 或内存，这可能使其他服务处于饥饿状态，并使应用程序处于退化状态

此选项的持续集成(CI)将遵循相同的模式: 在 CI 管道中构建和测试工件，然后使用持续部署进行部署。

部署构建在 CI 管道中的可执行文件需要自定义脚本

备选案文2: 多种机器和工艺

此选项实质上是选项1的升级。当应用程序超过服务器的容量时，我们可以扩展(升级服务器)或横向扩展(添加更多服务器)。在微服务的情况下，水平扩展到两台或更多机器更有意义，因为我们可以获得更好的可用性作为奖励。而且，一旦我们有了一个分布式设置，我们总是可以通过升级服务器来扩大规模。

负载平衡器仍然是单点故障。为了避免这种情况，多个平衡器可以并行运行

然而，水平伸缩并非没有问题。经过一台机器会出现一些关键点，使得使用微服务体系结构所带来的故障排除更加复杂和典型

如何将分布在多个服务器之间的日志文件关联起来？

我们如何收集合理的指标？

我们如何处理升级和停机？

我们如何处理交通高峰和下降？

这些都是分布式计算固有的问题，只要涉及到不止一台机器，你就会遇到(并且必须处理)这些问题。

如果您有一些空闲的机器，并且希望提高应用程序的可用性，那么这个选项是非常好的。只要使事情保持简单，使用或多或少统一的服务(相同的语言，类似的框架) ，就可以了。一旦您超过了一定的复杂性阈值，您将需要容器来提供更多的灵活性。

选择3: Containers

虽然将微服务直接作为进程运行是非常有效的，但这是有代价的。

必须使用必要的依赖项和工具对服务器进行仔细的维护

一个失控的进程可能会消耗所有的内存或 CPU

部署和监视微服务是一个脆弱的过程

所有这些缺点都可以通过容器来减轻。容器是包含程序需要运行的所有内容的包。容器映像是一个自包含的单元，它可以在任何服务器上运行，而不必首先安装任何依赖项或工具(容器运行时本身除外)。

容器提供了足够的虚拟化，可以独立运行软件:

Isolation 与世隔绝: 所包含的进程彼此隔离，操作系统。每个容器都有一个私有文件系统，因此不可能发生依赖冲突(只要您没有滥用卷)

Concurrency 并发性: 我们可以运行同一个容器映像的多个实例而不产生冲突

Less overhead 减少开销: 因为不需要引导整个操作系统，所以容器比 VM 轻得多

No-install deployments 非安装部署: 安装容器只是下载和运行映像的问题，不需要安装步骤

Resource control 资源控制: 我们可以对容器设置 CPU 和内存限制，这样它们就不会破坏服务器的稳定性

容器化的工作负载需要 CI/CD 上的映像构建阶段

服务器上的容器

这种方法用容器取代了过程，因为它们提供了更大的灵活性和控制。与选项2一样，我们可以将负载分布到任意数量的机器上。

将微服务流程包装在容器中使其更具可移植性和灵活性

无服务器容器

到目前为止所描述的所有选项都基于服务器。但软件公司的业务不是管理服务器(必须配置、修补和升级的服务器) ，而是用代码解决问题。因此，许多公司尽可能避免使用服务器也就不足为奇了。

AWS Fargate 和 Heroku 等容器即服务(Container-as-a-Service)产品使得无需处理服务器就可以运行容器化应用程序。我们只需要构建容器映像并将其指向云提供商，后者将处理剩下的事情: 提供虚拟机，并下载、启动和监视映像。这些托管服务通常包括一个内置的负载平衡器，这样就少了一个需要担心的问题。

使用 Fargate 的弹性容器服务(ECS)允许我们运行容器，而无需租用服务器。它们由云提供商维护

以下是托管容器化服务的一些好处:

No servers 没有服务器: 不需要维护或修补服务器

Easy deployment 很容易部署: 只需构建一个容器映像并告诉服务使用它

Autoscaling 自动缩放: 云供应商可以在需求高峰时提供更多的容量，或者在没有流量时停止所有容器

然而，在开始之前，你必须意识到一些重要的缺点:

Vendor lock-in 供应商锁定: 这是个大案子。从托管服务转移总是具有挑战性的，因为云供应商提供并控制大部分基础设施

Limited resources 资源有限: 托管服务强加无法避免的 CPU 和内存限制

Less control 控制力下降: 我们没有其他选择的控制力。如果您需要托管服务不提供的功能，那么您就不走运了

任何一种容器选项都适合中小型微服务应用程序。如果您对供应商感到满意，那么托管容器服务就更容易了，因为它为您处理了许多细节。

不用说，对于大规模部署来说，这两种选择都不合适。一旦您达到一定的规模，您就更有可能拥有具有(或愿意学习) Kubernetes 等工具的经验的团队成员，这些工具完全改变了容器的管理方式。

选项4: Orchestrators

编配器是专门用于在一组服务器上分发容器工作负载的平台。最著名的协调者是 Kubernetes，这是一个由 Google 创建的开源项目，由云计算基金会维护。

协调器除了提供容器管理外，还提供广泛的 络特性，如路由、安全、负载平衡和集中日志ーー运行微服务应用程序可能需要的所有东西。

K8s使用pod作为调度单元。Pod 是一组共享 络地址的一个或多个容器

我们远离自定义部署脚本。相反，我们用一个清单来编码所需的状态，并让集群来处理其余的事情

连续部署管道将清单发送到集群，集群采取完成清单所需的步骤

Kubernetes 得到了所有云供应商的支持事实上 微服务部署平台。因此，您可能认为这绝对是运行微服务的最佳方式。对于许多公司来说，这是事实，但也有一些事情需要记住:

Complexity 复杂性: orchestrators 以学习曲线陡峭著称搬起石头砸自己的脚 对于简单的应用程序，orchestrators是一种过度使用

Administrative burden : * 维护k8s设施需要大量专业知识。幸运的是，每个像样的云供应商都提供了托管集群，可以减少所有的管理工作

Skillset 技能: Kubernetes 综合症的发展需要一套专业技能。理解所有的活动部件需要几周的时间 了解如何对失败的部署进行故障排除. 在团队熟悉工具之前，过渡到 Kubernetes 可能是缓慢的，并且会降低生产力

对于大量使用容器的公司来说，k8s是最受欢迎的选择。如果是你，选择一个Orchestrators可能是唯一的出路。然而，在跳槽之前，请注意，最近的一项调查显示，大多数企业在迁往 Kubernetes 时面临的最大挑战是寻找熟练工程师。因此，如果您担心找不到熟练的开发人员，那么下一个选择可能是您的最佳选择。

选项5: 无服务器功能

无服务器函数与我们到目前为止讨论的所有其他函数都不同。我们不使用服务器、进程或容器，而是使用云来根据需要运行代码。像 AWS Lambda 和 Google Cloud Functional 这样的无服务器产品可以处理可伸缩和高可用性服务所需的所有基础设施细节，让我们可以自由地专注于编码。

无服务器功能可以自动伸缩，并按使用量计费

这是一个完全不同的范式，有不同的利弊。从好的方面来说，我们得到:

Ease of use 易于使用:我们可以在不编译或构建容器映像的情况下动态部署函数，这对于尝试和开发原型非常有用

Easy to scale 很容易缩放:你得到(基本上)无限的可伸缩性。云将提供足够的资源来满足需求

Pay per use 每次使用付费: 根据使用情况付费。如果没有需求，就不收费

然而，缺点可能是相当大的，使得无服务器不适合某些类型的微服务:

Vendor lock-in 供应商锁定: 与托管容器一样，你是在购买供应商的生态系统。从供应商迁移到其他地方可能会很麻烦

Cold starts 冷启动: 不常用的函数可能需要很长时间才能启动。出现这种情况是因为云提供者将附加到未使用函数的资源转换为周期性资源

Limited resources 资源有限: 每个函数都有内存和时间限制——它们不能是长时间运行的进程

Limited runtimes 运行时间有限: 只支持少数语言和框架。你可能会被迫使用一种你不喜欢的语言

不可预见的账单: 因为成本是基于使用的，所以很难预测月底发票的大小。使用量激增可能导致令人讨厌的意外。

Serverless 为可伸缩性提供了一种不受干预的解决方案。与 Kubernetes 相比，它没有给你那么多的控制权，但是它更容易使用，因为你不需要专门的技能为无服务器。对于快速增长的小公司来说，无服务器是一个极好的选择，只要他们能够承受其缺点和局限性。

结论

运行微服务应用程序的最佳方式取决于许多因素。使用容器(或进程)的单个服务器是试验或测试原型的绝佳起点。

如果应用程序是成熟的，并且跨越许多服务，那么您将需要更健壮的东西，比如托管容器或无服务器，随着应用程序的增长，以后可能还需要 Kubernetes。

没有什么可以阻止您混合和匹配不同的选项。事实上，大多数公司都混合使用裸金属服务器、虚拟机和 Kubernetes。将诸如在 Kubernetes 上运行核心服务、在 VM 中运行一些遗留服务以及为一些战略功能保留无服务器服务器这样的解决方案组合起来，可能是在每个关头利用云的最佳方式。

感谢您的阅读！