max indelicato是一位軟體開發主管和前首席軟體架構師，他最近發表了一篇關於如何設計具備可伸縮性的web應用程式 的文章。他提出要選擇正確的部署和儲存解決方案，選擇可伸縮的資料儲存和模式，並且使用抽象層。
indelicato的第乙個建議是「為工作選擇正確的工具」，想要達到這個目的，就要選擇下列架構解決方案中的一種：
他認為在開始開發應用程式的時候，這些解決方案並不是必須的，但是在開始時就選擇可伸縮的資料儲存解決方案是很明智的，因為那會避免之後再進行切 換。將應用程式部署到雲中會為我們帶來一些好處，特別是對於創業公司來說，因為他們無法準確地確定他們的應用程式在啟用之後會有多少人使用。將應用程式部 署到雲中之後，當需求增加時，就可以讓應用程式以優雅的方式進行伸縮。很多軟體架構師都講述了他們不得不對應用程式進行擴充套件的事件，其中他們會引入高速緩 存層，那會解決大部分問題。但是我們應該在設計階段就考慮相應的解決方案。 這樣在之後就很容易實現了。
接下來，indelicato建議選擇支援分割槽、複製並且有彈性的資料儲存，包括以下幾種： mongodb、cassandra、redis、tokyo cabinet、project voldemort，或者選擇mysql作為關係型資料庫。這是很必要的，因為不管怎樣，在應用程式的生命週期中，分割槽都是必要的。對於可伸縮性來說，分 區並不是必需的，但是對於「確保高可用性」就是必需的。靈活性可以讓我們快速地增加更多的節點，這可能是出現流量峰值的時候，也可能是「由於硬體故障或公升 級、大型的伸縮模式的變更或者任何需要讓節點下線的情況下，需要對節點進行維護的時候。」
indelicato建議建立一種模式，從而讓我們可以很容易地進行資料sharding，他還給出了下面的臨時元件的例子，user和userfeedentry：
collection (or table, or entries, etc) user
collection (or table, or entries, etc) userfeedentry
然後他建議根據userid進行分割槽：
通過根據userid欄位對user集合和userfeedentry集合分割槽，我們會將兩種相關的資料塊放在同乙個節點上。所有userid為 ***-***-***-***的userfeedentry資料和userid為***-***-***-***的user資料會被包含在同一資料片段 中。
為什麼這是可伸縮的呢？ 因為我們對於這個應用程式的需求完全是針對資料的分發的。當每個訪問者訪問user的資訊頁面時，系統會向資料片段發出請求以獲取user欄顯示使用者的詳 細資訊，然後再向同乙個資料片段發出請求以獲得使用者的userfeedentries。這兩個請求中，乙個會獲得一條資料，而另乙個會獲得多條資料，而這 些資料都包含在同一資料片段中。 假設在一天之中對大多數使用者的資訊都有相同次數的訪問，那麼我們已經設計了可伸縮的模式，它會支援我們的web應用程式的需求。
indelicato的最後一條建議是使用下述抽象層中的一種，但不僅限於這些： 元資料庫（repository）、快取和服務。當建立元資料庫層的時候，他建議：
不要以針對你所抽象的資料儲存特有的方式來為方法命名。 例如，如果你抽象的是關係型的資料庫，一般我們會為了執行sql查詢和命令而定義select()、insert()、delete()、 update()函式。不要這麼做。 相反，應該讓你的函式名不那麼專門化，可以使用fetch()、put()、delete()和replace()。這會確保你更好地遵循元資料庫模式， 並且當你需要切換底層資料庫的時候，工作會更簡單。
如果可能的話使用介面（或者抽象類等等） 將這些介面傳遞給應用程式中更高的層，這樣你永遠不會直接引用元資料庫的特定的固有實現。這對於構建和單元測試也是非常棒的，因為你可以編寫其他固有實現，它們會預先帶有與測試案例相關的資料。
將所有針對儲存的特殊**封裝到乙個類（或者模組等等）中，真正的元資料庫會引用或者繼承它。只在每個函式中放置針對訪問函式所必需的細節（查詢語句等等）。
時刻要牢記，並非所有元資料庫都需要抽象相同的資料儲存解決方案。只要你願意，你可以將user儲存在mysql中，而將 userfeedentries儲存在mongodb中，元資料庫要以這樣的方式實現，它們支援這麼做而不需要付出太多代價。之前的三點建議也間接地有助 於我們做到這一點。
indelicato說，對於快取記憶體層，在開始時他經常會使用「簡單的頁面（或者檢視等等）級別的快取或者服務層的快取，因為這是兩個不會經常發生狀態變更的區域。」
indelicato認為需要對服務層進行足夠的抽象，這樣當需求增加時，我們可以很容易地從服務的內部實現切換到程序之外的實現。
有些人認為在構建應用程式的時候不需要考慮可伸縮性問題，因為那會在必要的時候得到強調。 但是如果我們想要從開始就考慮可伸縮性，你還有什麼好的建議呢？
設計Web應用程式時要注意可伸縮性
適合工作的工具 indelicato的第乙個建議是 為工作選擇正確的工具 想要達到這個目的，就要選擇下列架構解決方案中的一種 他認為在開始開發應用程式的時候，這些解決方案並不是必須的，但是在開始時就選擇可伸縮的資料儲存解決方案是很明智的，因為那會避免之後再進行切 換。將應用程式部署到雲中會為我們帶來...
設計Web應用程式時要注意可伸縮性
max indelicato是一位軟體開發主管和前首席軟體架構師，他最近發表了一篇關於如何設計具備可伸縮性的web應用程式 的文章。他提出要選擇正確的部署和儲存解決方案，選擇可伸縮的資料儲存和模式，並且使用抽象層。indelicato的第乙個建議是 為工作選擇正確的工具 想要達到這個目的，就要選擇下...
在PaaS上構建SaaS應用程式需要注意什麼
遺留系統含有成千上萬個執行一大批業務功能的服務元件。比如說，假設貴企業執行的乙個內部遺留系統中的一套元件向企業高管提供乙份統計報告。為了趕在截至日之前獲得這份每週提交的報告，該高管應該考慮將必要的元件遷移到新的軟體即服務 saas 應用程式。如果經濟可行性研究表明這種遷移是明智的決策，他應該與其他高...