技术选型的一点个人思考

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

---

本人从事的是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.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.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.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程序员转过来的痕迹，满屏都快溢出来）