选开源项目：聚焦是否满足业务，而非项目是否优秀

软件开发领域有个流行原则叫DRY（Don’t repeat yourself），翻译过来就是”不要重复造轮子”。开源项目的主要目的正是共享，让大家不用重复造轮子——尤其在互联网这种快速发展的领域，引入开源项目能节省大量人力时间、加快业务发展速度。但现实没那么美好：开源项目虽然省了人力时间，带来的问题也不少，轻则宕机半小时，重则丢失几十万条数据甚至全部数据丢失。更讽刺的是，虽然DRY原则摆在那里，开源项目本身反而是最不遵守DRY的领域——你有MySQL我有PostgreSQL、你有MongoDB我有Cassandra、你有Memcached我有Redis，相似的轮子实在太多，选择反而成了让人头疼的问题。完全不用开源项目几乎不可能，架构师需要更聪明地选择和使用：不要重复发明轮子，但要找到合适的轮子——但如果你开的是保时捷，可别找个拖拉机的轮子。选择时一个常见误区是纠结”哪个项目更优秀”：相似的开源项目里，后出的总爱宣称比前面的更优秀，架构师容易因为担心选A错过B而无所适从。正确做法是聚焦于是否满足业务，而不需要过于关注开源项目本身是否优秀。书中以TT（Tokyo Tyrant）为例：某社交业务觉得TT既能当缓存替代Memcached，又有持久化存储能取代MySQL，功能强大就大量引入，结果发现TT不能完全取代MySQL（导致要维护两份存储、每次都要讨论数据该放哪）、功能强大但bug不少（甚至出现所有数据不可读，靠自己研究源码写工具才恢复了部分数据）、且需要花很长时间熟悉细节，不熟悉很容易踩坑；事后反思，其实当时的业务用Memcached+MySQL的组合完全能满足，且团队都熟悉，根本不需要引入TT。简单来说：如果业务要求1000TPS，一个20000TPS和一个50000TPS的项目对你而言是没有区别的；如果担心未来TPS上涨，也不用过于担心，架构本来就是可以不断演进的，等真正需要那么高时再做架构重构即可——这正是架构设计原则中”合适原则”和”演化原则”在开源项目选型上的具体体现。