互联网企业的开源使用窘境与出路

1

自从Hadoop生态圈流行开来以后，以Apache基金会为代表的开源社区空前强大，国内外互联网公司都纷纷使用开源软件。然而参与开源社区并非是一件容易的事情。需要投入人力物力尚在其次，更为主要的，是公司业务需求的发展，和开源社区的开发之间不可妥协的矛盾。

简单来说，开源社区的系统，对于日渐壮大的互联网公司，对于希望通过云计算服务提供给其他客户使用的云计算公司，都存在开源项目跟不上业务需求的困境。

比如说Hadoop发展比较早期的时候，Facebook内部最初是使用Hadoop原生系统的。但是慢慢的Hadoop本身的文件系统就无法满足Facebook内部业务需要了。而Hadoop社区的发展，又无法有效迅速的提升到可以满足Facebook业务的高度。这样一来，使用这个软件就很尴尬了。

2

面对这种局面，互联网企业通常的做法有两种，一种是自己组织技术力量，把开源产品的源代码按照自己的需求改了。比如说Facebook在很长一段时间里是自己改Hadoop的源代码来支持自己的业务发展的。又比如说，阿里巴巴的内部使用Flink流处理引擎的时候，发现了Flink的源代码实现不能支持阿里巴巴的业务，阿里巴巴团队对Flink的源代码进行了大规模的改动，形成了自己的Blink分支版本。

另外一种做法是保留接口，但是整个系统自己重新实现。这种做法国内国外企业都有。以Hadoop的生态圈为例。国外有一个Hadoop的发行商叫MapR。MapR的Hadoop发行版里整个Hadoop的文件系统是它们自己重写过的，只是保留了文件系统接口的兼容性。又比如说阿里巴巴集团的Max Compute平台。这个平台的前端采用了HIVE的语义和一部分的编译器源代码，后端的整个查询引擎则完全由自己重新实现了一遍。

类似的例子还有阿里巴巴集团维护的内存数据库的分支ApsaraCache和阿里巴巴集团自己用Java重新实现的Storm引擎的Java版本JStorm。此外，小米在很长一段时间里内部的HBase的版本和社区的也有很大的改动。由此可见，这两种做法在业界是很常见的。

3

这些做法产生了两个明显的问题。第一个问题是公司内部开源产品的升级问题。

小米内部负责HBase的团队在一次接受采访的时候描述了HBase在小米内部升级的困难。小米对HBase的源代码做了大量的定制，而社区的HBase版本每次重大升级又加了很多新特性。很长时间里小米内部只能对照社区的旧版本和新版本的代码，然后在自己的定制版本里手动改。这种做法很容易引入新的bug先不说，消耗的人力资源也同样非常的巨大。

Facebook经历了漫长的一段这样的时间之后，终于在一次重大的升级重置过程里抛弃了自己维护的Hadoop定制版本，整体迁移到了社区的某个新版本。但是这种做法，又让Facebook面临开源的版本跟不上业务的发展的窘境。

如果说这种做法仅仅是需要对代码修修补补迁移一下的话，只保留接口，重新实现后端的做法，就面临更大的问题了。倘若开源社区的产品已经非常稳定，接口没有太多变化的话，这还比较好办。如果是接口变化很大的话，那么这个新实现的系统，很可能就被迫固定在开源的某个版本上无法轻易前移了。又或者必须投入大量人力物力去实现新功能并且和开源版本保持兼容。

比如说亚马逊著名的数据库产品Redshift，前端和Postgress兼容，后端自己实现。这个产品现在就只能被锚定在特定的Postgress版本上，无法升级。但是用户是需要用新版本的很多新特性的，这让Redshift的境地尴尬。不过好在Postgress是一个非常成熟的开源项目，即使锚定在某个特定版本上不一定是大问题。

又比如说阿里巴巴的Max Compute，虽然一开始选择了和HIVE兼容，但是伴随HIVE的不断升级，Max Compute必须在自己的系统里面重新实现这些升级的功能并保持兼容。这显然是很难的。阿里巴巴做Max Compute的组做得很辛苦，最终也无法保证和HIVE的每个版本完全兼容。

4

第二个问题是自己用了开源社区的产品之后，怎么去反哺社区。所谓的人人为我，我为人人是开源社区的基石。如果每个互联网企业只拿不还的话，开源社区也不会壮大到今天这样。

但是这个问题其实也很尴尬。如果一个产品是完全重写的，这很大程度上就相当于另外一个产品了。举例来说，Storm是一个产品，阿里巴巴重新用JAVA开发的JStorm显然就是另外一个产品了。社区如果想要增加功能的话，最低底线是需要同时给Storm和JStorm增加，才能够维持两边的一致性。

因此把一个完全重写的产品开源出去，很多时候不一定会达到设想中的好效果。开源产品自身有粘性，重写的系统可能会起到引流而非壮大的作用。这也解释了JStorm开源这么久之后，其在Storm社区的实际影响力和社区参与进来的开发者始终都表现的不温不火。

如果说自己的系统是定制的，很多时候开源也不是一件容易的事情。与开源社区交流，确定哪些东西并入到开源的版本里，是非常繁琐的事情。把自己定制的东西剥离出来，融合进开源版本的代码也需要额外的工作。很多时候，这些事情做起来不仅仅琐碎而且耗费时间。因为不会给企业带来直接的价值，很多团队成员固然很想贡献开源，但是却因为业务需求而不了了之了。

5

互联网公司如何使用开源产品，如何和开源社区合作的问题，是一个很值得我们思考的问题。在这方面看下来，阿里云的Redis团队的做法，颇有值得学习的地方。

最初的阿里云Redis云服务是基于Redis2.8的版本的。但是开源的Redis在主备断开的情况下需要做全量数据同步。这种做法非常的低效率。在云计算场景下不适用。阿里云团队在开源代码基础上把整个存储结构改了。实现了类似于mySQL的binlog的log。这就使得通过binlog的数据流进行各种各样的事情，包括容灾和增量恢复等等。阿里云Redis团队把这个新版本的Redis开源出来，叫做ApsaraCache。这个分支一直由阿里云团队在维护。

和其他的项目做法不同的是，阿里云Redis团队和Redis的开源社区维护了很好的关系。他们把自己的方案给开源社区Redis团队审阅过。尽管Redis的开发者崇尚简单就是美，觉得自己的开源客户不太需要这样的场景，并未接纳这个改动进社区版本。但是Redis的开源社区对阿里云Redis团队在做什么，怎么做的有非常直观的了解。

6

2018年1月18日召开的云数据库大会上，阿里云Redis团队的负责人介绍了他们的基于Redis4.0的云服务新版。值得注意的是，Redis4.0的很多新功能，阿里云Redis团队的贡献仅次于Redis的作者本人，这个版本是阿里云Redis团队和社区共同努力推动的产物。

在维护自己分支的前提下，阿里云的Redis团队整体上采取了只要是社区可以接受的功能，都在社区版本里开发的想法和做法。社区不接受的功能，也会交给社区先审阅，然后在自己维护的ApsaraCache分支里开源出来。

这种深入参与社区，以社区版本为主导，对社区版本不接受的功能，再在自己开源分支里维护的做法，既降低了自己开发的定制版和社区版的差距，给自己的版本升级带来了便利。又给贡献开源，反哺社区提供了极大的便利。

尽管解决互联网公司使用开源软件的窘境是一件非常不容易的事情。阿里云Redis团队的做法无疑是在便利自身的升级和给开源社区做贡献之间找到了一个好的平衡点。这是很值得我们去思考和学习的。