深入淺出，以咖啡店為例演示Web應用程式擴充套件

深入淺出，以咖啡店為例演示web應用程式擴充套件

以下為譯文：

首先，我有一間咖啡店，經營的開銷與資源成正比。我有1間100平方英呎的店面，同時還有1臺咖啡機及1名咖啡調配師。

其次，是我店鋪的產能：同時只能服務乙個客戶，一杯咖啡需要煮3分鐘，每個客戶服務時間總計5分鐘。

假設我的咖啡師可以無休工作，德國製造的咖啡機同樣堅固無比，那麼我的咖啡店每小時就可以服務12名客人。

web server

鑑於同一時間只能服務一位顧客，因此在高峰時期會存在客戶流失的情形，沒有等待的空間。因此我得公升級店鋪，情況如下：

同樣大小的店鋪和基礎設施，3個咖啡調配師，2個咖啡機以及2張椅子。這時候的店鋪產能是，3分鐘兩杯咖啡，7分鐘可以服務3個顧客，2個顧客可以在椅子上等待，即：併發客戶=3，客戶容量=5。

縱向擴充套件

生意興隆，是時候公升級了，我期望更大的產能，於是進行了如下的調整：

店鋪占地擴大到200平方英呎，5個咖啡調配師，4個咖啡機及3把椅子。能力按比例提公升，一切進行的非常好。

在夏季，生意冷淡。對於咖啡店來說再正常不過了，因此有些時候我特別想縮減開支，但是房東肯定不會那麼好說話。因此對於我這樣業務不恆定的公司來說，大不一定總是好事！

通過負載均衡器進行橫向擴充套件

如果使用更小點可以安置3個咖啡機的櫃檯，同時我只做增加或減少櫃檯數量操作，那麼房東肯定不會太在意。那麼，只要預先通知，他就可以減少或者增加乙個設施。但是，如果同乙個時間，我只能照顧乙個櫃檯上的生意，那該怎麼弄？

幸運的是，這裡有一種特殊的櫃檯恰恰就是這麼設定的，這個櫃檯允許幾個顧客同時與櫃檯管理員互動。實際情況下，負責櫃檯的員工也並不需要是個咖啡調配師，他只需要完成訂單方面的相關工作，同時咖啡調配師也並不需要直接與顧客交流。這樣的話，店鋪的產能被提公升，我也可以按需減少或者增加放置咖啡機的基礎設施。

資源深加工

其實我的咖啡機是個通用型的食品製作工具，在接收到許多客戶的現烤麵包需求後，我決定把這個食品放到選單上。

但是問題出現了，我使用的兩個咖啡機1次只能製作1磅麵包，並且耗費製作咖啡雙倍的時間。因此從時間上看，1磅的麵包=4杯咖啡。

因此有些時候麵包的訂單會阻塞整個系統，喝咖啡的顧客並不願意等待太久，低效率的言語也隨之出來。我需要1個方法來分割訂單，同時更好地利用資源。

基於非同步佇列的處理

我引入了1個基於令牌的佇列系統。在使用者下單後會取得乙個對應的令牌號碼，然後等待他的食物。訂單攝入部分會取得訂單並分類儲存——麵包及咖啡。

咖啡調配師根據現有裝置運**況分析訂單，並選擇是先做麵包還是咖啡。當麵包或者是咖啡做好後，調配師會將它傳出，隨後櫃檯人員叫號傳送。

除下新建的輸入和輸出佇列，其他都是用著之前相同的資源，但是產能明顯提高了。

從顧客的角度上看，他們有著和之前完全不一樣的使用者體驗。

只要顧客能接受這個非同步系統，我們就可以管理它的複雜性，它提供了1個容量和產品多樣化的擴充套件途徑，與鄰居的競爭中將獲絕對優勢。

未來的擴充套件方向

當非同步系統達到限制極限時，我們又該如何處理？很顯然，在這種規模下咖啡店比喻已經完全不可用了，不妨深度搜尋一些類似dns round robin的技術。web應用程式的擴充套件已經不是件新鮮的事情，不妨多參加一些交流，向擴充套件大師們取經。