渠道接入java客户端评审小结

渠道接入java客户端

 

概述： 公司是做移动支付类业务的，经过几年的发展，初见规模，已经有很多商户（一些中小公司）想接入我们的支付系统，以实现支付，于是我们公司开发了个渠道接入服务器，采用自定义的报文格式，并且出于性能的考虑使用的是异步长连接的形式。但是我们会发现开发个异步长连接并不是件容易的事。今天的评审我们主要提了一下几点建议：

 

1、心跳报文的发送才用线程，比较消耗性能，是否可以考虑读写超时；

2、异步长连接，通信是异步的，报文的缓存应该在发送请求阶段；而不是接受响应阶段；

3、报文ID的生成规则，有没有考虑持久化和多线程环境下的使用；

4、MINA版本使用的是1.x，是否考虑使用MINA2.x；

5、codec是否考虑了“一个报文做两次发和一次发多个报文的”的情况；

6、异步长连接是否考虑了自动重连机制；

7、开多个连接时，服务端是否考虑了跨链路做交易的情况。（具体解释： 客户端把请求发送出去后，服务器端做处理，还没回响应，但是此时客户端断开了，如果客户端有重连机制，那么当客户端重新连接上的时，服务器能否依据连接对应的用户账号把消息发送给新的链接呢？ 这一点告诉我们开发业务时，不要只认物理连接，而应该要认用户账号，服务端可以维护个从“用户账号”到“物理连接”的映射关系。   回想到，我曾今开发的“POSP前置”，也没做这方面的处理，当然POSP上来的请求都是同步短连接的，这样即使服务端做了处理，客户端也读取不了两个报文。）

 

8、最后刘导的建议，更令人受启发。就是这个长连接客户端客观上其实是不容易的，也正因为这样，我们才考虑到为商户免费提供一个客户端，以方便商户的介入，但是问题是如果商户人家不用java呢？很多商户使用的就是php，c，asp.net等，我们是不是要为各种语言提供客户端呢？这样对公司的负担也很重。有没有其他解决办法呢？刘导经常强调做成服务的形式，可是我开始也误解了这里的服务，因为服务一次，如今用的太泛滥了，基本上等于一切可运行的程序，能提供外部调用的都叫服务。这样的误解很不好，应该说“服务意味着用标准协议”，比如走HTTP协议。 优点在于，走HTTP协议，既可以开发对Human使用的，也可以开发对Program使用的。调试非常方便。当然大家争议大的是，HTTP慢，但是如今HTTP如此流行，已经有很多新技术了，应该说HTTP性能对于中小企业来说根本不是问题。而且性能优化方面HTTP的有很多好的产品或开源项目能提供支持。所以，对于对外的（比如让其他公司接入的接入系统），我主张采用web形式。