像很多公司一样，字节跳动接触开源也有一个从 0 到 1、由浅入深的过程，大体经历三个阶段：
第一阶段，使用开源。 为了推动业务更快发展，如果已经有比较好的、比较成熟的开源技术和工具，我们拿过来使用。
其实在字节跳动业务发展的早期，在我们刚刚构建我们自身的技术中台和基础架构的时候，我们就大量采用了公有云，并且在公有云之上广泛采用相关的开源技术和开源中间件，来快速打造我们自身的技术中台。技术中台也推动了字节跳动包括抖音、头条等业务的发展。
第二阶段，参与开源。随着我们开源用得越来越深，在自身业务场景下，我们还会做很多的创新，包括对原有的开源项目会做技术的优化。第二个阶段我们也会把我们所产生成果反哺到社区里，与社区同学一起进行经验共享。
第三阶段，主动开源。 当这样的积累、经验优化多了以后，甚至我们会形成自己的完整项目。这就到了第三个阶段，我们会开源一些完整的、体系化的项目回馈到社区。
讲到主动开源，我这里也做了一个统计。大概从 2015 年我们开源 Rcproxy 项目开始，我们一直就在开源的层面不断地去提出我们自己的开源项目。
这几年大家从统计数据可以看到，我们总共开源了超过 100 个项目，当然这些项目我们也做了严格的分类。
比如常规项目，所谓常规项目就是端对端提供一个完整的场景化解决方案，或者是提供一个完整的功能闭环，这是我们的主体项目。
除了常规项目以外，我们也会辅助地去开源一些相关的 demo、CLI 或者 SDK 工具，这些是辅助的开源项目。
只看常规项目的话，过去字节跳动开源了超过 50 个主动开源项目，其中代表项目有前端的 Web 框架 Modern.js，云原生领域的中间件集合 CloudWeGo，以及在机器学习领域开源的高性能分布式训练框架 BytePS、联邦学习平台 FedLearner。
如果从数量上看，常规项目里排名第一的是基础架构相关的开源项目，除此以外，是和 AI、算法与平台相关的开源项目，以及和前端、音视频相关的开源项目。
1、开源委员会的责任和工作范畴
从 2015 年到现在，绝大多数开源项目由我们工程师的个人兴趣驱动。
这虽然打造了一种很好的开源文化，但过程中其实也遇到了一些问题，比如规范性问题，比如前一段时间引发的所谓抄袭风波。
这使我们意识到，开源仅仅靠工程师的个人兴趣驱动是不够的，还需要引入公司级的策略、规范与流程机制，这也是字节跳动开源委员会首先要做的工作。
此外，当公司越来越大，工程师投身开源的时候，需要合理分配精力和资源到更重要的战略型项目上，这也是我们成立开源委员会的另外一个初衷。
当然，开源委员会还要推进各个公司、组织、社区在开源领域建立更好的合作关系。
从确定要成立开源委员会到开源委员会正式成立，期间我们用了半年左右时间来完成前期准备工作。
开源委员会成立以后，我们面临的第一个问题是什么样的项目适合开源？
我们的标准是：
- 具备普适性
- 为开发者提供便利
- 助力社区/行业形成统一标准
- 具备技术领先优势，不重造轮子，避免 KPI 工程
项目开源出去以后，我们也参考 CNCF、云原生技术委员会对项目的分级机制，把项目分成了不同级别。
基于这样的一些项目分级机制以后，下一个问题就是，什么样的项目能够更加顺畅地进入到成熟阶段，获得公司更多的资源以及以更高的优先级去进行开源？
我们的标准是：
- 技术领域中没有形成事实标准，能够填补局部空白
- 开源技术可覆盖的开发者基数大，具有普适性
- 字节跳动在该技术领域有优势，能推动领域技术发展
- 不与公司业务发生冲突
- 能够推动自身业务发展、提升技术影响力
依据这些标准，当决定一个项目是否应该开源后，我们还要保证这个开源的项目能够成功。
针对成功与否，我们就需要有一套所谓的价值观或者价值体系来衡量。
这里我列举了几个我们的思考：
- 首先，一个开源项目不应该去设立短期 KPI，这样容易本末倒置，容易让大家动作变形。所以我们更多的会定一些更加长期的北极星指标，这个北极星指标就会更多的围绕我们前面说的几个价值点来进行衡量。
- 第二，我们更追求去打造有价值的精品项目，这个优先级要高于做项目的广泛覆盖。
- 第三，我们认为通过一个开源技术去创造用户价值，它的优先级要高于实现短期商业变现。
- 第四，安全和合规是我们的底线。
讲完这些以后，我会分享三个具体的开源项目，希望结合这些具体的项目，能够把我们前面提到的一些理念具象化。
2、CloudWeGo：聚焦微服务通信与治理
今天第一个要分享的开源项目叫做 CloudWeGo，它是一个微服务中间件的集合。
CloudWeGo 其实是一套企业级云原生架构的中间件集合，帮助企业快速地搭建自己的微服务系统。
CloudWeGo 也是由字节跳动基础架构团队开源出来的项目，专注于微服务通信与治理，具有高性能、可扩展、高可靠、易用性等几个显著特点。
CloudWeGo 里面的项目都是在字节内部经过大规模落地实践验证的，开源后每个功能的迭代也都是第一时间在内部使用验证过的，是一个真正的企业级落地项目，开源用户和字节跳动内部业务使用的是同一套服务框架。
其次，CloudWeGo 提供的功能，尤其是协议支持和服务治理，都是能解决真实业务痛点的，每一行代码优化都能实实在在地提升用户服务的性能。
最后，CloudWeGo 的研发也借鉴了一些知名开源项目的设计思路，同时也依赖一些开源项目的实现，项目开源出来既是为了反馈开源社区，也是为了进一步丰富开源社区的生态。
CloudWeGo 在第一阶段开源了四个项目，包括：
- Kitex
- Netpoll
- Thriftgo
- Netpoll-http2
发展到今天，CloudWeGo 在 GitHub 社区里，Kitex 已经有超过 4.3K 的 star，Netpoll 今天也有超过 2.6K 的 star。
目前 CloudWeGo-Kitex 已经支持接入阿里云的云服务引擎 MSE、应用实时监控服务 ARMS，还有腾讯云的微服务引擎 TSE。此外，服务治理等高阶的能力也在对接中。
前面我们也提到，字节跳动也提供了火山引擎这么一个企业服务的产品集合，CloudWeGo 项目目前也在和火山引擎的相关产品做集成，完成后相关产品和能力也将陆续地对大家开放，方便开源用户快速上云。
CloudWeGo 非常注重社区文化和社区建设，具有完善的成员晋升机制，同时也积极培养社区开发者作为社区的核心力量。
截止到目前，CloudWeGo 已经先后培养了五位 Committer，他们给社区的发展也做出了重要的贡献，在此感谢这些开源贡献者。
同时，我们也非常欢迎有更多志同道合的朋友可以参与到社区的建设中来，为社区的发展建言献策、贡献自己的力量。
3、Elkeid：更适合云原生时代
下面我再分享另外一个也是非常重要的领域——安全领域的开源项目实践，这个开源项目叫做 Elkeid，意思是瑶光/破军，也是北斗七星之一，它解决的问题就是主机安全。
Elkeid 是由字节跳动内部安全与风控团队自研的一个新的主机安全解决方案，它具备几个鲜明的特点。
一个就是规模大，能够支撑字节跳动内部百万级的服务器数量。当然讲到这块，也稍微剧透一下字节跳动内部的服务器规模。
另外一个特点，就是 Elkeid 采用了我们内核态的技术进行大多数指标和信息的收集。
这样一方面可以极大地提升性能，另一方面也可以去采集更多更丰富的数据，从而大大增强我们的检测能力。
上图是整个 Elkeid 的技术架构，这样一个架构提供了若干个好处：
- 首先，我们实现了端上去做采集，但是在后端去做分析，从而降低在端上原地的计算压力。
- 其次，后端所有的组件都可以支持高可用，从而可以支持我们刚才说的百万级别规模的接入。
- 除此以外，整体的依赖少，维护成本低。
- 最后，二次开发友好，每一个主机上的 Agent 都支持不同的插件，从而实现一些定制化的能力。
我们为什么要去开源这么一个项目呢？其实最早我们也是基于一些已有的主流主机安全方案来提升我们自身的业务系统的安全性。
但是随着我们业务体量、规模和需求不断地增多，我们也逐渐看到传统的方案在应对我们的场景之下越来越暴露出了瓶颈。
随后，基于我们前面所提到的内核态的这么一个开源主机方案，我们自研了 Elkeid，并且为行业里面去证明了该方案的可行性和价值。
进一步随着混合云和云原生发展的越来越快，传统的主机方案也很难适应新的容器化和云原生化的这样一种新的应用形态。
当我们看到这样一个趋势以后，我们也希望能够把自研的 Elkeid 开源出来，和领域去进行共建，能够借助更多的力量，我们去涵盖更多的场景，去开发更多的策略，进而提升整个我们项目的有效性。
4、ByteHouse：赋能下一代技术架构
今天最后一个案例，是一个非常重要的领域，数据仓库、数据分析。在这个领域会跟大家介绍我们从开源演化出来的一个技术，叫做 ByteHouse。
从 2019 年之后，字节跳动开始广泛使用 ClickHouse。目前，ClickHouse 在字节跳动内部的总节点数已经超过了 1.5 万个，管理的数据总量也达到了 600PB 之多，每日查询的请求也有超过上亿次，它的应用场景也非常多。
ClickHouse 本身有很多的优势，如果总结下来就是多快好省。当然，ClickHouse 本身也有不适合的场景。
比如说对于 KV 的支持，对于 Blog 或者文档存储的支持，或者在查询中如果使用大量的 Drive，也不能够支持得特别好。
当然除了这些局限以外，随着字节跳动深度使用，在第二阶段我们也开始遇到了一些问题，很多问题的根源其实都是来自于 ClickHouse 的架构。
随着我们业务的发展和扩张，ClickHouse 集群的算力会逐渐成为瓶颈，这时候我们就要对集群进行扩容。
但是一旦我们进行扩容，数据其实也要相应的去进行移动，去做所谓的重新平衡。
但是在重新平衡的过程中，我们又有很多其他的开销，有很多运维的准备工作。
包括我们要去应对数据丢失的风险，要保证原数据的一致性和正确性。所以这样也会导致我们错失了很多去进行集群扩展的最佳时间。
基于 ClickHouse 这些问题，在第三个阶段，我们就开始进行对应的技术优化。
最主要的一个技术优化点，就是我们使用了计算和存储分离的架构，我们也管它叫做分解式的基础架构。
大家如果看下边架构图就可以看得比较清楚：
原来在一台的节点之上，我们既做存储又做计算，但是在我们的分解式的基础架构或者存算分离的架构里，我们会提供一个通用存储层。
计算层可以自由地去进行灵活的弹性伸缩，这个时候当我们需要更多算力的时候，我们只需要添加更多的计算节点，如果我们需要更多的存储空间，我们就可以扩展存储层所需要的容量。
当然，弹性的伸缩还带来了无尽的扩展性，因为数据是在存储层中共享的，所以理论上我们可以横向地扩展，以尽可能的利用更多的计算资源。这样最终带来一个好处，就是对于集群管理者来讲也更加友好。
当然这个新架构也会带来一些挑战，我们也设计了对应的解决方案。比如我们能想到的就是性能，共享存储的架构是否会引发一些性能的妥协。
当进行 ByteHouse 研发的时候，我们会通过增加数据的缓存层来弥补远程读写的性能损耗。
第二个挑战就是 ByteHouse 引擎在读写分离的架构下，数据存储的系统我们希望可以适配使用不同的场景和不同的实现方案。
比如说如果是做本地存储，我们就会适配 HDFS，原始数据文件就不需要做大量的迁移。当我们部署在不同的公有云的时候，我们也希望能够快速地适配不同的云存储。
因此，在整个的物理存储系统之下，我们就需要构建一个抽象层，这一层我们内部管它叫 VFS，Virtual Filesystem，就是虚拟文件系统，来提供面向不同存储系统的访问接口。这是第三个阶段，我们做了一系列的技术优化。
到了第四阶段，当我们实现了一些自身的业务优化或者是功能创新的时候，我们也希望能够反哺社区。
ByteHouse 作为基于容器化和云时代的一个计算引擎，一个很大的亮点就是架构上实现了计算和存储的分离，允许两者去做独立的扩展和弹性的伸缩。
同时，我们可以方便用户根据不同的业务工作负载特点，来实现实时的计算和存储的资源配比，来达到最高的 TCO。
基于这样的一些架构的设计和技术创新，我们开始不断地把 ByteHouse 再进行产品化，并且把它定位成一站式轻量的云数仓。
除了 ByteHouse 以外，周边我们也补充了大量的工具和能力，来方便开发者更好的使用这项技术，包括获得多种数据源的导入，包括提高查询的这种可观测的能力和诊断能力，以及在多租户下去进行数据权限的多级管控等等。
