献给2021年技术选型中被我否定的那些技术

近几年来，我的团队构建了部门最大规模的线上平台，也是部门迄今最成功的基于微服务架构的系统。每当做部门技术分享，我说的最多的是那些被我否定的技术框架，分析的核心问题是这些技术框架在解决什么问题，我们真的需要么？ 就我的实践来讲，真的没什么可讲的，毕竟最近两年一直在对技术架构做减法。

第一个否定的是ELK架构，平台上线之初，我认真的研究了一下ELK整个技术体系，并进行线上验证，存在如下几个问题，是我团队无法解决的：

1. Elasticsearch的插入效率问题，每秒几百条的速度是个硬伤。 支撑系统3000TPS，每日大约3000万条日志，存在明显瓶颈。而且ES相当耗费内存。
2. 与CentOS系统默认安装的日志系统Rsyslog相比，Logstash的存在是个鸡肋，不明白为什么这么多人推崇。
3. Kibana是为支持Elasticsearch而生的，不多说。

最终选用了Rsyslog + 【实时分析：Goaccess + 日志文件本地存储】 + 【离线分析： Flink + clickhouse+ superset】，环境搭建相对简单，对资源的要求也很低。最最重要的是不想ELK那样大版本升级那么频繁，而且还各种不兼容。

第二个否定的是Springcloud， 不可否认它是一个不错的微服务架构，很多团队也用这个框架交付了很多项目，但我无法忍受的是Springcloud的绝大部分微服务特性，K8S容器引擎都都已经提供了而且对程序是无侵入性的。不用Springcloud的理由很简单：

1.  Springcloud + K8s的微服务特性是重叠的。 针对的业务场景越多，越能体现微服务的优势，再搭配K8s这样的容器引擎真是如虎添翼，但Springcloud这样一个完整的微服务解决方案和k8s从一些功能上是重叠的。如果业务场景单一，我真建议你开发一个大的本体应用，至少这样占用的服务器少，能省钱啊。
2. Springcloud的版本升级很频繁， 难道我要经常全量升级我的线上环境么？

第三个否定的是JWT。项目之初，同事建议采用无状态会话机制，采用JWT，提升平台的并发性能。 这个技术我简单的了解了一下，就否定了：

1. JWT看似节省了服务器的内存资源，但它是基于加密算法的，必定是CPU型，这对平台也是致命影响的。
2. JWT携带了大量的客户信息，就算安全性不说，它每次请求中都带着这样几KB甚至十几KB的请求头，是很占用上行流量的，务必影响并发和吞吐量。
3. JWT所SSO可以考虑，但是作为会话标识是肯定不行的。
4. 一个平台是不可能做完全无状态的，有多少在线用户，客户肯定是在意的。

第四个否定的是MongoDB。 最初的我在生产环境上，真把它作为Nosql的存储方案了，甚至基于它的GridFS进行文件存储，但是存储数据量的增加，MongoDB无法满足查询需要，相同配置下，远不及clickhouse。文件存储方案也该用更加简单的Fastdfs。