基于消息系统架构设计

        近期在弄一个业务系统，这个业务系统本来是有一个架构的，但是在后期扩展时发现问题多多。关键扩展很是不方便，而且因为业务系统安全规格较高。数据网络链接需要经过多个闸口传递才可，而且业务系统可能需要多地系统联合组网。共享业务数据，但是各地系统又必须相互独立。

用户但愿改动架构，让系统可扩展性添加，同一时候要知足系统相互独立方便升级和兴许开发。

依照用户的要求我考虑使用一个基于消息传递的架构设计来知足需求。

所谓基于消息，就是经过消息中转server，中转所有系统间链接数据，同一时候管理数据路由，由消息中心详细消息的目标。

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

当前业务系统设计中，尽管仍是使用相似的结构。但是消息server的功能将被大大的减弱。消息server将仅仅作消息的转发，再也不像EDI报文系统里那样什么事情都会去作。

 

1、架构需求

客户业务系统在各地分公司都是独立执行的，分公司之间的数据在必定条件下可共享，但各系统必须是独立存在。

可以将分公司理解为相互无关的独立企业。但企业间在需要时可以相互协做。

各地数据联网时需要经过多个安全闸口，因此数据需要在各闸口间方便搬运。但愿系统宽展性好，之后添加新系统尽可能不要更改结构。

 

2、架构设计

依照用户架构需求，考虑使用消息server连接所有设备，结构如图2.1

     

2.1

 

第一反应是否是很是像WCF的结构？但是仍是有差异，消息server不处理不论什么的东西，仅依照给定的路由地址转发到指定server处理消息。

如上图所看到的。所有的业务服务都由消息server串联起来。

比方，当业务系统需要将数据保存到数据库时。业务server首先处理完业务相关的数据。而后将需要保存的业务数据发给消息server进行转发。

消息处理server接收到数据后会依照数据指定的路由发送消息，此样例中会发送给数据server，数据server接收到数据后会依照数据要求将消息转会为可以保存到数据库中的格式并存入数据库。

简单的讲，每个处理环节由单独的server完毕，各司其职互不干涉。当架构中需要添加新环节时也不会产生连锁影响。

因为所有的系统都是独立的，之间仅经过消息系统关联。

数据可路由传送。当数据没法从一点直接到达还有一点时可经过中转数据包到达。而且目标是可以多个的，比方目标为数据server和邮件server

3、程序结构

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

各节点程序独立执行，訪问数据以实体串行化后进行传送，传送过程是异步的，当发送数据完毕后结果将经过异步方式返回给发送方并经过消息ID肯定详细数据。以后异步调用消息回调函数处理兴许事件。

因为消息是经过消息server转发的，因此各模块都可以独立开发，管数据操做的管数据操做（同一时候可以被隔离在安全地带），管业务的管业务，做为消息server同一时候可以经过负载均衡设置分配不一样的server来处理消息（因为模块独立，并行扩展很的方便）