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

软件开发领域有一个流行的原则：DRY，Don’t repeat yourself，我们翻译过来更形象通俗：不要重复造轮子。开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？

然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分同学都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万数据，甚至灾难性的事故是全部数据都丢失。

除此以外，虽然DRY原则摆在那里，但实际上开源项目反而是最不遵守DRY原则的，重复的轮子好多，尤其是歪果仁，一看哪个开源方案不爽，自己就吭哧吭哧搞一个差不多的：你有MySQL，我有PostgreSQL；你有MongoDB，我有Cassandra；你有memcached，我有redis；你有Gson，我有Jackson；你有Angular，我有React。。。。。。总之放眼望去，其实相似的轮子很多！相似轮子太多，选择就是让人头疼的问题了。

怎么办？完全不用开源项目几乎是不可能的，我们需要更加聪明的去选择和使用开源项目。形象点说：不要重复发明轮子，但要找到合适的轮子！你开的是保时捷，可别找个拖拉机的轮子。

接下来我将根据加入UC 5年与开源项目有关的经历，总结出一些“如何正确使用开源项目”的经验和教训。有的项目是我亲身经历，有的是我接触到的，有的是我观察的，其中部分描述细节可能并不完全准确，大家可以结合自己的经历一起探讨。

以下内容主要分3个部分进行描述，分别是“选”、“用”、“改”。

选：如何选择一个开源项目 【聚焦是否满足业务】

我们在选择开源项目的时候，一个头疼的问题就是相似的开源方案较多，而且后面的总是要宣称比前面的更加牛逼。我们在选择的时候有点无所适从，总是会担心选择了A方案而错过了B方案，或者反过来。这里我们的经验是聚焦于是否满足业务，而不需要过于关注开源方案是否牛逼。

案例：当时尝试一个社交类业务时，我们发现了TT（Tokyo Tyrant）这个开源方案，觉得既能够做缓存取代Memcached，又有持久化存储功能，可以取代MySQL，很牛逼，很高大上，于是就在业务里面大量使用了。但后来的使用过程让人很蛋疼，主要表现为：

1ï¼不能完全取代MySQL，因此有两份存储，设计的时候每次都要讨论和决策

2ï¼功能上看起来很高大上，但相应的bug也不少，而且有的bug是致命的，例如所有数据不可读，后来是自己研究源码写了一个工具才恢复了部分数据。

3ï¼功能确实牛逼，但需要花费较长时间熟悉各种细节

后来我们反思和总结，其实当时的业务Memcached + MySQL完全能够满足，且大家都熟悉，当时的业务完全不需要引入TT。

简单来说：如果你的业务要求1000 TPS，那么一个20000 TPS 和50000 TPS的方案是没有区别的。有的人可能会担心我TPS不断上涨怎么办？其实不用担心，我们的架构会不断演进的，等到真的需要这么高的时候我们再来架构重构，记住：不要过早优化，过早优化是万恶之源 —— 《UNIX编程哲学》

【聚焦是否成熟】

很多新的开源项目往往都会声称自己比以前的项目更加牛逼：性能更高、功能更强、引入更多新概念。。。。。。看起来都很诱人，但实际上都有意无意的隐藏了一个负面的问题：都更加不成熟！不管多牛逼的程序员写出来的项目都会有bug，千万不要以为作者牛逼就没有bug，Windows、Linux、MySQL的开发者都是顶级的开发者吧，一样很多bug。

不成熟的开源项目应用到生产环境，风险极大。轻则宕机，重则宕机后重启都恢复不了，更严重的是数据丢失都找不回了。还是以上面提到的TT为例：我们真的遇到异常断电后，文件被损坏，重启也恢复不了的故障，还好当时每天做了备份，于是只能用1天前的数据进行恢复，但当天的数据全部丢失了。后来我们花费了大量的时间和人力去看源码，自己写工具恢复了部分数据，还好这些数据不是金融相关的数据，丢失一部分问题也不大，否则就有大麻烦了。

所以在选择开源项目的时候，尽量选择成熟的开源项目，降低风险，形象点说：宁要2.0的熟女，不要0.2的处女！一般建议除非特殊情况，否则不要选0.X版本的，至少选1.X版本的，版本号越高越好。

【聚焦运维能力】

我们在选择开源项目的时候，基本上都是聚焦于技术指标，例如性能、可靠性、功能这些方案，而几乎不会去关注运维方面的能力。但如果要将方案应用到线上生产环境，运维能力是必不可少的一环，否则一旦出问题，运维、研发、测试都只能干瞪眼，求菩萨保佑了！

可以从以下几个方案去考察运维能力：

1ï¼开源方案日志是否齐全：有的开源方案日志只有寥寥启动停止几行，出了问题根本无法排查

2ï¼开源方案是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况

3ï¼开源方案是否有故障检测和恢复的能力，例如告警、倒换等

用：如何使用开源方案 【深入研究，仔细测试】

很多人用开源项目，其实是完完全全的“拿来主义”，看了几个Demo，把程序跑起来就开始部署到线上应用了。就好像看了一下开车指南，知道了方向盘是转向、油门是加速、刹车是减速，然后就开车上路了，其实是非常危险的。

案例：我们有团队使用了elasticsearch，基本上是拿来就用，倒排索引是什么不太清楚，配置都是用默认值，跑起来就上线了，结果就遇到节点ping时间太长，剔除异常节点太慢，导致整站访问挂掉。

案例2：UC很多团队最初使用MySQL的时候，也没有怎么研究过，经常有业务部门抱怨MySQL太慢了，其实经过定位，发现最关键的几个参数（例如innodb_buffer_pool_size, sync_binlog，innodb_log_file_size等）都没有配置或者配置错误，性能当然会慢。

可以从如下几方面进行研究和测试：

1ï¼通读开源项目的设计文档或者白皮书，了解其设计原理

2ï¼核对每个配置项的作用和影响，识别出关键配置项

3ï¼进行多种场景的性能测试

4ï¼进行压力测试，连续跑几天，观察cpu、内存、磁盘io等指标波动

5ï¼进行故障测试：kill，断电、拔网线、重启100次以上、倒换等

‌【小心应用，灰度发布】

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!