引出四个维度
工作快十五年了，从十年前开始经常会有新项目，需要从头开始做方案和设计。做技术选型很少成为我的难题。不是因为这方面我多有方法，而通常是很少有选择。在做技术选型的场景下基本有以下四个维度：
维度一
从系统构成上有两种：
第一种，有之前的老系统，需要重构
第二种，从零开始建的服务
维度二
从稳定性要求上有三种：
第一种，现在没有什么业务量，将来估计也不会有什么增长，甚至很可能不成
第二种，现在没有什么业务量，将来对稳定性要求很高
第三种，现在对有稳定性要求很高
维度三
从环境上有三种：
第一种，公司有很多基础设施
第二种，公司有一些基础设施
第三种，公司基本没有基础设施
维度四
从要求上有两种：
第一种，公司有标准化规范，需要用公司的统一组件
第二种，公司没有要求
各个维度组合的选项考虑
从零开始项目现在没有什么业务量，将来估计也不会有什么增长
从目标上，遇到这种项目，工作的重心就不在于把项目做好做坏，而在于人员培养。
如果公司对组件上没有什么要求，那我的建议是大家想学什么，就用什么。直接拿学习的试验田来用，一举两得。
如果公司有标准化规范，需要用公司的统一组件。但是公司的组件一般也是开源进行二次开发的，也一样可以想学什么就用什么，弄不明白的，还可以找维护组件的人请教。也可以用公司自研的，但是在业界有一定知名度的产品。研究的好可以作为面试的一个亮点。
瞎举个例子哈：
一六年、一七年做P2P并且不合规的公司，眼看就不行了。有的团队用的kafka，就是为了学习这个东西；有的团队自己搭建redis集群也是为了学习。
从零开始项目现在没有什么业务量，现在或者将来对稳定性要求很高
从目标上，这个是产生业绩的最佳项目，要精心规划。
做这种项目需要做好调研，包含业界调研和公司调研。业界的同类产品是怎么做的，有哪些缺点和优点。公司有没有同类或者可以登高类比(登高类比是指先找相似度最高的，找不到在逐渐扩大范围)的，那些项目遇到过哪些坑或者问题，是否和架构或者技术选项有关。
在做好调研基础上，如果公司对组件上没有什么要求，那就需要根据项目本身的特点综合比较。举例如下图：
不考虑项目本身特性，使用技术通用的考察项主要有：优势、劣势、技术成熟度、社区活跃度、资料丰富程度、是否有大牌公司在持续维护。
可参考我之前的文章《SpringBoot整合web容器》里面有介绍我当初对tomcat还是jetty选择的考虑点。
如果公司有标准化规范，需要用公司的统一组件。
这时候，如果公司的组件可选性很多，比如之前美团的监控告警组件就有cat、digger、tracing、大白等。这时候一方面考虑各个组件的侧重点和自身是否切合，最重要的是要看其他团队都用什么。周围团队用的很少，咱们也不要用了。兄弟团队有福同享有难同当，如果大家都用这个，组件稳定性有问题了，影响的不止一个团队，也相互有个依靠。就自己用了还出事了，额，让我想起一句歌词：“多少秘密在其中 欲诉无人能懂”-----一帘幽梦。暴露年龄了。
如果公司的组件只有一个，也要看看兄弟团队有没有在用，还需要组件团队给提供相应的SLA，对于还在推广中的组件要谨慎。
重构老系统现在没有什么业务量，将来估计也不会有什么增长
建议放弃重构！
重构老系统现在没有什么业务量，将来对稳定性要求很高
参考从零开始项目现在没有什么业务量，现在或者将来对稳定性要求很高的方法。
重构老系统，现在对稳定性要求很高
建议选型尽量和之前保持一致，以便于和之前的逻辑尽量一致。避免踩到特殊需求导致的特殊逻辑等坑。
实在不能一致，比如十二年前我们有个“新鲜事”中间件，类似于网页版的发朋友圈吧。之前是用c++写的，后来c++的同事都离职了，要求我们改成java。这时候要考虑的主要是技术的成熟度。这个成熟度包含业界技术本身的成熟度和团队成员对技术的熟练度。
对于这种类型，还有几句忠告：
不要特立独行，要合群！
使用成熟的技术！
使用成熟技术的成熟功能！
最后对使用成熟技术的成熟功能做个解释说明：比如redis很成熟了，redis有很多高级特性，比如订阅转发，稳定性要求高的不要用。用更加成熟的常用做订阅转发的比如MQ!
