您當前位置：
首頁 >
php開源 >
綜合技術 > [置頂] 電子商務系統的設計與實現(六)：賬務系統服務化的好處和壞處
[置頂] 電子商務系統的設計與實現(六)：賬務系統服務化的好處和壞處
來源：程序員人生 發布時間：2015-01-13 08:21:00 閱讀次數：2547次
賬務系統服務化，參考了公司Boss的設計。不過，隨著思考的深入，發現賬務系統服務化也有很多壞處，對1個中小型公司，小技術團隊，中小型網站來講。 壞處：1.開發本錢增大。
服務化，需要新建1個項目。開發調試的時候，必須保證賬務系統1直在運行，因此，部署的時候，賬務系統也需要單獨部署1次。
2.跨系統事務處理起來比較麻煩。
目前，投標的時候，立即需要支付，即把投標和支付2個跨系統的服務，想作為1個事務。但是，目前又沒有散布式事務的基礎框架。
因此，折衷的辦法是，把賬務這類不可回滾的操作，放在最后1個履行，如果失敗，就讓tender投標回滾。
但是，我發現投標和支付可以不作為1個事務。我們在電商網站購物的時候，1般都是先購物，生成定單，然后再支付，即從業務上就把某個業務和賬務操作分離了，不需要在1個事務中履行。
因此，如果我們非常把賬務服務化，對我們目前比較簡單的業務場景，可以不需要跨系統的事務，在業務層面，把投標和支付分開就行了。
但是，如果我們非要實現跨系統事務呢。固然是可以實現的。
聽說，支付寶之類的大型互聯網公司，有自己的事務框架，單獨的事務服務器。1個事務，常常有1個發起方和多個參與方，參與方成功或失敗，都會發送“回執通知”要求。根據這些要求，最后保障事務。另外呢，事務也可能不是實時去處理的，可能會把1些要做的事情，緩沖到數據庫中。然后再，定時處理這些事情，可能會需要事務。
在實際的購物網站中，跨系統事務是肯定存在的。比如，買家支付完成后，購物平臺1方面要通知買家成功支付信息，另外一個方面，要通知賣家可以發貨了。
好處
1.方便調用接口和協作。
多個系統之間，通過接口，可以很好地協作。
2.方便多個團隊同時開發。
比如，購物網站，賬務系統和主體商城商品可以由2個團隊完成。二者的開發，相互不影響。只要把接口定義好，保證接口最后的實現是符合規定的就能夠了。
本系統的實際情況
我目前正在做的這個購物系統，范圍比較小，開發人員也很少，把賬務單獨做出1個服務化的系統，感覺太麻煩了。另外，如果需要把賬務和1些業務放在1個事務中，事務的實現也更簡單。
有1個業務是可以肯定的，購物生成定單和支付相分離，是目前比較主流的做法。
感悟
之前都是在中小型公司工作，Web系統的業務相對照較簡單，不太清楚淘寶等大公司的技術做法。對很多業務場景，根本沒有斟酌過技術實現。還好，這次遇到了之前在支付寶等大公司工作過的boss，從他那里了解到了，很多業務需求和技術思想。至于技術的實現，對我們1直弄技術的人來講，不是太難，最少，開源的技術實現已很多了。
CSDN2014博客之星評選，幫小雷投1票吧
http://vote.blog.csdn.net/blogstar2014/details?username=fansunion
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
------分隔線----------------------------
------分隔線----------------------------
