这是一篇译文，文章使用一个经营咖啡店的例子来讲解 Web 应用扩容会经历的几个阶段，很有意思，通俗易懂。
我有一个小咖啡店。
店铺的开销和资源成正比： 100平方英尺的店铺面积和公用设施，一个服务员，一台咖啡机。
店铺的容量： 同一时间只能服务一个顾客，花 3 分钟出咖啡，服务完一个顾客总共会花 5 分钟。
假设服务员从来不休息，而且这台德国造的咖啡机不出问题，这个咖啡店的最大吞吐量是：12 个顾客 / 小时。
Web 服务器
同一时间只能服务一个客户，所以顾客会在高峰时期离开，这里也没有地方让人等。
我把店铺升级了，新店铺看起更好。
现在的开销： 同样的店铺面积，3 个服务员，2 个咖啡制造机，2 把椅子。
现在店铺的容量： 3 分钟可以出 2 杯咖啡，7 分钟内可以服务 3 个顾客，还可以让 2 个顾客坐在椅子上排队等候。
店铺的并发顾客数 = 3
店铺的顾客容量 = 5
垂直扩容
业务正在爆炸式增长，又该升级了，更大点会更好。
现在的开销： 200 平方英尺的区域，5 个服务员，4 台咖啡机，3 把椅子。
店铺的容量在线性增长，情况很好。
但是到夏天时，客流量下降了，这对于咖啡店来说很正常，所以我又想把店铺的规模缩小，但是我的房东却不允许我那么做。
垂直扩容对我这个客流量不稳定的店来说太贵了，大规模不一定好。
通过负载均衡器来水平扩容
房东愿意按照固定的区域（容纳 3 个服务员）来扩大或者缩小，如果我提前告知的话，他可以很轻松的打开或者关闭一个摊位。
如果我可以通过一个店面来同时管理多个摊位。
还真有这么一种柜台（负载均衡器）就是专门用来应对这种情况的。
它允许多个顾客同时与一个服务员交谈，实际上面对顾客的这个雇员不需要去制作咖啡了，只需要与顾客交谈并且将订单分发给制作咖啡的人。并且制作咖啡的人也不用来面对这些讨厌的顾客了。
这样做的优点是：如果我需要扩大规模，我可以直接添加一个可以容纳三个服务员的区域（和房东达成的协议），然后把这个区域和柜台连接起来，反之也可以用这种方式来缩小规模。
虽然费用增加了，但我也能更好地处理店铺的容量。我可以进行水平的扩容和缩容。
资源集中处理
我的咖啡机还可以用来处理制作食物，许多顾客告诉我他们想要买新鲜的烘焙面包，我就这个添加到菜单了。
但是有一个问题，一次能制作 2 杯咖啡的机器只能制作 1 磅面包，而且还要花两倍的时间。
在单位时间内， 生产 1 磅面包 = 制作 4 杯咖啡
有时候面包订单已经阻塞我的系统了，点咖啡的人也在不满的等待着，关于我工作低效的言论已经开始扩散开了。
我需要利用现有的资源来优化订单的处理方式
基于异步队列的处理方式
我引入了一个基于令牌的队列系统。
顾客进入到店之后，提交订单，然后拿一个令牌号码在等待。
这个订单按照类型进入不同的队列：面包或是咖啡。
服务员通过队列来决定他们接下来是烘焙面包还是制作咖啡。
当一份面包或者一杯咖啡就绪之后，就会被放到一个输出托盘上，处理订单的服务原就会喊出令牌号码，顾客就可以取走面包获咖啡。
- 输入队列和输出托盘是新加入的，其他的资源都是现成的，只不过在用不同的方式在工作
- 从顾客的视角来说，现在是完全不同的了
- 店铺开销和容量的计算已经很复杂了，整个系统的复杂度也在上升，如果出现问题，就很难进行排查和修复问题
- 如果顾客接受了这种异步系统，那我们就可以管理这种复杂性了，它提供了一种方式来扩打容量和生产不同种类的产品，我可以用这种方式来下一下我们对面的竞争者了
后续
我们已经达到了 Web 服务器的极限了，负载均衡，异步队列系统。然后还可以做什么？
在这一点上，用咖啡店来做比喻已经完全站不住脚了。
如果你想了解更多，可以去搜索 DNS 负载和其他的扩容技术。
如果你是 Web 应用扩容的新手，使用这篇文章中提到的技术就够了。
咖啡店例子是一个经过简化，以便激发读者对 Web 应用扩容的兴趣。
如果你真的想学习，可以修改这个系统，然后与专业的人进行实际的讨论。
关注微信公众号，聊点其他的
