知识卡片
开源项目二次开发的原则——改外围而非改内核
内容
发现开源项目不满足需求时，直接大改源码看似直接，实际代价很大——投入人力多，且改动越大越难跟上原项目后续版本演进。更好做法是保持原系统纯洁，通过外围辅助系统扩展能力，比如不改Redis本身而加一层proxy实现集群功能。若无合适现成方案，也可选择重新造一个贴合业务的轮子——这不是否定不重复造轮子，而是承认没有哪个开源项目为你的业务量身定制，选开源还是自研本质是成本收益权衡。
参考来源
- 位置：《从0开始学架构》第53章《48｜再谈开源项目：如何选择、使用以及二次开发？》（源文件：_epub-src/OEBPS/Text/part0052_split_004.html）
- 结论依据：原文明确"不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等。以Redis为例，如果我们想增加集群功能，则不要去改动Redis本身的实现，而是增加一个proxy层来实现。Twitter的Twemproxy就是这样做的"，并以自研缓存框架案例说明当开源方案确实不满足需求时"投入2~4个人花了大约2个月时间……自己做了一套缓存框架"。
- 原始内容：不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等。以Redis为例，如果我们想增加集群功能，则不要去改动Redis本身的实现，而是增加一个proxy层来实现。Twitter的Twemproxy就是这样做的……投入2~4个人花了大约2个月时间基于LevelDB的原理，自己做了一套缓存框架支持存储、备份、集群的功能。