這是一篇關於架構師眼中的MySQL開發模式的變化,看看小編的整理吧!
新舊兩套開發模式間的不同之處
現在我們來聊聊新舊兩種開發模式之間的幾項主要差異。
我認為目前我們所使用的開發模式,其最重要的特性就是整個開發流程以2到4個月為周期始終處於隨時可發布狀態,並且能夠穩定地按照每6個月推出新GA版本的進度進行運作。對於可發布狀態,我們的定義為:產品質量嚴格符合候選發布版的相關標准。在過去的開發模式中,我們的標准相對比較寬松,所謂可發布狀態是指當前版本到達候選發布要求——但由於在測試階段仍然可能有新功能不斷被添加進來,因此整個發布流程周期常常長達兩年,而不是現在的2到4個月。
新模式給MySQL新代碼帶來的影響
那麼這種新模式會給我們的MySQL新代碼開發工作帶來哪些影響呢?在我看來,這意味著新代碼必須以小規模模塊的形式添加到產品中來,換句話說新代碼中不能混雜過多舊代碼,因為這可能會帶來新的未知沖突及不穩定因素。總之,如果需要向MySQL Server中某個復雜程度較高的區域添加新功能,我們會首先對該區域進行重新設計,然後才著手實施功能添加工作。如此一來,我們就在某種程度上保持了開發流程的穩定性始終擁有最高優先級。而在過去,我們向MySQL Server中添加新功能時往往會造成系統穩定性優先級別的下降,這對於一款開發模式而言當然不是什麼好事。
有趣的是,隨著穩定性在開發流程中的重要性得到進一步增強,我們反而獲得了放手處理新功能的廣闊空間!不過有時候我們未必能按照自己的預期快速開發出特定的新功能。如果一項新功能會對MySQL Server中復雜性較高的某些代碼造成干擾,那麼為了系統穩定性的考量,我們會事先進行一系列准備工作及測試流程,這是此類新功能出台的必要前提。但是對於大部分與MySQL Server復雜區域不相關的邊緣新功能來說,整個添加過程則更加順暢同時輕松愉快。
新模式下的主要功能開發流程
接下來要談的是如何在這套模式中處理主要功能的添加工作,其中最需要注意的因素在於如何保證新代碼擁有良好的排布結構。也就是說在添加新功能時,我們不能簡單地從編寫代碼著手,而應該首先思考現有代碼結構能否與正在開始的新功能緊密契合。舉例來說,我們在MySQL 5.6版本中添加了眾多新功能,而LOCK_open正是其中之一。如果按照以往傳統的MySQL Server開發模式,我們會直接將新功能添加進來,然後檢測它會與哪些現有MySQL Server功能組件發生沖突,並確保所有已經確定的新問題在新的GA版本發布之前得到解決。但現在我們的思路更先進、處理方式也完全不同。首先我們會建立一系列重新設計項目,將LOCK_open主功能完全隔離起來,這樣就保護了運行中的元數據免遭破壞、同時也為連接中的元數據提供了緩沖措施。在以上步驟的執行過程中,我們可以繼續進行手頭的其它MySQL 5.6開發工作,而且原本非常重要的LOCK_open功能更新能夠以小補丁的形式添加進主系統當中,同時也讓功能升級變得更加安全。
新開發模式的靈感來源
我們之所以選擇這種全新的開發模式,其靈感顯然源自以Linux內核為代表的其它幾個典型開源項目。它們的成功為我們的新思路提供了指導與借鑒。
從舊模式向新模式的轉換
盡管新模式的優勢如此明顯,但從舊模式轉換為新模式的道路卻並不平坦。在決定發起變革之後,我們制定了新的開發流程,並在其中添加了多項意義重大的新功能。然而流程的出台並不意味著實際工作的順利進行,概念與可發布狀態之間仍然相隔十萬八千裡,因此我們做出了“一個艱難的決定”——以MySQL 5.1開發流程為基礎將一切過去推倒重來。這套新流程是我們首次在開發過程中使用“裡程碑”模式的嘗試,但原先的模式中同樣包含很多意義重大的理想方案,因此我們需要一步步將遺留資源與新規劃加以整合。整個過程持續了數年之久,由於新的開發流程對於新功能的運作效果及穩定性要求極高,因此進度不快也在情理之中。不過現在我們終於大功告成,所有有價值的功能都已經被遷移到新模式當中,其它的則要麼直接棄用、要麼利用其它方式加以替代。
對於未來MySQL開發的影響
那麼新模式的引入到底會在當下與未來給MySQL開發工作帶來哪些影響呢?首先要強調的是,我們在MySQL 5.6中添加了200項新功能,這表明新的開發模式確實能為我們的用戶及消費者帶來大量激動人心的革命性升級與改進。希望這套開發模式能夠繼續指引開發工作順利開展,我們也會繼續努力為MySQL技術社區帶來更多更具吸引力的功能。作為一位架構師,我非常自豪地關注著MySQL技術團隊的一舉一動,也為他們針對MySQL架構做出的改善而深感驕傲。相信隨著新模式的逐漸完善與新功能的持續加入,MySQL會為全世界使用者帶來更加光彩奪目的特性。
以上就是小編為大家整理的架構師眼中的MySQL開發模式的變化,希望對大家有所幫助。