如何看待华为1100亿行代码规模的代码库？华为云MVP这样说

　　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)将在深圳会展中心举办。届时会有哪些干货出炉，让我们拭目以待。

特别提醒：本网内容转载自其他媒体，目的在于传递更多信息，并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。