近期在弄一个业务系统，这个业务系统原本是有一个架构的，可是在后期扩展时发现问题多多。关键扩展非常不方便，并且由于业务系统安全规格较高。数据网络连接须要通过多个闸口传递才可，并且业务系统可能须要多地系统联合组网。共享业务数据，可是各地系统又必须相互独立。
用户希望改动架构，让系统可扩展性添加，同一时候要满足系统相互独立方便升级和兴许开发。
依照用户的要求我考虑使用一个基于消息传递的架构设计来满足需求。
所谓基于消息，就是通过消息中转server，中转全部系统间连接数据，同一时候管理数据路由，由消息中心详细消息的目标。
事实上类似的系统我在非常多年前使用过，当时的需求是基于不同物流行业间的数据交换设计的，做过物流行业的人都知道，物流行业数据（如：海关报关数据，船公司航次数据，箱信息等）都是通过EDI报文方式相互传递的，海关的系统和客户的系统毫无关系。他们通过暴露的EDI数据接口相互连接，当时我做了一个消息server功能比較单一，作为消息中转server，能够接收来自海关的EDI报文，同一时候能够通过多种方式将EDI报文发送（FTP，Email等）给指定用户或者直接保存到本地数据库，也会定时通过数据库数据制作EDI报文依照配置发送。也就是说当时这个程序须要做的。提供一个暴露接口给外部，外部系统能够通过这个接口向内部发送EDI，程序对接收的EDI报文进行分析并将结果保存入数据库中。它还须要在指定时间内依据配置制查询数据库作符合要求的EDI报文并发送给指定用户。
当前业务系统设计中，尽管还是使用类似的结构。可是消息server的功能将被大大的减弱。消息server将仅仅做消息的转发，不再像EDI报文系统里那样什么事情都会去做。
一、架构需求
客户业务系统在各地分公司都是独立执行的，分公司之间的数据在一定条件下可共享，但各系统必须是独立存在。
能够将分公司理解为相互无关的独立企业。但企业间在须要时能够相互协作。
各地数据联网时须要通过多个安全闸口，所以数据须要在各闸口间方便搬运。希望系统宽展性好，以后添加新系统尽量不要更改结构。
二、架构设计
依照用户架构需求，考虑使用消息server链接全部设备，结构如图2.1
2.1
第一反应是不是非常像WCF的结构？可是还是有差别，消息server不处理不论什么的东西，仅依照给定的路由地址转发到指定server处理消息。
如上图所看到的。全部的业务服务都由消息server串联起来。
比方，当业务系统须要将数据保存到数据库时。业务server首先处理完业务相关的数据。然后将须要保存的业务数据发给消息server进行转发。
消息处理server接收到数据后会依照数据指定的路由发送消息，此样例中会发送给数据server，数据server接收到数据后会依照数据要求将消息转会为能够保存到数据库中的格式并存入数据库。
简单的讲，每一个处理环节由单独的server完毕，各司其职互不干涉。当架构中须要添加新环节时也不会产生连锁影响。
由于全部的系统都是独立的，之间仅通过消息系统关联。
数据可路由传送。当数据无法从一点直接到达还有一点时可通过中转数据包到达。并且目标是能够多个的，比方目标为数据server和邮件server
三、程序结构
这里仅仅说一下简单的程序结构。全部的消息都必须包括路由信息（比方一个或多个目标），须要包括验证信息。各节点都应该验证信息正确性。
各节点程序独立执行，訪问数据以实体串行化后进行传送，传送过程是异步的，当发送数据完毕后结果将通过异步方式返回给发送方并通过消息ID确定详细数据。之后异步调用消息回调函数处理兴许事件。
由于消息是通过消息server转发的，所以各模块都能够独立开发，管数据操作的管数据操作（同一时候能够被隔离在安全地带），管业务的管业务，作为消息server同一时候能够通过负载均衡设置分配不同的server来处理消息（由于模块独立，并行扩展很的方便）