基于消息系统架构设计

        最近在弄一个业务系统，这个业务系统原本是有一个架构的，但是在后期扩展时发现问题多多，关键扩展很不方便，而且因为业务系统安全规格较高，数据网络连接需要通过多个闸口传递才可，而且业务系统可能需要多地系统联合组网，共享业务数据，但是各地系统又必须相互独立。用户希望修改架构，让系统可扩展性增加，同时要满足系统相互独立方便升级和后续开发。按照用户的要求我考虑使用一个基于消息传递的架构设计来满足需求。

所谓基于消息，就是通过消息中转服务器，中转所有系统间连接数据，同时管理数据路由，由消息中心具体消息的目标。

其实类似的系统我在很多年前使用过，当时的需求是基于不同物流行业间的数据交换设计的，做过物流行业的人都知道，物流行业数据（如：海关报关数据，船公司航次数据，箱信息等）都是通过EDI报文方式相互传递的，海关的系统和客户的系统毫无关系，他们通过暴露的EDI数据接口相互连接，当时我做了一个消息服务器功能比较单一，作为消息中转服务器，可以接收来自海关的EDI报文，同时可以通过多种方式将EDI报文发送（FTP，Email等）给指定用户或者直接保存到本地数据库，也会定时通过数据库数据制作EDI报文按照配置发送。也就是说当时这个程序需要做的，提供一个暴露接口给外部，外部系统可以通过这个接口向内部发送EDI，程序对接收的EDI报文进行分析并将结果保存入数据库中。它还需要在指定时间内根据配置制查询数据库作符合要求的EDI报文并发送给指定用户。

当前业务系统设计中，虽然还是使用类似的结构，但是消息服务器的功能将被大大的减弱。消息服务器将只做消息的转发，不再像EDI报文系统里那样什么事情都会去做。

 

一、架构需求

客户业务系统在各地分公司都是独立运行的，分公司之间的数据在一定条件下可共享，但各系统必须是独立存在。可以将分公司理解为相互无关的独立企业，但企业间在需要时可以相互协作。

各地数据联网时需要通过多个安全闸口，所以数据需要在各闸口间方便搬运。希望系统宽展性好，以后增加新系统尽量不要更改结构。

 

二、架构设计

按照用户架构需求，考虑使用消息服务器链接所有设备，结构如图2.1

     

2.1

 

第一反应是不是很像WCF的结构？但是还是有区别，消息服务器不处理任何的东西，仅按照给定的路由地址转发到指定服务器处理消息。如上图所示，所有的业务服务都由消息服务器串联起来。

比如，当业务系统需要将数据保存到数据库时，业务服务器首先处理完业务相关的数据，然后将需要保存的业务数据发给消息服务器进行转发。消息处理服务器接收到数据后会按照数据指定的路由发送消息，此例子中会发送给数据服务器，数据服务器接收到数据后会按照数据要求将消息转会为可以保存到数据库中的格式并存入数据库。

简单的讲，每个处理环节由单独的服务器完成，各司其职互不干涉，当架构中需要增加新环节时也不会产生连锁影响。因为所有的系统都是独立的，之间仅通过消息系统关联。

数据可路由传送，当数据无法从一点直接到达另一点时可通过中转数据包到达。而且目标是可以多个的，比如目标为数据服务器和邮件服务器

三、程序结构

这里只说一下简单的程序结构，所有的消息都必须包含路由信息（比如一个或多个目标），需要包含验证信息，各节点都应该验证信息正确性。

各节点程序独立运行，访问数据以实体串行化后进行传送，传送过程是异步的，当发送数据完成后结果将通过异步方式返回给发送方并通过消息ID确定具体数据。之后异步调用消息回调函数处理后续事件。

因为消息是通过消息服务器转发的，所以各模块都可以独立开发，管数据操作的管数据操作（同时可以被隔离在安全地带），管业务的管业务，作为消息服务器同时可以通过负载均衡设置分配不同的服务器来处理消息（因为模块独立，并行扩展非常的方便）