开发者学堂课程【如何成为技术大牛？：07使用开源项目的正确姿势，血和泪的总结】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1240/detail/18426
使用开源项目的正确姿势，血和泪的总结
内容介绍
一、开源项目的优点
二、使用开源项目的经验教训
一、开源项目的优点
1、流行原则
软件开发领域有一个流行的原则：don't repeat yourself，翻译过来更形象通俗，即不要重复“造轮子”。
2、优点
开源项目主要目的是共享，其实就是为了让大家不要重复“造轮子”，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目可以节省大量的人力和时间，大大加快业务的发展速度。
3、缺点
然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少。相信绝大部分同学都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万数据，甚至灾难性的事故是全部数据都丢失。
除此以外，虽然 dry 原则摆在那里，但实际上开源项目反而是最不遵守 dry 原则的，重复的“轮子”非常多，尤其是外国人看见哪个开源方案不适应，自己就搞一个差不多的。
一方有 MySQL，另一方有PostgreSQL；一方有 MongoDB，另一方有 cathedral；一方有 Memcached，另一方有 Redis；一方有 goson，另一方有 jackson；一方有 angular，另一方有 react。
4、总结
总之放眼望去，其实相似的“轮子”很多，相似“轮子”太多，选择就是让人头疼的问题了。完全不用开源项目几乎是不可能的，对此需要更加聪明的去选择和使用开源项目，形象的说就是不要重复发明“轮子”，但要找到合适的“轮子”。如果开的是保时捷，就不要找个拖拉机的轮子。
二、使用开源项目的经验教训
接下来将根据加入 UC 五年与开源项目有关的经历，总结出一些如何正确使用开源项目的经验和教训。有的项目是亲身经历，有的是接触到的，有的是观察。其中部分描述细节可能并不完全准确，大家可以结合自己的经历一起探讨。以下内容主要分三个部分进行描述，分别是选、用、改。
1、选
（1）选择经验
如何选择一个开源项目，聚焦是否满足业务。在选择开源项目的时候，一个头疼的问题就是相似的开源方案较多，而且后面的总是要宣称比前面的更加有效，在选择的时候有点无所适从，总是会担心选择了a方案而错过了b方案或者反过来。这里的经验是聚焦于是否满足业务，而不需要过于关注开原方案是否优秀。
（2）案例分析
当时尝试一个社交的业务时，发现了这个开源方案，觉得既能够做缓存取代 Memcached，又有持久化存储功能，可以取代Mexico，非常有效，于是就在业务里面大量使用了，但后来的使用过程让人很烦恼，主要表现为：
①不能完全取代 Mexico，因此有两份存储，设计的时候每次都要讨论和决策。
②功能上看起来很高级，但相应的 bug也不少，而且有的 bug 是致命的，例如所有数据不可读，后来是自己研究源码写了一个工具才恢复了部分数据。
③功能确实显著，但需要花费较长时间熟悉各种细节。
（3）反思和总结
其实当时的业务 Memcached 加 Mexico 完全能够满足，且大家都熟悉，当时的业务完全不需要引入 TT。简单来说，如果业务要求1000 TPS，那么一个两万 TPS 和五万 TPS 的方案是没有区别的。有的人可能会担心 TPS 不断上涨怎么办，其实不用担心，架构会不断引进的，等到真的需要这么高的时候，再进行架构重构。记住不要过早优化，过早优化是万恶之源。
（4）Unix 编程哲学
聚焦是否成熟，很多新的开源项目往往都会声称自己以前的项目更加优秀，性能更高，功能更强，引入更多新概念，看起来都很诱人，但实际上都有意无意的隐藏了一个负面的问题，即都更加不成熟。不管多优秀的程序员写出来的项目都会有bug，千万不要以为作者优秀就没有bug了，Windows，Linux，MySQL 的开发者都是顶级的开发者，一样有很多bug。
（5）应用不成熟开源项目的风险
不成熟的开源项目应用到生产环境风险极大，轻则宕机，重则宕机后重启都不能恢复，更严重的是数据丢失都无法找回。还是以上面提到的 TT 为例，真的遇到异常锻炼后文件被损坏，重启也恢复不了的故障，还好当时每天做了备份，于是只能用一天前的数据进行恢复，但当天的数据全部丢失了。后来花费了大量的时间和人力去看原码，自己写工具，恢复了部分数据。还好这些数据不是金融相关的数据，丢失一部分问题也不大，否则就出现大麻烦了。所以在选择开源项目的时候尽量选择成熟的开源项目降低风险。
（6）考察项目成熟的角度：
可以从以下几个方面考察是否成熟：
①版本号
一般建议除了特殊情况否则不要选择0.x版本的，至少选择1.x版本的，版本号越高越好。
②使用公司的数量
一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好，数量越多越好。
③社区活跃度
看一下社区是否活跃，发帖数、回复数以及问题处理速度等。
④聚焦运维能力
在选择开源项目的时候基本上都是聚焦于技术指标，例如性能、可靠性、功能这些方案，而几乎不会去关注运维方面的能力。但如果将方案应用到线上生产环境，运维能力是必不可少的一环。否则一旦出问题，运维、研发、测试都没有任何办法了。
(7)考察运维能力的方案
可以从以下几个方案去考察运维能力。
①开源方案日志是否齐全
有的开源方案日志只有寥寥启动、停止几行，出了问题根本无法排查。②开源方案是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况。
③开源方案是否有故障检测和恢复的能力，例如告警、倒换等。
2、用
(1)开源项目使用的现状
如何使用开源方案深入研究，仔细测试。很多人用开源项目其实是完全的拿来主义，看了几个 demo，把程序跑起来就开始部署到线上应用了。就好像看了一下开车指南，知道了方向盘是转向，油门是加速，刹车是减速，然后就开车上路了，其实是非常危险的。
案例分析：
①案例一
有团队使用了 elastic search，基本上是拿来就使用,倒排和索引是什么都不太清楚。配置都是用默认值跑起来就上线了，结果就遇到节点屏时间太长，剔除异常节点太慢，导致整站的访问失败。
②案例二
很多团队最初使用 MySQL 的时候也没有怎么研究过，经常有业务部门抱怨 MySQL 太慢了，其实经过定位发现最关键的几个参数都没有配置或者配置错误，性能当然会慢，可以从如下几方面进行研究和测试。
(2)测试的方法
①通读开源项目的设计文档或者白皮书，了解其设计原理。
②核对每个配置项的作用和影响，识别出关键配置项。
③进行多种场景的性能测试
④进行压力测试，连续跑几天，观察 CPU、内存、磁盘 IO 等指标波动。
⑤进行故障测试
⑥断电，拔网线，重启100次以上倒换的。
(3)小心应用灰度发布
假如做了上面的深入研究，仔细测试发现没什么问题，是否就可以放心的应用到线上了呢？即使研究再深入，测试再仔细也还是要小心为妙，因为再怎么深入的研究，再怎么仔细的测试都只能降低风险，但不可能完全覆盖所有线上场景。
案例分析：
①案例一：
还是以TT为例，其实在应用之前专门安排看源码，做测试，做了大约一个月，但最后上线还是遇到各种问题。线上生产环境的复杂度真的不是测试能够覆盖的，必须小心谨慎，所以不管研究多深入，测试多仔细，自信心多爆棚，时刻对线上要有敬畏之心。经验就是先在非核心的业务上用，然后有经验后慢慢扩展，做好应急，以防万一。即使前面的工作做的非常完善和充分，也不能认为就没有问题了。尤其是刚开始使用一个开源项目，运气不好的话，就可能遇到一个之前全世界的使用者从来没有遇到的 bug，导致业务都无法恢复，尤其是存储方面，一旦出现问题无法恢复，可能就是致命的打击。
②案例二
此案例是听说的，某个业务使用了 MongoDB，结果宕机后部分数据丢失，无法恢复，也没有其他备份，人工恢复都没办法，只能接一个用户投诉处理一个，导致 DBA 和运维从此以后都反对用 MongoDB，即使是尝试性。虽然因为一次故障就完全反对尝试是有点反应过度了，但确实故障也提了一个醒：对于重要的业务或者数据使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。例如如果要用 MongoDB 或者 Redis 可以用 MySQL 做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救急。3、改
如何基于开源项目做二次开发，保持纯洁加以包装。当发现开源项目有的地方不满足需求的时候，自然会有一种去改变的冲动，但是怎么改是个大问题。
(1)改的方式
一种方式是投入几个人从内到外全部改变，将其改造成完全符合业务需求，但这样做有几个比较严重的问题。
问题：
①投入太大，一般来说 Redis 这种级别的开源方案如果要自己改就至少要投入两个人操作一个月以上。
②失去了跟随原方案演进的能力，改的过多的话，即使原有开源项目继续引进也无法合并，因为差异太大，所以建议是不要改动原系统，而是要开发辅助系统、监控报警、负载均衡管理等。以 Redis 为例，如果想增加集群功能，不要去改动 Redis 本身的实现，而是增加一个proxy层来实现，Twitter的 TWEM proxy就是这样做的。而 Redis 到了3.0后，本身提供了集群功能，原有的方案简单切换到 Redis 3.0即可，详细可参考文档内网址内容。
(2)改动原有系统的方法：
如果实在想改到原有系统怎么办呢？
①对此建议是直接给开源项目提需求或者 bug，但弊端就是响应比较缓慢，这个就要看业务紧急程度了。如果实在太紧急，那就只能自己改了；不过不是太紧急，建议做好备份或者应急手段即可。
②发明自己要的“轮子”
这一点估计让很多人大跌眼镜，怎么讲了很多最后又回到了重复发明要的“轮子”？其实是否选择开源项目核心还是一个成本和收益的，并不是说选择开源项目就一定是最优的方案，最主要的问题是没有完全适合自己的“轮子”。软件领域或硬件领域最大的不同就是软件领域没有绝对的工业标准，不像硬件领域，造一个尺寸与众不同的“轮子”，其他车都用不上。“轮子”工艺再高，质量再好也是白费。软件领域可以造很多相似的“轮子”，也基本上能够到处使用。例如把缓存从 Memcached 换成 Redis 不会有太大的问题。
③除此以外，开源项目为了能够大规模应用，考虑的是通用的处理方案。而不同的业务其实差异较大，通用方案不一定完美适合具体的某个业务。比如说 Memcached 通过一致性提供集群功能，但是一些业务缓存如果有一台宕机，整个业务可能就被拖慢了，这就要求提供缓存备份的功能，但 Memcached 的又没有。而 Redis 当时没有集群功能，于是投入两到四个人，花了大约两个月时间，基于 level-DB 原理自己做了一套缓存框架，支持存储备份集群的功能。后来又在这个框架的基础上增加了跨机房同步的功能，很大程度上提升了业务的可用性水平。如果完全采用开源方案来实现是不可能这么快速的，甚至都有可能开源项目完全就不支持需求。所以如果有资金、有人员有时间，投入人力去重复发明完美符合自己业务特点的“轮子”，也是很好的选择，毕竟土豪们 Google，face-book，bat 等很多都是这样做的，否则也就没有那么多方便使用的开源项目了。
