ESB集成平台之业务模型和性能测算

对于业务模型和性能测算，以前已经写过不少的文章进行总结，包括对于ESB集成平台的业务测算模型和基准测算值，今天重点再谈下进行性能测算的一些关键点。

对于BenchMark基准数据，这个基准数据应该进一步准确化，原来我们谈的最多的是某种TPMC的机器，或者说类似4C，16G的虚拟机这个计算单元，1秒钟能够负载多大的服务并发调用。但是这个数据并不是特别准确，能够承受的并发量还和并发服务的如下输入相关，即：

1. 服务传输的数据量是多少？对于5k的数据和500k的数据，ESB能够承受的并发量显然是不一样的。

2. 服务调用的时长是多少？这个本身又受到原始服务响应时间影响，时长越长往往最资源和连接占用越久。

3. 如果是虚拟机，4C的CPU核数本身就是一个虚拟值，具体计算能力如何也需要重新测定。

4. 大并发调用的持续时长，如果存在持续长久的大并发是否会造成连接无法释放和内存泄露问题？

4. 是否记录日志，是否记录日志对于服务并发调用量又明显的影响。

这些都是我们在进行性能测算的时候需要考虑的问题，简单来说同样的服务器如果仅仅是5k，原始服务本身的响应时间也很短，同时又是短时间的大并发服务调用，那么单台服务器TPS达到2000以上是很容易的事情。或者说并发量支持2000-5000都是有可能的。但是考虑到服务本身的调用时长

在我们进行500并发性能测试的时候，实际ESB总线的性能损耗往往在10-15%左右，ESB平台最怕的还是大数据量或长响应时间的服务接入和调用，这种服务对ESB平台的连接资源和内存资源的消耗往往是最大的。

如果要对ESB平台进行完整的POC性能测试，不仅仅是测试服务类型+服务数据量+服务并发量的各种组合，更加重要的是形成具有各种服务类型，各种数据量和各种并发量的组合服务并发运行场景，以充分模拟出实际生产服务运行情况，这样测试出的性能BenckMark数据才有意义。

ESB服务总线在大并发下最容易出现的问题主要有两类，第一是服务运行超时，这往往是由于原生服务本身运行周期较长或者在ESB服务流控时候出现等待导致；第二是内存溢出，这种情况往往出现在大并发大数据量的访问同时服务运行时间较长，堆内存服务及时回收导致。

对于第一类情况，一个是优化原生服务的运行时间，其次是将同步服务变为异步运行服务；对于第二类情况则需要减少每次服务调用传递的数据量，例如通过分页，分批次传输等，其次则是需要采用类似ODI等专门的大数据传输和集成方案来解决问题。