一、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

适用场景：企业级供应链系统、金融对账、定制化消息通知

选择依据：功能完备，阿里提供的定制化特性（如延迟消息、死信队列）能快速满足复杂业务需求，避免二次开发。

五、总结

消息队列选型需结合企业规模、并发量、功能需求综合判断：

1. 高并发大数据场景（如大厂日志采集、峰值订单），优先选 Kafka，极致高吞吐适配大数据生态
2. 中低并发但需丰富功能（如电商核心业务、分布式事务），选阿里自研的 RocketMQ，可靠性高且功能全面
3. 中小企业低并发场景，选轻量级的 RabbitMQ，部署运维简单，降低技术成本
4. ActiveMQ 因性能和维护问题，目前新项目已基本不再使用