一个灵活的.NET文件处理系统体系结构——第一部分

使用这种技术，在系统的扩展性和维护性方面有很多优点：

使用消息队列可以将处理应用程序分布在不同的计算机上，同时多个处理应用程序可以从同一个队列获得消息，从而可以实现负载平衡（水平扩展）。

由于路由包含文件信息的轻量级消息，这减轻了处理消息需要的服务器之间网络流量，并将文件移动减少到最少，这将有助于解决调试问题。记住频繁的要求移动文件如解压和解密是需要时间的。

使用消息路由决定消息的目的地增强了维护性，因为所有的路由逻辑不再同监听器进程有紧密联系。这些逻辑储存在数据库或XML文件中，关于逻辑的编排将在以后的文章中介绍。

这个体系结构的核心在于消息路由与具体任务队列之间的交互。使用这种技术你可以方便地插入新的具体任务处理进程来满足不断改变的业务需求。

例如，假如目前你只是将flat文件直接导入数据库，就可以探测新文件，打开文件，解析文件并将数据插入数据库中。在这个系统中，当有新的需求出现时（在解析之前解压），你就不得不或者重写当前的解析程序用来完成解压或者修改一些其它代码并重新部署整个方案。

利用本文上面介绍的体系结构，仅需要简单的修改路由逻辑设置（该设置不能是硬编码的这是关键）创建一个新的“解压”任务队列并写一个解压过程处理该队列的消息。

你不需要改变已存在过程中的任何代码或重新部署它们。在一个集成环境中，这样可以节约大量时间，因为将代码改变移入到生产总需要一些步骤。

体系结构说明

关于本系统另一个需要说明的地方是在具体任务进程处理完一个消息之后，该消息几乎总是从具体任务处理被送到处理队列。这样系统可以自己断定（通过路由逻辑）需要对文件下一步做什么处理，不再需要有具体任务处理进程判断下一步要完成的任务。

依我个人经验，这个功能帮了我不少忙。例如，当我们的合作伙伴给我们发送包含其它压缩文件的压缩文件时（我们希望压缩文件中只包含普通flat文件）。

在我们的解压进程解压完一个文档之后，它将会对每个提取出来的文件给处理队列发送消息。这样，提取出的文件还是压缩文件，在从解压处理送到处理队列后，它们将被直接送回解压处理进程进行解压。

如果我们将发送解压结果到何处的逻辑完全在解压处理中实现，我们将不能正确处理这种的情况。

下一篇文章

在下一篇文章中，我们将介绍输入监听器是如何实现的并解释消息队列中的消息包含何种类型的数据。

责任编辑：德东

查看本文国际来源