历史介绍部分：
远程调用大致经过了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中所说的多次支付问题。
该部分内容，仅用来示例，提醒自己要培养互联网思维，不要仅仅用代码罗列一下业务逻辑就算了，要深入思考，考虑各种复杂情况下的处理，提高系统性能跟健壮性。