后端中间件发展现状，哪些值得关注

后端中间件发展现状，哪些值得关注？

最近在跟几个大厂的朋友聊后端架构的时候，明显能感觉到中间件技术在持续演进。今天就结合自己的一些实际项目经验，跟大家聊聊当下后端中间件的几个重要方向。

消息中间件：Kafka依然强势，新势力崛起

在消息队列领域，Kafka仍然是当之无愧的王者。我们项目组去年迁移到Kafka后，消息处理吞吐量直接提升了3倍多。这种基于分布式日志设计的架构确实抗住了我们每天上亿级的消息量。

不过有几个新选手也值得关注：

1. **Pulsar**：它采用了存储计算分离的架构，我们在测试环境部署后发现扩容特别方便，而且支持多租户特性很对SaaS类项目的胃口

2. **NATS**：轻量级的消息系统，有个项目做IoT设备通信时选用了它，内存占用只有RabbitMQ的1/5

RPC框架：云原生时代的选择

Dubbo在Java生态中的地位短期还是难以撼动，但我们发现越来越多的团队开始在云原生项目中使用：

• **gRPC**：跨语言支持做得真的好，上周给Python微服务对接Go服务时，proto文件定义好两边就能直接通信

• **RSocket**：支持反应式编程模型，在需要处理大量长连接的场景下表现惊艳

最近帮一个客户做技术选型时，发现他们甚至用**gRPC**代替了部分RESTful接口，性能提升明显。

数据存储中间件：多模数据库成趋势

现在谁还只用一个MySQL打天下啊？我们项目组的存储方案已经是组合拳了：

• **Redis 6.0**：客户端缓存功能让我们的热点数据查询QPS直接起飞

• **MongoDB 5.0**：时序集合功能完美解决了设备监控数据的存储问题

• **ClickHouse**：做实时数仓简直不要太爽，上次把报表查询时间从15分钟压到了30秒

特别要提一嘴**TiDB**，我们的财务系统迁移过去后，再也不用半夜做分库分表维护了。

服务网格：从概念到落地

去年在K8s集群里试水**Istio**时踩了不少坑，但今年1.10版本之后确实稳定多了。最大的收获是把服务间的TLS配置从应用层下沉到了基础设施层，安全团队的小伙伴表示很满意。

不过要注意的是，中小规模的项目用**Linkerd**可能更划算，我们在测试环境对比过，资源开销能差出40%左右。

最后说几句

中间件选型最重要的是匹配业务场景，别盲目追新。我们有个教训：曾经在QPS不到1000的项目强行上Kafka，结果运维成本反而比用RabbitMQ高出一截。建议先做好技术评估，可以先在非核心业务试点。

大家最近在中间件使用上有什么心得？欢迎在评论区交流。下一期准备聊聊Service Mesh在2023年的最新实践，想看的同学可以点个关注。