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

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

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

1. 概述

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

2. 与消息相关的问题

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

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

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

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

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

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

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

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

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

5. 消息序列

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

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

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

6. 消息到期

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

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

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

7. 格式指示符

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

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