首页 » 高可用架构

订单系统开发(仿淘宝、美团网) 之 项目总结

   发表于:高可用架构评论 ()   热度:1649

基于公司战略的调整和开发框架的升级换代,也伴随着SOP(面向服务编程)和SOA(面向服务架构)的软件开发思想在公司开发团队中的慢慢深入,最终讨论决定在将现有(旧)的支撑公司业务的项目模块(如:产品,商家和订单...)在进行底层架构升级的同时,要让这个模块在一定程度上可以达到复用性——即它应该可以满足新的栏目('同城网购')的相关需求且适当的考虑未来的需求扩展,它不能跟其它的模块耦合在一起,只负责属于这个模块领域内的数据服务(如:产品模块只用考虑产品相关数据的读写),可以独立公开作为一个服务,且可以满足分布式部署的需求(这个由新的基于CSLA的底层框架管理和决定)。 大概从今年1月份,我决定负责订单系统这块儿的设计和开发,由于中间有一些其它的原因,一直到4月中旬——这期间,我更多的是了解和研究淘宝订单交易的各个流程和相关细节,并做了主体的订单系统领域模型分析,这算是前期'耗时长效率低'的最初版的系统设计,也为后期的详细设计打下了基础和铺垫!    

  由于之前的订单模块,不是我开发的,也只能负责简单的交易处理,所以除了我从淘宝上做流程和数据分析别无参考;淘宝每天都有很多人在用,我也偶尔上去逛逛买点儿东西,但是如果我不负责这个订单系统的开发,我也不会感受到其流程之“复杂”——复杂背后带来的却是我们热衷使用的良好的“用户体验性”。    

  淘宝的订单系统很庞大,我目前开发的只仿照了其中65%左右的功能,即:从交易开始到交易结束最主要的的交易流程,像:售后、投诉等暂未实现。相对而言,美团网的订单交易就比较简单,可以算作是包含在淘宝订单交易中的一种特殊订单类型:虚拟物品(代金卷,代金卷即为美团卷)订单。

   交易总流程图如下:

  点击查看大图

  想必你看了上面的总流程图,就会感觉流程之复杂——相对于其它的比较单纯的信息类的数据(如:新闻,产品...),订单这部分的数据都是有状态且有超时时间,这也是订单系统设计和开发的难点!(会在之后的博客中跟大家分享我在做这个订单系统的设计想法)。

   我们平时可能会使用到淘宝、美团和京东等多个电子商务网站里的订单系统,对于使用体验一般大部分都大同小异,这样的话,订单系统的开发到底应该要满足或达到什么样的需求标准?
   在满足在线交易“方便、快捷”的基本前提下,让买卖双方在订单系统中能自助(可选择)、人性化比较顺畅安全可靠的完成交易中的各个(买家退款等)流程.

   这就是我对上面问题的回答,也是我对自己开发订单系统所定的标准。

  

  电子交易操作的安全基本要求

  • 信息的保密性
  • 交易者身份的认证(确认和鉴别)
  • 不可否认性(交易的确定性)
  • 信息的完整性(信息的准确可靠,不可修改)

    

  这是之前在网上看到的一段内容,同样也是我开发的技术要求指南!

     先写到这儿吧,这篇博客算是做个大概的描述;很久没写博客了,这期间一直忙着做这个订单系统的开发,虽然很累,但现在基本上算是开发'成功'结束了,有不少细节需要完善。写此系列的博客,也是希望大家能多提意见并分享你的想法和经验!

###################################################################################3

这里重点想说下订单系统开发的设计和有待优化改进的问题。

    

 

  

  上图是订单系统数据库设计比较重要的一个——其决定了订单数据的横向切割,而不是将所有的订单数据都存放在一个表中。为什么要这样设计?这样做有什么好处?(看下文便可知晓)  回答上面的疑问,我感觉有必要引出另外一个问题:对于数据库设计,如何能降低并发量 或 提高数据的读写数度?我所知道和比较常见的做法如下:——  

  1.读写数据库分离,了解数据库的都知道:数据库的(读)共享锁S和(写)排它锁(X)是互斥、无法共存的,即当一个表的数据在被修改时,会阻止其它用户的读取。  

  2.数据库表的横向(行数据)和纵向(数据列)切割。  

  3.对于基本上不会用户查询的多个列,可以使用json或二进制等压缩序列化列字段存放数据,这样有点儿类似于Google的Big Table,有助于提高查询效率。

   以上除了第一点在本次订单系统开发中都有使用,而且我相信你看完了上图,你应该会感觉到这样的数据切割:数据的存放(位置)比较清晰,比如:对于‘未付款’的订单数据,它一定是存放于Order_OrderInfo_Temp表中,这样:用户在搜索订单状态为“未付款”的订单时,可以很快方便的从此表中查询;或当用户在进行“取消交易”的操作时,基于上面第一点所提到的,它不会影响到处于'交易中'的订单用户的操作。

  

  

  写到这儿,感觉有点儿戛然而止——不知道该写点儿啥了;回顾这个项目的开发历程,模糊→清晰→迷茫→纠结→释然,这就是我在项目的各个阶段的感受,用一句话来形容就是:由最开始的感觉高山仰止、举步维艰,到现在的“神马都是浮云”,困难都是暂时的,等你越过去(把它踩在脚下),你也就感觉那算不上什么。

   现在只想谈下,有待优化和比较棘手的地方——  

  1.目前的订单系统跟支付系统的相互依赖程度比较高,以至于订单的各个阶段的操作,如:付款,买家确认收货...,都需要调用支付系统的服务,以保证两边数据的同步。  

  2.由于支付系统是基于第三方支付平台相关服务方法的封装,即支付系统对“现金”进出操作只相当于是个通道,无法控制和保证每个操作的成功。  

  3.基于以上两点,订单系统与之交互的操作就比较被动,让人感觉很不舒服,增大了程序的复杂度。  

  4.订单和退款超时数据的处理,目前没有使用定时器或数据库job,暂时用几个触发点来代替,这样从服务到UI都增加了相应的代码处理。

    怎样让订单系统和支付系统尽可能的'解耦',这将是下一个版本需要重点解决的问题!  

  就写到这吧,希望有这方面经验的朋友,能提些建议。

 

 

 

 

 

(。・v・。)
喜欢这篇文章吗?欢迎分享到你的微博、QQ群,并关注我们的微博,谢谢支持。