集群和扩展服务

许多人会告诉你他们有一个可扩展的系统 。 毕竟，扩展很容易。 购买服务器，安装WebLogic（或您使用的任何其他怪物应用程序服务器）并部署应用程序。 然后等待几周，直到发现所有内容都非常“快速”，您可以单击按钮，喝杯咖啡，然后等您回到办公桌前，结果将在等您。 你是做什么？ 你缩放。 您再购买几台服务器，安装怪兽应用程序服务器，然后在它们之上部署怪兽应用程序。 瓶颈是系统的哪一部分？ 没人知道。 你为什么要复制一切？ 因为你必须。 然后又经过了一些时间，然后继续扩展，直到用尽钱，同时，为您工作的人们发疯了。 今天，我们不采用这种缩放方法。 今天，我们了解到扩展还涉及其他许多方面。 这与弹性有关。 这是关于能够根据流量和业务增长的变化快速轻松地进行缩放的方法，并且在此过程中，您不应破产。 几乎所有公司都需要在不考虑IT部门责任的情况下扩展业务。 这是要摆脱那些怪物。

设计系统……受约束的组织只能制作出这些组织的通信结构副本的设计。”-M. Conway

可扩展性

让我们暂时退一步，讨论我们为什么要扩展应用程序。 主要原因是高可用性 。 为什么我们要高可用性？ 我们想要它是因为我们希望我们的业务在任何负载下都可以使用。 负载越大，效果越好（除非您处于DDoS之下）。 这意味着我们的业务蒸蒸日上。 高可用性使我们的用户感到高兴。 我们所有人都希望速度，如果加载时间太长，我们许多人便会离开站点。 我们希望避免停电，因为我们的业务无法运作的每一分钟都可能导致金钱损失。 如果没有在线商店，您将怎么办？ 可能去另一个。 也许不是第一次，也许不是第二次，但是迟早您会受够了，将其切换为另一个。 我们已经习惯了一切快速且响应Swift，并且有很多选择，在尝试其他事情之前我们不会三思而后行。 如果其他事情变得更好，那么……一个人的损失就是另一个人的收益。 我们是否通过可扩展性解决了所有问题？ 差远了。 许多其他因素决定了我们应用程序的可用性。 但是，可伸缩性是它的重要组成部分，它恰好是本章的主题。

什么是可扩展性？ 它是系统的属性，它指示其以优雅的方式处理增加的负载的能力或随需求增加而扩大的潜力。 这是接受增加的流量或流量的能力。

事实是，我们设计应用程序的方式决定了可用的缩放选项。 如果应用程序不能按比例缩放，则缩放效果将不佳。 这并不是说未设计用于缩放的应用程序无法缩放。 一切都可以扩展，但并非一切都可以很好地扩展。

常见的情况如下。

我们从一个简单的架构开始，有时使用负载平衡器，有时不使用，建立一些应用程序服务器和一个数据库。 一切都很好，复杂度也很低，我们可以非常快速地开发新功能。 运营成本低，收入高（考虑到我们刚刚起步），每个人都很高兴和有动力。

业务在增长，流量也在增加。 事情开始失败，性能下降。 添加了防火墙，设置了额外的负载平衡器，扩展了数据库，添加了更多的应用程序服务器等等。 事情仍然相对简单。 我们面临着新的挑战，但障碍可以及时克服。 即使复杂性在增加，我们仍然可以相对轻松地处理它。 换句话说，我们正在做的或多或少都一样，但是更大。 业务状况良好，但规模仍然相对较小。

然后它发生了。 您一直在等待的大事情。 也许其中一项营销活动就当场了。 也许您的竞争发生了负面变化。 也许最后一个功能确实是杀手one。 无论出于何种原因，业务都得到了极大的推动。 由于这种变化而在短暂的幸福之后，您的痛苦增加了十倍。 添加更多数据库似乎还不够。 乘法应用程序服务器似乎无法满足需求。 您开始添加缓存，而实际上不添加。 您开始感觉到，每当乘以某物时，收益就不一样了。 成本增加，您仍然无法满足需求。 数据库复制太慢。 新的应用服务器不再具有太大的区别。 运营成本的增长速度超出了您的预期。 这种情况伤害了企业和团队。 您已经开始意识到，以您为荣的架构无法满足这种负载增加的需求。 您无法拆分。 您无法衡量伤害最大的事情。 你不能重新开始。 您所能做的就是继续乘以此类行动的收益不断减少。

上述情况非常普遍。 刚开始是好的，但当需求增加时，不一定是正确的。 我们需要平衡对YAGNI（您将不再需要）原则和长期愿景的需求。 我们不能从针对大型公司优化的系统开始，因为它过于昂贵且在小企业时无法提供足够的收益。 另一方面，我们不能因任何业务的主要目标之一而失去重点。 从第一天开始我们就不会考虑扩大规模。 设计可伸缩的体系结构并不意味着我们需要从一个包含一百台服务器的集群开始。 这并不意味着我们必须从一开始就开发大型而复杂的东西。 这意味着我们应该从小处着手，但是​​以这种方式，当它变大时，就很容易扩展。 尽管微服务不是实现该目标的唯一方法，但它们确实是解决此问题的好方法。 成本不是开发，而是运营。 如果操作是自动化的，则可以Swift吸收该成本，而无需进行大量投资。 正如您已经看到的（并将继续在本书的其余部分中看到的那样），有许多出色的开源工具可供我们使用。 自动化最好的部分是，与手动完成相比，投资往往具有较低的维护成本。

这是DevOps 2.0 Toolkit中“ 集群和扩展服务”一章的开始：《使用容器化微服务实现持续部署管道的自动化》一书。 本章继续探索轴扩展和集群 ，比较Docker集群工具（Kubernetes，Docker Swarm和Mesos） ，最后完成Docker Swarm演练 。 本演练涉及使用Docker Swarm，Consul，Registrator和Jenkins设置微服务部署管道 。 请试一试。 欢迎任何反馈。

翻译自: https://www.javacodegeeks.com/2016/01/clustering-scaling-services.html