首次揭秘！字节跳动基础架构技术迭代演进之路

互联网科技公司的长久稳定发展，离不开坚实的技术支撑。

在全球拥有 15 亿月活用户的字节跳动，背后的技术支撑，离不开牢固的基础架构和对技术理解深刻的技术人。

目前主管字节跳动基础架构团队的是梁宇明，梁宇明 2010 年清华大学毕业后加入 Hulu，曾担任 Hulu 中国数据与广告团队负责人。2018 年，梁宇明离开 Hulu，加入字节跳动，成为字节跳动基础架构团队负责人。

2019 年 12 月 6-7 日的 ArchSummit 全球架构师峰会（北京站），拥有丰富的技术架构实践管理经验的梁宇明将担任会议 Co-chair。借此机会，我们采访了梁宇明，采访中，梁宇明分享了他这些年在工作方式、思考能力、技术洞察、技术管理上的经验，希望对大家有启发。

首先，Hulu 的经历帮助我可以以动态变化的观点审视周边。我是 2007 年在 Hulu 刚刚建立 4 个月的时候加入到 2018 年离开 Hulu，历经了 Hulu 从初创期到高速成长期历经波折逐步进入成熟的生命周期，参与了一段相对完整的企业生命周期。在不同的阶段，企业所展现出来的业务特征、人才结构、组织流程、技术体系有非常大的不同。这份经历让我学会了以动态变化的观点来审视周围，对于企业所处的阶段有更好的判断，进而可以做出更加适应发展阶段的技术决策。

其次，因为在初创期加入 Hulu，涉及到的技术栈相当对来说比较广泛，从搜索推荐到移动端开发再到大数据体系都有所涉猎，对于不同技术体系、业务体系的认知会使得做基础架构的时候可以更加理解业务需求，与业务达成更深度的合作共赢。

从文化上讲，两者有很多的相同点，也有些不同点。相同之处在于，Hulu 的基本文化特征是强调 collaboration & consensus 而非 command & control，这一点与字节的始终创业、坦诚清晰、开放谦逊是非常一致的，一鸣提过一个理念，叫“Context，not Control”，两家公司都有比较强的自下而上推动革新的特征。不同之处在于字节更加敢为和突破，更加强调不设边界，而 Hulu 更加追求稳定，这个业务特征以及用户预期是非常相关的。

从组织管理上来讲，两者有非常大的区别。Hulu 更像是经典的树状组织结构，一些重要共识需要上升到共同父节点达成共识，而字节更加扁平化，构建的是网状链接，可以无需上升到 leader 层面快速达成多团队的共识。在 Hulu 要发挥重要作用需要非常熟悉 Hulu 的流程和机制，将自己的想法在一定的流程中寻求共识；而在字节需要建立更加广泛的连接，通过连接达成共识，前者更加可预期，后者更加高效，适应了各自企业的发展阶段。

从发展阶段来讲，两者也非常不同，Hulu 相对进入成熟期，业务模型趋于固定，商业模式比较稳定，技术体系相对稳定，组织结构和组织流程也相对完善，更加强调的 integrity；字节仍旧处于高速发展期，业务模型、商业模式还在快速演进的阶段，更加强调能能突破敢担当，强调尝试多种可能，在组织结构和组织流程上还在持续优化中。

首先字节的业务模型非常的多元化，不同业务呈现出非常不一样的特征。传统的信息流业务数据以及服务规模极大，对于系统的可扩展性和性能有非常高的要求；新型的飞书、教育等业务的数据模型非常复杂、系统的可用性、数据的一致性要求非常高。这样截然不同的业务模型，使得基础架构很难通过较为精简的几套系统做到全面支持，需要更为复杂的产品矩阵。

其次字节的规模性是非常大的，国内我们有几十万台顶配的物理服务器、数 EB 的存储的规模、数万微服务，而且传统信息流业务模型、中台化构建，使得字节业务架构体系非常复杂。如何在系统稳定的前提下，提升系统的可观可控性，同时有降低系统成本是一个很大的挑战。

最后从发展阶段上来讲，字节还处于高速发展的阶段，在做各种类型的探索，总体上来讲，我们期望尽量减少对于业务的约束（虽然有些约束是更合理的），提供更加丰富的功能 / 特性来使得业务更加快速的迭代，而这种轻约束、重 feature 的期待对于基础架构的挑战尤为困难。

首先需要明确我们的优化目标：

• 支持业务的快速迭代：针对字节当前业务发展阶段，为了更好地支持业务的快速迭代，需要做好这几件事：

• 体系结构持续升级换代：字节跳动急速发展使得早期的架构必然呈现“糙快猛”的特性，体系结构的升级换代是非常关键的，为了字节更长远的发展，需要下定决心给高速行驶的飞机换发动机，而非在已有系统上缝缝补补，所以体系结构的升级换代和支持短期业务增长是一样重要的目标。

其次要对齐我们的技术理念，字节跳动在 2018 年开启了基础架构 2.0 的演进，基本特征就是从「跟随业务」向「源于业务而高于业务」「源于业务而先于业务」的方向发展。

• 基础架构必须「源于业务」，完全脱离业务的基础架构是空中楼阁，容易陷入自嗨。真正的好的架构必须来源于业务实际，这也意味着基础架构需要和业务建立深入联系；

• 「高于业务」是指架构提供的系统基本指标是高于业务需求的，抽象度是高于业务需求的，这一点对于高速发展期间的公司是非常重要的，因为业务发展变化非常快，如果做到「恰好」满足业务需求，会很快发现几个月后，变成「恰好」不满足用户需求。从基础架构侧角度讲，我们也应当给出最佳实战的范例，这也意味着基础架构不仅仅聚焦在 Infrastructure，同时需要提供 Architecture 的支持；

• 「先与业务」是指架构需要对业务发展方向有预判，提前做好准备，因为基础架构很多系统的实现时间很长，有一定的提前量对于业务系统会很有帮助，这也意味着基础架构会做很多面向未来的投资。

首先从组织结构上，字节将在线的基础架构与离线的基础架构融合为一个团队。整合后的基础架构提供了横跨离线在线的存储、计算、研发体系这三大基础设施，成为支撑今日头条、抖音、飞书等所有字节产品线的共同底座。组织结构调整和优化目标密不可分，例如字节的在线编排调度团队（以 Kubernetes 为基础）和离线（以 YARN 为基础）整合为一个团队为离线在线混合部署的快速推进、和技术体系演化打下了坚实基础。

其次从技术体系上，字节的架构主要由三部分构成，存储 + 计算 + 研发体系：

• 在存储层面（注：这里的存储包括 HDFS、对象等经典存储系统，也包括 NoSQL、NewSQL、图数据库等系统），字节的策略是演进到分层存储的体系结构下，在统一的池化存储上构建兼容开源系统的存储产品矩阵来满足业务需求。基于池化存储的分层结构帮我们统一底层实现，将分布式的常见问题以及重要优化实施一次，benefit 所有上层系统，简化上层系统的开发，避免丰富的存储产品矩阵所带来运维复杂性；兼容开源系统的存储产品矩阵主要用来简化业务接入，提升开发效率；

• 从计算层面，我们在推进在线计算系统和离线计算的融合，长期来讲会将 Kubernetes 和 YARN 底层整合为一套资源调度系统，将 PaaS、FaaS、批式计算、流式计算在统一编排调度体系运行，持续推进资源利用率的提升。字节内部也在探索虚拟化和容器化的进一步融合；

• 从研发体系侧（字节将 RPC 框架、PaaS、智能运维、治理系统、稳定性系统、效能系统统称研发体系），字节绝大部分的业务是基于 PaaS 构建而非基于 IaaS 构建的，PaaS 化使得业务方关注的是资源而非机器，对于资源流量统一调配、环境治理系统的统一有非常重要的意义。

再次从合作流程上，基础架构有相对完善的长期规划、中期目标、短期执行管理机制，同时最大限度的将架构的信息同步给业务方，因为在一个业务急速变化、团队规模快速成长的团队中，增强信息同步、减少信息不对称对于增强互信、推进合作有着非常重要的意义。

管理业务预期是非常关键的，有时业务并不是真的此时此刻那么着急，而是看不到好转的希望，所以着急。将长短期计划更好分享给业务，管理好大家的预期，对于营造宽松氛围，梳争取更多资源意义重大。

需求比想象的要收敛：基础架构经常收到各种类型的需求，但如果可以抽象到更高的层次，很多需求是可以归位一类的。这要求基础架构的同学并不是一味执行，需要更多的思考与升华，避免没有想清楚盲目做，留下各种问题，使得迭代速度越来越慢。

优先级是可以谈的，大部分业务需求真实紧急度和宣称的有比较大出入，深入业务，理解真实需求和优先级，有助于抓住主要矛盾，解决核心问题。

作为基础架构要做好“融资”。基础架构经常面临的问题是，业务觉得架构做的不够快，自己有很着急，业务自己就开启了。往往业务侧更注重短期实用性，对于所做的基础设施通用型会有差距。如果以后这些系统交给基础架构维护，架构往往要花费更大的力气重构，很多也会成为历史债；如果不交给基础架构维护，那么公司级的基础设施会逐步分裂。要解决这个问题，需要基础架构擅长和业务达成合作关系，“竖起大旗，引导大家跟随”很重要。要做到在方向和方案层面和业务达成共识，指引关键方向，引入更多业务资源共同开发，借助业务方的力量共同演进。

技术大的迭代往往需要组织结构的支撑，条件允许的情况下，做团队的拆分，分别 focus 在长短期，会非常有帮助。

演进过程中肯定有很多棘手的问题，我在这里给大家讲一个相信每个快速成长的团队都会遇到，但不是所有团队都可以快速走出来的问题，那就是运维黑洞。所谓运维黑洞，就是团队的主体精力都投入在运维中了，系统本身根本没有空迭代，而业务规模还在持续扩张，运维越来越吃力，最终深陷其中。如何预防运维黑洞，相信大家都有想法，例如要推进运维从人肉化到脚本化、到平台化、最后到智能化的进化，但是事实上，很多方向还是会陷入运维黑洞中去，这和技术体系、业务发展阶段等都有密切的关系。

前几个月我接手的一个存储系统，就是因为早期运维投入不够，稳定性投入不够，而业务使用产生了爆发式增长，导致所有的研发几乎都陷入到运维之中去了。为了解决这个问题，我们做了几方面的努力：

• 既然是黑洞，通过自身的力量是非常难逃逸出来的，所以快速人员调配、扩充团队是非常必须的，这时可以把其他团队低优先级的事情先停下，快速召集人力，通过扩充人员这个最土的办法，先把人均运维负载降低下来，这样才有时间去做优化；

• 仅仅是调配人还是不够的，还需要补充不同类型的角色进来，例如陷入运维黑洞这个事实可能反映出来团队已有人才在构建高可维护性系统上可能的缺失，补充不同的角色，补充具有不同特性人员的进入是非常有必要的；

• 在有人的基础上，走出运维黑洞最重要的是准确识别核心问题，避免东一榔头、西一棒槌抓不住重点。明确梳理核心运维痛点，制定专有计划，抓住要点是关键；

• 往往陷入运维黑洞的系统，不仅仅是运维工具本身的缺失，也和系统设计、系统部署等有密切的联系，有的时候需要有大的更改才可以走出来，所谓不破不立。但更改伴随着风险，作为 leader 要做好背书，做最全面的准备，做最坏的打算，对走出运维事故过程中的可能产生的事故不能过激反应，不然会严重的影响团队的决策；

• 最后往往在运维黑洞中的团队，团队士气会是一个很大的问题，补充人力、明确计划，给大家清晰地预期是非常关键的，定期的进展同步，对于积极改变的肯定，多会帮助团队重塑信心。

运维黑洞是大家都想避免的，但陷入其中的不在少数，要走出来需要的不仅仅是重视，而更多的是 leader 的资源倾斜、问题背书、精神支持。

团队的目标要与公司相一致，字节文化中对创新的重视是各团队构建良好创新氛围的基础。针对到架构团队，我忍创新是需要制度来保证的，没有制度保证的创新往往不是 reproducable 的。首先要创新就要求大家不仅仅是关注自己眼前的一点事情，需要获得整体的视野。字节基础架构每双周会做架构内部大范围信息同步，帮助大家了解架构各个方向重要进展，从而获得全局视野，双月的总结也会不断强化这一个过程；其次创新是需要有规划性的，结合字节项目周期，架构每个双月会更新一版本的长期规划，长期规划是自底向上大家一起探讨的，反映了大家共同对于长期的思考，因为双月迭代一次，这里的 overhead 也不会太大。再次创新是需要组织保证的，我们构建了应用创新中心团队，这个团队与其他团队共同推进创新新项目的研发与落地。

最后创新是需要激励机制的，我们在年度绩效总结的时候，要求所有的 team member 必须写一项由自己主动提出而非自顶向下指派项目，也要求所有 leader 写一项由 team member 提出并在他们的支持下落地的项目。通过这些机制结合在一起推进架构的创新。

在我看来，作为一个技术管理者，至少需要具备三方面的能力：Leadership Skills + Management Skills + Technical Skills

• Leadership Skills 用来确立团队方向、凝聚培养团队、构建组织文化，保证我们有正确的人在朝正确的方向走；

• Technical Skills 用来完成 Solution Design、Problem Solving、Engineering Excellence，保证我们技术选型能够支持我们的 vision；

• Management Skills 用来确立工作模式、构建组织项目流程、推进外部合作共识，保证我们在以合作共赢、风险可控的方式前进。

在不同的公司发展阶段，管理者的关注点会有所不同，在不同的管理层级上的关注点也会不同。一般一线 leader 更重 Technical Skills，二线 leader 更加强调 Leadership skills；初创期的 leader 更强调 Technical Skill，快速成长期的 leader 需要更好的 Management Skills。作为字节这家快速成为大型公司的基础架构的负责人，我需要更多的时间确立团队方向、构建团队、设置组织项目流程、推进合作，但要引领基础架构走向下一个阶段，技术又是重中之重，所以这些方面我都在持续学习中。

👇点击阅读原文了解大会详情