技术选型的一点个人思考

2021年9月7日 2点热度 0条评论 来源: 是春壹呀

目录

1.前言

这个题目有点大。工作也有些年头,从开始入行的被动接受,什么流行就学什么;到有一些想法,会去思考为什么使用这种技术;再到主动去学习一些前沿框架。从开始的不理解,事不关已高高挂起,不在其位不谋其政;到也成为了团队中的中坚力量,去据理力争应该使用某些技术,把觉得好的技术安利给同事,试图引入到团队中;有成功有失败;也有迫于种种因素使用一些所谓“过时的技术”,有时候有在想,这种“被迫”或"过时"是“为了技术而技术”吗?

本人从事的是JAVA后端开发,从业七八年,时间不长,但也经历了不少。从需要使用juqery,easyui等各种前端技术,到前后端分离成为主流;
从一开始的hibernate+structs/structs2框架大行其道,到后来几乎消声匿迹;
从最初的redis/memcache两者之间还能一较长短,到redis一统江湖。
从spring mvc 到言必谈spring boot,微服务。不来两句服务化,降级限流熔断,高并发你都不好意思出门。

后来转战“大数据”领域。那时mapreduce已是明日黄花,strom以及阿里巴巴主导的汉化版jstorm也是江河日下。而spark正当其时,如日中天。遂入坑。
到flink异军突起,阿里巴巴再出汉化版blink,与spark分庭抗礼,直至略占上风。后来者只知flink,而鄙视spark之风气,怪异而可爱。

从传统关系型数据库到非关系型数据库,NOSql,NewSql,到数据湖,再到兼顾OLAP,OLTP的各种分布式数据库如雨后春笋般出现。
这时期的数据库已无法像传统关系型数据库那样三足鼎立(o+m+else)(java位面下),而是春秋时期百家争鸣的局面,各家大厂根据自身的业务需求订制化了许多产品,包括不限于Fusion,mariadb,OceanBase,TiDB,ClickHouse,greenplum,dorisdb,kudu等等。
对于普通开发者,这是好事?坏事?
对于技术团队,这是好事?坏事?
有了更多的选择权?要学的东西更多了?

怎么选择一种技术框架,从是否开源,是否KPI开源,开源社区是否活跃/持续/稳定(我没有说阿里,别乱说),是否有国内大厂使用,社区(特别是问答社区)是否活跃,中文资料是否够多,都是影响普通开发者/团队选择某种技术的原因。

下面将从效率(技术本身),环境(开源,社区),团队(负责人/骨干的技术水平和技术偏好)三个方面来谈谈我的看法。

为避免说教的意思,以及倚老卖老(并不老)的嫌疑,首先声明,以上以下只代表个人观点。

2.效率

2.1没有绝对的效率

我有点害怕技术讨论会上,上来就说据XX公司/官网测试,XX比XX效率高出5%(8%or10%...).

这就有点像面试中上来就问QPS多少。不才曾经做过一个广告竞价平台,日均访问量几千万,听起来好像很牛逼的样子,但该系统是纯内存计算,严格限制单次访问时间,这种系统谈QPS根本不具备任何横向参考意义。

或者像面试中多次被问到spark/hadoop集群多少个节点的问题。我一般会回答一个大概的数字,然后补充一下集群cpu cores/内存/存储空间总数,必要时补充集群任务数,单日/总处理数据量。如果只是性能空间并不太好的有限物理机,用容器虚拟成上千个节点,那就达到了大厂的集群规模了吗?

只有在控制变量的前提下,谈论单一指标才有意义。

效率并非不重要。但为那点3%的效率牺牲其它东西,值得吗?这是值得衡量的。说句诛心的话,那点性能优势对于绝大多数公司,我觉得可能是你自己想多了。还不如好好优化一下那堆shit山。

2.2效率是否绝对重要

在RocketMq(阿里牛逼!)没有开源前,消息队列一般有三种选择RabbitMQ,ActiveMq,ZeroMq。
三者控制变量的前提下,TPS测试结果表明ZeroMq效率最高。但那些年我所待过的公司,我了解到的情况(同事,网络),消息队列基本都在RabbitMQ,ActiveMq两者之间选择,鲜少使用ZeroMq.

这个例子可能并没有很强的说服力。但大概就是这么个意思。

3环境

3.1国内开发大环境

最典型的例子就是mybatis vs hibernate.
除了银行之类的老项目,现在有新项目在使用hibernate吗?就算有,hibernate在国内也早就远离了主流。
可是,在国外,hibernate依然是绝对的主流。
在stackoverflow上的tags数量,看对比图,hibernate热度碾压mybatis,两者根据不是一个数量级.

按google搜索趋势,过去五年,hibernate的搜索量依然碾压mybatis.

同样google搜索趋势,按国家地区划分。全球范围内,mybatis热度胜过hibernate的,只有东亚地区。中日韩东亚三国最喜欢mybatis。迷惑。。。

为何会有这种地区之间的巨大差异?有人说是阿里巴巴的带动作用。阿里对国内JAVA整体环境的带动和影响是毋庸置疑的,但在mybatis之所以流行这件事情上,完全归于阿里,也无法解释韩国和日本同样流行mybatis这件事。

不管怎么说,不管公司,团队还是个人,都是一定程度上从众的。既然大环境都在使用mybatis,那么这样用就不会犯大错。公司好招人,个人也好找工作。大家的成本都在最低,皆大欢喜。

3.2技术社区的影响

有个笑话,外行人看到程序员在工作,觉得好牛逼,全英文的界面。知乎也常有提问,英语不好,学编程可行吗?
底下回答,很多鼓励,英语跟编程没有太大关系云云。

这句话有毛病吗?
这至少透露出来两层意思。

  • 不是说编程方面英语不重要。英语好,优势巨大。

  • 国内程序员很多英语不好。以本人常年混迹小公司的经验来说,好多程序员连eclipse或者idea上常用的界面按钮上的单词都认不全。唯手熟尔。不懂就百度。这个很多,是好多,无法统计,但个比例绝对不低。

  • 国内IT圈子是一个比较封闭的圈子。虽然,用的技术基本都是发源于国外,但国内的规模保证了资源的足够。比如spark/flink不需要去官网阅读一手资料,各个论坛网站上公众号各种二手三手N手的资料满天飞(这其中博客园已经可以算是一股清流了);比如出现了问题,第一时间打开百度,CSDN虽迟但到,虽然上面都是各种推广广告复制粘贴错误百出答非所问僵尸文章,但一个一个试嘛,多翻几页,总能解决问题嘛。(大雾)

有追求的程序员,或者大厂的大佬觉得嗤之以鼻,遇BUG先必称看源码,再次github issue,stackoverflow,搜索必须google,资料必须原文。对CSDN表示垃圾。

本垃圾表示CSDN是个好垃圾。就算是一条底裤,一张厕纸,都有它的用处。

所以英语跟编程没有太大关系,这不是一个疑问,对很多程序员来说,这就是事实。大量分布于各类中小型公司,严重依赖于国内各种社区学习(copy)技术,解(zhi)决(zao)问题,赚钱养家。

国内头部公司/团队用什么,大多数的公司/团队/个人就用什么。

这件事情的另一个力证是spring cloud vs apache dubbo,两者隐隐有在国内分庭抗礼之势。但在全球范围呢,我就不放google trend图了。有点欺负人。

但是因为apache dubbo是阿里巴巴出品,进而影响到了国内整个程序员圈子,社区,所以大家也逐渐愿意去用,虽然被之前的开源社区挺尸行为伤过。就像一个渣男,但他是高富帅啊,自带光环。

4团队

4.1 团队负责人及核心骨干的技术积累以及技术偏好

2017年新公司进行一个流计算项目。当时整个团队都是新组建,尚处于磨合期。当时我个人偏向于spark streaming,用得比较熟,上手快,能够提前排坑,能快速解决线上问题。但当时的技术负责人在召开技术研讨会,听取各方意见后,决定使用jstorm。

我当然服从决定。
当时的jstorm尚有余晖。而且据说那时jstorm在开源社区诈尸了。颇有几分卷土重来的架势。加上当时负责人力排众议,让我觉得很安心,他应该是很懂jstorm这项技术栈的。

后来项目顺利上线。再后来,不出意外,运行一段时间,遇到棘手线上问题。几次团队沟通后,我得出一个结论,决定使用jstorm的负责人并不了解jstorm,甚至应该不懂java技术栈(客观白描事实,无情绪输出,技术管理者并不一定要懂技术);所以,整个团队最懂jstorm的好像就是我了。
肝吧,骚年。在经历了好几个后半夜,并成功在国庆享受了三倍工资(并没有)后,BUG解决。

后来回想,如果当时上的是spark streaming就不会出现同样的问题,就算出现这样的问题,凭借对spark streaming的较深入了解,也能够快速解决。

上述这段经历,我想表达什么?

  • 一个程序员的竞争力包括什么?不是会用某一种技术,也不是能够快速上手某种新技术。

    • 学习新技术的欲望,动力,能力;快速上手,保证任务,这些只是基本功。对于新技术,能够利用经验,快速理解原理内幕,预排坑道,又快又好解决线上问题,更为重要。所以,当决定使用某种新技术(哪怕技术并不新,如果团队当中没人使用过,没有深刻了解过)时,并不能仅满足于“能快速上手”。
  • 技术本身没有立场。没有好的坏的,没有国外的国内的。有些技术栈,并没有mybatis和hibernater那么悬殊,如何抉择,很大概率就看技术团队的偏好,类似于spark vs flink,spring cloud vs apache dubbo,不管谁是胜出者,都很隐。

  • 除了团队的学习成本,还要考虑其它成本.

    • 比如,运维成本,比如,用scala还是java开发spark.
      用java的好处是虽臃肿但新手外行上手超快。用scala好处是它是spark开发语言,熟悉scala便于查看spark源码,语法强大,逼格高(我真见过scala开发spark的鄙视使用java的);坏处是,语法强大,语法糖很爽,但有时天马行空对于团队合作开发真的是灾难。
    • 行政成本比如招人成本。
      招一个使用scala的程序员不难,基本上会用java的都能快速上手,但要写出没有“java”味儿的scala代码,还真不容易。(scala的java味儿,就是那种,你一看就是java程序员转过来的痕迹,满屏都快溢出来)
    • 等等
    原文作者:是春壹呀
    原文地址: https://www.cnblogs.com/eryuan/p/15223921.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。