CaseStudy：接口程序架构

在上一个项目中，需要开发一个在全国范围内传输文件的接口程序。包括从另一个系统中导出数据，在把收到的接口文件导入到另一个系统中去。这个架构基于流水线的工作原理，队列就是流水线，工人就是具体的处理程序，设计的目的是做的每个工人只处理一条流水线上的任务，并且该任务是单一、开始标记和完结标记都很明确的任务。
导入程序架构：

导出程序架构

注意，这里的队列不是指物理上的队列，是逻辑上的队列，完全可以通过数据库设计来把对列表合并成一个物理数据库表。

第一个难点是：处理程序的划分，究竟哪些功能该划分在一个单一的处理程序中（可以形象的理解为，到底一个工人该做多少工作，到底应该把工作细分到什么程度）。那么我的经验是，抓住结束标记来看。
例如，业务上有个要求，需要导出10个数据库表的信息，这些数据文件才算有效，任何一个导出失败，则通通算作失败。那么我就把导出10个表的小处理程序

另外，请仔细考虑每个处理程序是否会造成数据库死锁（比如交叉访问相同的两张表），如果会，把处理放到同一个队列，让他们不能同步进行。
例如，这个项目中导出和导入的数据库表用的是同样的几张表，并且都使用了表锁定，结果造成了数据库级别抛出异常。

划分为一个单独的处理程序（也就是把这10步活都给一个工人做）。当然，你也可以划分为10个处理程序，再在程序里进行判断。

第二个难点是：接口数据的跟踪。我常常遇到客户要我告诉他，某条数据导出成功吗，发送成功吗？所以，在接口程序中，一定要注意，在两个对列表中，至少要在一端保存对应关系，然后开发一个小工具（就几句SQL文的小事情），可以把该条数据每一步的处理情况检查的一清二楚。

第三个难点是：日志的记录。日志可以分为数据库表日志和文件日志，各有好处。有时会因为程序员忽略考虑，如何记录数据库表日志的失败的异常处理，而导致因小失大，失去了整个处理过程。可以把日志和处理程序分开。另外，如果对日志要求不高，可以采用文件方式。还有，日志记录的详细程度。最好设置一个开关，可以控制日志的详细程度。