编译速度提升 700%,字节跳动中台技术揭秘

阅读数:12864 2019 年 6 月 11 日

在当今世界互联网时代下,平台化正兴起,从基础设施到人工智能等各个领域不断涌现的各类平台,对于软件开发人员及企业带来了深远的影响。在国内提“数字化平台战略”大家可能会觉得比较抽象,比较远大空;我们更喜欢用”中台战略“这个词来描述,这样显得更接地气一些。

从 BAT 到美团、京东、华为都在调整组织架构,建立自己的中台部门,一时间”中台战略“仿佛成了那把角逐互联网下半场的取胜之匙。聊了这么多,到底什么是”中台“呢?这里引用网络上的一段解释:在一部分人眼里:中台就是技术平台,像微服务开发框架、DevOps 平台、PaaS 平台,容器云之类的,人们都叫它“技术中台”;在一部份人眼里:中台就是微服务业务平台,像最常见的什么用户中心、订单中心,各种微服务集散地,人们都叫它“业务中台”;在一些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣) 中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”

上面这段解释其实基本是符合业界对于”中台“在企业中的定位的,阿里玄难之前说过:中台是一个基础的理念和架构,我们要把所有的基础服务用中台的思路建设,进行联通,共同支持端上的业务。

说到中台,大家可能首先会想到阿里的”大中台、小前台“战略,这的确是阿里人不懈努力的技术结晶。华为也早在几年前就提出了”大平台炮火支撑精兵作战“的战略,其实跟阿里的方式有异曲同工之妙。但这里不得不提一个公司,字节跳动。嘉御基金创始合伙人、前阿里巴巴 B2B 总裁卫哲在混沌大学讲课时曾经说过,今日头条的崛起很大程度在于今日头条是大互联网公司中第一个率先实现强中台的公司。有了强大的技术中台支持,字节跳动在前台放四五个员工,就能做出抖音这样的产品来,快速试错,不断迭代,大大提高了效率。

如果你想参与更多前端技术交流,获取更多专家分享,可以加入我们的“前端技术交流群“,社群内会经常讨论前端相关的技术、分享免费学习资料,我们也会邀请前端专家进行社群分享、直播、公开课等活动。如果你感兴趣,欢迎戳此添加社群管理员微信,回复“前端群”申请入群。

GMTC 全球大前端技术大会上,我们邀请到了来自字节跳动的无线研发平台负责人吴思振老师,带来《如何使超大型⼯程矩阵高速运转及⾃下而上的技术演进揭秘》的精彩演讲,他将揭秘字节跳动超大型产品矩阵背后,无线研发中台是如何运作的。下面是我们对吴老师做的简单采访:

Q1: 吴老师你好,请先简单的介绍一下你自己和你目前所负责的业务?

吴思振:大家好,我是吴思振,毕业于北京邮电大学,2012 年开始进行 iOS 开发,目前就职于字节跳动 iOS 基础技术组,负责为公司内所有业务线提供通用组件化技术、编译优化方案、CI/CD 等相关技术输出。

Q2: 我们知道目前字节跳动旗下有一个规模巨大的 APP 矩阵,其中涉及了很多技术层面上的交流与迭代,是一个什么样的契机让字节跳动开始决定搭建无线研发中台的呢?

吴思振:随着公司发展,开始在各个领域开发 APP 进行尝试,在 2017 年年末,字节跳动 iOS 基础技术组将开发环节中的各个阶段进⾏抽象,开始建立起一个具有标准化开发、接入维护流程和辅助工具,实现一键集成、持续反馈和迭代的中台服务。提供了从线下开发到 CI 测试再到线上管理的闭环、一站式研发平台。同时针对各个抽象研发阶段都产出了独立的技术成果,其中针对业内常⻅的超⼤型工程编译效率产出了核心的专利技术。

Q3: 可以简单的介绍一下这个无线研发中台主要有哪几个部分组成,其中有哪些技术亮点?

吴思振:目前研发中台从业务纬度划分包括组件平台、CI/CD、应用管理平台,目前还在规划整合预审平台、发布平台。其中组件平台我们提供了通用的组件管理方案整合公司内所有的组件、CI/CD 平台使用了我们自研的分布式云编译专利方案,以头条为例可以提升接近 700% 的编译速度。

Q4:无线研发平台的出现可以为业务线解决哪些问题呢?在效率上带来了什么收益?

吴思振:无线研发平台是一个具有标准化开发、接入维护流程和辅助工具,实现一键集成、持续反馈和迭代的中台服务,针对业务开发过程中遇到的构建速度慢、代码准入复杂、测试回归效率低等问题提供了一站式的解决方案。其中从业务开发角度,我们提供了增量构建、二进制调试、容器化、自动解耦等功能,解决之前构建速度慢,调试周期长等问题;从 CI/CD 角度,我们使用自研的编译方案,测试出包效率在业务无感知和改动情况下,提升了数倍。

Q5:字节跳动超⼤型产品矩阵的背后是如何协作的?以及如何自下⽽上的进行技术推进的?

吴思振:随着业务的发展以及开发人员增加、每个大型产品都有对应数量的开发同学作为支撑,而在长期的协作中,我们发现各大开发团队都会遇到比较有共性的难点,比如构建速度慢、开发测试周期长、协作困难等问题,而在快速的业务迭代中,各大团队的开发同学往往只会将所在团队的问题进行简单的优化,因此会存在各大团队重复遭轮子,跨业务合作困难等问题,针对这种情况,我们将这些大型产品开发中遇到的问题进行抽象、形成一个统一的解决方案,通过在跨业务团队以及特定大型业务线中试点,逐步推广到其他业务线。

Q6:我看到您的演讲提纲中提到,中台技术为 APP 高速开发提供了安全保障,其中的核心技术–分布式编译在这些 APP 中是如何实践的?

吴思振:再说这个实践之前,先谈之前碰到一个真实的痛点,在大型业务中为了保证正常地发版,往往都是 QA 同学作为最后的验证。之前 QA 同事每到一次验收日经常要等到半夜才下班,究其原因主要是构建测试包速度太慢,在大型业务中构建一次测试包可能要花费几十分钟甚至小时级的,因此针对这一痛点,我们自研了编译方案,在业务无任何改动情况下,将单次打包实践缩短到 3-5 分钟。

Q7:对于大中型互联网公司,如何合理的使用中台技术或者如何提高工程效率,您有什么建议吗?

吴思振:中台的出现是为了在解决技术架构与业务架构慢与贵的矛盾,进行业务‘配速’而生,合理的中台技术必然是以解决当前的业务与技术矛盾为出发点的,因此在中台的实践中,不必一味的去效仿,需要根据当前的业务痛点以及技术架构进行实践,设计一套最符合自身需求的中台服务。

在以上的采访中,吴老师简单的介绍了一下字节跳动的无线研发中台技术,相信大家也没有听过瘾,详细的技术细节和实现方式欢迎大家来大会现场与吴老师面对面交流。目前大会购票倒计时 9 天,想要买票的小伙伴抓紧啦,可以直接联系我们的票务小姐姐:18514549229

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论

最新评论

嘀嗒 2019 年 06 月 14 日 13:35 1 回复
百分之700怎没算出来的?比如原来编译需要1分钟,现在需要-6分钟
哦,sorry理解错了 0 回复
没有更多了