发布时间:2023-04-30 10:30
参考链接: 捐赠
序言
今年的双十一对阿里巴巴中间件消息团队来说,注定是个不平凡的日子。在这一天,稳定性小组重点攻克的低延迟存储解决方案成功地经受住了大考。整个大促期间,99.996%的延迟落在了10ms以内,极个别由于GC引发的停顿在50ms以内,对于读写比例几乎均衡的分布式消息引擎来说,这一结果无不令人兴奋。甚至可以毫不夸张地讲,即便拿到明年的Java one大会上,也必定是场非常吸睛的技术干货分享。接下来,团队同学会把相关的经验提炼总结出来,期待能在接下来全球Qcon大会上为小伙伴们带去尽可能多的干货分享。
除此之外,更让大家倍感欣慰是我们终于为赢得世界的尊重,拥抱世界走出了第一步,这一步走的着实不易,每走一步,回头看看,都是记忆满满。正所谓,桥曾坚固,但已坍塌;路虽沧桑,但已破旧;街曾繁华,但已被拆;巷虽深远,但已变旧。唯一不变的,是那生命里留下的深深脚印。
初衷
捐赠最好的项目给Apache~ 这个想法,最早是14年中旬,在开发maven dependency mediator这个开源组件的时候冒出来的。当时,为了解决中间件组件依赖问题,我研究分析了业界最主流的开源方案,有Maven官方的,也有民间的,甚至研究了Gradle的解决方案,很可惜,不知道是不是我们写代码相比老外比较随意,还是说我们的规模达到了让组件依赖熵混乱不堪的境界,必须自己着手撸这么个轮子(平心而论,这些年为各类国际开源社区没少贡献ISSUE或者PR。但即便如此,心中那种撸轮子的”恶念”时不时会浮现)。于是乎,着手写了这么一个组件。接下来问题来了,怎么去维护,怎么做能够持久的去演进这款组件?相信喜欢撸轮子的童鞋都有这样的经历,产品从0到1容易,再从1再到0可就难了去了。放眼望去,这方面做的最棒的无非就是FastJson了,这么些年的坚持,为大家带来了极尽优化的性能(不仅性能,功能方面也不落后于同类产品)体验。能够持久专注,不断演进才应是我辈应该追求的开源情怀啊。
回过头来,我们再来看这个maven组件项目,为了能够吸引更多的外籍朋友反馈,专门写了一个长篇E文,系统化介绍怎么做二进制兼容依赖,从最初的设计编码,到运维部署都有一套相对体系化的方案探索出来,为此还曾想过发表专利来保护下这块,不过后来因为事情多也就搁浅了。到此,我们发现,上面提出的让人纠结的问题还是没有解决,这个项目怎么发展?因为之前的调研过程中,从maven的Codehaus,也就是maven最大“非法”(非官方)插件集散地得到了一些灵感 - 捐赠给它。Okay,接下来,结果大家也看到了。这个小项目发展到1.0.2版本的时候,被我搁浅了(说实话,这个项目的代码质量在当时那种情况,算是不错了。但我要吐槽一下Maven自身的单测框架和集成测试框架,问题还是挺多的。不管如何,如果有童鞋希望展这个项目,可以联系我,截止目前,放眼望去,业界还是缺少这么一个好用的兼容检测组件,这里面还是有一些非常好玩的想法我没有精力落地掉:-))。为什么搁浅?因为当时自己的工作重心主要在分布式消息引擎、消息推送这块,并且也是公司这块几个中间件的贡献者以及负责人。能不能聚焦一下,那些工具撸起来固然爽快,但后续的发展着实让人操心。俗话说,众人拾材火焰高。能不能找几个技术好手把分布式领域的精髓都体现在某个产品中,和当时消息团队的负责人誓嘉(非常低调的厉害家伙:))闲暇时间聊起来,聊到这块,聊到开源,聊到分布式技术,聊到业界分布式消息引擎,聊到它们未来的发展。随后,再随后,方向渐渐明晰了,于是便有了捐赠Apache这个现在看来最最基础的一步。
我个人是比较喜欢聆听批评,尤其是足球和开源这块,等等,姑且先抛开中国男足,今天只谈开源。有很多人讲,国内的开源氛围不好,很多都是只谈绩效,沽名钓誉,尤其是几个大厂甚至把风气都带歪了。即便开源了,设计、源码、文档、社区也是很难持续跟进。不可否认,这样的事实也许存在。但今天,我们把RocketMQ放出来,就是想给大家一个证明,一起来看看由内而外,然后再由外而内这种模式到底能不能行得通。我们彼此心里非常清楚,开源与商业化相辅相成,水可以载舟,也可以覆舟。产品、技术、商业如何能够打好配合,激发出1+1+1大于3的价值来,这也是我们今年思考最多的问题。
MQ简介
RocketMQ是阿里巴巴在2012年开源的第三代分布式消息中间件,不仅在传统高频交易链路有着低延迟的出色表现,在实时计算等大数据领域也有着不错的吞吐。开源至今,社区参与度非常高,国内拥有超大规模的活跃交流群,ISSUE上更是收录了来自全球数百个高质量的话题交流以及问题沉淀。除此之外,在产权保护、知识输出这块,有着接近20篇专利的沉淀。去年,RocketMQ获得了中日韩开源论坛CJK OSS大奖,今年早些时候又进入欧美主流开源门户网站Awesome-java视野,意味着RocketMQ正式走出国门。也正是基于如此卓越的表现,为后续Bruce,Brian等欧美大拿引路Apache奠定了良好的群众基础。
在它之上,我们构建了自己的内部版本MetaQ,还有云产品MQ。经历了几年线上近乎苛刻的场景验证,在双十一当天消息容量达到万亿级的体量。这中间,有不少小伙伴默默地付出着(这里面还有一个小插曲,社区的朋友为感谢RMQ项目,捐赠了近500 RMB,不过我们把这些钱一次性捐赠给公司的公益事业啦:) )。而今天,我们将这些毫无保留的开源出来,就是为了让更多人受益。阿里巴巴是个很讲究感恩的公司,我们取之于开源不在少数,是时候体系化地反哺社区了。什么样的社区能让Alibaba的产品走上更健康的道路呢,思考来思考去,还真只有Apache。相信在Apache这个平台上,没有人会去偷懒,没有会想着走捷径。今天也只是一个孵化项目,想不想毕业,能不能毕业,完全取决于我们对于开源精神的理解和诠释。我想,应该没有人会拿名族大义开玩笑吧(呸呸呸,扯到这上面来了。其实就是要给公司以及国内的同行们带个好头,做个表率,争口气:) )。毕竟,我们代表中国,代表中国最先进,最执着的那批技术探路者。
捐赠历程
接下来,进入重点。一起看看Apache的整个捐赠历程吧。整个历程始于2014年,终于2016年(这里用终于不是很妥当,我们只是刚开始走上正路而已)。想法可能天天有,但怎么落地,尤其是这个想法的落地,非常具有挑战。在研究Apache官网关于捐赠流程的文章后,我们甄选了几位MQ方面非常有经验的老美,和他们聊聊吧。在很诚恳的给他们讲述了我们希望捐赠给Apache的诉求,Brian(ActiveMQ PMC member,Groupon CTO)率先答应了会帮助我们。接下来,开始准备Proposal呗。很快,初稿就出来了。经过和Brian反反复复几次沟通,不断修改,算是有点模样了。这时,问题来了,我们失去了和Brian的联系。虽然说老外非常喜欢度假式放松,但这次回来可真联系不上了。就像断线的风筝那样,我们无所是从。接下来,大家也看到了,这件事情基本上被搁浅了。在John(JCP专家组成员)的邮件里,他也用folded out这个词来问我,到底是什么原因让你们中途搁浅了呢。Okay,搁浅的原因讲清楚了。接下来,时间来到了2015年。通过朋友的引荐,结识了Kylin的总架构师蒋旭(技术上任何牛逼的词都可以往上贴,非常低调的榜样)以及在Apache上的主推手Luke(非常Nice的一位GG,Kyligence联合创始人)。又在Apache 亚洲路演北京站和他以及后来也是我们的Mentor之一的姜宁(Apache多个项目的PMC member,committer)进行了交流,请教了一些禁忌事项。至此,我们捐赠进程又活跃了起来。再后来呢,Luke和姜宁也成为阿里巴巴RocketMQ IPMC国内的两位mentor。不仅如此,他们也欣然接受了阿里巴巴weex团队的邀请(具体牵线人应该是我们可敬的JStorm负责人纪君祥:)),继续在Apache进程中为我们“保驾护航”。说到这里,最最重量的小伙伴要等登场了。除了mentor,我们还需要征集最最重要的champion候选人。Brian这条线断了,需要我们再挖掘一位贵人相助。这个时候“大拿“Bruce(ActiveMQ in Action的作者,这里我不想过多描述他在开源领域的杰出贡献,感兴趣的童鞋可自行google)出现了。给我印象最深的是Bruce一上来就问了我5个“究极”的问题:
是否了解Apache 孵化进程,是否知晓ASF 项目的一些基本要求 是否联系过其他Champion 是否联系过其他Mentor 是否联系过Apache ASF Membe 进入Apache后,RocketMQ会怎么发展
当然,回答这些问题应该不成问题。但从这几问题看得出来,Bruce非常有经验,也非常有心的在尝试帮助我们。此后的岁月里,我们保持着高频度的邮件来往,前前后后大概接近100封吧。考虑到时差,这一来一去,也就2个月过去了。期间又恰逢Bruce金婚19年(由衷的祝福),中间出去旅行了一阵子。很快,一个重要的日子来了。一天,Burce问我”准备好了吗,我们即将开启Apache之旅“。我的回答也毫无犹豫,”Let’s Go~“一切都在平稳的向前推进着。双十一当天,迎来了投票。预料之中的是,社区非常活跃的John对我们提出了几个犀利的问题,对我们的社区数据提出了疑问。本着实事求是的原则,我公开邮件加私信的方式将事情的原委和他一一道来,疑虑担心算是打消了。这里面还有一个小插曲,在大家”交涉“期间,来自Apache董事会的President和Vice chirman也来帮我们说话,用文化差异,包容性等帮我们解困。真的要非常非常感谢他们。
现在回想起来,John为什么会问那几个犀利的问题,主要原因来自他也是ActiveMQ PMC成员,要知道我们网罗了3位ActiveMQ的VP来帮助我们。而且按照Bruce的建议,Proposal里加入了和Apache ActiveMQ和Kafka的客观对比。我的妈妈呀,这一举,为我们带来了这么多不必要的麻烦。在咨询了Bruce之后,我们的Proposal并没有删除这个对比,但是稍微聚焦了一下我们的优势。就这样,看似平稳的投票朝着非常好的方向发展了。
这还没完。接下来,更有意思的事情出现了,Apache Trafodion项目的Release Manager开了一个专题,题目为 - China Contribution. (was: RocketMQ Incubation Proposal)。我的妈妈呀,这跟RocketMQ有毛线关系,实在看不下去了,适时地发表了我的见解。在这个讨论里,大家主要聚焦的问题是Trafodion项目里,来自中国的contributors喜欢用QQ,而不是邮件进行沟通,这让他们很是头疼。说到这,大家想必也看到了,国内其实还是有很多非常乐于开源的同学活跃在Apache社区的。另外,由于标题太过于刺眼,好玩的事情出现了。中国人嘛,看到有人扯到跟中国开源相关的事情,大家不乐意了。Luke,姜宁,陈亮(华为Apache Carbondata孵化项目负责人),包括Databricks那个华人GG,都发表了防御性“声明”。由于各种原因,中国人无法邮件,无法google,所以才。。。最后的结果大家想必也猜到了,不可能有结果,没有结果可能就是最好的结果。所以这里给大家的建议就是,如果希望让国外的小伙伴参与进来,就试着把自己的英语拾起来吧,注释,讨论以及一些必要的文档尝试用英语,本地化社区可以有非英语支持频道!
经过了这么多折腾,投票结果总算出来了,还不算坏 - 10票带binding的+1,无反对票,正式进入孵化期。孵化成功后有望成为国内首个互联网中间件在Apache上的顶级项目,成为全球继ActiveMQ,Kafka之后,分布式消息引擎家族中的重要成员。此次捐赠,也意味着以MQ为代表的互联网中间件在新兴物联网,大数据领域会发挥着越来越大的作用。另外,我必须提一下,虽然目前大数据技术”横行当道“,尤其以Spark和Hadoop为阵营的各大开源平台层出不穷(看看近些年那些最活跃的那些Apache产品)。小伙伴要当心,大数据背后的那些分布式技术都是相通的,看问题学技术要掌握本源,只有掌握了最根本的,在技术广袤的海洋里,你才不会迷失。另外,也正是通过这次Apache之旅,让我深刻意识到在社区里面,有着大量的MQ 爱好者,如果能激起这些久经沙场的国外大拿的共鸣,那么这势必将是一个充满竞争力的社区。
从这些经历中,大家可以清晰地看到,捐赠从想法酝酿到成型,再到落地,前前后后接近一年半。中间也经历了各种曲折。回过头来看,这些都是宝贵的财富,团队也在不断反思和总结。整个投票过程,团队核心Committer全程参与,很好的近距离体验了Apache Way,为后续其它产品的输出奠定了坚实基础。
MQ未来
再接下来,也是我最想分享的。Apache RocketMQ接下来如何发展。大家知道,我们在云上围绕着RMQ做了云端版本的消息引擎MQ,像发送者事务,消息轨迹这些功能都是集成在MQ中的。一个初具规模的软件产品,一般都会有社区版和商业版两种授权。RocketMQ和MQ两者之间,也是这样的关系。所以也请大家理解我们在开源版本和商业版本之间的不同发展路线。这两者如何能够相互配合,互相补充,共同繁荣,在全球都是一个不易解的问题。不过,我们可以承诺,只要是团队开源出来的,一定是在阿里久经考验的臻品,而且质量会越来越好,越来越趋向标准化。除此之外,为了更透彻的响应Apache社区关于多元社区文化的理念,在新的contributor和committer这块,我们会加大力度扶持、甄选具有开源情怀的童鞋,无论国籍,靠谱即可:) 能在大数据技术林良满目的今日,国内自主研发的互联网中间件从中杀出一条血路,向着拥抱全球规范的道路前行。这条路不容易走,但方向对了,就不怕远~
心动不如行动
到这里,希望那些有志于打造世界顶级互联网中间件的同学加入我们,帮助我们,监督我们,让我们一起打造全球最棒的消息引擎(不仅如此,我们还有更好玩的产品在后面),携手拥抱分布式领域最值得期待的规范体系。
路才刚刚开始,如果还有梦想,那就带着灵魂出发吧~
方向,节奏,专注,激情~