软件开发领域有一个流行的原则：DRY，Don’t repeat yourself，即不要重复造轮子。开源项目的主要目的是共享，就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目可以节省大量的人力和时间，大大加快业务的发展速度。
开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分技术人员都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万条数据，甚至灾难性的事故是全部数据都丢失。
不要重复发明轮子，但要找到合适的轮子。
聚焦于是否满足业务，而不需要过于关注开源项目是否优秀。
如果你的业务要求 1000 TPS，那么一个 20000 TPS 和 50000 TPS 的项目是没有区别的。架构是可以不断演进的，等到真的需要这么高的时候再来架构重构，这里的设计决策遵循架构设计原则中的“合适原则”和”演化原则”。
很多新的开源项目往往都会声称自己比以前的项目更加优秀：性能更高、功能更强、引入更多新概念，但实际上都有意无意地隐藏了一个负面的问题：更加不成熟！
不成熟的开源项目应用到生产环境，风险极大：轻则宕机，重则宕机后重启都恢复不了，更严重的是数据丢失都找不回来。
在选择开源项目时，尽量选择成熟的开源项目，降低风险。
从这几个方面考察开源项目是否毕竟，很多财大气粗的公司（BAT 等）都是这样做的，否则我们也就没有那么多好用的开源项目了。成熟：
大部分架构师在选择开源项目时，基本上都是聚焦于技术指标，例如性能、可用性、功能这些评估点，而几乎不会去关注运维方面的能力。
如果要将项目应用到线上生产环境，则运维能力是必不可少的一环，否则一旦出问题，运维、研发、测试都只能干瞪眼！
从这几个方面去考察运维能力：
如果是开源库，例如
Netty这种网络库，本身是不具备运维能力的，就需要在使用库的时候将一些关键信息通过日志记录下来，例如在Netty的 Handler 里面打印一些关键日志。
从这几方面进行研究和测试: 毕竟，很多财大气粗的公司（BAT 等）都是这样做的，否则我们也就没有那么多好用的开源项目了。
再怎么深入地研究，再怎么仔细地测试，都只能降低风险，但不可能完全覆盖所有线上场景。先在非核心的业务上用，然后有经验后慢慢扩展。
即使前面的工作做得非常完善和充分，也不能认为万事大吉，尤其是刚开始使用一个开源项目，运气不好可能遇到一个之前全世界的使用者从来没遇到的 bug，导致业务都无法恢复，尤其是存储方面，一旦出现问题无法恢复，可能就是致命的打击。
对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。
当发现开源项目有的地方不满足需求时，自然会有一种去改改的冲动。一种方式是投入几个人从内到外全部改一遍，将其改造成完全符合业务需求。但这样做有几个比较严重的问题：
所以不要改动原系统，而是要开发辅助系统：监控、报警、负载均衡、管理等。
以 Redis 为例，如果我们想增加集群功能，则不要去改动 Redis 本身的实现，而是增加一个 proxy 层来实现。
如果实在想改到原有系统，建议直接给开源项目提需求或者 bug，但弊端就是响应比较缓慢，这个就要看业务紧急程度了，如果实在太急那就只能自己改了；如果不是太急，建议做好备份或者应急手段即可。
选与不选开源项目，核心还是成本和收益的问题，并不是说选择开源项目就一定是最优的项目，最主要的问题是：没有完全适合你的轮子！
软件领域和硬件领域最大的不同就是软件领域没有绝对的工业标准。
开源项目为了能够大规模应用，考虑的是通用的处理方案，而不同的业务其实差异较大，通用方案并不一定完美适合具体的某个业务。
如果有钱有人有时间，投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择！