【51CTO.com快译】应用程序自动规模伸缩以适应负载需求确实非常理想，但其中也蕴含着严重的复杂性与潜在风险。
不管大家有没有听说过，最近几年市场上出现了一类***吸引力的新方案——也就是云服务器。虽然这个名称本身并没有实际意义，但大家可以将云服务器理解成一系列包含有计算与I/O资源的实例，我们能够根据自己的需求随时将其实例化或者关闭。总之，亚克西。
不过单靠云技术概念还远不足以构建起理想国。没错，它的出现让构建可扩展环境变得非常轻松，但管理这类环境同样非常复杂——特别是考虑到由业务变动引发的自动缩放与服务增长问题。在这种情况下，大家可能会突然发现自己找不到一种能够搞定一切状况的标准化方案。
我们过去一直将可扩展能力视为一种相对比较缓慢的调整选项。如果我们刚刚招徕到一大批新员工，那么IT部门就需要为他们提供额外的扩展服务器资源以支撑其存储与应用需求，有时候甚至还得另行构建强大的数据库集群等方案。我们需要花几个月甚至几年时间来不断规划规模伸缩机制。相比之下，大型互联网站点则包含有大量物理服务器，而不必考虑当前实际负载——这是因为他们需要为时刻可能出现的峰值以及日常状态下的平稳资源需求做好准备。而在多数情况下，这些服务器设备都处于闲置状态。
但现在规模缩放已经成为一项能够瞬间完成的任务。我们可以根据意愿生成新的实例，并在负载峰值结束后将其弃用。我们能够在几分钟而非像过去那样利用几个月完成规模伸缩调整。不过这种自动化机制当中也包含有潜在风险，而且很难得到准确调整。自动化应用程序在规模伸缩当中包含众多变量与调整空间，而不同应用在这些方面拥有着独特的要求——换言之，对某款应用非常适用的方案在迁移至另一应用时往往效果极差。总结来讲，细节就是其原罪。
举例来说，我们可以设想一套典型的分层Web应用程序。在这里，我们拥有数据库、存储以及前端应用服务器这几大元素。为了能让这套基础设施根据负载变化情况实现动态规模伸缩，我们需要监控所有这些组成部分，并根据实际负载决定其变动方式——同时又要考虑到其它部分负载给其带来的影响。
如果我们的前端服务器开始出现峰值，那么我们则需要引入更多前端资源，但同一时间数据库服务器的负载强度可能并没那么大，这代表着我们需要在增加前端服务器数量的同时降低数据库服务器数量。接下来，存储I/O又会带来新的问题，因此我们也需要为其添加更多资源。
在此之后，当负载开始重新回归平稳时，我们则需要在基础设施当中释放这些多余资源——但不能释放得太多，也不能释放得太快。我们还需要在调整规模的同时为各处负载添加标签，因为一个区域的容量降低可能会对另一区域产生负面影响。如果我们减少了数据库资源，那么应用程序服务器上的负载可能会因此出现瓶颈，同时前端服务器则不受影响——总之，我们需要对其关联保持高度关注。而且单纯增长应用程序服务器而不解决负载资源紧张的问题，显然也是于事无补。
正如大家所见，在这种情况下我们的决策树将变得极为庞大，而且其中很可能包含有重大缺陷。我们需要部署大量监控机制与计时工具，记录等待状态、阈值以及计数。此外，我们还得将无数声明与比较规则纳入进来以构建起一套自适应基础设施，且其逻辑本身也需要受到监控与调整。这绝不仅仅是一项单纯的目标，而是一段不断延续的摸索过程。
如果基础设施的实际复杂程度超出我们之前设定的简单Web应用，那么可能还会涉及多种公共API集成、缓存与查询服务器、队列 NoSQL数据库服务器或者数量不等的现代服务组件，这将使得动态负载管理机制的复杂性呈指数级增长。很明显，这绝不是一句简单的“如果一台服务器超载了，就使用另一台”所能概括。
哦，另外需要强调的是，我们还没有考虑到相关应用程序在设计当中是否考虑到了快速规模伸缩场景。如果答案是否定的，那么我们将很难甚至根本无法对后端资源进行调整。
动态规模伸缩能力带来的收益是显而易见的。它能够以更低的使用成本为我们提供理想的性能水平与可用性表现，这无疑是一种双赢局面。然而，要发挥其固有优势也需要大家投入心血与代价，各位千万不要等闲视之才好。
原文：The dark side of scaling in the cloud
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
