历史介绍部分:
远程调用大致经过了corba、webservice、二进制跟restful四个阶段
corba时代,corba(Common Object Request Broker Architecture,通用对象请求代理架构)算是公认的所有远程调用的鼻祖,是由OMG(object mangement group)制定的一套远程调用机制。rpc中的一些概念,例如 调用方、服务、提供方等都是corba最早定义的。但其定义过于繁琐,兼容不太好且效率一般,后来逐渐被其它技术取代。
webservice时代(http+soap),java在90年代末广泛应用后,webservice随即迅速发展,第一个webservice框架aixs诞生,aixs诞生在盛产神油的神奇国度--印度,其实印度一直是一个it外包产业发达的国家,虽然我们日常更多关注的是他的奇闻异事;但aixs做的质量不好,架构跟性能都有点问题,apache觉得这合作伙伴有些丢人,就整理了一下,做了aix2。后来又有了Xfire跟进化版的cxf。webservice是基于http传输的,协议采用soap。soap使用xml来承载,而且不属于任意公司或组织,因此很多公司自己实现了一套解析方案,经常会有jar包冲突的问题。而且xml数据传输效率(里边太多用于维护结构等接口无关的数据)跟对象转为xml的序列化效率都不高,导致webservice注定不是一款高性能的rpc协议。
二进制时代(tcp+byte),鉴于webservice有上述问题,性能更优秀(理论上)的二进制rpc协议应运而生,代表有hession跟rmi。二进制自然涉及到对象的序列化,其实这个性能也比较差,单纯就这一点来说,webservice甚至略有优势,因为有些机型的cpu为对象跟xml的序列化提供了硬件支持。二进制解决了网络传输效率问题,但没解决对象序列化效率问题。二进制协议后来并没有遮住webservice的光芒,跟伟大的IBM也不无关系,2005年IBM提出SOA的设计概念,这个思想对java产生了深远的影响,而IBM的SOA实现采用的是webservice。
restful时代(http+json),json开始是用在前端,后来发现在后端对象的转换效率也非常高,于是传输效率跟转换效率都解决了。
自定义协议,dubbo协议等,值得注意的是一些二进制协议也在不断发展,比如hessian2,性能也有一些进步,但效果仍然一般。
-------------------------------------------------
代码编写部分,远程调用并不麻烦,无论使用dubbo还是webservice,使用起来都非常方便,但仍然有一些细节处理需要我们注意。
业务场景:有新订单生产,用户点击结算进行付款,后台调用远程支付接口划款,更新订单状态。
1、第一种写法:
@Transactional
public void tixian(OrderInfo orderInfo){
try {
OrderVO order = new OrderVO();
order.setAmount(orderInfo.getAmount());
order.setId(orderInfo.getId());
order.setName(orderInfo.getName());
//调用远程接口,从用户账号扣款,转账到自己账户
//此处response只是模拟写法,具体要参照api来写,而且此处可能有异常,该处的异常暂不考虑
//此处认为,response为null是网络异常的情况
BankResponse response = bankService.moneyOut(order);
//根据远程接口返回的状态,判断是否支付成功
if(response !=null && response.getCode().equalsIgnoreCase("s")){
orderInfo.setStatus(2);//支付成功
}else {
orderInfo.setStatus(3);//支付失败
}
//保存订单状态
orderInfoDao.updateByPrimaryKey(orderInfo);
}catch (Exception e){
e.printStackTrace();
}
}
BankService是个远程接口,本地demo配置为:
<bean name="bankService" class="com.istack.base.httpService.client.HttpProxyFactoryCglib">
<property name="targetClass" value="com.xxx.bank.BankService"></property>
<property name="endPoint" value="http://localhost:18080/rpcTest"></property>
<property name="timeOut" value="35000"></property><!--超时会返回null-->
</bean>
OrderInfo的status,1未支付,2支付成功,3支付失败,4处理中(支付过,但结果未知)
这段代码逻辑上是比较清晰的,但会两点问题:
a、事务范围过大
事务直接加在方法上,那么一旦进入该方法,即启用事务,直至该方法结束才对事务进行提交或者回滚。而事务是依赖于数据库连接的。一般来说,远程调用的耗时都会相对较长(毕竟不在本地,网络延迟可能会比较严重,而且有的业务的确复杂,处理需要一段时间),那么,当短时间内访问量较大的情况下,每个用户一个线程,每个线程占用一个数据库连接,会在短时间内耗光数据库连接池的连接,这时候,会导致后续的用户无法进行结算(因为没有数据库连接,需要等待),或者数据库连方面连接已满,导致其它应用无法连接数据库。这两种情况,对于业务系统来说都是灾难性的。
b、状态判断不合理
只判断了接收到远程反馈的情况,如果由于网络或者黑客等原因,导致没有接收到远程反馈的情况没有处理。比如发送了支付请求,银行方面进行了处理,也进行了反馈,但这个反馈信息中途被拦截,导致超时,或者某些支付系统返回的是个处理中这类模糊信息,而不是处理成功或者处理失败的明确信息,该代码则无法应对。
如何解决这两个问题?
2、第二种写法:
针对第一种写法中的问题,我们改进代码如下:
public void tixian2(OrderInfo orderInfo){
try {
OrderVO order = new OrderVO();
order.setAmount(orderInfo.getAmount());
order.setId(orderInfo.getId());
order.setName(orderInfo.getName());
//调用远程接口,从用户账号扣款,转账到自己账户
BankResponse response = bankService.moneyOut(order);
//根据远程接口返回的状态,判断是否支付成功
if(response !=null){//有返回值
if(response.getCode().equalsIgnoreCase("s")){
orderInfo.setStatus(2);
}else{
orderInfo.setStatus(3);
}
}else {//无返回值,这里这么写,代指超时或者网络异常等,不一定支付失败,实际情况要根据接口api来写这个判断
orderInfo.setStatus(4);
}
//保存订单状态,(编程式事务)
template.execute(new TransactionCallback<Object>() {
@Override
public Object doInTransaction(TransactionStatus transactionStatus) {
orderInfoDao.updateByPrimaryKey(orderInfo);
return null;
}
});
}catch (Exception e){
e.printStackTrace();
}
}
该代码避免了第一种写法的两个问题,貌似完美但仍有一个问题,如果由于某种原因,比如用户点击了两次,或者该订单是通过mq发过来的,而mq有可能重发消息,这样的话就会导致同一个用户多次支付,如何避免?
3、第三种写法
public void tixian3(OrderInfo orderInfo){
try {
int rows = orderInfoDao.update("update order_info set status=4 where order_info_id=? and status=1",new Object[]{orderInfo.getId()});
if(rows == 1){
OrderVO order = new OrderVO();
order.setAmount(orderInfo.getAmount());
order.setId(orderInfo.getId());
order.setName(orderInfo.getName());
//调用远程接口,从用户账号扣款,转账到自己账户
BankResponse response = bankService.moneyOut(order);
//根据远程接口返回的状态,判断是否支付成功
if(response !=null){//有返回值
if(response.getCode().equalsIgnoreCase("s")){
orderInfo.setStatus(2);
}else{
orderInfo.setStatus(3);
}
}else {//无返回值,不一定支付失败,可能是超时或者网络异常等
orderInfo.setStatus(4);
}
//保存订单状态,(编程式事务)
template.execute(new TransactionCallback<Object>() {
@Override
public Object doInTransaction(TransactionStatus transactionStatus) {
orderInfoDao.updateByPrimaryKey(orderInfo);
return null;
}
});
}
}catch (Exception e){
e.printStackTrace();
}
}
跟2的区别是开始的时候修改了状态,使得后续的相同订单处理无效。这是一种乐观锁的处理方式,这样就避免了2中所说的多次支付问题。
该部分内容,仅用来示例,提醒自己要培养互联网思维,不要仅仅用代码罗列一下业务逻辑就算了,要深入思考,考虑各种复杂情况下的处理,提高系统性能跟健壮性。