軟體可擴充套件性：來自星巴克的經驗

【編者按】本文作者 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