企业官网建设流程全解析

简介：这份资料是北邮国际学院中间件课程的期末复习材料，聚焦Block1至Block2的核心考点，适合正在备考中间件相关课程的高校学生梳理知识框架。内容围绕Middleware概论与Messaging机制展开，涵盖中间件的通讯桥梁定位、消息服务的创建发送接收读取删除流程，以及异构集成、减少系统瓶颈、提升可扩展性三大优势，并逐一区分云消息服务、短消息服务、即时消息服务与多媒体消息服务四类机制，同时延伸至面向消息的中间件MOM定义与结构，知识点覆盖较为完整。资源包内含1个PDF文件，大小约1.93MB，便于打印或平板批注复习。目前已有290人学习，可作为期末冲刺阶段对照讲义查漏补缺的参考，帮助读者快速建立从概念到分类的复习脉络。

1. 从一道期末题说起：MOM 到底在考什么

期末复习翻到 Middleware 这一章，很多人第一反应是背定义：消息中间件、异步、解耦、P2P、Pub/Sub。但真到做题或者面试被追问，往往卡在一个点上——为什么要有 MOM，它到底解决了什么工程问题。我见过太多人把 MOM 当成"发消息的组件"来记，结果一遇到"异构集成""系统瓶颈""可扩展性"这类考点就答不到点子上。

这份复习资料覆盖的是 Middleware 里最核心的两块：Messaging 机制和 Message-oriented Middleware（MOM），以及 Java Messaging Service（JMS）的编程模型。它适合正在准备中间件期末的在校生，也适合想快速把 MOM 概念体系捋一遍的开发者。内容偏概念和 API 结构，不是让你跑一个完整项目，而是让你能把"消息服务→MOM→JMS"这条链路讲清楚、写出来、答对题。下面我按复习的实际节奏，把这份资料拆成能直接用的笔记。

2. Messaging 机制：从 peer-to-peer 到四类消息服务

2.1 Messaging 的定义与 peer-to-peer 特性

Messaging 的本质是一种软件组件或应用程序之间的通信方法。资料里给了一个很关键的定义：peer-to-peer facility——每个 messaging client 既可以向其他 client 发消息，也可以从其他 client 收消息。这句话在选择题里经常被拿来和"客户端-服务器"做对比，考点在于：messaging 里没有固定的服务端和客户端角色，每个组件既是 client 也是 server。

消息服务（Message Service）是建立在面向服务架构（SOA）之上的软件组件功能，允许用户创建、发送、接收、读取、删除和保存消息，消息形式包括文本、音频、图片和视频。这里有一个容易被忽略的细节：发送方只需要知道数据格式和接收方的目的地，不需要知道接收方内部怎么处理。这正是后面"松耦合"的伏笔。

2.2 三大优势：异构集成、减少瓶颈、提高可扩展性

资料把 Messaging 的优势归纳为三条，每一条都可以单独出简答题。

异构集成（Heterogeneous Integration）：实现不同平台之间的通信和集成，可以调用完全异构平台上实现的服务，提供无缝连接。考试里常问"为什么消息中间件能连接不同语言写的系统"，答案就落在这里——因为消息是跨平台的，发送方和接收方不需要共享编程语言或运行环境。

减少系统瓶颈（Reduce System Bottlenecks）：瓶颈出现在某个进程的处理速度跟不上请求速率的时候。消息中间件通过异步机制把请求排队，让慢的进程按自己的节奏消费，而不是被上游直接压垮。

提高可扩展性（Increase Scalability）：多个消息接收者可以并发处理不同的消息。这一点在 Pub/Sub 模型里体现得最明显，后面会展开。

2.3 四类 Messaging 服务的区分

资料列了四种消息服务，考试里最容易混的是 SMS 和 MMS 的边界，以及 IMS 和 SMS 的区别。

记忆技巧：SMS 只管文本，MMS 是 SMS 的多媒体扩展，IMS 强调"实时在线"，Cloud Messaging 强调"大规模 + 异构"。资料里还举了几个云消息服务的例子：GCM（Google Cloud Messaging）、OMC（Oracle Messaging Cloud）、JMS（Java Messaging Service）、小米 MIUI 云消息服务。这些例子在选择题里可能作为选项出现，记住它们都属于"云消息服务"这个大类就行。

3. MOM 的结构与消息模型：Broker 到底做了什么

3.1 MOM 的定义与四步通信流程

MOM（Message-oriented Middleware）是软件或硬件，通过在不同系统之间传递消息，为异构应用、平台和系统提供通信通道。资料里把 MOM 的通信过程拆成四步，这四步是理解 MOM 的核心：

1. 客户端发起 API 调用发送消息。
2. 消息发送到 provider 管理的目的地，调用触发 provider 的路由和投递服务。
3. 消息发出后，客户端可以继续做其他工作，provider 会保留消息直到接收方取走。
4. 基于消息的模型加上 provider 的中介，使得构建松耦合组件系统成为可能。

第 3 步是考试高频点：消息在接收方取走之前，broker 会存储它。这就是"异步"和"可靠"的来源。

3.2 三个核心组件：Producer、Broker、Consumer

MOM 的组件分三块，每块都有明确的职责。

MOM Client - Producer：客户端使用MessageProducer对象生产消息，消息通常发送到 API 中通过 destination 对象指定的物理目的地。

Message Broker：broker 负责接收和发送消息，是 producer、管理服务和 consumer 之间的连接枢纽。它的职责包括：维护持久化数据存储以可靠地发送数据、通过加密的 SSL 认证连接提供安全通信、监控消息和连接活动并生成诊断日志供管理员排查问题。这三个职责——存储、安全、监控——在简答题里经常被要求展开。

MOM Client - Consumer：因为 MOM 使用异步消费方式，消息会自动交给 consumer 定义的MessageListener对象。另一种方式是 consumer 只消费匹配自己选定属性的消息，这就是后面要讲的消息选择器。

3.3 两种 MOM 类型：Message Queuing 与 Publish/Subscribe

MOM 分两种类型：Message Queuing 和 Publish/Subscribe。Pub/Sub 又细分为 Topic Based 和 Content Based。

Topic Based 使用专用队列，缺点是太受限，因为它使用特定术语。Content Based 不使用特定术语描述内容，而是用类似查询的语法来订阅内容，优点是限制更少。这个对比在选择题里经常出现，关键区分点是"是否使用特定术语"。

MOM 的实现模型资料列了四个：MSMQ（Microsoft）、JMS（Oracle）、WebSphere MQ（IBM）、Sonic MQ。这些名字可能作为选项出现，记住它们都是 MOM 的具体实现即可。

3.4 P2P 与 Pub/Sub 的对比

这是 MOM 里最重要的对比，几乎每次考试都会涉及。

Pub/Sub 的关键优势在于：发送方和接收方解耦，接收方匿名，producer 和 consumer 不需要同时运行。资料明确说这"为分布式和动态云系统提供了最佳解决方案"。

3.5 MOM 的优势与安全机制

MOM 的优势资料列了七条：隐藏复杂性、发送接收模式可靠、安全、异步发送消息、允许异构系统通信、允许不同编程语言跨平台移植（可移植性）。这七条可以编成口诀记：隐、可、安、异、移、松、扩。

安全方面，IBM 使用 SAF（System Authorisation Facility）控制对 MOM 的访问。加密消息方面，Qpid AMQP 使用 SASL/TLS 进行 JMS 中消息的认证和加密。这两个缩写容易考填空。

队列类型有六种：FIFO、FIFO with Priorities、Journal Queue、Public Queue、Private Queue、Connector/Bridge。其中 Journal Queue 是系统保留所有消息的跟踪和副本，Private Queue 需要认证和授权才能使用，这两个是高频考点。

4. JMS 编程模型：从 ConnectionFactory 到 MessageListener

4.1 什么时候用 JMS API

资料给了三个判断条件：组件可以轻松替换（松耦合）、不是所有组件都同时运行（异步通信）、不需要立即响应。这三条其实就是 MOM 优势在 JMS 层面的具体化，答题时可以直接引用。

4.2 JMS API 架构的五个组成部分

JMS 架构分五块：JMS Provider（实现 JMS 接口的消息系统，提供管理和控制功能）、JMS Clients（生产和消费消息的 Java 程序或组件）、Messages（在 JMS Clients 之间传递信息的对象）、Administered Objects（管理员预配置的 JMS 对象，分 Destination 和 Connection Factory 两种）、JNDI Namespace（Java 目录服务 API，允许客户端通过名称查找数据和对象，连接 LDAP 等外部目录服务）。

JNDI 这块容易出简答题：它连接 Java 应用到外部目录服务，也允许 Java Servlet 查找托管 Web 容器提供的配置。

4.3 JMS 编程模型的八个步骤

这是整份资料里最像"代码题"的部分，按顺序走一遍。

第一步：Connection Factories。客户端用来创建与 provider 连接的工厂对象，封装了管理员定义的连接配置参数。每个 CF 是QueueConnectionFactory或TopicConnectionFactory的实例。JNDI 查找的代码：

// 获取 JNDI 上下文，查找预配置的连接工厂 Context ctx = new InitialContext(); QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup("QueueConnectionFactory"); TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) ctx.lookup("TopicConnectionFactory");

逻辑说明：InitialContext是 JNDI 的入口，lookup方法通过名称找到管理员预先配置好的连接工厂对象。参数就是 JNDI 名称，必须和管理员配置的一致，否则会抛NameNotFoundException。

第二步：Connection。用连接工厂创建连接，消费消息前必须调用start方法。

// 从连接工厂创建连接 QueueConnection queueConnection = queueConnectionFactory.createQueueConnection(); TopicConnection topicConnection = topicConnectionFactory.createTopicConnection(); // 消费消息前必须启动连接 queueConnection.start();

逻辑说明：createQueueConnection和createTopicConnection分别创建队列连接和主题连接。start方法是必须的，不调用的话接收方收不到消息，这是新手最容易翻车的地方。

第三步：Destinations。客户端用来指定消息目标和来源的对象。

// 通过 JNDI 查找预配置的目的地 Topic myTopic = (Topic) ctx.lookup("MyTopic"); Queue myQueue = (Queue) ctx.lookup("MyQueue");

逻辑说明：Destination 分 Queue 和 Topic 两种，分别对应 P2P 和 Pub/Sub 域。查找方式和 ConnectionFactory 一样，都是通过 JNDI 名称。

第四步：Session。生产和消费消息的单线程上下文。

// 创建非事务性会话，自动确认消息 TopicSession topicSession = topicConnection.createTopicSession( false, Session.AUTO_ACKNOWLEDGE);

逻辑说明：第一个参数false表示会话不是事务性的，第二个参数Session.AUTO_ACKNOWLEDGE表示消息成功接收后自动确认。如果改成true，就需要手动调用commit和rollback，考试里常考这两个参数的含义。

第五步：Message Producer。由 session 创建，用于向目的地发送消息。

// 创建发送者和发布者 QueueSender queueSender = queueSession.createSender(myQueue); TopicPublisher topicPublisher = topicSession.createPublisher(myTopic); // 发送和发布消息 queueSender.send(message); topicPublisher.publish(message);

逻辑说明：QueueSender 用send方法，TopicPublisher 用publish方法，这两个方法名不能混。参数是消息对象，消息类型后面会讲。

第六步：Message Consumer。由 session 创建，用于接收发送到目的地的消息。

// 创建接收者和订阅者 QueueReceiver queueReceiver = queueSession.createReceiver(myQueue); TopicSubscriber topicSubscriber = topicSession.createSubscriber(myTopic); // 同步接收，设置超时 queueConnection.start(); Message m = queueReceiver.receive(); topicConnection.start(); Message m2 = topicSubscriber.receive(1000); // 1 秒超时

逻辑说明：receive()不带参数会一直阻塞，receive(1000)表示最多等 1 秒。P2P 和 Pub/Sub 都用receive方法同步消费，前提是已经调用了start。

第七步：Message Listeners。异步事件处理器，实现MessageListener接口，包含onMessage方法。

// 定义监听器，收到消息时自动触发 onMessage TopicListener topicListener = new TopicListener(); topicSubscriber.setMessageListener(topicListener);

逻辑说明：给 receiver 或 subscriber 注册 listener 后，收到消息会自动捕获，不需要手动调用receive()。这是异步消费的标准做法，考试里常问"同步和异步消费的区别"。

第八步：Message Selectors 与 Messages。消息选择器允许 consumer 指定只接收感兴趣的消息。JMS 消息分三部分：Header（必需）、Properties（可选）、Body（可选）。

Header 里JMSMessageID是唯一标识，JMSDestination表示消息发送到的队列或主题。Properties 用于提供与其它消息系统的兼容性或创建消息选择器。Body 定义了多种消息类型，允许以不同形式发送接收数据。

// 创建并发送 TextMessage TextMessage message = queueSession.createTextMessage(); message.setText(msg.text); queueSender.send(message); // 消费端接收并强制转换 Message m = queueReceiver.receive(); if (m instanceof TextMessage) { TextMessage textMessage = (TextMessage) m; System.out.println("Reading message: " + textMessage.getText()); }

逻辑说明：消费端收到的消息是通用Message对象，必须强制转换成具体类型才能调用getText等方法。instanceof判断是安全做法，避免ClassCastException。这段代码在考试里经常被要求补全或改错。

5. 复习避坑：那些年我们背混的概念

5.1 坑一：把 P2P 和 Pub/Sub 的"是否需要同时运行"记反

现象：选择题问"哪种模型允许发送方和接收方不同时运行"，选了 P2P。

原因：P2P 是一对一，直觉上觉得"点对点"更灵活，实际上 P2P 要求接收方知道消息正在发送，发送方和接收方耦合更紧。

解决：记住 Pub/Sub 的核心特征是"解耦 + 匿名 + 不需要同时运行"，P2P 是"指定队列 + 接收方需知情"。做题时先看题干有没有"匿名""解耦""不同时运行"这些关键词。

5.2 坑二：JMS 里 Topic 和 Queue 的创建方法混用

现象：代码题里用QueueSession创建TopicPublisher，或者用TopicSession创建QueueSender。

原因：JMS 的 P2P 域和 Pub/Sub 域各有独立的 API 体系，Queue 对应 QueueConnection、QueueSession、QueueSender、QueueReceiver；Topic 对应 TopicConnection、TopicSession、TopicPublisher、TopicSubscriber。

解决：画一张对照表贴在笔记上，做题时先判断题目属于哪个域，再选对应的类。资料里明确写了"JMS 里面只有 Topic"这个点，说明 Pub/Sub 域在 JMS 里就是 Topic 体系。

5.3 坑三：忘记调用 connection.start()

现象：代码看起来没问题，但接收方一直收不到消息。

原因：JMS 连接创建后处于停止状态，必须调用start方法才能开始投递消息。

解决：把start当成消费消息的前置条件，代码里看到receive或setMessageListener之前，先检查有没有start。资料里专门强调了"Before your application can consume messages, you must call the connection's start method"。

5.4 坑四：Session 的两个参数含义记混

现象：问createTopicSession(false, Session.AUTO_ACKNOWLEDGE)里两个参数分别是什么意思，答反了。

原因：第一个参数是 boolean，表示是否事务性；第二个参数是确认模式。

解决：记"先事务后确认"。false= 非事务，AUTO_ACKNOWLEDGE= 自动确认。如果第一个参数是true，就需要手动commit或rollback。

5.5 坑五：Message 强制转换时不做类型判断

现象：代码题里直接(TextMessage) m而不做instanceof判断，被扣分。

原因：消费端收到的消息是通用Message对象，如果实际类型不是TextMessage，直接转换会抛ClassCastException。

解决：标准写法是先if (m instanceof TextMessage)再转换。资料里的示例代码就是这么写的，考试时照着写不会错。

6. 把 JMS 编程模型压缩成一张答题卡

复习到最后，最有用的不是把资料从头再读一遍，而是把 JMS 编程模型的八个步骤压缩成一张能默写的答题卡。我的习惯是：拿到白纸，先画一条竖线，左边写 P2P 域，右边写 Pub/Sub 域，然后从上到下把八个步骤的类名和方法名填进去。填不出来的地方就是薄弱点，回头翻资料对应章节。

这张表默写三遍，JMS 的代码题基本不会丢分。另外两个容易忽略的点：一是 JNDI 查找的lookup参数必须和管理员配置的名称一致，二是消息选择器（Message Selector）用的是类似 SQL 的查询语法，用来过滤 consumer 感兴趣的消息。

还有一个进阶技巧：如果题目问"如何实现异步消费"，答案就是注册MessageListener，在onMessage方法里定义消息到达时的动作。如果问"如何实现同步消费"，答案是用receive()方法，可以带超时参数。这两个答案在简答题里几乎可以互换使用，关键是分清题目问的是哪种消费方式。

从那以后我每次复习中间件，都会先把 MOM 的四步通信流程和 JMS 的八个编程步骤默写一遍，写不出来的地方才去翻资料。这个方法比从头读到尾效率高得多，因为默写暴露的是真正的盲区，而阅读容易产生"我好像会了"的错觉。希望帮到你。

本文还有配套的精品资源，点击获取