首页 > 代码库 > 电子商务系统的设计与实现(六):账务系统服务化的好处和坏处

电子商务系统的设计与实现(六):账务系统服务化的好处和坏处

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

  坏处
1.开发成本增大。
  服务化,需要新建一个项目。开发调试的时候,必须保证账务系统一直在运行,因此,部署的时候,账务系统也需要单独部署一次。
2.跨系统事务处理起来比较麻烦。
  目前,投标的时候,立即需要支付,即把投标和支付2个跨系统的服务,想作为一个事务。但是,目前又没有分布式事务的基础框架。
因此,折衷的办法是,把账务这种不可回滚的操作,放在最后一个执行,如果失败,就让tender投标回滚。

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

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

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

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

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

好处
1.方便调用接口和协作。
   多个系统之间,通过接口,可以很好地协作。
2.方便多个团队同时开发。
  比如,购物网站,账务系统和主体商城商品可以由2个团队完成。两者的开发,互相不影响。只要把接口定义好,保证接口最后的实现是符合规定的就可以了。

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

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

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

http://vote.blog.csdn.net/blogstar2014/details?username=fansunion

电子商务系统的设计与实现(六):账务系统服务化的好处和坏处