账务系统服务化，参考了公司Boss的设计。不过，随着思考的深入，发现账务系统服务化也有不少坏处，对一个中小型公司，小技术团队，中小型网站来说。

  

坏处

：

1.开发成本增大。

  服务化，需要新建一个项目。开发调试的时候，必须保证账务系统一直在运行，因此，部署的时候，账务系统也需要单独部署一次。

2.跨系统事务处理起来比较麻烦。

  目前，投标的时候，立即需要支付，即把投标和支付2个跨系统的服务，想作为一个事务。但是，目前又没有分布式事务的基础框架。

因此，折衷的办法是，把账务这种不可回滚的操作，放在最后一个执行，如果失败，就让tender投标回滚。

 但是，我发现投标和支付可以不作为一个事务。我们在电商网站购物的时候，一般都是先购物，生成订单，然后再支付，即从业务上就把某个业务和账务操作分离了，不需要在一个事务中执行。

因此，如果我们非常把账务服务化，对于咱们目前比较简单的业务场景，可以不需要跨系统的事务，在业务层面，把投标和支付分开就好了。

 但是，如果我们非要实现跨系统事务呢。当然是可以实现的。

 据说，支付宝之类的大型互联网公司，有自己的事务框架，单独的事务服务器。一个事务，往往有一个发起方和多个参与方，参与方成功或失败，都会发送“回执通知”请求。根据这些请求，最后保障事务。另外呢，事务也可能不是实时去处理的，可能会把一些要做的事情，缓冲到数据库中。然后再，定时处理这些事情，可能会需要事务。

在实际的购物网站中，跨系统事务是肯定存在的。比如，买家支付完成后，购物平台一方面要通知买家成功支付信息，另一个方面，要通知卖家可以发货了。

好处

1.方便调用接口和协作。

   多个系统之间，通过接口，可以很好地协作。

2.方便多个团队同时开发。

  比如，购物网站，账务系统和主体商城商品可以由2个团队完成。两者的开发，互相不影响。只要把接口定义好，保证接口最后的实现是符合规定的就可以了。

本系统的实际情况

我目前正在做的这个购物系统，规模比较小，开发人员也很少，把账务单独做出一个服务化的系统，感觉太麻烦了。另外，如果需要把账务和一些业务放在一个事务中，事务的实现也更简单。

有一个业务是可以确定的，购物生成订单和支付相分离，是目前比较主流的做法。

感悟

之前都是在中小型公司工作，Web系统的业务相对比较简单，不太清楚淘宝等大公司的技术做法。对于很多业务场景，根本没有考虑过技术实现。还好，这次遇到了之前在支付宝等大公司工作过的boss，从他那里了解到了，很多业务需求和技术思想。至于技术的实现，对于咱们一直搞技术的人来说，不是太难，至少，开源的技术实现已经很多了。

 CSDN2014博客之星评选，帮小雷投一票吧