一、前言

技术人一般都喜欢研究技术，但是如果你问他一般技术选型到底怎么做，估计他一下子懵掉了。因为一般来说，技术人可能更关注于学习什么新技术，反而更少去了解怎么选择一种合适的技术手段去解决业务问题。因为平时日常工作也需要涉及到这块领域，因此心里一直想想总结一下，毕竟作为一个十几年的老司机，在做技术选型的时候如果完全都是随心所欲的话，那就真的太水了吧。

首先，技术选型它会涉及到方方面面的因素，例如市场上的人员招聘难度、技术组件的社区活跃度、文档丰富程度、具体落地案例、后期运维复杂度、人员学习成本等等不一而足。这里我就开始讲一下我对一个系统的技术选型的一些个人拙见吧，也权当为自己做个总结给到以后参考吧。。

二、因素

1、社区活跃度

社区活跃度高，才不断有人提 issue，不断有人 commit，这个产品才能健康茁壮的“成长”。一般来说，主要看以下三个指标：

最后，如果选择开源的话，最好是从 Apache 基金会里面的项目去选取，毕竟大部分项目都是由那些头部企业贡献出来的，质量还是有一定保证且经过业务验证（当然肯定是有“阉割”的），但是针对我们一般的企业那肯定是没太大问题。

大家有兴趣可以浏览一下 Apache 项目列表：

2、具体落地案例

我相信任何人也不想当白老鼠吧，特别如果是针对一些更重视成熟方案是否曾经落过地的行业，例如如银行业。

3、运维复杂度

我们在做技术选型或者针对厂商产品选型的时候，要注意奥卡姆剃刀，千万别好高骛远想着要上什么“高大上”的解决方案，看起来多厉害啊；而且要适度的考虑到运维成本，这里的成本包括学习成本、日常运维的时间成本及相应的技术人员储备成本。特别如果对于一些刚创业或者技术团队规模不大的公司，哪里能找到那么多的“全能人”，就算找到凭什么人家要选择你？这样的话带来的人员连续性风险就很高。

笔者曾经所参与的一个项目，单单数据库中间件就有 6 种，这代表需要懂这 6 种数据库的人才，但这种人才很难找啊。怎么办？办法不外乎两个：

针对不同技术栈招聘不同的人维护，这代表额外的技术人员储备成本；

让团队现有人员分别学习不同数据库并兼顾不同数据库的运维工作，这意味着有额外较多的学习成本；

直接买厂商的维保服务吧，貌似这也是一个选项，只是这个成本一般也不低但实际上也没有太多的工作，但是不买也不行。

4、学习成本

首先我们要定义或明确公司或团队的技术栈，在这个基础之上，我们需要考虑的是团队的接受程度和能力水平了。如果你的团队是用 JAVA 的，而导入的框架却是.net 的话，那估计就真的是要全部重新学习了。因此在选型时有几个建议：

尽量选用跟公司或团队目前主流技术栈相同或相似的。例如，如果你是 JAVA 的，起码尽量选用 Scala 这类基于 JAVA 发展起来的且兼容 JAVA 的，搞起来相对容易一点；

看看团队内部有没有部分人认识或者在前司已经使用过对应的技术栈或框架。如有的话，也可以适当的考虑。

当然这里的学习成本也包含了技术资料的丰富度，其实这里有两个维度的资料。一是官方资料的详尽性，毕竟它是最正规的材料（从源码、使用手册、安装手册等）；二是民间资料，这里指的更多是网民们的博客分享、经验总结。当然我不是建议大家当 copycat，但是大家还是需要尽量基本掌握原理、知其然也要知其所以然；而且，如果有过来人的经验总结对我们来说肯定是事半功倍的，毕竟“站在巨人肩膀上能够看得更远”，起码网上分享能够有助于帮我们进行快速定位问题或者提前避“坑”。

5、公司 IT 策略

为什么会这样说呢？如果公司的业务变化是很频繁的，一般都会要求 IT 具备相应的响应速度，这类型公司一般要求的都是独立自主，相应的技术选型更倾向于开源，毕竟如果选择商业或者闭源的，当你在干着急的时候厂商估计更关心的合同范围的问题（估计国内还好一点，如果让你遇上国外供应商可能有点悬，鄙人前司所负责的一个项目就是因为项目范围变动，然后就是新一轮的谈判，妥妥的合约精神）。

6、业务体量

业务的体量永远是处于动态变化的一个过程，我们在做技术选型的时候考虑的一般是未来 3-5 年的业务量作为一个基准，而非当前。一般来说，我们会按照业务提供的现在和未来的体量进行对应的框架、组件。例如，当我们在做埋点数据采集的时候，我们预期每秒会有数十万的行为数据的话，在队列方面（虽然 Kafka 不是队列），我会更偏向于采纳 Kafka，毕竟 Kafka 作为一款分布式流式数据处理系统，它的水平扩展性要比 RabbitMQ 更优越。另外，凭着 Kafka 内置的零拷贝机制（即绕过用户层直接通过内核层进行数据复制）而带来的高性能，我更偏向于使用 Kafka。

7、注重业务场景

任何的技术选型一定以场景为依归，明明流量没达到，硬要为了“高大上”而“高大上”是完全没有必要，量体裁衣才是最重要的。明明你的系统数据也就千万级别，业务范围就是国内的，选个 mysql+多节点部署基本能解决问题，你硬要上个 spanner，你说你是不是搞事情嘛。就算真要搞，也等到你的业务面向全球再来考虑这个也不晚吧。

8、是否有商业或开源支持

这里体现的更多是业务连续性的问题。我们在做技术选型的时候，因为一开始的时候受到各种因素制约，例如预算不足、业务规模小等，这个时候如果选用开源的话，也可以考虑有能够提供有偿技术支持的开源产品，就是到时遇上什么极端问题也可以通过购买服务解决。这就好像我们平时做服务端开发，操作系统一般采用 centOS，就算后续有什么断更的情况下也可以切到有技术支持的 Redhat 去。

三、原则

1、经验主义需要适当被重视

这里的“适当”是指针对经验要懂得去粗取精，既不要“全盘否定”也不要“拿来主义”。经验能够在一定程度上省略了繁琐的分析计算过程，简化了事情处理步骤，能够将实物通过经验这种更加直观高效的方式展示出来。本质上来看，现在很多方法论都是从经验萃取一步步升华而来的，特别我们尤其习惯或者擅长于使用归纳法而非演绎法。

2、在市场上是否主流

主流意味着是成熟方案，成熟方案意味着坑已经被很多前人踩过了，我们实际上是没必要再踩一遍的。主流意味着多人使用，多人使用意味着学习成本低，人员置换度高，这样的话从采纳到投入使用的周期就短，而且人员连续性也得到保证。具体如果想了解业界目前哪些技术比较主流的话，官方的话可以注意类似 ThoughtWorks 的技术雷达；民间的话直接上招聘网站看看也能获取到一些信息的。

3、本地化技术支持

如果是选择厂商的话这个太重要了。有故障发生的时候，什么都得靠远程支持效率是出奇的低（不接受反驳）。那个场景下，什么都是假的，以最快速度修复故障，最小代价降低业务损失比什么都要高优先级。报个障还得等厂商技术坐个飞的十几个小时过来，你等着切腹吧。

4、货比三家、同业调研很重要

这个不多讲了，就好像大家买东西一样的道理，看多几家总没错的，说不定可以通过多家咨询总结出目前该产品/技术框架的一些优缺点、业界通用方案、替代方案呢。而且，要敢于多点向自己同行多交流经验，纵然不一定会把老底掏出来给你看，但是也能在宏观层面也能向同业学到一些经验，总比自己瞎捣鼓要强得多。

5、先做 POC

对于首次引进的产品/技术框架，充分全面的技术验证这个步骤是必不可少的，而且验证的案例一定是拿公司里面的最复杂的情况进行验证，而且整个验证过程最好是按照日常的工作流程进行模拟，有很多人贪图方便就拿个简单案例把产品部署一下验证一下没问题就“鸣金收兵”，这样风险还是蛮高的，起码本人可是被某些我认为是“有意图的重要信息掩盖”坑过一次，最终当然也是通过商务方式进行解决。

四、决策

当我们依据以上的因素、原则进行了初步的评估筛选后还有几个对应的解决方案能满足需求的话，那我们应该如何进行正式的决策，避免决策的主观性呢？这里可以使用 CMMI 模型里面的 DAR 模型（Decision Analysis and Resolution）。

DAR 一般涉及到以下几个活动：

建立评价备选方案的准则（即评分项）

识别备选方案

使用已建立的准则对备选方案进行评价

基于评价结果选择最终方案

首先，在建立评价准则的时候，需要考虑相关干系人的关注点并把关注点纳入到准则当中并尽量通过数字和权重进行量化以便后续量化评分。当然，评价准则应该要尽量避免存在那些一票否决的评分项。因为如果存在这些一票否决的因素，直接就可以按这个因素选择了而不必使用这个 DAR 模型了。

接着，当我们识别到备选方案后，就根据评价准则（评分项）进行打分汇总后得出每个方案的最终得分。如果评出来的分数最高的剩余方案之间的分差不明显的话，我们就要挑战或者说重新调整我们的准则，然后针对剩余方案再次发起评价。

五、后语

技术选型本身就是一门复杂的学问，上述的因素考量要基于具体的项目而定，不同的项目对上述因素的权重考量是不一样的。作为技术负责人，有些时候就算我们上述方法都用尽了可能最终还是算了一个非最优方案。但没关系，我们更应该注重的是，当我们选择的这个方案出现问题的时候，反而更应该通过利用上述的因素反过来去优化或弥补现在的方案的缺陷或问题，让这个方案变成最优方案，这才是最重要的。