在目前的集成应用中，无论是SOA的架构体系也好，还是传统的EAI架构体系也好，都对通过这样的一个平台能够达到的管理提出了很高的要求。在SOA的领域里面，将管理提升到了一个很高的层次，在Open Group的参考架构中，管理和治理（government）被单独提出来，作为一个重要的组成部分。
但在实际的项目中，应用集成平台，需要发挥很高的管理作用，就意味着在应用集成平台的运行期，需要对数据、业务进行很多的操作。举个简单的例子，用户需要监控平台中所发生的每一笔数据交换的内容，需要知道什么时候，具体的那些数据发生了交换。那么应用集成平台，必须对每一次发生交换的数据，进行日志记录。这样的操作，往往会给整体平台带来时间、空间性能上的损失。
我们在一个实际的项目中，就碰到了这样的问题。 该项目是某省的企业征信信息中心平台，采用我们的Apusic ESB产品作为基础支撑，实现37个部门和4大数据中心之间的数据同步。
 
在项目中，用户对于平台所能够赋予的管理功能，提出了如下的要求：
u 能够按指定的时间片（单位可以是小时、日、月、年）统计并展现某年度发生交换的数据，包括各个部门发送的数据量和各个部门接收的数据量；
u 能够查询得到所有交换数据的详细数据信息，以备日后进行数据审计
为了满足这样的管理要求，我们在项目实施的过程中，通过配置的方式，对平台中所有的发生交换的数据，都采取日志记录的方式记录下来。试运行期间，结果非常好。但是运行了一段时间时候，问题出现了：日志数据非常庞大，在系统上线后的两周之内，日志数据已经达到了百万级。随着系统的运行，预计在不长的时间内，日志数据将达到千万级。
日志数据庞大的原因是：
u 涉及到的厅局较多，达到了37个厅局，发生数据的数据量本身非常大。
u 各个厅局的数据是海量数据，例如社保部分的数据，单单这个省某个市的社保数据就有1200万条，整个省的社保数据将达数千万条。
u 接收数据的中心节点相对较多，共有4个中心。每增加一个数据中心，日志数据将会增加一倍。
也就是说，通过这样的记录日志的方式，没交换一条数据，就会有4倍于这条数据的日志记录。在这样的大数据量的情况下，日志数据变得非常的庞大。
针对于如此庞大的日志数据，进行高效率的实时统计分析难度是比较大的。用户登陆监控管理平台后，点击查看日志统计，需要较快的（客户可接受的时间是30秒以内）统计出截至当前所发生的数据交换结果。
针对这个问题，我们提出了一个解决的方案，就是针对如此庞大的数据日志，通过某种机制，能够自动生成统计结果，并将结果持久起来。这样每次用户看到的都是上一次生成的统计结果，而非实时地统计记录。统计记录的自动生成周期合理的话，那么用户看到的结果和实时的偏差在可控的范围内。
针对这样的方案，我们提出了几种解决办法：
u 由Apusic ESB引擎进行日志统计分析。在原有日志表的前提下，增加几张相应的统计数据表，在ESB引擎插日志数据到日志表的同时进行统计，将数据插入到统计表。这个方案的优点是，可以在数据传输的同时得到传输结果统计，在监控管理平台查询数据时将能很轻松的得到实时的统计结果，监控管理平台的效率将会相当高；缺点是，这种做法会增加增加ESB引擎的负担，而且目前引擎并不具备此功能，一来需要修改引擎，二来会给引擎带来不稳定因素。
u 由触发器进行日志统计分析。对日志表建触发器，一旦有日志数据进入日志表，马上由触发器来自动完成统计分析。此做法的优点是，监控管理平台无需自行做统计分析，能很轻松的得到实时的统计结果，缺点是，插日志的效率将会降低，而且会影响日志数据库的性能，同时针对不同的数据库都需要开发相应的触发器，在日志表结构产生变动的时候需要相应的维护触发器。
u 采用定时统计方式进行统计分析。在原有日志表的前提下，增加几张相应的统计数据表，由监控管理平台进行定时统计，例如每天凌晨1点钟进行统计，每次统计都仅需要统计前面24小时内发生交换的数据，然后相应的更新统计数据表即可。此方法的有点是，可以让系统在硬件、网络等都相对较空闲的时候做统计分析，而且每次统计的时间范围相对小，降低了统计负担，另外，真正使用监控管理平台查看统计结果都是在白天进行，而统计数据都是在半夜准备好了的，于是监控管理平台的效率将会相当高，缺点是，损失了实时性，每次查看到的统计数据都只能是前一天发生的，当天发生传输的统计结果要到第二天才能查询到。
最后考虑到项目周期比较紧张，在经过与用户协商，在用户接受的前提下，采用了第三种方案，同时给日志表增加索引，并且优化了引擎记录日志的策略。截至目前系统（包括监控管理平台）运行非常良好，用户对日志统计分析的结果和效率都相当满意。