原始架构与性能——mypay1.0

可在svn地址中tag目录下寻找1.0版本，并根据接下来的部署方案，运行本系统，对本系统有一个大致的了解

初识龙果支付

1.0系统的运行只是为了让大家能把项目跑起来，性能不是关注的重点，因此这部分我是在家里完成的。运行的设备为i3（4cpu），8gb笔记本一台，I7（7700K），16gb台式机一台。以下为网络拓扑图：

其中台式机创建了4台虚拟机（2cpu，2gb）：

192.168.2.120部署zk

192.168.2.122部署mysql，内含rp_trade_payment_order，rp_trade_payment_record，seq_table，TCC_TRANSACTION_TRADE四张表

192.168.2.123部署mysql，内含rp_account，rp_account_history，TCC_TRANSACTION_ACCOUNT三张表

192.168.2.124部署mysql，内含rp_accounting_voucher，rp_point_account，rp_point_account_history，TCC_TRANSACTION_POINT四张表

192.168.2.160为笔记本，部署mysql，内含base.sql中的所有表

192.168.2.100为台式机，部署有activemq，七个services，3个app与四个war包。以下是系统运行时的消耗

以下为activemq的消息页面

由activemq的图片可以看出此系统的一个bug，bank_notify队列的消费数大大超过accounting_notify的入列数，正常处理流程应为消费一条bank_notify消息产生一条accounting_notify消息，bank_notify与accounting_notify的数量应该大致相等（可以相差几十条，为正在处理的线程的数目），实际运行中可以发现bank_notify的消息会被直接消费不会产生堆积，事实是app-queue子项目中bank_notify队列的消费方法有缺陷，该方案直接消费了bank_notify中消息并产生task放入了对应的threadPool中等待处理，等于是app-queue本身持有了不能及时处理的消息，这个设计是非常不合理的，此时消息页面将无法反应消息的堆积量，该bug将在后续的版本中被修改。

以下是系统的sql数据，分析可以得出qps为20左右。

系统运行后得到的数据链接：https://pan.baidu.com/s/1AV9-g_oPGav_BhOkn4JTgQ 密码：jxc9