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

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

1. 前言

会对这本书感兴趣主要是因为笔者一直所在的电子政务行业中对于消除”数据烟囱”和”信息孤岛”的诉求愈发强烈，而笔者当初由.NET转到全职Java研发的过程中，所构建的第一类系统就是数据共享交换平台，只是限于当时对于集成概念的缺乏，虽然基于最基本的软件工程思维无比确信系统的架构实现中存在着大量的冗余和不稳定性因素，却说不出个所以然来。

直接参与共享交换平台系统的构建大约一年之后笔者转而去参与其他项目，不过关于”集成”的概念和痛点至今一直萦绕在笔者心头。直到2019年初在偶然的机会下接触到了Apache Camel以及其所代表的EIP，当时的第一反应就是”这正是我一直在寻找的解决方案”。

如果不出意外的话，这应该是一个系列性文章，本来按照笔者的习惯，这类读书笔记应该是放在笔者的简书账户下的，但考虑到本系列的特殊性，最终还是决定将其搁在CSDN中。

本系列应该不会涉及过多的实例代码，毕竟本书的书名基本明示了其给予的是一个通用的解决方案，给出的示例代码更多也只是伪代码。本系列将记录笔者阅读过程中的个人所悟所感，以及当时阶段个人理解的Apache Camel与其的联系。

2. “集成”的意义

正如本书的推荐序作者之一，大名鼎鼎的Martin Fowler所说的”相互独立的应用是没有生命力的”。现实世界中一个规模比较庞大的企业或者是电子政务系统体系往往都是由成百上千个系统所构成的，这些系统或是定制开发，或是第三方获取，亦或是遗留系统的一部分。造成这种局面通常是因为：

即使不考虑发展带来的系统更迭，试图创建一个巨无霸应用来解决企业经营中遇到的所有问题已经被无数的现实证明是徒劳，这是现实的复杂性决定的。
将业务功能分散到多个应用中，对此企业有着天然的吸引力。正如现在如火如荼的”微服务”概念，拆分带来的灵活性和可扩展性让企业有更多的选择。

与以上现状相对的，是往往客户在使用这些应用的时候，并不会考虑系统的边界问题，他们只会关注业务功能的执行，而不会在乎这项业务功能在底层是由多少个内部系统构成的。这就使得”应用集成“随着人们对于”便捷性”提出更高的要求而变得愈发重要和必要。

3. “集成”的挑战

“集成”的目标很美好，但实现集成的过程并没有那么愉快，可谓充满荆棘：

既有系统基本上都是非常稳定运转多年，极少会因为集成需要进行大幅度修改，且秉承”能不改就不改”原则。
集成解决方案领域标准少。虽然名义上XML，JSON能够解决集成数据标准问题，但就像识字并不代表你能读懂文章表达的意思一样，语义上的差异将消耗大量的时间和精力。
集成解决方案有着天然的复杂性。天然的分布性和多种技术的混合使用，使得系统的部署，监控和问题排查等等问题势必对人员提出更高的要求。
集成不仅仅是涉及到计算机之间的通讯，更是其所代表的业务部门和IT部门之间的通讯，而业务的复杂性往往让本已不多的技术选择更加雪上加霜。
集成的覆盖面广，影响范围大，这势必对其要求有着更高的标准。

4. “集成”模式

集成模式的总结是由一批解决过大量集成问题的专家，通过分析与反思过往已经解决过的问题，抽象归纳总结出来的针对某一类常见问题，应该使用哪些解决方案。

而且模式与解决方法最大区别在于，模式能够被用来解决尚未发生的问题，有助于填补集成的高层目标与具体实现之间的鸿沟。EIP之于企业集成等同于设计模式之于OOP。

5. “集成”世界

标题名比较晦涩，直接一点说就是现阶段(2003年)人们为了实现集成大概会用哪些方式，大约分为以下六种（2020年了，好像还是这样…这就是道与器的差异吧）：

信息门户。在展示端汇总，底层还是各玩各的。
数据复制。我这的数据也发给你一份，你自己存起来。
共享的业务功能。
面向服务的体系架构。
分布式的业务系统。以上三者界限很模糊，稍稍改变看问题的视角它们之间就能完成彼此的切换。例如将共享的业务功能抽离出来，以服务的方式向外界提供…
企业到企业(B2B)的集成。与上面的3，4，5与6的区别主要在于前者更多的是企业内部，后者则是企业之间。

6. 松耦合

基本的核心概念是减少对对方作出的假设。这种假设或显式，或隐式。而一个成功的集成解决方案最基本的要求之一就是松耦合。

关于”隐式假设”，书中举了一个使用TCP协议进行EAI集成的例子，例子中的方案隐含的假设有：

平台技术。表现为数字和对象的内部表示，例如有的系统是big-endian，有的则是little-endian。
位置。调用方必须明确知晓服务方的机器地址。
时间。所有组件必须同时可用。
数据格式。被转换成字节的参数必须被双方共同认可并准确识别。

7. 一个松耦合的集成解决方案

本章的最后，作者用假想公司的集成需求讲解了一个松耦合的集成解决方案应该包含哪些基础组件和特性。

通道（channel）。负责将信息从一个应用传递到另外一个应用。表现形式有一系列TCP/IP连接，一个共享文件，一个共享数据库，甚至是一个U盘。
消息（message）。被集成的应用之间需要传递数据，这一段数据在集成解决方案中被成为消息，其体积可大可小，视双方需求而定。
转换（transfer）。被集成在一起的系统通常都有着自己独特的数据格式要求，因此集成解决方案必须提供一类机制来适配这个交互需求，这个机制被成为转换（translation）。
路由（route）。在集成解决方案中，另外一个需要解决的问题是服务寻址的问题，也就是将繁重的服务地址记录和查找功能从调用端剥离出来，交给专门的中间件来完成，这个中间件就是路由（Route）组件。
系统管理（monitor）。以上核心功能的提供已经揭示了集成解决方案的复杂性，因此相应的系统管理功能必须足够强大，以监控数据流，确保所有的应用和组件都在正常运行，并能及时报告出错情况。
消息端点（endpoint）。正如我们在”集成的挑战”这一小节中着重提到”大多数封装好的或历史遗留系统设计之处并没有打算参与集成”，因此集成解决方案还要提供一种机制来将这些系统显式接入到集成解决方案中。这种机制就是消息端点（endpoint）。

7.1. 示例中用到的EIP模式

笔者在阅读本章的过程中发现的很有意思的一件事是，本章中的例子与 2011出版的《Camel In Action》中的第二章”Routing with Camel”中的例子有着异曲同工之妙。

这里汇总下笔者个人理解之下该例子中用到的EIP模式（以Apache Camel为参考）：

通道适配器。负责将应用连接到消息系统。
消息转换器。负责将外部不同的消息格式转换为内部统一的消息格式。
聚合器（Aggregator）。负责收集多个输入信息，并将它们合并成一个发出的消息。
基于内容的路由器（Content-Based Router）。负责根据消息的内容，将其按照预先制定好的规则将消息投放到相应的通道中。
非法消息通道（InValid Message Channel）。对应于Apache Camel中的 “Dead Letter Channel EIP.”。
分解器（Splitter）。负责将一个消息分拆为多个单个的消息。一般都会和上面提到的聚合器搭配使用。
路线分解器（Wire Tap）。对应于Apache Camel中实现的“Wire Tap EIP”。
消息过滤器（Message Filter）。负责对消息进行过滤，只让符合指定标准的消息通过。
动态接收表（Dynamic Recipient List）。是接收表（Recipient List）和动态路由器（Dynamic Router）两种模式的组合所得。
10.系统监控检查。关于这一点Apache Camel内置了基于JMX的内部状态暴露和行为控制。比较典型的有 Apache Camel监控之使用hawtio 。