一、Java Web 技术演进脉络
1. 早期：Servlet 时代（极简业务）
背景：早期门户网站 / 企业官网，业务极简单、用户量少，几乎无复杂业务逻辑
局限：基于 Servlet（或 Silverlight）开发，代码耦合度高，可维护性差，难以支撑复杂业务（如下单流程）。
2. 框架：SSM 框架（单体应用）
背景：业务复杂度提升（出现下单等流程），Servlet 开发效率与可维护性不足
方案：SSM（Spring + Spring MVC + MyBatis）框架，分层解耦，提升开发效率与可维护性
局限：单体架构，性能瓶颈随用户量增长凸显，高并发下难以支撑。
3. 集群：SSM 集群（水平扩展）
背景：网民数量激增，单体 SSM 性能不足，无法承载高并发流量
方案：部署 SSM 集群（多实例部署），类比「饭店扩建」，提升整体承载能力
局限：集群内负载不均（部分节点繁忙、部分空闲），资源利用率低，且单体逻辑仍耦合
二、微服务的诞生：从「单体拆分」到「业务解耦」
1. 思路------按业务域拆分
类比「连锁饭店负载不均」问题，将单体 SSM 按业务领域拆分为独立模块：
- 用户模块：仅负责用户相关业务
- 积分模块：仅负责会员积分业务
- 订单模块：仅负责订单相关业务
- 支付模块：仅负责支付逻辑
- 商品模块：仅负责商品管理......
2. 微服务
将原本单体的系统，按照业务边界拆分为多个独立、自治的服务模块，每个模块只专注于单一业务域，独立部署、独立演进，这就是微服务架构。
三、演进逻辑
| 阶段 | 技术形态 | 类比场景 | 核心问题 | 演进动力 |
|---|---|---|---|---|
| 早期 | Servlet 单体 | 县城小饭馆 | 代码难维护、业务支撑弱 | 业务复杂度提升 |
| 框架期 | SSM 单体 | 装修后的正规饭店 | 性能不足、并发承载弱 | 用户量爆发增长 |
| 集群期 | SSM 集群 | 连锁饭店 | 负载不均、资源浪费 | 集群效率瓶颈 |
| 微服务 | 微服务拆分 | 专业化分工的连锁品牌 | 解耦、弹性伸缩、高可用 | 分布式系统复杂度与高并发需求 |
微服务不是凭空出现的技术，而是业务发展、用户增长、技术瓶颈共同驱动的必然结果------ 从「单体耦合」到「业务拆分」，本质是为了解耦、提升系统弹性与可维护性，更好地支撑大规模分布式场景。
四、常见消息队列产品特性对比
这张表格对比了ActiveMQ、RabbitMQ、RocketMQ、Kafka四款主流消息队列的核心特性，是技术选型的参考依据。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类系统进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐的影响 | - | - | topic 可达几百 / 几千级别，吞吐量有较小幅度下降，同等机器下可支撑大量 topic | topic 从几十到几百个时吞吐量会大幅下降，需控制 topic 数量或增加机器资源 |
| 时效性 | ms 级 | 微秒级，延迟最低（一大特点） | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式架构（一数据多副本，少数机器宕机不影响可用性） |
| 消息可靠性 | 有较低概率丢失数据 | 基本不丢 | 经参数优化可做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域功能极其完备 | 基于 Erlang 开发，并发能力强、性能好、时延低 | MQ 功能完善，分布式、扩展性好 | 功能较简单，主要支持简单 MQ 功能，在大数据领域（实时计算、日志采集）大规模使用 |
通常选型
- 互联网大厂首选 ：Kafka 和RocketMQ 使用最广泛，原因是高吞吐能力，能支撑大规模并发与数据场景
- 低延迟场景：RabbitMQ 凭借微秒级时延，适合对延迟敏感的业务（如即时通知、实时交互）
- 功能完备需求：ActiveMQ 功能最全面，但吞吐量较低，适合传统企业级场景
- 大数据场景：Kafka 是事实标准，完美适配日志采集、实时流计算等场景
快速选型建议
| 业务场景 | 推荐 MQ | 原因 |
|---|---|---|
| 电商订单、支付等核心业务（要求可靠、高可用） | RocketMQ | 0 丢失、分布式架构、高吞吐，适合金融级可靠性要求 |
| 日志采集、用户行为分析、大数据流处理 | Kafka | 高吞吐，适配大数据生态 |
| 实时通知、IM 消息（要求低延迟） | RabbitMQ | 微秒级时延，响应速度快 |
| 传统企业内部系统（功能全面、并发一般） | ActiveMQ | 功能完备，满足企业级需求 |
分场景总结
1. 大型互联网企业（高并发、大数据场景）
首选：Kafka / RocketMQ
适用场景：双 11 订单峰值、用户行为日志采集、实时流计算、分布式事务消息
选择依据：
- Kafka：高吞吐，适配大数据生态（如 Flink、Spark），支撑百万级 QPS
- RocketMQ：阿里生态深度适配，金融级可靠性，提供消息回溯、事务消息等丰富功能，适合电商核心业务
2. 中小企业 / 创业团队（中低并发、快速迭代）
首选：RabbitMQ
适用场景：后台管理系统通知、小型电商下单、即时消息推送
选择依据：
- 轻量级：安装部署简单，运维成本极低，适合技术团队规模小的场景
- 性能足够：满足中小厂万级 QPS 的并发需求，微秒级时延适配实时交互场景
3. 传统企业 / 定制化业务（中低并发、强功能需求）
首选：RocketMQ
适用场景：企业级供应链系统、金融对账、定制化消息通知
选择依据：功能完备，阿里提供的定制化特性（如延迟消息、死信队列）能快速满足复杂业务需求，避免二次开发。
五、总结
消息队列选型需结合企业规模、并发量、功能需求综合判断：
- 高并发大数据场景（如大厂日志采集、峰值订单），优先选 Kafka，极致高吞吐适配大数据生态
- 中低并发但需丰富功能（如电商核心业务、分布式事务），选阿里自研的 RocketMQ，可靠性高且功能全面
- 中小企业低并发场景，选轻量级的 RabbitMQ，部署运维简单，降低技术成本
- ActiveMQ 因性能和维护问题，目前新项目已基本不再使用