远程调用历史及代码编写demo

Posted nevermorewang

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了远程调用历史及代码编写demo相关的知识,希望对你有一定的参考价值。

  历史介绍部分:
  远程调用大致经过了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中所说的多次支付问题。

  该部分内容,仅用来示例,提醒自己要培养互联网思维,不要仅仅用代码罗列一下业务逻辑就算了,要深入思考,考虑各种复杂情况下的处理,提高系统性能跟健壮性。

以上是关于远程调用历史及代码编写demo的主要内容,如果未能解决你的问题,请参考以下文章

手写一个rpc远程调用服务demo

PHP创蓝253云通信平台国际短信接口调用demo案例

JUC并发编程 共享模式之工具 JUC CountdownLatch(倒计时锁) -- CountdownLatch应用(等待多个线程准备完毕( 可以覆盖上次的打印内)等待多个远程调用结束)(代码片段

JavaScript的历史由来及简介

如何测量代码片段的调用次数和经过时间

编写高质量代码:改善Java程序的151个建议(第3章:类对象及方法___建议36~40)