從咖啡館的經營看Web應用的擴充套件

　　譯註：這是一篇趣文，作者是Vistaprint的工程師Sriram Devadas，他用如何經營一家咖啡館作為例子來講解Web應用所面臨的擴充套件問題，文章生動有趣，講解淺顯易懂。

　　我經營著一家咖啡館。經營成本同所用的資源成正比。

　　我的咖啡館店面大概有一百平方英尺（約九平方米），僱傭了一個咖啡師，一臺咖啡機。

　　營業能力：

　　每次能夠服務一個顧客，用三分鐘泡製一杯咖啡，算下來服務一個顧客的總時間是五分鐘。

　　如果我的咖啡師不間斷的工作，並且所使用的德制咖啡機不會出問題，那麼我的咖啡館的接待量為每小時十二位顧客。

　　Web伺服器

　　高峰時期顧客很多，可是我們每次只能服務一位顧客，並且沒有等候區。

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

　　升級後配置：

　　同樣地店面面積，僱傭了三個咖啡師，購置了兩臺咖啡機並新增了兩張椅子。

　　營業能力：

　　三分鐘能夠泡製兩杯咖啡，約七分鐘能夠同時(Concurrent)服務三位顧客，並且還有兩位顧客可以在新加的椅子上排隊等待。

　　併發服務的顧客量=3，顧客接待量=5。

　　縱向擴充套件

　　新店大受歡迎，顧客絡繹不絕，所以我再次升級了店面，新店面更大！設施更好！

　　升級後配置：

　　兩百尺的店面，五位咖啡師，四臺咖啡機，三把椅子。

　　營業能力隨著投入的增加而變大，一切似乎都很美好。

　　然而隨著夏天的到來，也到了咖啡館經營的淡季。這時候由於經營成本的壓力，我想減少店面的配置。但是我的老闆不會讓我這麼幹。

　　由於業務的漲落，縱向擴充套件對於我和我的咖啡館而言代價有些過於昂貴了。有時候更大並不意味著更好。

　　通過業務量負載均衡進行橫向的擴充套件

　　經過商議，老闆同意以三個咖啡師為一組調整咖啡館資源的配置，如果我事先通知，他可以增加或減少這樣一組資源。

　　要是我能夠管理多個同樣配置的資源組…

　　是的，正好有這樣一種特殊的吧檯！這種吧檯允許一個咖啡師同時服務多個顧客，事實上為顧客服務的人並不一定非要是咖啡師，顧客只需要有人為他們下單就可以了，並且咖啡師也並不需要直接同這些難纏的顧客打交道。

　　所以我做出了改進。如果我有擴充套件業務的需求，我會額外僱傭三個咖啡師(老闆說OK)，並且將他們放到哪個特殊的吧檯中，如果業務量下降，我就會解除僱傭合同，讓三位咖啡師撤出吧檯。

　　隨著投入的增加，店面的接待能力變得更強，同時營業能力可以動態調整。

　　資源密集型處理

　　我發現我的咖啡機非常全能，能夠製造各種食品。許多顧客建議我應該在選單中加上烤麵包，我就這麼做了。

　　這時候出現了一個問題：我所用的兩臺咖啡機需要花兩倍泡製咖啡的時間來烤一磅的麵包。

　　這麼算來，烤一磅麵包所花的時間等於泡製四杯咖啡所用的時間。

　　這樣一來，麵包訂單有的時候會阻塞整個系統！點咖啡的顧客很不滿，大家都在議論我的經營方式太低效。

　　我需要一個根據營業負載分流訂單的方法，使我的資源能夠優化的利用。

　　基於處理的非同步佇列

　　我發明了一種使用號牌的佇列系統。

　　顧客到來，點單之後會拿到一個號牌並等待。

　　訂單被分置於兩個輸入佇列中，分別是麵包和咖啡。

　　咖啡師根據目前兩個佇列以及店面資源的狀況選擇是響應咖啡訂單還是麵包訂單。

　　一旦咖啡或是麵包準備好了，會被放置於一個輸出托盤中，並且服務員會叫號，顧客會把東西端走。

• 雖然輸入佇列及輸出托盤是新加的，但是仍舊使用這些資源，只是說服務方式不同了。
• 投入和服務能力的計算很複雜，所以整個系統的複雜性也隨之增加了。所以如果這期間發生了問題，處理和解決將是很頭疼的。
• 如果顧客們能夠接受這種非同步的服務方式，並且我們能夠控制這麼複雜的系統，那我的咖啡館就能夠根據業務量擴充套件的同時還能提供多樣的服務種類。這足以嚇退那些競爭對手。

　　寫在最後

　　我們已經討論了Web伺服器、負載均衡以及基於佇列的非同步系統，那麼接下來呢？

　　我的咖啡館比喻已經可以結束了。

　　如果你真這些感興趣，去找找經典的系統擴充套件的例子看看，例如迴圈DNS或其他相關技術。

　　如果你在Web應用擴充套件方面還是新手，那麼先照著這篇文章中提到的方法先試試。

　　我所用的咖啡館模擬只是一個簡化的問題抽象，目的是描述Web應用擴充套件問題的精髓。

　　如果你真想學，那麼仔細琢磨下這些系統，並且找個有實際經驗並懂行的人討論一下，那會很有幫助。

　　原文連結： highscalability   翻譯： 伯樂線上 - 熊崽Kevin