1.web应用拓展比喻场景

我经营着一家咖啡馆。经营成本同所用的资源成正比。

我的咖啡馆店面大概有一百平方英尺（约九平方米），雇佣了一个咖啡师，一台咖啡机。

营业能力：

每次能够服务一个顾客，用三分钟泡制一杯咖啡，算下来服务一个顾客的总时间是五分钟。

如果我的咖啡师不间断的工作，并且所使用的德制咖啡机不会出问题，那么我的咖啡馆的接待量为每小时十二位顾客。

2.Web服务器

高峰时期顾客很多，可是我们每次只能服务一位顾客，并且没有等候区。

所以我升级了店面，新店很棒！

升级后配置：

同样地店面面积，雇佣了三个咖啡师，购置了两台咖啡机并添加了两张椅子。

营业能力：

三分钟能够泡制两杯咖啡，约七分钟能够同时(Concurrent)服务三位顾客，并且还有两位顾客可以在新加的椅子上排队等待。

并发服务的顾客量=3，顾客接待量=5。

3.纵向扩展

新店大受欢迎，顾客络绎不绝，所以我再次升级了店面，新店面更大！设施更好！

升级后配置：

两百尺的店面，五位咖啡师，四台咖啡机，三把椅子。

营业能力随着投入的增加而变大，一切似乎都很美好。

然而随着夏天的到来，也到了咖啡馆经营的淡季。这时候由于经营成本的压力，我想减少店面的配置。但是我的老板不会让我这么干。

由于业务的涨落，纵向扩展对于我和我的咖啡馆而言代价有些过于昂贵了。有时候更大并不意味着更好。

4.通过业务量负载均衡进行横向的扩展

经过商议，老板同意以三个咖啡师为一组调整咖啡馆资源的配置，如果我事先通知，他可以增加或减少这样一组资源。

要是我能够管理多个同样配置的资源组…

是的，正好有这样一种特殊的吧台！这种吧台允许一个咖啡师同时服务多个顾客，事实上为顾客服务的人并不一定非要是咖啡师，顾客只需要有人为他们下单就可以了，并且咖啡师也并不需要直接同这些难缠的顾客打交道。

所以我做出了改进。如果我有扩展业务的需求，我会额外雇佣三个咖啡师(老板说OK)，并且将他们放到哪个特殊的吧台中，如果业务量下降，我就会解除雇佣合同，让三位咖啡师撤出吧台。

随着投入的增加，店面的接待能力变得更强，同时营业能力可以动态调整。

5.资源密集型处理

我发现我的咖啡机非常全能，能够制造各种食品。许多顾客建议我应该在菜单中加上烤面包，我就这么做了。

这时候出现了一个问题：我所用的两台咖啡机需要花两倍泡制咖啡的时间来烤一磅的面包。

这么算来，烤一磅面包所花的时间等于泡制四杯咖啡所用的时间。

这样一来，面包订单有的时候会阻塞整个系统！点咖啡的顾客很不满，大家都在议论我的经营方式太低效。

我需要一个根据营业负载分流订单的方法，使我的资源能够优化的利用。

6.基于处理的异步队列

我发明了一种使用号牌的队列系统。

顾客到来，点单之后会拿到一个号牌并等待。

订单被分置于两个输入队列中，分别是面包和咖啡。

咖啡师根据目前两个队列以及店面资源的状况选择是响应咖啡订单还是面包订单。

一旦咖啡或是面包准备好了，会被放置于一个输出托盘中，并且服务员会叫号，顾客会把东西端走。

· 虽然输入队列及输出托盘是新加的，但是仍旧使用这些资源，只是说服务方式不同了。

· 投入和服务能力的计算很复杂，所以整个系统的复杂性也随之增加了。所以如果这期间发生了问题，处理和解决将是很头疼的。

· 如果顾客们能够接受这种异步的服务方式，并且我们能够控制这么复杂的系统，那我的咖啡馆就能够根据业务量扩展的同时还能提供多样的服务种类。这足以吓退那些竞争对手。

7.写在最后

我们已经讨论了Web服务器、负载均衡以及基于队列的异步系统，那么接下来呢？

我的咖啡馆比喻已经可以结束了。

如果你真这些感兴趣，去找找经典的系统扩展的例子看看，例如循环DNS或其他相关技术。

如果你在Web应用扩展方面还是新手，那么先照着这篇文章中提到的方法先试试。

我所用的咖啡馆模拟只是一个简化的问题抽象，目的是描述Web应用扩展问题的精髓。

如果你真想学，那么仔细琢磨下这些系统，并且找个有实际经验并懂行的人讨论一下，那会很有帮助。