47-开源项目：如何选择、使用以及二次开发
前言
软件开发领域有一个流行的原则：DRY,Don’t repeat yourself。即不要重复造轮子。开源项目的主要目的就是共享，其实就是为了大家不要重复造轮子。 引入开源项目可以节省大量的人力和时间，大大加快业务的速度。但是其带来的问题也不少，小的影响可能是宕机半小时，大的问题可能是丢失几十万条数据，甚至灾难性的事故是全部数据丢失。
同时，虽然DRY的原则在那里，但实际开源项目反而是最不遵守DRY原则的，重复造的轮子特别多，如Mysql、Postgresql，MongDB、Cassandra，Memcache、Redis，Gson、jackon，Angular、React…，总之重复的轮子特别多，那该如何选择呢？不要重复造轮子，但要找到合适的轮子。
选：如何选择开源项目
聚集是否满足业务
架构师选择开源项目时，头疼是相似的开源项目有很多，而且一个比一个说更优秀。那该如何选择呢？聚集于是否满足业务，而不需要过于关注开源项目是否优秀。
聚焦是否成熟
很多新的开源项目声称自己比以前更加的优秀，性能更强、功能更强…，但实际上都有意无意的隐藏了一个负面问题：更加不成熟。不管多优秀的程序员写出来的项目都会有Bug，不要以为作者利害就没有Bug。
不成熟的开源项目引入生产环境，风险极大。轻则宕机，重则宕机重启后都恢复不了，更严重的是数据丢失找不回来。
所以在选择开源项目时，尽量选择成熟的开源项目，降低风险。
可以从以下几个方面考察开源项目是否成熟：
- 版本号：除非特殊情况，否则不要选择0.X版本的，至少选择1.X版本的，版本号越高越好。
- 使用公司的数量：一般开源项目都会把采用自己项目的公司列在主页上，公司越大越好，数量越多越好。
- 社区活跃度：看看社区是否活跃，发贴数、回复数、问题处理速度等。
聚焦运维能力
大部分架构师在选择开源项目时，基本上都是聚焦于技术指标，如性能、可用性、功能这些评估点，而几乎不会去关注运维方面的能力。但如果要将项目应用到线上生产环境，则运维能力是必不可少的一环。
可以从以下几个方面去考察运维能力：
- 开源项目日志是否齐全：
- 开源项目是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况。
- 开源项目是否有故障检测和恢复能力，例如告警、切换等。
用：如何使用开源项目
深入研究、仔细测试
很多人使用开源项目，其实完完全全的“拿来主义”，看了几个demo，把程序跑起来就开始部署到线上应用了。其实是非常危险的。
可以从以下几个方面进行研究和测试：
- 通读开源项目的设计文档或者白皮书，了解其原理。
- 核对每个配置项的作用和影响，识别出关键配置。
- 进行多种场景的性能测试。
- 进行压力测试、连接跑几天，观察CPU、内存、磁盘I/O等指标波动。
- 进行故障测试：kill、断电、拔网线、重启100次以上、切换等。
小心应用、灰度发布
做好应对、以防万一
改：如何基于开源项目做二次开发
保持纯净、加以包装
当发现开源项目有的地方不满足我们的需求以后，自然会有一种改的冲动，但是怎么改是一个大学问。一种方式投入几个人从里到外全部改一遍，将其改造成完全符合我们业务需求。但是这样做有几个比较严重的后果：
- 投入太大
- 失去了跟随项目演进的能力。改的太大，即使原有的开源项目继续演进，也无法合并了，因为差异太大。
所以建议是不要改动原有的系统，而是开发辅助系统：例如监控、报警、负载均衡、管理等。
如果实在想改原有的系统，怎么办？建议是直接给开源项目提需求或者Bug，但是弊端就是比较慢，这个要看业务紧急程度，如果太急就自己改了，如果不急的话，建议做好备份或者应急手段。
发明你要的轮子
其实要不要选择开源项目，核心还是一个成本和收益的问题，并不是说选择开源项目就一定是最优的项目，最主要的问题是：没有完全适合你的轮子。
软件领域没有绝对的工业标准，可以造很多相似的轮子，基本上都可以使用。
此外，开源项目为了能够大规模的使用，考虑的都是通用方案，而不同的业务其实差异很大，通用的方案不一定能够完美适合具体的某个业务。
所以，如果有钱有时间，投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择。毕竟，很多的大公司都是这么干的。
