每个人都希望有一个可扩展的系统，因为它使我们能够满足我们面前的业务需求。对我们很多人来说，问题不在于我们是否想要扩展（我们大多数人都这么做），而是我们如何扩展。在许多情况下，扩展是添加更多服务器并将其配置为集群的一部分的问题。尽管这句话听起来是对的，但它暴露了几个问题。通常不需要更多的服务器，而且在需要时，配置它们是一项成本高昂的操作（人们花在某件事情上的每一小时都是成本）。结果呢？企业往往认为IT部门是一种负担。它需要更多的资金来建造更多的服务器，并需要更多的人来维护它们。记住，所有成功的公司都想扩大业务规模，而在当今时代，这是这种需求的关键部分。业务的增加意味着需求的增加，需求的增加意味着基础设施的增加。除非我们能更好、更高效地管理我们的基础设施，否则这一点就成立了好吧。在在这一点上，你可能会问我为什么要在CloudBees博客中谈论缩放。答案很简单。通过更好的设置，Jenkins操作系统，尤其是企业版插件，大大改进了我们大规模运行Jenkins的方式。在大规模经营詹金斯的时候，我们应该考虑很多方面，但是，今天，我将集中讨论奴隶。更具体地说，我们将探讨如何在过程。什么我们需要詹金斯吗？很多事情，但最重要的一点是充当持续集成（CI）、交付或部署（CD）的框架。我假设您已经在使用Jenkins，并且知道CI/CD是什么，所以我将跳过关于可用性的讨论。仅仅设置部署管道并在每次提交到代码存储库时运行它们是不够的，只会发现它们排队等待下一个可用的执行器。如果它们被排队，管道结果将被延迟，问题会在稍后检测到，修复它们的成本更高，等等。有了CI/CD，我们需要尽快的管道反馈。我们如何减少排队等候的时间？通过添加更多服务器？在很多情况下，这是个错误的答案。更多的服务器意味着成本的增加，费用的增加意味着业务收入的减少。问问你自己，你的构建一直在排队吗。您是否在全天候运行部署管道？如果你真的需要更多的服务器。然而，更可能的是，您的需求量只有在高峰时段。我们的企业不是三班倒的工厂。我们倾向于从9点到18点工作，希望剩下的时间能和家人在一起，做一些活动，看电影等等。即使在工作时间内，需求也会有所不同。最初几个小时对我们的CI/CD基础设施的需求往往较低。毕竟，在将代码提交到存储库之前，我们需要一点时间来编写一些代码。在这种情况下，我们对从机的CI/CD基础设施需求可能是跟随。从9小时到12小时-中等需求从12小时到18小时-高需求剩余时间-低需求（可能是一些预定的工作）如果我们想高效地运营我们的业务，我们的基础设施应该能够处理任何需求。这对外部用户和内部用户同样有效。我们如何处理任何需求？通过设计可扩展系统。什么是可伸缩性？它是一个系统的属性，表示它以一种优雅的方式处理增加的负载的能力，或者它随着需求的增加而扩大的潜力。它是接受增加的交通量或交通量的能力。事实是，我们设计应用程序的方式决定了可用的缩放选项。如果应用程序不是按比例设计的，它们就不能很好地扩展。这并不是说，一个不是为扩展而设计的应用程序不能扩展。一切都可以扩展，但不是所有的都可以扩展。这不仅适用于我们面向公众的应用程序，也适用于为内部使用而创建的应用程序，例如詹金斯。那个解决詹金斯奴隶问题的办法往往会走两个极端。一种是完全基于前提的专用基础设施。这是昂贵的，因为在这种情况下，基础设施需要与最高峰值的负载一样大，否则可能会有很长的队列时间。结果就是浪费了中低谷的资源。浪费资源等于浪费金钱。另一个极端是完全建立在云上的基础设施。再说一次，太贵了。云计算单元的成本远高于内部部署（除非我们使用私有云）。如果两个选项（完全内部部署和完全云计算）都很昂贵，那么解决方案是什么？答案是两者的结合。我们应该将本地专用的从属服务器与可从云提供商（或在数据中心自己构建）获得的弹性结合起来。计算最小需求，并在服务器上为其创建从属服务器。以100%的资源利用率为目标。请记住，我说的是aim，因为硬件永远不可能一直得到充分利用。一旦您的服务器上安装了从属服务器，并且您确信它们（几乎）得到了充分利用并满足了最低需求，那么就将其余的迁移到云上。请注意，您的云从属服务器需要配置为在不使用时释放资源。将它们设置为在需要时创建新的vm，并在需要时销毁它们未使用。如果您可以将本地专用从属服务器与弹性云节点相结合，结果将是高可用性和非常短的队列时间（刚好足够在云中实例化一个新的虚拟机）。您的团队会很高兴，因为部署管道将在代码提交后立即运行。您的企业会很高兴，因为您可以降低基础设施的成本。您将尽可能使用更便宜的本地计算单元，并且只向您的云提供商支付高峰时段的使用费。每个人都是赢家。我们'将在下一篇文章中继续讨论。我带你看看我们讨论过的设置。等一下。我会利用这个机会做一些无耻的自我推销。如果您对DevOps感兴趣，您可能想看看devops2.0toolkit:automatingthecontinuousdeploymentpipeline with Containerized Microservices一书。在许多其他过程和工具中，它更深入地探讨了集群和伸缩，这是我们在本文中几乎没有涉及的主题。