准确来说应该叫脱离业务的弹性云或者容器都是伪弹性。之所以标题中有APM一是因为它近来热门，二是因为它在我将要说的这个事情上起到关键性的作用。

不管是亚马逊的弹性云、容器方案或者国内众多云厂商在自动伸缩的时候所依据的关键指标基本都是硬件资源的利用率，当某一硬件资源利用率达到设定的阀值时会自动进行节点的水平扩展，从而达到所谓的业务服务持续可用。这样看上似乎没有什么问题，比以前的运维方式有很大的改进，从而深受众多运维人员的喜爱。

但这样的自动伸缩来保证服务其实隐含两个前置条件：

1.程序部署到这些云上之前经过充分的性能测试，保证没有软件bottleneck

2.workload基本固定，不会有过多的动态改变导致消耗resource的pattern完全不同

 

想象下，比如有一个应用没有经过充分的性能测试，退一万步说即使经过很多的测试，仍然有可能在线上出现软件性能问题，那么此时很可能硬件资源的resource并不会达到预定阀值，弹性云不会自动创建更多的节点来保持业务的持续性，但此时终端用户的体验已经很差了，比如响应时间长了。

又比如，在进行测试时，通常会提取先前的业务日志来构建workload模型，这样测试下来可能会做出某个决策说该应用是CPU intensive或者其他啥的。 但很多互联网业务总是在进行调整，有时甚至是营销策划活动都有可能完全改变用户的访问路径，造成workload跟预先测试的完全不一样，消耗resouce的pattern也不一样了。这还不用说很多国内test guys会follow dev们所谓的压力测试，完全就没有量化应用的性能，根据应用性能特征所设定的阀值也就是无稽之谈了。

 

在随着软件复杂性越来越高，软件所覆盖的场景越来越多的今天，还能满足上面这两个前置条件的应用恐怕不占多数。那么怎么样才能做到真正的弹性伸缩，也就是即使不满足这两个前置条件也能正确的自动伸缩。

 

前几年团购兴起的时候，经常有报道说某饭店进行团购，结果遇到集中消费，短时间内饭店的营业额是上去了，但是在人满为患的餐厅吃饭的体验想必去过的人都不想再去了，因为人多服务能力有限服务的水准自然就下降了。排队没人理，上一个菜要等半小时才上第二道，说不定因为忙菜里面还额外赠送了高蛋白食物。在服务行业领域，有很多跟服务级别水平相关的，比如酒店，从三星到七星；比如去银行办事，办完了还要给柜台服务人员打星评价。这些都是量化服务的，因为只有去量化服务才能知道服务的水平，才知道以后要不要改善服务。

 

在软件工程中，我们可以借助于APM来量化我们所要提供出去的服务，实时知道当前的服务水平。我很欣赏SAAS的概念，大部分软件跟普通商品和服务并没有本质上的区别，它们都是为人服务的，我们最应该考虑的是进行服务时，我们的服务水平到底怎么样，低于预期的话能不能马上更正过来。所以在能借助自动水平扩展保证服务的应用中，我们应该根据APM中的定义的SLA来进行自动伸缩，使得终端客户感知到的软件服务水平是一致的。