好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受。
不谈具体技术，从更高层面看，技术选型应该怎么做？
写在前面
技术选型是一个很热门的话题，最近我看到自己的微信朋友圈有好几篇关于技术选型的文章，读者对这类主题的热情很高。在技术组织内部，技术人员经常会面临技术选型问题，有时候，技术选型还常常牵扯好几波干系人，相互之间还会产生争议，有的甚至还可能发展到派系斗争的地步。即便像我自己，已经有十几年研发和架构经验的老司机，不管是工作还是业余，有很大部分时间的思考都是深陷在 A 技术和 B 技术的利弊权衡之中，不能自拔。无论如何，技术选型说小了关乎项目和团队成败，说大了关乎企业业务的发展，不可小觑。
本文所表达的技术选型理念应该是与具体技术无关的，但是由于我个人的背景更偏向互联网后端的研发和架构，所以本文的视角更偏向后端技术的选型。
软件的本质复杂性
近年，云计算、微服务、容器和 DevOps 等新技术和理念层出不穷，技术人员对各种新技术的追捧热情也空前高涨，各种新技术微信讨论群也如雨后春笋般冒了出来。这是一个好现象，说明我们的开发人员多了，技术环境也日趋成熟，有点百花齐放的感觉。同时也让我有一点担忧，我担忧的是纯技术和工具论的抬头，也就是太过专注技术，认为技术可以搞定一切，反而忽略了软件研发的本质复杂性。回想当年，自己也曾是这样的技术狂热分子，EJB 刚出来的时候，我为 EJB 摇旗呐喊，Spring 出来的时候，我也曾一度是该技术的死忠，简单认为这些技术是银弹可以帮助解决所有的复杂性问题。
1986 年，人月神话的作者 Brooks 就提出，软件的本质复杂性（Essential Complexity）存在于复杂的业务领域中（用技术的话讲是业务领域建模复杂性），技术仅是辅助工具，它解决的问题是帮助将业务领域问题映射转换成软件实现，只解决次要复杂性（Accidental Complexity）。
作者同时指出，由于软件本质的复杂性，真正的银弹并不存在；也断言在十年内，没有任何一项技术或者方法可使软件工程的生产力提高一个数量级。30 年前作者提出的论断，今天依然闪烁智慧的光芒。人月神话已经出了 40 周年纪念版了，堪称软件工程的圣经，建议所有从事软工行业的朋友学习。除了业务和技术，我还想强调软件的本质复杂性同时隐含在企业的人、组织、流程和管理中，不容忽视。
架构师只有深刻理解软件的本质复杂性，才能站在解决实际业务问题的角度，更好的做出技术选型，否则易陷入唯技术工具论的陷阱。
使用成熟的技术
大部分公司都是商业组织，不是科研机构或者纯软件研发机构。商业组织使用技术是为了解决当下的业务问题，他们更应该使用成熟稳定的技术。
如下图，技术的使用有明显的生命周期，早期有创新者和早期使用者采用，我把这个阶段称为试水趟坑期，也就是说这个阶段技术不是很成熟稳定的，虽然尝新者可能占据一定的技术领先优势，但是他们常常需要以踩坑填坑作为代价；如果这项技术经过早期验证则会跨越鸿沟进入早期大众阶段，这个阶段技术会逐渐走向成熟，处于上升期，坑逐渐被填平，技术被大众所采纳；之后技术缓慢经过末期大众阶段，最终走向滞后期，一直到生命周期的结束退出历史舞台。
技术选型的一大智慧是不要盲目追求新技术，老老实实采用成熟稳定的技术，让那些喜欢追新的人去踩坑