开源之殇

声明
本文为Gleasy原创文章,转载请指明引自Gleasy团队博客

问题的提出
最近被一些非专业的朋友问及关于使用开源快速建立产品的问题,因此开此文全面阐述一下我个人的理解。

使用开源有风险
前提:这里的开源产品,特指业务关联度高的中间件产品(比如分布式文件系统,消息队列中间件,即时通讯服务器,任务调度中间件,检索系统等)。
最大的风险来自两方面:1. 使用过程中发现后续需求不满足 2.线上遇到BUG或者问题
1. 使用过程中发现后续需求不满足
新项目来了,需求方又把时间期望压缩得厉害(这是所有需求提出人的共同特质),于是在技术选型时,自然而然就会有“不要重复开发轮子”这种朴实的想法,于是在开源世界是寻找解决方案。毕竟开源的东西看上去真的很美,现成可用,节省开发时间,节省人力成本。。。
好吧,仓促之下,决定选择某间公司的开源解决方案。
下载,打包,学习教程,配置集成;
研发过程中不断发现开源的中间件产品过多保留了开源厂商的影子(比如一些特定的使用习惯和使用场景),这些功能本身与自己所需要的一点关系都没有,但是没办法,多余的东西能不用就不用,忍忍吧;
基础功能满足了,项目上线了。。
使用一段时间,需求方或者用户提出一些新需求,分析之下,发现底层的开源中间件不提供这能力,于是悲催了。。。

2. 线上遇到BUG或者问题
需求不满足,倒是不紧急,毕竟可以对用户说我们还在计划中。
但是如果遇到系统故障,查明原因发现是来自底层中间件。。。该如何办呢?
更何况如果你的客户是企业用户,他们每天都在使用你的系统进行工作相关的内容,十万火。。。感觉更加悲催了!

3. 遇上以上问题怎么办呢?
向开源提供者发邮件,请求加入开发计划,然后就是漫长的等待。。。。。。
一周两周,一个月两个月。。。。需求就这么被无限地搁置?
实在受不了了,开始研究源码,自力更生!
于是开始读代码,可恨的是开源的产品多数没有清晰的注释,更不提设计思想指引了。。
艰难地进行中,一天两天,一周两周,复杂的中间件如分布式文件系统,几万行甚至十几万行代码。。。
终于搞清楚了代码结构,准备开始着手修改!
改一点东西,发现牵一发而动全身,于是越改越多。。。。
终于有一天,突然发现,已经改得面目全非,完全不是之前开源产品的样子了,
霍然回首,醒悟过来,当初为何不借鉴其思想而自行定制研发,我研发出来只适合自己的中间件也不需要这么多时间和精力啊!搞到现在天翻地覆,自己的需求也没能完美满足,还有一堆自己不需要的东西去维护,欲哭无泪啊!
于是痛下狠心,决定推倒重来,按照自己产品的思路重新研发最适合自己的特有中间件。。。

选择开源要谨慎
基本使用开源中间件的公司在产品做到一定规模一定会遇到上面提到的风险和问题,大多数公司的选择也是一样,推倒重来,重新开发适合自己的中间件。比如淘宝,比如新浪,比如TWITER。相同的功能大家做了又做,不是炫耀自己有多牛,而是逼不得己。
但并不是所有的开源都是洪水猛兽似的,通用性工具类的,特别是经过了大公司长时间验证过的通用性工具,是可以选用的,比如MYSQL,ZOOKEEPER,NGINX,HAPROXY,OPENFIRE,SOLR,KEEPALIVED,LIBEVENT,MINA,NETTY,TOMCAT,APACHE,LUCENE,REDIS,MONGODB,MEMCACHED等等等等,是可以放心去选用的,前提是要对这些产品的配置和优化有充分的理解。

best online casino

此条目发表在 C/C++, Java技术, 分布式技术, 数据库技术, 运维 分类目录。将固定链接加入收藏夹。

发表评论