远程调用历史及代码编写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中所说的多次支付问题。

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