《企业集成模式》读书笔记 - 第五章

╰+哭是因爲堅強的太久メ 2022-12-08 04:59 209阅读 0赞

> 本书英文全名为《Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions 》对应的中译版为《《企业集成模式——设计、构建及部署消息传递解决方案》》，出版于 2003 年。绝对称得上是老前辈了…

### 1. 概述 ###

本章标题为"消息构造"，诚如标题所述，本章节重点关注的是作为数据载体的消息。关注在使用消息的过程经常会遇到的一些问题，以及相对应的解决方案。

### 2. 与消息相关的问题 ###

使用消息传递系统进行系统集成时候，在涉及到"消息"的使用时候我们一般需要关注以下这些方面：

1.  消息的目的。
2.  消息的发送方如果需要响应，应该如何处理？
3.  消息中包含海量数据应该如何处理？
4.  如果因为某些原因，消息传输到接收端的时间过慢应该如何处理？
5.  世界上唯一不变的就是变化本身。那么对于消息中包含的数据，其格式随着时间发生变化，我们应该如何处理？  
    催生了5.2，5.3，5.4的各类消息

以上这几个问题，基本就是在使用"消息"这个概念的过程中会遇到的问题。接下来我们就分别针对这些问题给出相应的说明和对应的解决方案。

### 3. 命令/文档/事件消息 ###

这一小节要解释的就是"消息的目的"这个问题，我们在应用集成的过程中基本都是这么几个需求：

1.  请求端希望执行服务端中的某端的逻辑（一般表现为服务端定义的某个方法）。这一需求在消息层面对应的就是命令消息。
2.  请求端向服务端发送一段数据信息（例如文档，数据记录等）。这一需求在消息层面对应的就是文档消息。
3.  请求端广播某件事情的发生，由订阅者自行决定如何响应（类似"订阅者模式"）。这一需求在消息层面对应的就是事件消息。

### 4. 请求/响应-返回地址-关联标识符 ###

这一小节要解决的就是如果消息的发送方期待得到响应，应该如何处理？关键点大约有如下几条：

1.  我们需要建立两条通道，分别对应请求和响应。
2.  发送消息的请求者应该把返回地址包含在消息体的头部，而不应该由应答者去记住每条请求消息对应的返回地址。
3.  应答者返回的消息中应当包含一个响应ID，用来标识该响应信息对应的是哪个请求信息。这样最终实现整个请求-应答的完整链条。这个响应ID的值应该等于消息发送方放到消息时放在消息头部的请求ID。

### 5. 消息序列 ###

这一小节要解决的是"消息中包含海量数据应该如何处理？"。

对于这个问题，直接能想到的办法就是类似于分片传输。关于这一块，TCP/IP协议已经给出了成功的例子。

关于"海量数据"这一块，注意不仅仅是针对响应数据，请求数据也是存在海量的情况的。

### 6. 消息到期 ###

应用在传递消息的时候，如果消息不能在规定时间内到达，那么该消息就应该被判断为无用的，应该被忽略。

关于这一点，主要由两方面来共同保证：

1.  消息的发送方应该在投递消息的时候设置好消息的有效期。
2.  消息传递系统应该确保消息在有效期之外不会被消费。例如将过期消息转移到死文字通道。

### 7. 格式指示符 ###

最后这一步小节解决的就是消息格式随着时间发送改变的问题。关于这一点大体思路是：

1.  不能简单地将新格式开辟专门的通道进行投递。因为你无法确保每个接收者能够及时准确地切换到该通道。应该采用老格式的消息使用的通道传递新格式消息。
2.  采用格式指示符标识当前消息的格式大约有三种方式：  
    a. 版本号。最容易想到的办法，约束就是双方都应该知道这个版本号的意义。  
    b. 外键。例如文件名或者数据库主键等，接受者可以根据该值去约定的位置取到格式说明文档。  
    c. 格式文档。对，直接在消息中包含该消息的格式文档，好处自然是消息自解释，坏处当然是消息的体积会增大。

### 8. 总结 ###

本章主要探讨了消息传递系统中，使用消息时候遇到的问题以及对应的解决方案。