架构设计：系统间通信（41）——自己动手设计ESB（2）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

4、Broker Server设计

那么如何赋予ESB中间件原子服务整合、服务路由编排的关键能力呢？读者当然可以自行实现ESB中间件中这两个关键模块的功能，但问题的关键是即使是一个团队负责这部分的开发工作也不可能在短时间内完成该模块的开发，而且功能完整度和模块性能也不一定能达到设计之初的要求。所以在我们自行设计的ESB中间件中，选择将原子服务整合功能和服务路由编排功能交给我们已经介绍过的Apache Camel组件。

另一方面，为了保证ESB中间件不会成为整个软件顶层设计中的性能瓶颈，ESB中间件将采用多运行节点的方式为各个业务系统服务（就是前文中提到的ESB-Broker Server节点）。在进行设计时，我们还必须保证业务系统注册的原子服务发生变化后，或者从流程编排工具/流程发布工具传来新的编排好的路由服务注册请求后，ESB-Broker Server节点 可以在不停止工作的情况下 响应这些变化。另外，ESB-Broker Server还需要具备动态伸缩能力：

换句话说，我们需要运行多个Apache Camel应用服务，并且能够随时启动一些新的或者停止一些在运行的应用服务。这些Apache Camel应用服务在启动时甚至可能没有加载任何的Service，而是在运行过程中根据某种事件通知对各种Camel的Service进行动态加载（包括但不限于Route、Processor）。

4-1、ESB-Broker Server设计

4-1-1、最直观的设计

那么问题来了，我们如何进行ESB-Broker Server节点的设计呢？读者可能首先想到的就是：在流程编排工具/流程发布工具（以下称为Studio）上进行Apache Camel工程的开发，然后人为的将Apache Camel工程打包发布到ESB-Broker Server节点上。这种“最直观”的处理方法还有一种改进方式：在每一个将可以承载ESB-Broker Server的节点上安装Docker Engine，并采用Swarm进行统一管理。这样就可以实现ESB-Broker Server节点的自动化管理了。如下图所示：

Docker Swarm是Dotcloud公司（这个公司也是Docker的开发商）官方提供的Docker集群管理工具，通过这个工具管理人员可以轻松管理远程计算机上的多个Docker容器实例，包括Docker创建、启动、停止等操作。Docker Swarm还提供基于命令行的API接口，以便于其它程序能够通过它间接管理Docker集群。所以，我们可以用这个技术方案基于Studio进行Docker集群的管理，以达到自动管理ESB-Broker Server节点的目的。本章节不进行知识点的扩散讲解，不进行Docker和Docker Swarm的详细介绍。

但是以上的设计方案，包括对其的改进方案（我们暂且称为“第一方案”）还不能完全满足我们对ESB-Broker Server的设计要求：显然“第一方案”能够实现ESB-Broker Server节点的横向扩容，我们可以在整个ESB中间件服务快要达到性能瓶颈时立即开启新的ESB-Broker Server节点（是否能立即为ESB-Client提供服务，我们将在下文进行讲解），还可以在ESB中间件服务闲暇时关闭一些节点。

但无论是通过人工部署新的节点还是通过Docker容器将ESB-Broker Server包装成微服务进行部署，ESB-Broker Server中所注册的原子服务和路由编排都需要Studio中预先完成编辑，并且它们不能在ESB-Broker Server节点运行的过程中进行新增、修改或者删除。这是因为ESB中间件中没有一个合适的事件通知机制，在ESB-Broker Server运行时将Studio中产生的变化行为通知给前者。

4-1-2、进行设计方案调整

那么，我们至少需要在“第一方案”的基础上找到一种合适的事件通知机制，基于这个事件通知机制能够让ESB-Broker Serve