字节跳动如何从 0 到 1 打造一个开源项目？

单常规项目这一项，字节跳动主动开源了 50 多个项目，其中代表项目有前端的 Web 框架 Modern.js，云原生领域的中间件集合 CloudWeGo ，机器学习领域开源的高性能分布式训练框架 BytePS，以及联邦学习平台 FedLearner 等等。如果从数量上看，常规项目里排名第一的是基础架构相关的开源项目，除此以外，是和 AI、算法与平台相关的开源项目，以及和前端、音视频相关的开源项目。

从确定要成立开源委员会到开源委员会正式成立，期间我们用了半年左右时间来完成前期准备工作。开源委员会成立以后，我们面临的第一个问题是什么样的项目适合开源？

• 具备普适性；
• 为开发者提供便利；
• 助力社区/行业形成统一标准；
• 具备技术领先优势，不重造轮子，避免 KPI 工程。

• 技术领域中没有形成事实标准，能够填补局部空白；
• 开源技术可覆盖的开发者基数大，具有普适性；
• 字节跳动在该技术领域有优势，能推动领域技术发展；
• 不与公司业务发生冲突；
• 能够推动自身业务发展、提升技术影响力。

• 一个开源项目不应该去设立短期 KPI，这样容易本末倒置，让大家动作变形。所以我们会制定一些长期的北极星指标，这些指标会围绕我们前面说的几个价值点来进行衡量；
• 我们追求打造有价值的精品项目，这个优先级要高于对各技术领域的广泛覆盖；
• 我们认为通过一个开源技术去创造用户价值，它的优先级要高于实现短期商业变现；
• 安全和合规是底线。

CloudWeGo 是由字节跳动基础架构团队开源的一套企业级云原生中间件集合，帮助企业快速地搭建自己的微服务系统。专注于微服务通信与治理，具有高性能、可扩展、高可靠、易用性等几个显著特点。

CloudWeGo 的项目都是在字节内部经过大规模落地实践验证的，开源后，项目的每项迭代更新都经过内部业务场景实践，内外能力一致，是一个真正的企业级落地项目。其次，CloudWeGo 提供的功能，尤其是协议支持和服务治理，都是能解决真实业务痛点的，每一行代码优化都能实实在在地提升用户服务的性能。最后，CloudWeGo 的研发也借鉴了一些知名开源项目的设计思路，同时也依赖一些开源项目的实现，它的开源不仅是字节跳动对开源社区的反哺，也是对社区工具链的进一步丰富。

CloudWeGo 目前开源了 Kitex、Hertz、Netpoll 和 Thriftgo 等项目。

发展到今天，cloudwego/kitex 已经有超过 4.7K 的 star，Netpoll 也有超过 2.9K 的 star。目前 cloudwego/kitex 已经支持接入阿里云的微服务引擎 MSE、应用实时监控服务 ARMS，还有腾讯云的微服务引擎 TSE。

同时，项目也在积极与字节跳动推出的云服务平台火山引擎的相关产品做集成，完成后相关产品和能力也将陆续地对大家开放，方便开源用户快速上云。

下面我再分享另外一个也是非常重要的领域 —— 安全领域的开源项目实践，这个开源项目叫做 Elkeid，意思是瑶光 / 破军，也是北斗七星之一，它解决的问题就是主机安全。Elkeid 是由字节跳动内部安全与风控团队自研的一个新的主机安全解决方案，它具备几个鲜明的特点。

Github：https://github.com/bytedance/Elkeid

一个就是规模大，能够支撑字节跳动内部百万级的服务器数量。另外一个特点是 Elkeid 采用了字节内核态的技术进行大多数指标和信息的收集。这样一方面可以极大地提升性能，另一方面也可以采集更多、更丰富的数据，从而大大增强我们的检测能力。

• 实现了端上采集，后端做分析，降低在端上原地的计算压力；
• 后端所有的组件都可以支持高可用，从而可以支持百万级别规模的接入；
• 整体的依赖少，维护成本低；
• 二次开发友好，每一个主机上的 Agent 都支持不同的插件，从而实现一些定制化的能力。

进一步随着混合云和云原生发展的越来越快，传统的主机方案很难适应新的容器化和云原生化的这样一种新的应用形态。当我们看到这样一个趋势以后，我们也希望能够把自研的 Elkeid 开源出来，和领域去进行共建，能够借助更多的力量，我们去涵盖更多的场景，去开发更多的策略，进而提升整个我们项目的有效性。

字节跳动在数据仓库、数据分析这个重要的领域从开源演化出来了一个技术，叫做 ByteHouse。从 2019 年之后，字节跳动开始广泛使用 ClickHouse。目前，ClickHouse 在字节跳动内部的总节点数已经超过了 1.5 万，管理的数据总量也达到了 600 PB 之多，每日查询的请求超过上亿次，它的应用场景也非常多。

ClickHouse 本身有很多的优势，如果总结下来就是多、快、好、省。当然，ClickHouse 本身也有不适合的场景。比如说对于 KV 、 Blog 或者文档存储的支持能力不够，或者在查询中如果使用大量的 Drive，也不能够特别好的支持。

除了这些局限以外，随着字节跳动深度使用，在第二阶段我们也开始遇到一些问题，很多问题的根源其实都是来自于 ClickHouse 的架构。随着字节业务的发展和扩张，ClickHouse 集群的算力会逐渐成为瓶颈，这时候我们就要对集群进行扩容。一旦扩容，数据也要相应的移动，去做所谓的重新平衡。但是在重新平衡的过程中，又会有很多其他的开销、运维的准备工作。包括应对数据丢失的风险，要保证原数据的一致性和正确性。所以这样也会导致错失很多集群扩展的最佳时间。

基于 ClickHouse 这些问题，在第三个阶段，我们就开始进行对应的技术优化。最主要的一个技术优化点就是我们使用了计算和存储分离的架构，也叫做分解式的基础架构。

原来在一台节点上既做存储又做计算，但是在分解式基础架构或者存算分离的架构里，会提供一个通用存储层。计算层可以自由地进行灵活的弹性伸缩，如果需要更多的算力，只需要添加更多的计算节点，如果需要更多的存储空间，可以扩展存储层所需要的容量。当然，弹性的伸缩还带来了无尽的扩展性，因为数据是在存储层中共享的，所以理论上我们可以横向地扩展，以尽可能的利用更多的计算资源。这个设计对于集群管理者十分友好。

这个新架构也会带来一些挑战，我们也设计了对应的解决方案。比如性能问题，共享存储的架构是否会引发一些性能的妥协。当进行 ByteHouse 研发时，我们通过增加数据的缓存层来弥补远程读写的性能损耗。

第二个挑战就是 ByteHouse 引擎在读写分离的架构下，数据存储的系统我们希望可以适配使用不同的场景和不同的实现方案。比如说本地存储就会适配 HDFS，原始数据文件就不需要做大量的迁移。当我们部署在不同的公有云的时候也希望能够快速地适配不同的云存储。

因此，在整个的物理存储系统之下，我们就需要构建一个抽象层，这一层我们内部管它叫 VFS，Virtual Filesystem，就是虚拟文件系统，来提供面向不同存储系统的访问接口。这是第三个阶段，我们做了一系列的技术优化。

到了第四阶段，当我们实现了一些自身的业务优化或者是功能创新的时候，我们也希望能够反哺社区。

ByteHouse 作为基于容器化和云时代的计算引擎，一个很大的亮点就是架构上实现了计算和存储的分离，允许两者去做独立的扩展和弹性的伸缩。同时，我们可以方便用户根据不同的业务工作负载特点，来实现实时的计算和存储的资源配比，来达到最高的 TCO。基于这样的一些架构的设计和技术创新，我们开始不断地把 ByteHouse 再进行产品化，并且把它定位成一站式轻量的云数仓。

本文转载自 51CTO 开源基础软件社区

下载云原生白皮书

基于字节跳动基础架构提供的云原生技术能力和技术实践，火山引擎已经构建了全栈的云原生服务产品矩阵，包括面向算力的云原生服务、面向应用的云原生服务和面向场景的云原生服务三大板块。

扫描二维码，下载火山引擎云原生白皮书

点击【阅读原文】，加入我们！