软件可扩展性：来自星巴克的经验

【编者按】本文作者 Weronika Łabaj 是Particular Software的开发人员。她专注于通过软件提供业务价值，探索新模式，应对挑战。在星巴克，她总是点中杯焦糖玛奇朵。

文章系国内 ITOM 管理平台 OneAPM 编译呈现，以下为正文：

星巴克通过扩展运营机制和劳动力，避免了较长的顾客等待时间。无独有偶，开发人员也可以这样做！

2004年，Gregor Hohpe发表了一篇很棒的文章——“Starbucks Does Not Use Two-Phase Commit.(星巴克不相信两阶段提交) ”当笔者在阅读时，突然想到自己大学时在星巴克的工作经历。多年以来，我逐渐意识到程序员也可以从这家著名咖啡连锁企业学到更多。

很多开发人员都想构建可扩展软件，但实际操作中却很难实现。当我们在处理各类任务时，经常会陷入某种陷阱，认为每项工作都同等重要，需要同等的资源，并应当根据预先定义的顺序同步完成。

事实证明其并非如此——至少在可扩展系统中并非如此，在星巴克也并非如此。

 

如何制作咖啡

在星巴克，制作咖啡涉及四个步骤。首先，顾客排队，在柜台点单，依据先到先服务原则。第二，员工（咖啡师）帮顾客下单，并接受付款。第三，开始准备饮品。第四，当饮品制作完成后，将其放在吧台上，并呼叫顾客姓名。

尽管整个模式听起来非常合理，但却很快会导致很长的队伍。一位员工在同一时间，只能处理一项任务，因此顾客在咖啡师按顺序制作饮品时，只能排队等候。如果想要服务更多的顾客，就需要扩展。我们来看看星巴克是如何做的。

 

扩展咖啡师

星巴克可以选择的扩展方式之一就是雇用“超级咖啡师”——非常能干，效率很高，非常聪明的咖啡师。 星巴克需要在他们的发展上投入巨资，优化他们工作的各个方面，不断提高他们的效率。在软件中，这种方案被称为向上扩展（垂直扩展）。

这种扩展的问题在于，员工的工作速度（和工作时间）是有限的。总有一天，即使是超级咖啡师也无法满足所有需求。一旦出现这种状况，顾客就会沮丧地离开店铺，可能再也不会回来。

同样的，我们优化软件的程度也是有限的。我们不可能买到200 GHz的CPU。即使最大的CPU是多核的，其每个芯片的最高速率也仅在3到4 GHz。

星巴克可以采取的另一种扩展方式，是改变工作结构，添加更多的普通员工，就如软件中的并行处理。当一位咖啡师接到订单后，另一位就开始准备。这样，第一位咖啡师就可以处理下一个订单，同时第一个订单在并行准备中。

你可能会认为，只有在需求量达到一定程度时，才应该考虑并行处理。事实上，并不是那么简单。不可能在我们需要的时候，就可以马上切换到并行处理。我们必须事先做好准备。

星巴克很清楚这一点。每开设一家新的门店，即便每个班次只有一位员工，但是并行处理的一切从一开始就准备好了。他们可以随时增添人手。

经验：如果我们构建的系统不支持并行处理，就无法轻易实现并行处理。

现在，让我们看看星巴克是如何实现这一切的。

 

从消息传递开始

如果你曾在星巴克点过咖啡，就会注意到杯子上的那些小框框里总是标有某些符号。这些符号是一种简写，帮助咖啡师快速了解饮品类型以及其它额外要求（例如奶油，奶泡等等）。

杯子，或者信息，是员工之间沟通的基础。它告诉咖啡师需要制作的饮品，而上面的符号提供饮品的细节。即使店内并不忙碌，而且只有一名员工服务顾客时，也仍然会在杯子上标注符号。

乍看起来，似乎有点多余。但是，如果突然有一大批顾客进入店内，那么后备员工能够马上提供帮助。无需任何额外的沟通，他们可以根据信息开始制作饮品。

经验：突然增长的需求并不可怕， 只要我们能够随时添加更多员工，进行分工。使用消息是方法之一。

 

分工解决

正如前文所述，整个咖啡制作流程可以由一位员工——即咖啡师完成。不过星巴克的默认流程则是由一位员工（即收银员）下单并接受付款，再由另一位员工（咖啡师）制作饮品。

通常来讲，整个流程中速度最慢的环节就是制作咖啡，这也正是为什么当店内很繁忙时，有多名咖啡师同时制作咖啡。他们往往会从一叠杯子中拿取杯子，平均分担任务。而这正是“Competing Consumers(竞争消费者)”模式的体现。

不过在某些场景下，这种方式也可能带来麻烦。举例来说，有三位咖啡师共同使用一台咖啡机与一台星冰乐机。有三位顾客点了咖啡，而第四位则点了一杯星冰乐。下订单的员工排列杯子，上面分别写有对应的符号。每位咖啡师拿取一个杯子准备制作饮品。第一位开始使用咖啡机制作饮品时，其他两位只能等待。

我们可以通过分工，来避免这种状况。一种方式就是对信息进一步细化，分类处理。例如，我们都知道星巴克会利用杯子上的信息来表示需要准备的饮品类型。但是，这套系统还区分热饮和冷饮：热饮使用纸杯，冷饮使用塑料杯。当我们接到三份热咖啡订单，然后再接到一份星冰乐订单时，我们有三个纸杯和一个塑料杯。第一位咖啡师从纸杯中拿取一个，并开始制作。第二位咖啡师看到咖啡机正在使用， 因此拿取塑料杯，使用星冰乐机器。这样，就有两杯饮品在并行制作了。

这种分工，使咖啡师拆分任务，并行完成，被称为“细分”。

经验：事实证明，细分是有效扩展策略的一个关键因素。并非所有的工作都需要同等水平的扩展。能快速完成的小型任务可由单一员工完成，而高需求，更耗时的任务可由多位员工共同完成。通过细分，我们能够对每个任务实现独立扩展。

 

并非每项工作都同等重要

星巴克成功的原因之一，是对其员工进行培训，让他们意识到记住常客的重要性。比如，每天早上，那个为他的团队购买两杯超大杯美式和两杯大杯拿铁的男士。还有，每周三，那位点中杯焦糖玛奇朵，并在店内坐上一个小时读书的女士。

如果咖啡师在周三看见这位“中杯焦糖玛奇朵女士”进入店内，他们就会在她还未到达柜台前开始准备她最爱的饮品。顾客什么也不用说，就获得了想要的饮品，肯定会很开心。收银员已经知道她要点什么饮品，就可以寒暄几句，然后接受付款。在付款完成前，她的咖啡已经准备妥当，放在吧台上了。

你可以无法想象，星巴克顾客中的常客比例非常高。为他们带来最佳体验是很重要的。通常，他们获得饮品的速度要快于其他顾客。这让他们感觉受到了重视，并鼓励他们继续前来，也为公司带来更多价值。

经验：某些任务较其它任务更为重要。通过将标准任务构建成可重用的，独立的模块，我们可以轻松地修改流程，为更有价值的任务提供更好的服务。

 

并不是所有的错误都值得预防

在以上所有示例中， 星巴克员工都需要在顾客获得咖啡之前，确认他们已经付款。为了确保这一点，咖啡师们可以在交付咖啡之前要求顾客出示小票。然而，事实上，他们没有这样做。

星巴克发现，很少有顾客会在没有付款的情况下，去领取饮品。他们的分析显示，让咖啡师专注于完成订单才最重点，而不是关心偶尔丢失的咖啡。 如果有人碰巧拿走了你点的咖啡（通常是无心的），咖啡师会准备一杯新的给你。

经验：要构建可扩展系统，我们必须接受某些无可避免的错误。要完全避免这些错误，代价太高。我们应该快速检测问题，当它们发生时，及时弥补。

 

总结

看似简单的制作咖啡四步曲，演变成了一个有趣的业务流程。那些看似独特和罕见的任务，却是业务中的必要因素。

突然增长的需求，或错误，每天都可能发生很多次。设计一个可以良好应对这些状况的系统，需要考虑各种常见的情况。通常，首先想到的模型不能够解决这些问题。另外，也还需要考虑意外情况。比如，取消订单。

从星巴克的例子可以看出，如果我们采用简单的方案，那么业务将无法扩展，为更多顾客服务。随着顾客数量的增加，我们的服务水平将不断下降，最终导致顾客不再访问。因此，我们必须改变工作方式，满足增长的需求。最后，构建的系统不仅技术上可以扩展，还可以随着业务流程不断扩展。

OneAPM 能为您提供端到端的 Java 应用性能解决方案，我们支持所有常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本原因。分钟级部署，即刻体验，Java 监控从来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

原文地址：https://dzone.com/articles/what-starbucks-can-teach-us-about-software-scalabi