【.com快译】应用自动扩展以满足负载需求确实是理想的，但也蕴含着严重的复杂性和潜在风险。无论您是否听说过，近年来，市场上出现了一类极具吸引力的新解决方案——即云服务器。虽然名字本身没有实际意义，但是你可以把云服务器理解为一系列包含计算和I/O资源的实例，我们可以根据需要随时实例化或关闭。不管怎样，亚历克西。然而，仅仅依靠云技术的概念还远远不足以构建一个乌托邦。是的，它的出现使得构建可扩展的环境变得非常容易，但管理这样的环境也非常复杂——尤其是考虑到业务变化带来的自动扩展和服务增长的问题。在这种情况下，你可能会突然发现你无法找到一个可以解决所有情况的标准化解决方案。我们历来将可扩展性视为一个相对缓慢的调整选项。如果我们刚刚招聘了大量的新员工，那么IT部门就需要为他们提供额外的扩展服务器资源来支持他们的存储和应用需求，有时甚至要单独搭建强大的数据库集群等解决方案。我们需要花费数月甚至数年的时间来不断规划扩展机制。相比之下，大型Internet站点包含大量物理服务器，而不管当前的实际负载如何——这是因为它们需要随时为可能的峰值做好准备，并在日常条件下平滑资源需求。大多数情况下，这些服务器设备都是闲置的。但缩放现在是一项可以在瞬间完成的任务。我们可以随意启动新实例，并在负载峰值结束后停用它们。我们能够在几分钟内扩大和缩小规模，而不是像过去那样几个月。但是，这种自动机制存在潜在的风险，而且很难准确调整。自动化应用程序在缩放方面有很多变量和调整空间，不同的应用程序在这些方面有独特的要求——换句话说，对一个应用程序有效的东西往往对另一个应用程序表现不佳。总之，细节就是它的原罪。作为示例，我们可以想象一个典型的分层Web应用程序。这里我们有数据库、存储和前端应用程序服务器的大元素。为了让基础架构随着负载变化而动态扩展，我们需要监控所有这些组件并确定它们如何根据实际负载发生变化——同时考虑负载的其他部分对其的影响。如果我们的前端服务器开始出现峰值，那么我们需要引入更多的前端资源，但同时数据库服务器的负载强度可能不会那么大，这意味着我们需要减少数据库的数量服务器，同时增加前端服务器的数量。接下来，存储I/O会带来新的问题，所以我们也需要为它增加更多的资源。之后，当负载开始再次趋于平稳时，我们需要释放基础架构中的这些多余资源——但不能太多，也不能太快。我们还需要在调整规模时标记所有地方的负载，因为一个区域的容量减少可能会对另一个区域产生负面影响。如果我们减少数据库资源，那么应用服务器的负载可能会因此成为瓶颈，而前端服务器不会受到影响——总之，我们需要密切关注它的相关性。而且，不解决负载资源紧张的问题，单纯的增加应用服务器显然是没有用的。如您所见，在这种情况下，我们的决策树将非常大并且可能包含重大缺陷。我们需要部署很多监控机制和计时工具来记录等待状态、阈值和计数。此外，我们还必须结合大量声明和比较规则来构建自适应基础设施，并且逻辑本身需要进行监控和调整。这不仅仅是一个简单的目标，而是一个不断探索的过程。如果基础设施的实际复杂度超过了我们之前设定的简单Web应用程序，它还可能涉及多个公共API集成、缓存和查询服务器、队列NoSQL数据库服务器，或者数量不等的现代服务组件，这将使动态的复杂性负载管理机制呈指数级增长。显然，这不仅仅是简单的“如果一台服务器过载，就使用另一台”的声明。哦，还值得强调的是，我们没有考虑所讨论的应用程序是否在设计时考虑了快速扩展。如果答案是否定的，那么调整后端资源将是困难的或不可能的。动态缩放功能的好处是显而易见的。它能够以更低的使用成本为我们提供理想的性能水平和可用性表现，这无疑是双赢的局面。不过，要想发挥出它先天的优势，也需要大家的付出和付出，所以请大家不要掉以轻心。原文：云端缩放的阴暗面【译文，合作网站转载请注明原译者和出处.com】
