隨著車企、手機廠商、家電等制造企業(yè)業(yè)務(wù)的快速發(fā)展,軟件應(yīng)用開發(fā)規(guī)模也隨之不斷擴大。不同類型的交付制品的管理也成為DevOps落地的一大難題。制品分散管理,存儲隨意,下載困難,分發(fā)緩慢等現(xiàn)象長期受到產(chǎn)線用戶挑戰(zhàn),急需快速解決。經(jīng)過業(yè)務(wù)場景分析及用戶調(diào)研后,總結(jié)為以下通用問題:
痛點
1,制品存量大
制品達到PB級別,分散存儲到S3及EMC存儲上,管理分散,浪費存儲,并且數(shù)據(jù)量在成倍增長。
沒有合理的制品清理機制,導(dǎo)致過多無效存儲
2,制品質(zhì)量缺失
制品無質(zhì)量標簽,篩選版本復(fù)雜,增加迭代時間,測試人員經(jīng)常下錯版本,浪費時間
制品無版本概念,經(jīng)常出現(xiàn)制品覆蓋現(xiàn)象,最終導(dǎo)致發(fā)布失敗
3,制品分發(fā)復(fù)雜
由于存量過大,國內(nèi)多地研發(fā)中心、海外研發(fā)中心同步制品不可行,多地傳輸浪費帶寬
制品無統(tǒng)一管理,分散到不同團隊,不同集群上,不便于數(shù)據(jù)資產(chǎn)梳理
制品往往需要分發(fā)到不同的工廠、合作伙伴、售后站及IoT終端,場景復(fù)雜
4,制品下載緩慢
單文件最大達到100G+,下載時經(jīng)常出現(xiàn)丟包、中斷等現(xiàn)象,用戶體驗極差,浪費時間
解決方案
1,解決性能瓶頸
在下述部署條件下進行性能測試,得到了一份超級滿意的測試報告,在極端數(shù)據(jù)讀寫的壓力下,6節(jié)點Artifactory的每小時吞吐量達到了10TB級別,目前基本可以承載國內(nèi)所有軟件研發(fā)企業(yè)制品的吞吐量,具體測試報告可以聯(lián)系JFrog的工程蛙們了解測試細節(jié)。
2,解決制品大批量下載問題
JFrog提供高性能下載工具jfrog cli,可實現(xiàn)分片、多線程、斷點續(xù)傳等下載方式,基本可以打滿網(wǎng)絡(luò)帶寬
JFrog在服務(wù)端提供cache技術(shù),可實現(xiàn)有ssd磁盤緩存熱文件策略,如緩存空間大,可緩存所有熱文件,提升下載速度
由于服務(wù)端網(wǎng)絡(luò)端口依然存在瓶頸,可使用p2p技術(shù)進行分流,提升下載速度3-4倍
3,異地分發(fā)能力
私有化部署+Saas服務(wù),實現(xiàn)制品庫多云多數(shù)據(jù)中心混合架構(gòu),通過倉庫聯(lián)邦及高速分發(fā)兩種策略,鏈接世界所有節(jié)點,實現(xiàn)制品分發(fā)
用戶案例
某手機廠商案例
1,某手機廠商,使用JFrog Artifactory 6個節(jié)點,架構(gòu)設(shè)計如下:
承載業(yè)務(wù)量:
接管整機構(gòu)建daily及Release項目50個,每月420T整機制品包,目前共存儲4PB+數(shù)據(jù)
接管組件構(gòu)建項目11000個,每周組件個數(shù)231000,150T組件包,目前共存儲1PB+數(shù)據(jù)
每小時上傳流量接近3TB,下載流量接近2TB
峰值上傳流量15G/S,下載流量5G/S
制品庫存儲總量達到了6PB
2,解決質(zhì)量缺失
通過JFrog Artifactory的元數(shù)據(jù)及AQL功能,確保每個制品均具備10條以上的質(zhì)量數(shù)據(jù)標簽,實現(xiàn)開發(fā)與測試之間零溝通,使版本具備自動化篩選能力,避免下錯版本,浪費時間。
具體實現(xiàn)為,開發(fā)團隊構(gòu)建制品版本,并將過程數(shù)據(jù)、需求數(shù)據(jù)、測試數(shù)據(jù)、匹配機型數(shù)據(jù)等自動補全在制品的元數(shù)據(jù)屬性中,如未攜帶此數(shù)據(jù),則無法成功上傳。測試人員在使用制品進行燒機測試時,則通過自動化腳本,自動篩選符合自己機型并具備一定質(zhì)量屬性的制品,自動測試,整個版本篩選過程無需人與人的溝通,一切自動化完成,提高效率,避免出錯。
通過此項改進,獲取了如下收益:
打造制品可信平臺,確保所有交付組件包攜帶質(zhì)量元數(shù)據(jù),便于快速定位版本
制品清理機制,定期實現(xiàn)制品清理
3,解決制品分發(fā)
在此方案架構(gòu)下,為了統(tǒng)一管理集團所有產(chǎn)線制品,后期將制品分布在5個Artifactory集群中管理,其中app應(yīng)用使用一個物理集群,不同產(chǎn)線整機版本各使用一個集群,私服及Docker鏡像使用一個集群。由前段CI工具統(tǒng)一控制制品寫入位置及讀取位置。另外在成都、重慶、上海分中心建立只讀集群、實現(xiàn)制品快速分發(fā),多地可讀。同時在印度、印尼、孟加拉、阿爾及利亞等地工廠建立只讀集群,按需分發(fā)制品到工廠。
為了優(yōu)化下載速度,該方案中使用了JFrog Artifactory的p2p下載功能,在不同地域的分廠中沒有設(shè)置只讀節(jié)點,而是使用p2p的peer節(jié)點,節(jié)約成本,加速下載。整體制品庫架構(gòu)如下:
免責(zé)聲明:市場有風(fēng)險,選擇需謹慎!此文僅供參考,不作買賣依據(jù)。