软件开发领域有一个流行的原则：DRY，Don’t repeat yourself。翻译过来更通俗易懂：不要重复造轮子。开源项目的主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？
然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分技术人员都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万条数据，甚至灾难性的事故是全部数据都丢失。
除此以外，虽然 DRY 原则摆在那里，但实际上开源项目反而是最不遵守 DRY 原则的，重复的轮子好多，你有 MySQL，我有 PostgreSQL；你有 MongoDB，我有 Cassandra；你有 Memcached，我有 Redis；你有 Gson，我有 Jackson；你有 Angular，我有 React……总之放眼望去，其实相似的轮子很多！相似轮子太多，如何选择就成了让人头疼的问题了。
怎么办？完全不用开源项目几乎是不可能的，架构师需要更加聪明地选择和使用开源项目。形象点说：不要重复发明轮子，但要找到合适的轮子！但别忘了，如果你开的是保时捷，可别找个拖拉机的轮子。
选：如何选择一个开源项目
1. 聚焦是否满足业务
架构师在选择开源项目时，一个头疼的问题就是相似的开源项目较多，而且后面的总是要宣称比前面的更加优秀。有的架构师在选择时有点无所适从，总是会担心选择了 A 项目而错过了 B 项目。这个问题的解决方式是聚焦于是否满足业务，而不需要过于关注开源项目是否优秀。
Tokyo Tyrant 的教训
在开发一个社交类业务时，我们使用了 TT（Tokyo Tyrant）开源项目，觉得既能够做缓存取代 Memcached，又有持久化存储功能，还可以取代 MySQL，觉得很强大，于是就在业务里面大量使用了。但后来的使用过程让人很郁闷，主要表现为：
