使用开源项目的正确姿势，都是血和泪的总结！

使用开源项目的正确姿势，都是血和泪的总结！

软件开发行业有一个流行的标准:干，不重复自己。当你翻译中文时，你的品牌形象会变得更受欢迎:你不必一次又一次地制造轮子。开源项目的关键目的是资源共享，其实是为了更好的让人不用重复造轮子，尤其是在互联网技术这样一个飞速发展的行业，速度就是生命。引入开源项目可以节省大量的人力资源和时间，大大加快业务的发展趋势。为什么不试一试？

殊不知，实践中通常并不那么快乐。虽然开源项目节省了大量的人力资源和时间，但是也存在很多问题。我坚信大部分同学都踩过开源手机软件的坑。小的危害可能是服务器宕机30分钟，大的问题可能是几十万的数据丢失，甚至毁灭性的安全事故是数据全部丢失。

再说，虽然干标放在那边，但其实开源项目是最不符合干标的，重复的轮子很多，尤其是外国人。当他们看到哪个开源方案不舒服，就会开始一个类似的:这里有MySQL给你，是PostgreSQL对我来说；给你，MongoDB，是我卡珊德拉；；给你，memcached，是我redis；给你，Gson，是我，Jackson；给你，棱角，是我的反应。。。。。。总而言之，从远处看，其实还有很多类似的轮子！类似的轮子太多了，挑选起来很头疼。

我该怎么办？基本上不可能完全淘汰开源项目。我们必须更明智地选择和应用开源项目。品牌形象点说:不用反复发明轮子，找对轮子！你开的是玛莎拉蒂，不要找大拖拉机的轮子。

接下来我将根据5年加UC与开源项目相关的经验，总结一些“如何正确应用开源项目”的工作经验和教训。新项目有些是我真实的经历，有些是我感动的，有些是我观察到的，有些里面的关键点大概也不完全准确，大家可以结合自己的经历一起探讨。

以下重点分三部分叙述，分别是“选”、“用”、“改”。

选择:如何选择一个开源项目【重点是业务】

我们在选择开源项目的时候，一个头疼的问题是，类似的开源项目有很多，后面的总是声称比前面的更强大。我们在选择的时候有点无所适从，总担心选择了A计划，错过了B计划，或者反之。大家在这里的工作经验都是专注于业务，而不是过于担心开源方案是否强大。

举个例子:当时我们在尝试一个社交媒体业务的时候，发现了TT(东京暴君)这个开源的方案，觉得可以代替Memcached做缓存文件，而且还具有持久存储功能，可以代替MySQL。它很棒，非常高端，所以被广泛应用于商业领域。但是事后申请的整个过程是很痛苦的，表现为:

1ï?它不能完全取代MySQL，所以它有两份存储。在设计方案的情况下，每次都需要讨论和管理决策。

2ï?在功能上看起来很高端，但是也有很多相对的bug，而且有些bug是致命的，比如所有的数据信息都无法读取，然后用自己的科研源代码写了一个特殊的工具来修复一些数据信息。

3ï?确实很厉害，但是要花很长时间去理解各种重点。

经过你的思考和总结，其实当时的业务MemcachedMySQL是可以考虑透彻的，大家都知道当时的业务根本不需要导入TT。

简单来说:如果你的业务规定1000TPS，那么20000TPS和50000TPS方案没有区别。有些人很可能会担心我持续增加TPS。我该怎么办？其实我很担心大家的架构会继续进化，直到真的要那么高。记住:升级没必要太早。过早升级是罪恶之源——UNIX编程哲学

【对焦点是否完美】

很多新的开源项目通常会宣称比之前的更强大:更高的特性，更强的功能，大量新思想的引入。。。。。。看起来都很诱人，其实不经意间隐藏了一个负面信息的问题:都比较不成熟！程写的新项目再厉害，总会有bug。不要以为创作者厉害就没有bug。Windows、Linux、MySQL的开发者都是顶尖的开发者，也有很多bug。

不成熟的开源项目应用到工作环境，是有风险的。服务器宕机的话，服务器宕机后重启服务器是无法修复的，更严重的是内容丢失无法恢复。以上面提到的TT为例:我们确实遇到过非正常关机后文档被破坏的通病，重启后无法修复。当时每天都做备份数据，所以只使用一天前的数据信息进行修复，但是当天的数据信息全部丢失。之后大家花了大量的时间和人力去看源代码，自己编写专用工具修复一些数据信息。这个数据信息和金融行业无关是可以的，丢失一部分问题不大，不然就麻烦了。

所以在选择开源项目的情况下，尽量选择完善的开源项目，降低风险。品牌形象点说:2.0的成熟美女比0.2的处女座好！一般情况下，除非是特殊情况，否则没有必要选择版本号为0。x，但至少要选择1.x的版本号，版本信息越高越好。

[焦点运维管理能力]

当我们选择开源项目时，他们大多关注性能指标，如特性、可信度和功能，但基本上不容易关心运维管理的能力。但是，如果该方案要应用于在线工作环境，运维管理能力是不可或缺的一部分。否则一旦出现问题，运维管理、产品研发、测试都只能看着。祈求佛祖保佑！

能够从以下几种方案中考察运维管理能力:

1ï?开源程序系统日志是否完整？有些开源程序系统日志只有启动和终止两行，有问题没办法查出来。

2ï?开源方案是否有cmd、管理方法控制面板等专门的维护工具？，并且可以看到系统软件运行时的状态？

3ï?开源解决方案有没有检查和修复常见故障的能力，比如报警和交换？

使用:如何使用开源解决方案[深入分析，仔细检测]

很多人用开源项目，其实完全是“拿来主义”。在观看了许多演示之后，他们刚刚开始在网上部署他们的程序。这就好比看了行车手册，知道方向盘在转，油门在加速，刹车在减速，然后按顺序行驶，其实风险很大。

例:每个人都有一个应用elasticsearch的精英团队，大部分都是即时使用的。倒索引是什么不太清楚，所有设备都配有初始值。当它运行时，它就上线了。结果就是ping连接点的时间太长，异常连接点的清除速度非常慢，导致整个站点的源代码浏览挂起。

例2:2:UC中很多精英团队在第一次应用MySQL的时候，并没有科学的研究。业务部门经常抱怨MySQL太慢。事实上，在精确定位后，他们发现许多最重要的主要参数(如innodb_buffer_pool_size、sync_binlog、innodb_log_file_size等。)没有配备或者没有正确配备，功能自然会很慢。

能够从以下几个方面进行科学研究和测试:

1ï?仔细阅读开源项目的设计文档或市场调研报告，掌握其结构设计。

2ï?检查每个设备项目的功效和危害，并识别重要的设备项目。

3ï?在各种场景下进行功能测试。

4ï?进行稳定性测试，持续运行几天，观察cpu、运行内存、磁盘io等指标的波动情况。

5ï?进行故障检测:杀、关电源、拔网线、重启100次以上、更换等。

[小心使用，以灰度发布]

如果做了上面的“深入分析和仔细测试”，发现没有问题，可以安心上网使用吗？不要太高兴。即使你的科研再深入，测试再仔细，你也最好小心一点。因为无论你的科研有多深入，无论你的测试有多细致，都只能降低风险，而不太可能完全覆盖所有的线上场景。

让我们以TT为例。其实我们曾经指派过一个大神去看源代码，测试了一个月左右，但是最终发布还是遇到了各种问题。在线工作环境的复杂性不是测试能覆盖的，一定要谨慎。

所以，无论科研有多深，考察有多细致，信心有多足，都要时刻对互联网保持敬畏之心，谨防万年巨轮出航。大家的工作经验都是先专注单核业务，有工作经验后再逐步拓展。

【做好应急，以防万一】

就算你前面做了很完善很充分的工作，也不能觉得一切都会很顺利。尤其是当你开始应用一个开源项目的时候，如果运气不好，很可能会遇到一个全世界用户都没有遇到过的bug，导致业务无法修复，尤其是在存储层面。一旦出现无法修复的问题，很可能是致命的严重打击。

例子(这个例子是听过的):MongoDB被应用到某个业务上。结果服务器宕机后，部分内容丢失，无法修复。没有其他备份数据，无法靠人力修复。只处理了一次客户紧急情况。结果DBA和运维管理从此都抵制使用MongoDB，哪怕是探究式学习。

虽然因为一个常见的故障就完全抵制尝试有点过分，但确实常见的故障也提醒我们，在为关键业务或数据信息应用开源项目时，最好有另一个完善的方案来备份数据，尤其是数据存储。比如想用MongoDB或者Redis，可以用MySQL做备份数据存储。这样虽然复杂度和成本增加了一点，但是关键时刻还能救人！

变化:如何根据开源项目做二次开发【保持童真，多方面打包】

当我们发现开源项目的某些方面不符合大家的要求时，当然会有一些不合理的地方去修改，但是如何设置是一门学问。一种方式是把钱投给几个人从内到外改变一切，更新到符合每个人的实际业务需求。但是这样做有几个严重的问题:

1ï?投入了大量资金。总的来说，redis级别的开源方案确实需要自己去改变。至少要两个人投入一个月。

2ï?失去跟随原方案进化的能力:如果改动太多，即使原开源项目再进化，大家也无法协同工作，因为差别太大。

所以大家的建议是，不需要修改原有的系统软件，只需要开发设计辅助系统软件:监管、报警、三层切换、管理方式等。以Redis为例。如果要完善聚类功能，不必修改Redis本身的完成度，只需升级一个代理层即可完成。Twitter的Twemproxy做到了这一点，Redis来到3.0后展示了它的聚类功能。原来的方案可以简单地转换成Redis3.0。详细参考(http://www.cnblogs.com/gomysql/p/4413922.html)

如果我真的想换成原来的系统软件怎么办？大家的建议都是立刻要求或者bug开源项目，缺点是响应比较慢，这要看业务的紧急程度。如果真的太急，那就只有自己改了，不过也不算太急。建议做好数据备份或应急方式。

[创造和发明你需要的轮子]

这可能会让很多人瞠目结舌。怎么能说了半天最后又回到“反复创造发明你需要的轮子”？

其实选择不选择开源项目的关键是一个成本和利润的问题。并不意味着选择开源项目就一定是最优方案。最关键的问题是没有完全适合自己的车轮！

手机软件行业和硬件配置行业的一大区别是，手机软件行业没有确定的行业标准。每个人都玩得很开心，想玩什么就玩什么。不像硬件配置行业，你造一个不寻常规格的轮子，别的车用不了。你的车轮加工技术再高，质量再高，都是徒劳的。手机软件行业可以造出很多类似的轮子，而且大部分都可以随处使用。比如把缓存文件从Memcached改成Redis，就不容易出大问题。

另外，开源项目为了大规模使用，考虑的是通用的解决方案，但是不同的业务其实差别很大，通用的解决方案不一定是某个业务最好的。比如Memcached，根据一致性哈希，显示聚类功能。但是，在人人的一些业务中，如果缓存文件的一个服务器宕机，所有业务都有可能延迟。这就需要大家展示缓存文件备份数据的功能，而Memcached没有，Redis当时也没有集群功能。所以大家投入了2~4个人2个月左右的时间，根据LevelDB的基本原理，做了一套存储、备份数据、集群的缓存文件架构。然后在这个架构的基础上，基本完善了跨主机间共享的功能，大大提高了业务的可用性。如果开源方案选择彻底完成，不太可能这么迅速，甚至很有可能开源项目并不能完全兼容所有人的要求。

所以，如果你很有钱，有人有时间，把钱投在人力资源上，重新打造极其适合自己业务特点的轮子，也是一个非常不错的选择！毕竟，许多富人(BAT.....等等。)那样做，否则不会有这么多强大的开源项目:)

关于阿里百川

阿里百川(baichuan.taobao.com)是阿里巴巴“云”和“端”的重点发展战略。它是Alibaba.com的无线网络开发者平台。根据国际后端开发服务项目和完善的商业服务组件，并根据“技术、商业服务和互联网大数据”的开放，为移动创业者呈现能够快速构建app并实现app商业化、提升客户体验的解决方案。此外还有各种人力资源服务——物理室空、彩蛋管理、风险投资等。为流动创业者提供全方位保障。