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