在2017在線技術峰會——首屆阿里巴巴研發效能嘉年華上，來自研發效能事業部的楊再新分享了《打造支撐百萬用戶的分布式代碼托管平臺》。他主要介紹了GIT和SVN思想差異、開源的代碼托管平臺的挑戰、云代碼托管平臺的架構設計以及云代碼托管后續發展。其中，他主要分享了云代碼托管平臺的設計思路，穩定性、安全性的構建。

?

以下內容根據直播視頻整理而成。

直播視頻：https://yq.aliyun.com/edu/lesson/548

PDF下載：https://yq.aliyun.com/attachment/download/?id=1839

?

GIT和SVN思想差異

GIT和SVN是目前主流的代碼托管工具，阿里巴巴目前的代碼托管80%在GIT上，經歷了從CBS到SVN到現在幾乎全部應用轉為GIT，其中，GIT和SVN的思想差異主要在以下幾個方面：

• GIT是分布式管理工具，是去中心卻集中，所有服務可以有中心存在但是又可以去中心；
  
• 直接記錄快照，而非差異；
  
• 不一樣的分支概念，GIT分支是指向hash的指針而不是一個拷貝；
  
• 三個工作區，三個文件狀態，SVN只有一個本地worker和服務器worker，這兩個worker是不一樣的，而GIT有一個本地暫存的workspace、存到本地的GIT庫、存到遠端三種文件狀態。好處是，GIT本地的代碼是全庫的。
  

去中心卻集中

圖中origin是中央倉庫，周邊代表四個團隊，他們可以從中心獲取代碼，又相互之間獨立。

數據完整性check

在保存到GIT之前，所有數據都要進行內容的校驗和計算，并將此結果作為數據的唯一標識和索引。所以如果文件在傳輸時變得不完整，或者磁盤損壞導致文件數據缺失，GIT都能立即察覺。GIT使用SHA-1算法計算數據的校驗和，通過對文件的內容或目錄的結構計算出一個SHA-1哈希值，作為指紋字符串。所有保存在GIT數據庫中東西都是用此哈希值來作索引的，而不是靠文件名。

SVN怎么遷移GIT

（1）使用GIT SVN工具

• Git svn clone http://code.taobao.org/svn/xxx/
  
• Git remote add origin git@code.aliyun.com:xxx/xxx.git
  
• Git push origin –all
  

（2）https://yq.aliyun.com/articles/6046 圖文教學文檔

開源的代碼托管平臺的挑戰

阿里巴巴是在2011年開始轉用GIT的，剛開始時調用了許多開源代碼平臺。

Gitlab CE架構

Gitlab自我管理倉庫的功能非常強大，可以很大的解放效率，可以自己創建代碼庫、分配權限。Gitlab CE技術棧前端是由nginx提供http服務，open-ssh全局加密，性能更好，ruby上手非?？?#xff0c;提供API功能方面比較強悍。Git非常依賴于文件體系，所以有專門的文件系統，數據庫選擇MySQL redis存儲緩存。此外還有一個簡單的消息系統用來處理異步消息。

遇到的挑戰

• 可用性：數據量比較小的時候是單機，機器宕機之后穩定性無法保證，物理擴容比較困難，宕機之后的容災也是問題。
  
• 可靠性：數據安全方面，如果磁盤數據壞了之后數據的恢復也是非常大的挑戰。
  
• 高并發的效率：阿里巴巴在研發的投入是非常大的，各種各樣的研發工具非常依賴于托管底層的平臺，底層平臺的數據調用量是非常大的，整個RDC調用數據的量非常大。
  
• 用戶規模。
  

云代碼托管平臺的架構設計

設計思路

首先，穩定性優于體驗，體驗優于成本，運維導向是面向failover。重監控，態勢感知，可回溯；重管控，突破規模制約，代碼量非常大，管控措施很重要。

上圖是機房內的架構，有兩個proxy，分為了http協議、SSHD協議。http協議根據http body信息來進行路由轉發。SSHD協議解析了所有命令行的信息，包括想獲取哪個代碼庫的數據下載，每個集群有多個節點，每個節點有三臺以上的機器，機器有不同角色master、mirror、backup。實際中，讀寫比例比較懸殊，大約為20:1，所以進行讀寫分離提高效率。backup的作用是，如果master掛掉的話，監控上會有感應，此時會將backup切換成master。Sharding記錄節點機器的狀態以及namespace和node節點之間的對應關系，這樣遷移的時候只需要先將數據遷移，那么里面的狀態就會無縫遷移。

構建穩定性

對于單機房，采用主/備切換，根據監控指標自動切換。用VIP、DNS來切的話，時效性會比較慢。同城災備，如果整個機房宕機，那么直接切換DNS。異地災備策略上和同城災備是一樣的。

上圖展示了兩個機房之間的數據同步，MNS是阿里云的消息服務，機房中任何數據變更時會向MNS發送消息，消息類型比較多，比如倉庫的生命周期，訂閱消息通過system hook下發存入MNS里面。在容災機房里面有消息消費，消息消費之后會調用RPC服務，把一些庫創建出來。通過異步消息來做，在時效性上有點差，但是可以忍受，但最終數據是一致的。

引入了新的技術棧。以前采用Ruby+MySQL來做，現在采用Golang，性能好，易部署。此外，使用Grpc，其基于http2，是谷歌新開發出來的工具，支持服務端和服務端之間的加密，易擴展，跨語言。使用阿里云的自研消息系統MNS，支持主題/訂閱。這樣做解決了穩定性，從單機宕機到機房宕機，再到同城宕機都有一定的解決方案。

安全性

數據安全方面采用多重備份，異地災備。流量控制根據IP做流控，此外還會做namespace流控，因為有些庫里面namespace比較多，namespace宕機之后會導致節點的數據量變大，影響整個節點的穩定性，所以需要對namespace做多維度的流量控制。

具體的技術細節是：使用golang的sshd服務替換原生的open-sshd，解決ruby中gitlab-shell啟動慢，并且解決authorized_keys的文件變大后，性能下降的問題；用更多的redis來解決webhooks的性能，大量外部系統依賴webhook，確保穩定性，解決webhook的時效性。

大容量支持

大容量上很好的支撐是提供5GB以上的下載流量，整個數據存儲在100T以上，用戶數可以支撐100w級別，倉庫數也可以支撐100w級別。

平臺能力

每天支撐阿里百萬級別的GIT的操作，覆蓋著阿里全部BU，對外能力輸出阿里云code。阿里云code平臺是2016年上線的，內部體系包括阿里云自己的內部體系以及基于阿里云的其他體系，其他能力一致。

云代碼托管后續發展

從技術來說，目前存儲和計算的分離做的不夠好，node節點上的數據有大量的計算。分離的好處是選用不同的硬件設備來做更好的容量規劃。未來希望更好的支持容器化，拆分更多微服務，對各種邏輯進行歸類。

功能方面，正在打造更好的代碼review平臺。由于本地環境特殊復雜，一些工程在本地不是很好搭建，在線IDE使得所有環境都是固態化，減輕開發的負擔。繼續加強webhook，做到性能更加優化。

總結

以上是生活随笔為你收集整理的打造支撑百万用户的分布式代码托管平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。