OpenStack是一種開源產品，得到了一大批志愿者和領薪代碼貢獻者的支持，它讓人們意識到了一種全面審查的架構和一種深思熟慮的設計具有的重要性，這種架構和設計似乎貫穿著OpenStack峰會的主題。無論這種意識是切實存在的還是只是個人感覺，出席亞馬遜re:Invent或谷歌I/O等大會的人士對于旗艦產品展現出來的關注度和責任感似乎不如他們在出席2015年5月OpenStack大會時展現出來的關注度和責任感。
伴隨眾多OpenStack峰會與會人士的這種個人投入而來的是，他們更加深入地了解每天做出的架構和設計方面的逐步決策具有的重要性，那是由于這些決策可能會對未來的版本發布帶來影響。正因為如此，在評估每一個變動、更新、補丁和貢獻時，既要顧及OpenStack使命聲明，又要顧及OpenStack的基本設計準則。使命聲明既簡單又野心勃勃：力求開發出無所不在的OpenStack云計算平臺，有望滿足公有云和私有云(無論規模大小)的要求，為此要做到易于部署、能夠大規模擴展。說到編寫和部署代碼，下面所列的幾條設計準則來得更重要一點。這樣一來，了解這些準則如何適用于OpenStack軟件的發展道路顯得至關重要。
可擴展性和彈性。第一條設計準則明確規定，“可擴展性和彈性是我們的主要目標;”第二條準則表明，限制主目標的任何組件都應該是可選的。這打造了一個令人關注的生態系統，其中有數百個大有幫助、不過隨意性的插件。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設計準則來處理這個難題：在基于云的系統中管理分布式數據。
雖然這些準則對OpenStack及其周邊項目和插件的日常發展起到了關鍵作用，但有些經驗或心得卻是所有軟件開發人員都可以借鑒的。測試、開發無狀態應用程序、讓可擴展性成為優先事項，以及考慮程序逐漸変得龐大后其性能將會如何，這些都是每一個軟件開發人員都應該運用到本企業組織和軟件項目的最佳實踐。
京公網安備 11010502049343號