选:如何选择一个开源项目?
聚焦是否满足业务?
聚焦是否成熟?
可以从以下几个方面考察是否成熟:
1)版本号:一般建议除非特殊情况,否则不要选0.X版本的,至少选1.X版本的,版本号越高越好。
2)使用的公司数量:一般开源项目都会把采用了自己项目的公司列在主页上,公司越大越好,数量越多越好
3)社区活跃度:看看社区是否活跃,发帖数、回复数、问题处理速度等
聚焦运维能力?
可以从以下几个方案去考察运维能力:
1)开源方案日志是否齐全:有的开源方案日志只有寥寥启动停止几行,出了问题根本无法排查
2)开源方案是否有命令行、管理控制台等维护工具,能够看到系统运行时的情况
3)开源方案是否有故障检测和恢复的能力,例如告警、倒换等
案例2:很多团队最初使用MySQL的时候,也没有怎么研究过,经常有业务部门抱怨MySQL太慢了,其实经过定位,发现最关键的几个参数(例如innodb_buffer_pool_size, sync_binlog,innodb_log_file_size等)都没有配置或者配置错误,性能当然会慢。
用:如何使用开源方案?
深入研究,仔细测试
可以从如下几方面进行研究和测试:
1)通读开源项目的设计文档或者白皮书,了解其设计原理
2)核对每个配置项的作用和影响,识别出关键配置项
3)进行多种场景的性能测试
4)进行压力测试,连续跑几天,观察cpu、内存、磁盘io等指标波动
5)进行故障测试:kill,断电、拔网线、重启100次以上、倒换等
小心应用,灰度发布
假如我们做了上面的“深入研究、仔细测试”,发现没什么问题,是否就可以放心大胆的应用到线上了呢?别高兴太早,即使你的研究再深入,测试再仔细,也还是要小心为妙,因为再怎么深入的研究,再怎么仔细的测试,都只能降低风险,但不可能完全覆盖所有线上场景。
但是,不管研究多深入、测试多仔细、自信心多爆棚,时刻对线上要有敬畏之心,小心驶的万年船。我们的经验就是先在非核心的业务上用,然后有经验后慢慢扩展。
做好应急,以防万一
虽然因为一次故障就完全反对尝试是有点反应过度了,但确实故障也给我们提了一个醒:对于重要的业务或者数据,使用开源项目时,最好有另外一个比较成熟的方案做备份,尤其是数据存储。例如:如果要用MongoDB或者Redis,可以用MySQL做备份存储。这样做虽然复杂度和成本高一些,但关键时刻能够救命!
改:如何基于开源项目做二次开发?
保持纯洁,加以包装
我们的建议是不要改动原系统,而是要开发辅助系统: 监控,报警,负载均衡,管理等。以Redis为例,如果我们想增加集群功能,不要去改动Redis本身的实现,而是增加一个proxy层来实现,Twitter的Twemproxy就是这样做的,而Redis到了3.0后本身提供了集群功能,原有的方案简单切换到Redis 3.0即可。详细可参考(http://www.cnblogs.com/gomysql/p/4413922.html )
如果实在想改到原有系统,怎么办呢?我们的建议是直接给开源项目提需求或者bug,但弊端就是响应比较缓慢,这个就要看业务紧急程度了,如果实在太急那就只能自己改了,不过不是太急,建议做好备份或者应急手段即可。
发明你要的轮子
如果你有钱有人有时间,投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择!毕竟,土豪们(BAT、Facebook、Google......等)很多都是这样做的,否则我们也就没有那么多好用的开源项目了 :)