MSMQ部署实施建议

 

1.1             业务描述

由外系统和DMS系统向MasterDB进行多类业务数据上传，通过MSMQ经由Biztalk映射和处理后，进入MasterDB。

1.2           首选方案A

a.在外系统/DMS与MasterDB之间按业务建立多个MSMQ队列；

b.按单个业务一一对应建立数据Schema、数据格式转换；

c.遵照特定的Schema，从对应业务MSMQ中接收数据、映射和处理；

d.通过相应Port提交到MasterDB；

1.3           备用方案B

a.在外系统/DMS与MasterDB之间建立一个MSMQ队列；

b.统一包装多种报文，按信封建立统一的数据Schema；

c.制作信封拆解、报文分捡机制；

d.将真正的数据报文转向预定好的子流程；

e.按单个业务一一对应建立数据Schema、数据格式转换；

f.遵照特定的Schema，从父流程中接收数据、映射和处理；

g.通过相应Port提交到MasterDB；

1.4           方案对比

对比项	A方案	B方案
架构对比	MSMQ以业务为单位建立，每个MSMQ代表一个业务数据源； 查询一个MQ的信息，就可即时了解对应业务的队列信息； 一个MSMQ出现异常，不影响其他业务； 可对支持同一数据Schema的多业务系统数据源提供透明支持；	MSMQ以系统为单位建立，所有业务都通过同一个队列进行数据交换； 查询MQ的信息，很难了解各项业务的队列情况； 一个MSMQ出现异常，所有业务都无法正常交换； 多业务系统共用同一MQ较易带来问题；
设计开发对比	以业务流程为基本设计开发和驱动单位； 工作量较小，只需建立每个业务的Schema/Mapping/Orchestraction等； 不容易出现重名和其他冲突问题；	以业务子流程为设计开发单位，以拆解分捡调度流程为调度驱动； 工作量较大，不仅需要建立新建业务的Schema/Mapping/Orchestraction等； 还需要在拆解分捡主流程中加入对新业务的支持； 较容易出现重名和其他冲突等问题； 任何一个子流程的错误可能会引发分捡调度流程的异常；
部署对比	向生产系统加入新业务对任何已经在运行的现有业务无任何影响；	需要完全停掉主分捡调度流程，部署新业务子流程和新分捡调度流程；
运行效能对比	多个MQ以并行方法进行MQ数据的读、写操作； Biztalk应用直接通过多个对应业务的Port进行多流程并发处理；	唯一一个MQ以串行方法进行MQ数据的读、写操作； Biztak取得数据后，必须先通过对报文信封的拆解，分捡，解析后，决定应该将此报文交给哪个子流程来处理； Biztalk子流程由于是通过同一个Port进行串行数据的获取，多个Orchestration子流程也将串行化运行；