伸縮性和可用性反模式

這篇文章講了伸縮性 和可用性方面的反模式，也按照自己的理解翻譯了一下，歡迎各位探討。

1 單點失敗（Single Point of Failure）

大部分的人都堅持在單一的設備上部署我們的應用，因爲這樣部署的費用會比較低，但是我們要清楚任何的硬件設備都會有失敗的風險的，這種單點失敗會嚴重的影響用戶體驗甚至是拖垮你的應用，因此除非你的應用能容忍失敗帶來的損失，否則得話應該儘量的避免單點風險，比如做冗餘，熱備等。

2 同步調用

同步調用在任何軟件系統中都是不可避免的，但是我們軟件工程師必須明白同步調用給軟件系統帶來的問題。如果我們將應用程序串接起來，那麼系統的可用性就會低於任何一個單一組件的可用性。比如組件A同步調用了組件B，組件A的可用性爲99.9%，組件B的可用性爲99.9%,那麼組件A同步調用組件B的可用性就是99.9% * 99.9%=99.8%。同步調用使得系統的可用性受到了所有串接組件可用性的影響，因此我們在系統設計的時候應該清楚哪些地方應該同步調用，在不需要同步調用的時候儘量的進行異步 的調用（而我這裏所說的異步 是一種基於應用的異步 ，是一種設計上的異步 ，因爲J2EE目前的底層系統出了JMS是異步 API以外，其它的API都是同步調用的，所以我們也就不能依賴於底層J2EE平臺給我們提供異步 性，我們必須從應用和設計的角度引入異步 性）

3 不具備回滾能力

雖然對應用的每個版本進行回滾能力測試是非常耗時和昂貴的，但是我們應該清楚任何的業務操作都有可能失敗，那麼我們必須爲這種失敗作好準備，需要對系統的用戶負責，這就要求系統一定要具有回滾的能力，當失敗的時候能進行及時的回滾。（說到回滾大家可能第一時間想到的是事務 的回滾，其實這裏的回滾應該是一種更寬泛意義的回滾，比如我們記錄每一次的失敗的業務操作，這樣在出現錯誤的時候就不是依靠於事務 這種技術的手段，而是通過系統本身的回滾能力來進行回滾失敗業務操作）。

4 不記錄日誌

日誌記錄對於一個成熟穩定的系統是非常重要的，如果我們不進行日誌記錄，那麼我就很難統計系統的行爲。

5 產品質量依賴於測試

測試固然重要，但是軟件系統的質量應該從設計支持就融入進來，而不是靠以後測試出問題，然後再修復。測試驗證系統的行爲和預期的一致，並且要保證在引入新的功能特性以後不會影響到系統的其它部門。因此希望在測試中發現性能，伸縮性和可怕用戶體驗的問題，然後再修復它是一種沒有效果並且浪費時間和精力的不佳實踐。因此我們需要在設計之初就關注系統的伸縮性 和可用性，而不是依賴於測試。

6 無切分的數據庫

隨着系統規模的慢慢變大，我們就需要打破單一數據的限制，需要對其進行切分。

7 無切分的應用

系統在規模小的時候，也許感覺不出無切分的應用帶來的問題，但是在目前互聯網高速發展的時代，誰能保證一個小應用在一夜或者是幾夜以後還是小應用呢？說不定哪天，我們就發現應用在突如其來的訪問量打擊的支離破碎。因此我們就需要讓我們的系統和我們一樣具有生命力，要想讓系統具有應付大負載的能力，這就要求我們的應用具有很好的伸縮性 ，這也就要求應用需要被良好的切分，只有進行了切分，我們才能對單一的部門進行伸縮，如果應用是一塊死板的話，我們是沒有辦法進行伸縮的。就好比火車一樣，如果火車設計之初就把他們設計爲一體的，那麼我們還怎麼對火車的車廂進行裁剪？因此一個沒有切分的應用是一個沒有伸縮性 和沒有可用性的應用。

8 將伸縮性 依賴於第三方廠商

如果我們的應用系統的伸縮性 依賴於第三方的廠商，比如依賴於數據庫集羣 ，那麼我們就爲系統的伸縮性 埋下了一個定時炸-彈。因爲只有我們自己最清楚我們自己的應用，我們應該從應用和設計的角度出發去伸縮我們的應用，而不是依賴於第三方廠商的特性。

9 沒有卓越文化
如果我們沒有一種對待錯誤的優秀的文化，那麼我很難保證同一個失敗不發生第二次。因此我們需要一種確保同樣的失敗不發生第二次，這需要通過我們認真的對待每一次系統的失敗，從中找出問題，而不是每次修修補補，能解決問題就行，如果這樣，我們會發現，最終系統會變得遍體鱗傷，體無完膚。

原文： http://www.jdon.com/jivejdon/thread/37794