虽然刚工作几年接触不到技术选型，因为大部分已有架构设计、总体设计的人确定了，但随着个人工作成长，未来很可能要面临技术选型，其实如果你真的动手做些自己的项目的话，也面临着技术选型，只是看你是否足够重视罢了。吸取别人失败的教训会让我们少走弯路。
其原因大致可概括为：缺乏估算、实验不够与轻视经验。这三点该如何理解呢？
| 缺乏估算
简单来说就是对技术模型维度的分析，考虑某个组件是否有可能达到我们想要的目的，确认它是否真的做到了。
就像选择一门开发语言，我们会考虑它的内存模型和性能指标，而数据库选型，我们则会考虑其存储模型、数据量级及成本开销。如果是开源项目，还要考虑它的社区活跃度、分值支持率及文档完整性等。
对于像中间件这种关键技术项，除了考虑它的健壮性、扩展性及灵活性等基本要素，你还应适当阅读核心源码，不能因为耗费精力过多、嫌麻烦，就一笔带过。
| 实验不够
既然是估算，那就有可能存在偏差。比如一个语言虽说具有自动管理内存的功能，但并不代表它在所有场景下都会起作用，因此需要实际场景实验，毕竟用实际数据说话是最靠谱的。
所以，要对核心业务进行场景镜像构建，并使用工具对服务进行特定场景下的分析，或通过提高压力、增加容量或者针对性的测试，来验证是否达到预期，并分析不同场景之间的差异和表现。比如可以尝试在开发环境做一次，在集成测试环境做一次，最后在仿真环境再做一次。
在实际工作中，这几步往往被简化，而我觉得，如果你希望中间件这种关键技术项在生产环境中运行稳定且高效，你就应该严格走好每一步。
| 轻视经验
在技术选型上，我一向忌讳 “在百度搜一下，觉得差不多了就照抄” 的方式，尤其对于中间件这类基础服务来说，忽视经验的举动都是危险行为，在还没弄清楚原理与本质之前，如何才能确定这项技术是否经得起产线的考验？
比如我对分布式数据库进行技术选型，通过百度搜索下，肯定出现许多看上去极其靠谱的信息，但我们的需求是解决并发与读取频率较高，而数据块不大，对于交易系统而言，必须确保数据安全，显然这样的需求无法使用关系型数据库，因为性能是瓶颈，然而看看网上写的，几乎所有的关系型数据库都会说自己能够满足高性能场景。
在实际工作中，我会先列出需求，再细分需求，待明确评判标准之后，或通过基于已有经验进行实验，或走访外部团队进行学习，将经验带回后再进行实验，千万不可盲目的跟风走，哪个热门就选哪个，这些方式不但不正确，而且后患无穷。