Linus:就算我被巴士撞了,Linux內核也不會有事

在 8 月 31 日舉行的北美開源峰會上,Linux 的創造者 Torvalds 在與 VMware 的首席開源官 Dirk Hohndel 的談話中分享了他對 Linux 未來的看法。他稱如果他被巴士撞了他不擔心內核會受到沖擊。雖然這個假設不太吉利,但卻很有道理,為什么呢?

工作流程比代碼更重要

“我真正擔心的是補丁的流程,工作流程比代碼更重要,”Torvalds 說?!叭绻阌姓_的工作流程,代碼就會自行解決,如果出現錯誤,我們知道如何處理?!?/span>

他承認他現在不清楚內核中的每一行代碼,但這并非是一件壞事。Torvalds 說,內核的龐大規模導致了它日益復雜化,而開源模式是內核成功的核心。因為在復雜的世界里,應對復雜性的唯一方法是公開交流想法。你不能在一個封閉的環境中管理復雜性。

自 1992 年起 Linus 開始采納其他開發人員的補丁,如今,Linus 擁有一個實力超群的內核維護小組,Linux 系統的協助模式是 Linus 負責總體的協調和溝通,他會對接十余名核心貢獻者,每個人都有自己負責的具體領域和項目內容,每次有新的開發任務時 Linus 會將它分配給對應的人;而這十余位核心貢獻者又有各自的熟知并信賴的高手小團隊。Linus 只需知道將任務交給他自己團隊中十余名成員哪個人即可。

Dirk Hohndel 曾經問 Linus,這樣的開發模式是否可持續?Linus 笑著回答如果當前團隊中有程序員變老變胖(感覺像在說自己哈哈)不想繼續做下去的話也沒有問題,因為會有新的程序員補充進來。Dirk 又追問 Linus 道,在內核不斷提升迭代的過程中,是不是你具有著絕對的決定權?Linus 回答到“不是的”,他發自內心地鼓勵大家按照自己的需求建立 fork,如果最終這樣的想法有良好的結果做證明,其精華部分就會被吸收到 Linux 內核項目中。Dirk 對此總結,當今的分支發展再吸收代碼的模式其實反映的就是 Linus 本人或其團隊的決定性。

不難看出,Linus 等技術大神對于軟件開發的流程都非??粗?。一個設計完備、良好運轉的軟件開發流程,對于提升軟件工程的效率,解決突發問題都大有裨益,那么問題來了,怎么做呢?我們看一下 Facebook 的經驗案例。

Facebook 是怎么做開發與部署的?

Facebook 是世界上最大的社交網站,早在 2017 年,其月活就超過了 20 億,是微信的兩倍還多。支持這樣一個站點的運行,還要不斷發布新的功能,Facebook 的工程師是如何做到這一切的?

Facebook 的工程師們不會像傳統軟件行業那樣使用瀑布模型進行開發,他們不斷地開發新的功能,并迅速上線,讓用戶能夠訪問到這些新功能,這就是大家口中經常提到的持續部署(continuous deployment)。在他們看來,Facebook 的開發永遠沒有到頭的那一天,代碼庫在不停地增長著,代碼隨時間呈現超線性增長的趨勢。

在 Facebook,所有前端工程師都工作在同一個穩定的分支上,這也能加快開發速度,因為省去了繁瑣的分支合并過程。在日常開發中,每個人都用 git 在本地進行開發,當代碼就緒之后,就會將它推送到 SVN 上(之所以是 SVN,這是出于歷史原因),這樣就很自然地區分開了開發中的代碼和可以上線的代碼。

但是為了保證網站的穩定運行,并非是工程師將代碼推送到 SVN 上,認為可以上線,代碼就能發布上線的。Facebook 采用了一種兼顧了速度與穩定性的做法——將每日發布與每周發布結合到一起。所有的代碼變動默認是每周發布,每次發布會包含相對比較多的變更,在每周日的下午,代碼會被發布工程師推送到 SVN 上,隨后會進行大量的自動測試,其中包含很多針對正確性和性能的回歸測試,這個版本會成為 Facebook 員工內部使用的默認版本,正式的發布通常被安排在周二下午。

發布工程師會為每個工程師的歷史表現打分,內部稱為“Push Karma”,比如那些代碼經常出問題的人,分數就會相對較低,他們的代碼自然也會受到更多的“關照”。這樣做的目的是控制發布的風險,而非對某人做出評判,因此這個分數是保密的。除此之外,越是大的變更,或者在 Code Review 時討論越是多的代碼,也是風險較高的地方,同樣會受到更多的“關照”。

在被納入發布之前,代碼已經經過了開發者的單元測試和 Code Review,在 Facebook,Code Review 是非常重要的事情,他們使用名為 Phabricator 的工具進行 Code Reivew,該工具是和代碼版本管理整合在一起的。

在大量的自動化測試之外,每位員工在內部使用 Facebook 時也相當于進行了高密度的測試,每位員工都能報告自己發現的問題,寫代碼的人多了,代碼增長的快了,相對而言,對代碼進行測試的人也多了。

在性能方面,Facebook 使用 Perflab 對新老代碼的性能進行對比,如果新的代碼性能不理想,并且開發工程師無法及時修復,那么相關代碼就會從本次發布中剔除出去,待問題修復后再進行發布。每個小的性能問題都是不容忽視的,因為小問題會很快累積起來,變成影響容量和性能的大問題,Perflab 能通過圖表的形式直觀地展現系統的性能。

Facebook 每周的發布是分階段進行的,首先是 H1,即部署到僅有內部訪問的服務器上,進行最后的測試,很多公司也稱其為“預發布”;隨后是 H2,部署到幾千臺服務器上,開放給一小部分用戶;如果 H2 階段沒有發現問題,則進入 H3,部署到全部服務器上。

如果在這個過程中發現問題,工程師會立即進行修復,隨后重新開始分階段的部署。當然,也可以選擇回滾代碼,有兩種回滾方式——常見的是回滾某個變更及其依賴的文件,另一種則是回滾整個二進制包。

這個“準持續(quasi-continuous)發布周期”的最大優點在于:它迫使我們開發下一代工具、自動化和流程,以使公司能夠擴大規模。

在發布時,與變更相關的開發者必須在線,發布工程師會通過 IRC 機器人進行確認,如果人不在,那么他的變更會被回滾。這樣保證了問題能夠在上線之初就被快速發現并修復,當然,想在這么大的一個系統里及時發現一些問題有時也是很困難的,所以 Facebook 會結合內部工具 Claspin 和外部的信息源(比如 Twitter)持續地監控系統的健康狀態。

通過 Gatekeeper 系統,工程師們可以方便地控制多少用戶能夠訪問特定的新功能,篩選的條件可以是地區,也可以是年齡,在遇到問題時也能迅速關閉某個功能的入口。在 Gatekeeper 的幫助下,工程師們能方便地進行 A/B 測試,藉此迅速收集用戶的真實體驗,對產品做出調整。不要忘了,在 Facebook,是工程師來選擇自己做什么的,那么工程師們肯定是選擇把東西做出來,看看用戶的反應,而不是坐在會議室里和一堆人開會去猜測用戶想要什么。

現在,Facebook 有數千名名開發工程師,但卻沒有獨立的測試工程師。每位工程師都可以看到全部的代碼,并且能提交補丁,或者提交詳細的問題描述。工程師們需要自己編寫詳盡的單元測試,他們的代碼還要通過所有的回歸測試,并能支持后續的各種運維工作。

除了要對自己的代碼負責,他們還要面對各種巨大的挑戰,往往要針對多種解決方案進行大量試驗。比如,當時為了解決 PHP 的性能問題,有 3 個不同的方案同時在進行開發,當某個方案的負責人發現另一個方案更好時,他們就會停下來;最后 HipHop 勝出了,但另兩組人的精力也沒白費,他們提供了重要的備份能力。

Copyright ? 2008-2019 Aiitec Inc. AII rights reserved 廣州愛特安為科技股份有限公司 版權所有
地址:廣州市荔灣區花地大道中66號荔勝廣場(華南新三板大廈)北塔13樓
銷售熱線:020-81537575、400-000-8130總機:020-81010649
番禺分公司地址:廣州市番禺區鐘村街鐘韻路56號2樓
澳門分公司地址:澳門亞美打利庇盧大馬路346號勝昌商業大廈3樓D室
網站備案號:粵ICP備 10206031 號 股票代碼:872375
金博188官方网址