騰訊工蜂Git
引言:
近日,2018 DevOps China 沙龍在深圳騰訊大廈舉辦。本次沙龍邀請了多位嘉賓,分享了關於DevOps的實踐與心得。會上,騰訊高階工程師、工蜂系統架構負責人羅奇帶來“揭祕騰訊程式碼管理核心:工蜂 Git 系統架構”的經驗分享,為大家闡述了騰訊工蜂的起源、發展以及未來規劃。
1 騰訊工蜂
騰訊工蜂是騰訊經過10年的積累和摸索打造的企業程式碼管理協作解決方案。具備程式碼檢視、分支管理、會話式開發、整合定製、審查和監控等企業級研發管理系統特性,秉承了前沿的研發思想和先進的研發理念,助力企業貫穿研發流程,讓開發和研發管理更加敏捷高效。
2 工蜂系統的架構
從2012年開始,Git逐漸成熟。因為Git的去中心化、快速拉取分支和便捷使用等特性,被眾多開發者所青睞,Git的使用在國內逐漸流行起來。此時騰訊也正著手準備搭建Git程式碼託管系統,計劃將原來的SVN逐步切換到Git上。
我們採用自研的方式,是因為它既能夠滿足整個騰訊的日益增長的程式碼託管需求,又能夠很好地適應公司企業管理、安全和內部開源文化。在架構方面,面對騰訊這樣的體量,我們需要分散式叢集的能力和高可用的解決方案,也需要強化後臺管理、監控、運維能力。再者,自研有很好的可控性,可以做很多企業定製化的功能。
在系統架構的選擇上,為應對騰訊上百T的程式碼庫總量,和不斷產生的平臺方接入需求,比如自動構建、自動程式碼掃描等,我們選擇了微服務。微服務結合容器部署方案,具備快速水平擴充套件、可插拔和增量釋出等特性,這些特效能夠很好的滿足高可用高併發場景。
微服務的架構模組圖 在儲存擴容方案上,考慮到Git的程式碼庫服務是IO密集型,再加上大庫在分散式儲存中的效能不足,最終選定資料分片作為儲存擴容方案。使用資料分片的優點在於,它可以根據業務需求實現不同的分片策略,控制靈活和方便擴充套件。 在工蜂架構的流程圖中,列舉了SSH、HTTP、WEB和API四種網路請求的方式。Auth用於統一的認證服務,Router用於資料分片定址的路由服務,Manager用於後臺資料的組裝服務,最後端則是程式碼庫叢集。路由是所有服務的核心,所有對程式碼倉庫操作的請求都要通過路由進行定址,並且通過切面的方式,最終實現對業務呼叫的透明和較低的侵入。
以客戶端HTTP請求這條鏈路為例,使用者請求先通過Nginx,轉發到HTTP代理,經過呼叫Auth認證,認證成功後由路由查詢對應叢集節點,最後透傳到對應的Server叢集。圖中右邊的程式碼庫Server採用的是兩地三中心的容災解決方案。
3 架構提供了哪些能力
水平擴充套件能力,由於服務都採用容器部署,再加上無狀態的底層服務,水平擴充套件將更加方便。即使突然有大量業務接入時,系統也能隨時通過調整例項數量的方式進行輕鬆擴充套件,做到快速響應。 服務間的獨立性,單鏈路出現異常時,其它鏈路依然保持正常工作。例如資料庫所在的網路受到影響,web服務出現短暫異常,但由於HTTP代理有快取路由資料,所以使用者最基本的Pull/Push等客戶端操作依然能夠正常執行,開發人員的基本程式碼操作不會受到任何影響。 提供熔斷、有損服務,防止瞬時負載過高引發的雪崩效應。 服務的高可用,我們通過運用兩地三中心和主寫雙活的方式,並且採用跨機房,定期增量備份等措施,提供高標準的可用性和容災備份能力。
4 實際運營中遇到了哪些問題
隨著工蜂系統使用者量的增長,系統在執行中也逐漸湧現出新的問題,例如出現了異地專案訪問慢、大庫專案逐漸增多和大庫Merge操作超時等問題。為了能夠儘快解決這些眼前的問題,我們決定對工蜂系統進行一次新版本的進化。
5 工蜂系統架構的進化
下面是新版本的架構流程圖,黃色部分是系統增加的新特性。我們引入IDC選擇器來解決異地部署的問題,引入LFS用來解決大庫問題,從而分別實現異地專案快速訪問和大庫操作快速響應。
- LFS 在實際運營中,有大量使用者反饋載入慢的問題,通過掃描發現此類使用者的專案包含大量依賴包檔案,其中還關聯大量的歷史。除此之外,有些遊戲業務部門的專案資料量超過50G,其中包含大量的圖片和視訊資源。
下面是LFS部署的架構流程圖。我們部署了LFS代理和專門的LFS伺服器。當使用者有LFS操作時,Git智慧協議會將程式碼、圖片、視訊等檔案的文字指標,通過HTTP代理推送到程式碼倉庫,再將檔案資源推送到LFS代理,LFS代理會先查詢路由,進行許可權認證,最終把檔案資源推送到LFS伺服器。此外,為了能夠讓使用者在後臺進行統一的控制,我們還在HTTP代理中新增了後臺配置,對單個檔案、單次提交進行攔截,攔截後會通知使用者使用LFS進行轉換。
- 異地協同開發 我們發現,異地專案訪問慢的情況發生在這種場景:同一部門的員工分別分佈在深圳和北京,他們都需要使用工蜂系統。北京的小組有獨立的專案,而深圳與北京的員工之間又有公共的專案。當專案中出現對於大庫的Clone和Push等操作時,系統響應會非常緩慢。作為同一個部門,在有公共專案的情況下,部署兩套完全不同的環境是不可能的,那如何解決這種問題呢?
假設IDC1是深圳,IDC2是北京。我們只需在深圳的一套完整系統中增加IDC協調器,然後在北京部署最基本的HTTP代理、路由、IDC選擇器和用於讀寫的新的Server叢集,就可以解決上述問題。當北京的同事在使用客戶端操作時,訪問請求會由IDC選擇器分配到對應的地方,從而實現就近訪問。協同開發方面,由於北京和深圳的Web和資料庫採用同一套系統,所以資料之間是相互可見的,同事之間可以通過Fork公共專案來進行協同開發。
還有另外一種異地協同開發的場景。例如北京的同事需要使用深圳共用的構建系統,進行版本的構建和發版。這種場景是需要在不同網路中使用同一個版本庫。為了能夠實現這種異地構建的場景,我們在北京部署最基本的HTTP代理、路由、IDC選擇器和一臺備機(備機和主機分配在同一個叢集)。當主機接收到寫請求時,協調器會根據IDC標誌,分別對兩邊的備機下發同步任務,實現資料的同步,這樣就可以滿足異地構建的需求。6 進化所帶來的能力提升
大庫方案 在上一個版本中,我們已經通過將儲存資料分片和微服務,讓整體儲存容量可以自由地水平擴充套件,最終實現整體儲存容量無上限。現在通過LFS,單個庫也能實現理論上容量無限制。現在不僅能夠輕鬆應對遊戲部門整體專案遷移的需求,還能做到後臺統一配置和管理攔截大檔案的規則。
異地協同開發能力 通過IDC選擇器,現在工蜂系統能做到就近訪問和協同開發,在保證資料統一和系統易維護的基礎之上,為分公司同事提供了較好的使用體驗。
計算和儲存分離 MySQL的分片支援,讓資料容量和API呼叫也能實現分片操作,從而提供海量資料的支援。
提供Open API和OAuth功能,更好地跟第三方應用整合
7 對未來的期望
工蜂系統作為程式碼託管系統,是DevOps研發工具鏈中重要的一個環節。目前工蜂系統已經通過Web Hooks、API和OAuth實現了和其它系統的對接,共同打通需求、程式碼託管和構建等整個環節。今後,我們將更多地專注於企業的需求,讓工蜂系統開放更多的能力和更加緊密地整合DevOps上的服務,最終形成研發工具鏈的閉環。