【萨德基】如今,Apache bRPC 在 GitHub 上已经斩获了 14,356 个 Star,并正式宣布从 Apache 创业团队大学毕业正式宣布成为世界顶级开放源码工程项目。但 bRPC 的获得成功并不是操之过急的,开放源码近 6 年,遭受过 KPI 形式的失利;项目组源自相同子公司,都有各别的本职,引致一些街道社区机能没有配套措施通过项目组及时处理合作开发;海内外探讨人文的相同、词汇的心理障碍之类。
这首诗,譬如一个开放源码工程项目怎样同时实现Lizier的高速成长,又是我国合作开发人员怎样从开放源码应用软件的普通用户高速成长为开放源码工程项目的COBOL、众所周知的真实写照。由 CSDN 及《新合作开发人员》统计数据研究能看见,那时,
电视广告序言
从 baidu-rpc 到 Apache bRPC;
从轻量的 RPC 库到通用型、高效能、云原生植物的 C++ RPC 架构;
从 2015 年第二行标识符到时至今日的 20 圆觉标识符;
从乏人问津的街道社区到 100+ 位COBOL;
从子公司外部的 RPC 库到 20+ 的选用子公司条目;
从找寻 Mentor 到获得成功正式宣布成为 Apache 世界顶级工程项目。
……
Apache bRPC 项目组核心初创人员将讲述开放源码过程中从零到一的跌宕起伏,并以时间轴为线索为你呈现它开放源码之路背后的故事。读者通过本文可以斩获对 bRPC 和 Apache 应用软件基金会的基本了解、bRPC 在获得成功大学毕业前所遇到的困难和我们对此的思考和解决方案,以及开放源码的力量和参与开放源码过程中的斩获。
工程项目介绍
Apache bRPC 是用 C++ 词汇编写的工业级 RPC 架构,常用于搜索、存储、机器学习、电视广告、推荐等高效能系统。
Apache bRPC 的亮点主要包括:
支持多种开放源码通信协议,如 HTTP、gRPC、Thrift、Redis 等;
丰富的服务发现、负载均衡、组合访问支持;
高度可扩展设计,很容易添加自定义协议和策略;
极致的性能优化;
可视化的内置服务和调试工具。
下图展示了 bRPC 丰富的功能和无所不在的扩展性:
为什么要加入 Apache 应用软件基金会
Apache 应用软件基金会(ASF)旨在为全世界提供优质的开放源码应用软件,同时欢迎全世界的朋友加入 Apache 街道社区贡献力量,并在这个过程中不断成长、得到肯定、共建开放源码街道社区。无论是否从事应用软件合作开发工作,大家多少都知道它的存在及其提供的优质开放源码工程项目,可见其影响之大、之深远。
此外,参与 Apache 开放源码街道社区,并在自己的努力下正式宣布成为 Apache Committer 和 PMC,更是大多数应用软件合作开发工程师心之所向。
bRPC 在开放源码之初,就有步入 Apache 应用软件基金会的计划。其原因有以下几点:
Apache 应用软件基金会独特的 Apache Way 和街道社区建设思想会让一个开放源码工程项目更规范、更有生命力;
Apache 应用软件基金会的导师制度会给一个开放源码街道社区带来优秀的指导和帮助;
Apache 应用软件基金会会为旗下的开放源码工程项目带来版权和商标上的法律保护;
Apache 应用软件基金会在全世界范围内的影响不言而喻,若是能步入 Apache 应用软件基金会,则会扩大工程项目的影响力,使其步入世界范围的开放源码领域;
Apache 应用软件基金会内的工程项目会更有机会登上世界舞台,并与其他开放源码工程项目建立友好交流,也能吸引更多COBOL加入街道社区。
但同样,步入 Apache 开放源码基金会的门槛可并不简单,特别对于国内的工程项目来说,词汇和地域的心理障碍无疑雪上加霜。
获得成功步入 Apache 创业团队
在 2017 久可靠地维护下去,并留住工程项目核心人员,正式宣布成为我们最需要考虑的首要问题。
当时可行的方案是建立成熟的街道社区、培养更多的 Committer 和合作开发人员。它的思想有点类似从 Single Point of Failure(单点故障)的项目组进化成更可靠的分布式项目组的模式。Apache 应用软件基金会成熟的街道社区培育模式能为 bRPC 带来新的视角和方法,于是我们决定把工程项目捐给 Apache 应用软件基金会,用 Apache Way 来给 bRPC 注入新的生命力,希望它可以可持续发展。
决定之后,我们首先需要获得百度外部管理层的许可,签署捐献工程项目所需要的文档。其次,步入孵化,我们需要找到一位领路人和三位导师。当时负责百度开放源码整体推进的谭中意找到 bRPC 工程项目当时的负责总监,完成了 Apache Software Grant Agreement 文件的签署。其后谭老师又通过各种关系,为我们找到了领路人和导师。领路人是 Dave Fisher,Apache 应用软件基金会非常有名望的导师之一,三位导师分别是 Jean-Baptiste Onofré(我们简称他为 JB),Von(冯嘉)和 Kevin A. McGrail,后来 Kevin 因为太繁忙而中途退出,我们又找了 Apache 应用软件基金会我国地区的第一位女性成员——潘娟作为导师。他们给 bRPC 在建立街道社区和标识符 License 规范上提供了不少的建议。我们也借鉴了相同开放源码工程项目的经验,在 2018 年获得成功发了第一个 Apache(WIP)版本。后来的发版过程也越来越获得成功。
整个过程不在这里详细说明了,简单来说主要做了如下几件事情:
将所有文件的 License 改成 Apache 应用软件许可协议(ASL) ,并检查第三方标识符是否和 Apache 兼容;
把所有的文档译者成英文;
提交一份提案来申请步入 Apache 创业团队。
街道社区之火怎样燎起
提案通过之后,就是孵化和培养街道社区的过程。到那时,我们已经有由 6 个发版管理员发的 6 个正式宣布版本。在今年(2023),还会考虑加入更多的机能发版。
用户、COBOL、Committer 和 PMC 的逐渐增加和多样性的变化
步入了 Apache 创业团队以后,我们面临的问题是:怎么让街道社区活跃进而扩大?街道社区的活跃对于开放源码工程项目尤为重要,无论是用户、COBOL还是 Committer 的活跃都会给工程项目带来收益。活跃的街道社区会带来活跃的合作开发人员,活跃的合作开发人员又促成活跃的街道社区。
在初期我们很难找到合适的新人加入合作开发队伍。关键在于:开放源码工程项目不是子公司工程项目,没有明确的 OKR/KPI 驱动,大家参与的动力主要是兴趣和技术驱动;C++ 是一门复杂的词汇,入门门槛比较高;C++ 场景的多样性在慢慢变小,以致于不是所有合作开发人员都知道 bRPC,也就没配套措施参与。
针对上面这些问题我们也采取了一些措施来尝试解决。
对于第一点,当时没有很好的解决配套措施,靠谱的形式是把街道社区建好和文章写好,可以吸引更多的合作开发人员和用户。我们相信好的工程项目自然会吸引更多的合作开发人员参与进来,事实也证明了这一点。当然也做了一些的运营活动来帮助推广。
对于第二点,我们写了入门文档(https://brpc.apache.org/zh/docs/getting_started/),以及在 GitHub 上标注了 Good First Issue(对新人友好的 issues)方便合作开发人员提交一些基本的标识符和完成整个提交流程。我们还举行了若干个线下的活动。
2019 年开放源码年会上,bRPC Workshop 合影用 bRPC 的过程中遇到的疑问,来拓展更多的 bRPC 使用场景和培养更多的合作开发人员。
截止到目前为止,bRPC 已经有 16 位 Committers,129 位COBOL(2023.01 统计数据)。
源自社区贡献的机能持续增加
开放源码的这几年中,我们经历了机能的持续迭代。相比刚开放源码的时候,我们发布了更多的机能,提高了更多的稳定性,一开始由百度外部完成,后来大部分都是由开放源码街道社区共同完成。比如说 HTTP2、gRPC 协议支持、自适应限流、熔断器、Prometheus 支持、Mac 支持、Arm 支持等重要机能都是由开放源码街道社区共同完成的。
开放源码 5 年(包含 4 年的 Apache 孵化过程)中项目组遇到的困难以及高速成长
开放源码以来我们主要遇到下面几个问题。
(1)精力问题
由于大部分 Committers 都有自己的本职,参与开放源码工作需要平衡好本职和开放源码工作,作为街道社区的一员,可能会出现因为优先级的原因要离开 bRPC 的合作开发工作一段时间然后之后再回来继续参与合作开发,这在 bRPC 目前的街道社区下完全是可能的:工作会由街道社区其他同学完成。街道社区的存在让项目组由 Single Point of Failure 变成了分布式的。参与开放源码会增加额外的工作量,这里合作开发人员就要更加小心去平衡好这些额外的工作量。避免由本职+开放源码的长工时引起的职业倦怠(Burnout) 是让生活和工作可持续进行的重要因素。
(2)街道社区的建立和本土化。
由于 Apache 街道社区鼓励用邮件条目和订阅的形式来探讨问题,这样做的好处是所有的探讨都可以留档,方便之后再次查看和搜索;但这种形式并不适合国内的探讨人文,大家更喜欢拉一个群,在群里探讨问题。于是在初期,为了更好地与用户交流,我们就建立了一个 QQ 群和微信群,来探讨各种问题。后来经过实践,我们选用了一种折中的方案:用 GitHub Issues 来记录一些值得留档的内容,比如需要合作开发的机能描述、某一个需要解决的 Bug 或者一个反复出现的问题;用微信群来解决一些需要及时处理沟通的问题,让用户遇到问题时可以更快联系到合作开发人员。
(3)项目组源自相同子公司,大家有各别的本职,引致一些街道社区 Feature 没有配套措施通过项目组及时处理合作开发。
我们并没有一个专门的项目组来同时实现源自街道社区的需求。很长一段时间以来,合入的新机能往往是合作开发人员在自己子公司有一个这样的需求,在外部合作开发完成并上线稳定了,然后把这个机能贡献给街道社区;如果作为用户有一个新的需求,自己并没有意愿或能力去同时实现的话,只能依赖街道社区有人遇到相同的问题,然后贡献标识符。这个情况在 2022 年有所好转,主要是我们吸纳了更多成员,同时戈君等早期成员回归,带动整个街道社区更加活跃,Issues 解决和 PR(Pull Requests)合入的速度都有了明显加快,并且形成了每个季度定期发版的节奏。
(4)街道社区的可扩展性。
原有的机制没有配套措施适应到越来越大的街道社区。例如,刚开放源码的时候可能一个人花一两个小时就能看完一周内所有的 issues 和 PR,而随着街道社区越来越壮大,这样的形式被证明是不可扩展的,因为个体的时间总是有限的。于是一些新的机制得以建立来解决这些问题:1. 建立 Oncall 轮值,每位同学多于在 Oncall 时才被期待去解决街道社区的 issues 和 PR;2. 对于一个需要合入的 PR,需要有一个源自 Committers 的 LGTM(Looks Good To Me,指标识符已经过 Review,可以合并)就可以合入 master;3. 各种流程的文档化。例如,我们选出下一位发版经理后,只需要按照发版文档来进行发版就可以了。感谢这个发版文档的主要译者——PMC 成员李磊。随着街道社区变大,我们还需要探索更多更好的形式来适应这样的街道社区规模,来让 bRPC 发展得更快更好,不被非技术原因的瓶颈所限制。
开放源码的力量
bRPC 已经是真正意义上的开放源码工程项目,Committers 的子公司分布非常广泛,大部分新合入的机能也是由街道社区共同完成。本篇主要介绍我们理解的开放源码带来的力量。
KPI 形式的失利
bRPC 刚加入 Apache 创业团队不久的那一段时间,当时百度还是很重视 bRPC 的发展,在外部找了一些同学,给他们设置了 KPI,比如一个季度要合入多少个 PR、要在什么时间大学毕业等,但实际的效果并不好。原因是这些同学并不是真正的对 bRPC 工程项目感兴趣,缺乏持续贡献的动力。另一个原因是源自百度外部的 PR 和街道社区的需求并不完全一致,缺少和街道社区成员的沟通,因此难以被街道社区接受。KPI 的方法维持了不到几个月就宣告失利,事实证明街道社区的力量才是推动工程项目发展的真正动力。
街道社区与土壤
开放源码街道社区和产品的关系有点像土壤和树的关系:不能做拔苗助长的工作,只能做好灌溉的工作,并相信树在好的灌溉下会茁长高速成长。bRPC 的大学毕业是一个新的开始,它标志着 bRPC 街道社区已经是成熟可自治的街道社区,我们在未来会继续去发展街道社区(土壤),相信良好的街道社区会让 bRPC 发展良好,使其在更多的场景下更好地发挥它的能力。
参与开放源码街道社区的斩获
参与开放源码街道社区是需要花额外精力的,除了可以为产品本身做贡献,我认为它为工程师自身带来的斩获也是巨大的。
(1)开放源码工程项目提供有别于子公司工程项目的视角,可以学到相同的技术栈和合作开发流程;
(2)能认识有同样兴趣的工程师,他们往往源自海内外相同子公司,交流能产生更多斩获和思考;
(3)开放源码工程项目中获得更多的成就感:短短一行标识符的提交可能会影响所有的使用子公司,具有杠杆效应和大的影响力;
(4)参与街道社区是一份公开的简历,由于所有的探讨和提交记录都是公开的,所有人都能看见你提交和讨论了什么;
(5)紧跟业界动态:知道业界需要的是什么样的 RPC 架构,以及上层使用 bRPC 的应用有什么具体的需求。
从创业团队大学毕业,正式宣布成为世界顶级工程项目
所有创业团队的工程项目最终都希望能走向 TLP(Top Level Project,世界顶级工程项目)。在 Mentor 的指导、PPMC 的探索、Committer 和 Contributor 的支持与付出下,bRPC 开始筹备从 Apache 创业团队大学毕业。
Apache 成熟度评估模型
依据如上所示的 Apache 的成熟度评估模型,可以很好地评估街道社区和工程项目是否成熟。其实在 Apache 工程项目街道社区的初建阶段,建议大家就在这几个方面发力,因为这是官方给予的大学毕业标准及指导方针。以此为方向,探索属于各别工程项目的独特街道社区运作形式,也可谓是百花齐放。
经历 Release、街道社区建设、Apache Member 的指导、Meetup 举办等一系列事件,bRPC 终于在街道社区发起了大学毕业探讨,开始接受 Apache Member 及所有 Apache 成员的指导和评估。即便是经过四年多的街道社区建设,工程项目基本成熟,但面对大学毕业还是有很多工作要合乎规范,例如确认商标是否可使用、完成工程项目官网有关 Apache brand 和 trademark 的陈述、网站符合 Apache Way 等。
最终,bRPC 以 16 +1 binding votes、9 +1 non-binding votes 和 no -1 or +/-0 votes 获得成功通过大学毕业投票。
2022 年 12 月 22 日,Apache bRPC 最终通过基金会董事会决议,加入了 TLP 行列。2023 年 1 月 26 日,Apache 应用软件基金会正式宣布官宣,Apache bRPC 正式宣布成为世界顶级工程项目。
Apache 应用软件基金会官宣博文
未来之路
回首这一路,斩获与付出兼存,而在文章结尾,我们也特别想对合作开发人员朋友说:
感谢所有参与 bRPC 工程项目的COBOL!你们是这个工程项目能获得成功大学毕业的基础,你们的贡献和支持是我们最大的动力,你们的积极参与和不懈努力让 bRPC 能不断高速成长,特性更加丰富、更加稳定可靠、更加灵活易用。我们真诚地感谢你们,希望你们继续在 bRPC 开放源码街道社区中做出贡献。
从 Apache 创业团队大学毕业正式宣布成为 TLP,对 bRPC 来说,并不是一个结束,而是另一个开始。在产品机能上,bRPC 将继续在 RPC 领域上深耕,支持更多协议,提供更丰富的服务治理能力;在性能方面,bRPC 将不懈追求极致性能,引入 RDMA、DPDK 等高效能网络技术,优化线程模型和事件模型等。从街道社区角度讲,bRPC 仍将继续活跃街道社区,鼓
虽然未来的路不可预测,但我们还是坚定地立足于当下,眺望未来,持续地追求我们的愿景。
Apache bRPC Committer 条目
Mentor
Jean-Baptiste Onofré
Von 冯嘉
潘娟
PMC
戈君,字节跳动
何磊,字节跳动
朱佳顺,Google
陈章义,Momenta.AI
蒋如杰,字节跳动
王耀,百度
王伟冰,百度
谭中意,第四范式
蔡道进,Shopee
李磊,自由职业
Committer
牟盖东,腾讯
王维,腾讯
刘帅,百度
王晓峰,百度
胡希国,百度
陈光明,欢聚时代
Apache bRPC 官网:
https://brpc.apache.org/
GitHub 地址:
https://github.com/apache/brpc
译者信息:
朱佳顺,Apache bRPC PMC,目前就职于Google
王伟冰,Apache bRPC PMC,目前就职于百度