10月10日,有媒體刊登了一篇文章「1100億行原始碼,這家公司如何應對大規模代碼託管的挑戰」,預告上海QCon將邀請華為專家在技術裂變中的可信軟體開發專場做演講。文章中心思想是希望開發者關注做好代碼倉庫的版本控制,保證軟體開發過程可控性,並吸引開發者參會。
說者無意,聽者有心,1100億行代碼迅速吸引了開發者的關注。
網友們紛紛拿出計算器,用1100億行代碼計算華為的人均代碼產出,更有好事者拿這個代碼量和Google對比,以證明華為的代碼量過於龐大,軟體工程能力有待改進。一夜之間,「如何看待華為1100億行代碼規模的代碼庫」的話題被頂上了知乎熱榜。
網友的意見基本分成3派:貶低派:質疑代碼量太大,存在冗餘代碼,過程管理不佳,甚至質疑拷貝粘貼代碼。解釋派:從華為的業務規模,業務量,員工數,軟體歷史,通信設備與網際網路的區別等方面,解釋1100億行代碼的合理性。分析派:筆者認為網友stephenzhao的分析最具代表性,他把1100億行代碼的原因歸結為分支「branch」,而分支的數量又和企業的經營模式息息相關,強市場導向,及時響應客戶,那就多拉分支,典型如華為。one track「一個主線」是對開發和維護最友好的,但對銷售和服務最坑爹。網絡設備升級意味著割接,所以銷售服務都很鬱悶,說你這沒競爭力,華為打補丁就搞定了。但好處是人少,幾十人就能支撐一個平臺。CMO都是和別的項目共享的。華為不苦呵呵地拉分支,搞局點測試,搞性能,出補丁,996,哪來的攻城掠地?這個分析很有深度。
網友引用華為內源平臺莊老師的回覆很明確——1100億行代碼不是光榮,是實實在在的挑戰,1100億怎麼來的不重要,如何搞定這1100億行代碼的管理才是重點。
帶著好奇和疑問,作為華為雲用戶和MVP,筆者參加了QCon上海的華為雲技術專場。
會中,華為雲專家分享了《華為雲DevCloud 在大規模團隊Git協作的探索》,在最後提問中也正面回應了知乎上有關華為雲1100億行規模代碼庫的問題。華為雲專家的觀點如下:首先,華為的產品族多達幾十個,比如傳統通信設備域有路由器、交換機、傳送網、無線波分、5G等產品;晶片領域有手機麒麟晶片和伺服器鯤鵬晶片;伺服器領域有TaiShan;作業系統領域有鴻蒙、openEuler、LiteOS;資料庫領域有GaussDB等等,每個領域從硬體到驅動、系統模塊,再到上層應用,相關組件與代碼倉庫繁多。其次,華為的代碼倉庫可以向前追溯十幾年,與 Google 等網際網路廠商最典型的區別在於華為代碼的可追溯性。網際網路廠商的源碼多數是發布到自己的伺服器上,DevOps是可以從內部的源碼倉庫走到內部的伺服器上,因此網際網路廠商多數不會維護一個10年前的版本與代碼倉庫。而華為的代碼倉庫是在內部Dev開發,產品發布後卻是在用戶的機房中進行Ops的,因此華為必須要歸檔和維護歷史版本,尤其是發布給用戶的版本,包括正式版本和補丁版本,導致代碼倉庫數量非常多。綜上,華為的代碼倉庫數量以及1100+億的代碼規模,從現狀來看是存在的。
華為雲DevCloud 的代碼平臺要託管如此多產品代碼,且多數產品倉庫每天都會被大量的CI工程下載,同時峰值平臺也會收到1萬次下載/每秒的請求,在這種複雜的軟體工程背景下,華為雲專家介紹了華為雲DevCloud 的代碼平臺是如何支撐海量業務的連續性和可信。
華為雲專家表示,華為iSource是華為內部的代碼託管平臺,它在華為雲上對外提供服務的名字是CodeHub(是不是有點耳熟?),這兩者都是華為雲DevCloud的一個組成部分。簡而言之,一個辦公室,兩塊牌子。
iSource/CodeHub的歷史回顧
2014年,華為確定基於GitLab的社區版本進行深度定製,並在2015年4 月底,上線了 iSource 第一代的分布式架構,通過倉庫路由做到存儲IO能負載到不同後端伺服器上。2015年底,為了解決不同華為研究所遠程下載 Git 速度慢的問題,又在華為各地域數據中心建立了節點,實現了多中心分布式架構。各個中心間的同步採用異步同步,雖然不能保證數據的強一致性,但是通過遠程代理等手段實現了用戶體驗上的一致性。
2018年,華為又基於 GitLab 9.0 開始了下一代的架構調整,同時也看到GitHub的架構對原有的分片進行了突破,通過應用層三副本複製,實現一個倉庫同時可由三臺伺服器提供服務。另外,GitHub的Spokes分布式架構,是華為下一步突破的方向,目前正在進行一些基礎性的改造工作,包括倉庫分片微服務,路徑哈希、引用派生等,這些架構上的進步會進一步提升用戶體驗。
由於華為產品代碼倉庫多,派生多,每個產品會面臨眾多倉庫要開發和維護,需要解決如下問題:多倉庫關聯問題,如何解決多個源碼倉庫之前的版本關聯;派生倉庫的管理問題,倉庫派生後相關配置會在派生倉庫失去管控;上遊同步複雜,派生倉庫與上遊倉庫同步困難,會消耗大量工作量;磁碟消耗太快,派生倉庫在使用過程中,會產生大量冗餘存儲。
OMEGA開發模式橫空出世
華為iSource團隊經過了很多嘗試和對比後,最終選擇對標 Gerrit平臺的開發模式,基於 GitLab 的內核,開發了 OMEGA (One-stop MultipurposE Git Access) 代碼倉庫集中式開發模式。
OMEGA 開發模式有如下特點:開發人員不再需要派生倉庫。伺服器上的 Git 倉庫不需要開發人員的開發分支存在,分支大量減少。使用 xml 文件來描述倉庫關聯關係,沒有 submodule 存在的子倉庫衝突問題,可配置化,更容易維護。通過客戶端工具git-mm一鍵推送修改並創建 Merge Request,加快代碼提交速度。
華為雲專家還介紹了OMEGA背後的技術,如客戶端git-mm和iSource服務端協議。總的來說,在OMEGA開發模式下,開發人員不需要fork倉庫,通過 init 和sync 下載所有的倉庫,然後在本地創建一個分支,進行相應的開發工作,最後通過upload 把修改推送到代碼平臺的伺服器上,產生一個Merge Request。同時平臺發送消息給相關的pipeline server,啟動相應的CI工程。如果CI工程不通過,或者 committer 審核不過的話開發人員可以進行修改並更新Merge Request,沒問題的話就可以刪除本地的開發分支,進入下一步的迭代開發。同時在pipeline server上可以通過命令來記錄各個倉庫的快照情況,有了這個快照,就可以對每條CI的結果、每次代碼檢查的結果 ,包括發布的每一個版本,進行源碼回溯。通過這個快照,完全還原當時構建時每個倉庫對應的提交點。
結束語
聽完華為雲專家的介紹,筆者的感覺是,代碼託管平臺背後的技術並不簡單,如果企業的開發模式稍複雜,代碼量大一些,絕不是自己搭建一套開源版就能完全解決,真遇到問題時,我總不能自己去修改開原始碼吧,從這個角度說,花一點錢買服務,聚焦在核心業務上,反而是低成本的選擇;其次呢,我們看到了華為的OMEGA技術的創新,當你遇到倉庫多,派生多,多倉庫關聯,多個源碼倉庫之前的版本關聯,存儲量大等問題時,或者說現有的代碼託管平臺體驗不好了,你應該考慮一下OMEGA,要麼直接使用華為雲DevCloud旗下的CodeHub,要麼你等華為開源。華為雲專家也透露了 OMEGA 的開源計劃, 2019年底將上線DevCloud產品CodeHub代碼平臺,在2020年做到開源。
筆者獲悉,2020年2月11日-12日期間,華為公司面向ICT領域全球開發者的年度頂級旗艦活動——華為開發者大會2020(Cloud)將在深圳會展中心舉辦。屆時會有哪些乾貨出爐,讓我們拭目以待。