http://cloud.51cto.com/art/201506/478815.htm
Basic Design Tenets
- Scalability and elasticity are our main goals
- Any feature that limits our main goals must be optional
- Everything should be asynchronous
- a) If you can't do something asynchronously, see #2
- All required components must be horizontally scalable
- Always use shared nothing architecture (SN) or sharding
- a) If you can't Share nothing/shard, see #2
- Distribute everything
- a) Especially logic. Move logic to where state naturally exists.
- Accept eventual consistency and use it where it is appropriate.
- Test everything.
- a) We require tests with submitted code. (We will help you if you need it)
可擴展性和彈性。第一條設計準則明確規定，“可擴展性和彈性是我們的主要目標;”第二條準則表明，限制主目標的任何組件都應該是可選的。這打造了一個令人關注的生態系統，其中有數百個大有幫助、不過隨意性的插件。Dark Secret Software公司的首席執行官Sandy Walsh是名經驗豐富的OpenStack軟件開發人員，他說：“如果你看一下OpenStack代碼，就會發現有許多可選的組件。一切基本上就是插件。”
異步性。等待響應、阻止入站傳輸會要了大規模企業系統的命。因而，OpenStack軟件開發的第三條準則就是“一切都應該是異步的。”當然了，這也有其不足之處。大量耗用內存的應用程序會從異步操作中受益匪淺，而大量耗用處理器的應用程序將會飽受其苦。但是單一機器上的孤立性能並不是OpenStack的目標，大規模橫向擴展性纔是其目標。正因爲如此，異步性是一個優先事項。Walsh說：“可擴展性和彈性是兩個主要目標。這種系統一定要能夠擴展。”
橫向擴展。第四條設計準則認爲，“所有代碼應該能夠橫向擴展。”縱向擴展是個優點，但是編寫隨着越來越多的內存和處理器安裝到機器上，可以相應擴展的代碼並不需要大量的規劃。另一方面，開發一個能夠橫向擴展的系統可能是個挑戰，尤其是隨着參與節點的數量增至三倍或四倍，更是困難重重。所有設計決策務必要牢記橫向擴展這一條準則。
狀態管理。企業Java應用程序遇到的最常見的性能問題之一就是，隨意使用基於狀態的變量，導致企業系統運行速度減慢，幾乎不可能實現線性擴展。外設JVM語言已證明了使用不可變數據在可擴展性方面具有的好處，所以發現第四條準則是“使用無共享(SN)架構或分片(sharding)”也就不足爲奇了。
一切都必須分佈式。下一條準則就是“一切都要分佈式”，尤其是“邏輯”。Hadoop等大數據成功故事一再證明了這個理念;如果能確保數據和邏輯能協同運行，而不需要網絡調用，就能大大改善性能和可擴展性。
測試、測試、測試。最後，最終一條準則堅決主張開發人員必須“測試一切”，這不足爲奇。要是沒有經過一系列全面的測試，任何東西都不得進入代碼庫;未經測試就貿然提交的代碼、補丁或特性改進根本得不到接受和認可。這與其說是一條準則，還不如說是標準的盡職調查，而這也是確保沒有遺漏的好方法。
想法簡單，執行復雜。如果這些簡單的設計準則運用於異常複雜的問題，開發的OpenStack軟件就會變得極其令人關注。一個典例就是OpenStack的分佈式對象存儲系統Swift的工作方式。SwiftStack的技術主管John Dickinson說：“藉助Swift，你將存儲的數據與用來存儲數據的實際介質分離開來。相比較過去的數據存儲策略，這正是讓Swift成爲全新策略的特性。”有了這種方法，開發方面的人員只需要操心將數據傳送給Swift，將Swift當成它似乎就是一種公用資源。從操作的角度來看，這裏要擔心的唯一問題是，服務器和驅動器集羣是否處於良好的工作狀態。這種高度可擴展的方法日臻完善，運用OpenStack設計準則來處理這個難題：在基於雲的系統中管理分佈式數據。
