论支付宝与12306的业务类型可比性

我在上文中已经提到,淘宝支付宝在感性的双十一节曾经服务中断,而Twitter可以在全民参与的总统大选中无发生任何意外,将中外技术比较是否有些不公平?但是我看到有人也进行另外一个不公平的比较,将支付宝和铁路售票系统12306进行比较,这里不公平不是指管理运营机制,无疑支付宝是市场经济的代表,我说的是业务类型的比较。

有IT公知说:支付宝昨日订单数超过一亿,而 12306 最高一天出票量大约是 166 万。电商订单交易复杂度要远超过车票。

如果单从数量上比,支付宝超过车票,但是忽视一个重要的业务类型不同:支付宝交易是每个人自己的账户扣款,没有共同资源需要争夺,而铁路售票则是同时抢位子,大家抢一个,而且抢的人越多,对计算机软硬件要求越高。铁路售票类似淘宝自己有时推出的“秒杀拍卖”。

自己扣自己的钱,如同一对一聊天或Twitter微博一样,他们的交互都是有一个清晰的自我边界,不会象广播机制那样扩散。打个不恰当比喻:有的大城市很大,但是你发现实际是由一个个小城镇社区发展起来的;而有的大城市是在统一规划,统一布局下发展起来的。前者类似支付宝这种业务类型。

好了,以上只是普及贴,下面从逻辑上严肃认证一下。

首先,从业务分析方法四色原型 或UML的用例图来看,四色原型的特点是什么人在什么地方做了什么事情,核心是人做事;而用例图也是一个左边一个角色Role,右边是干什么事。如下图:


两者核心都是操作者角色也就是人(Party)和物(Object)的划分。

一个系统的复杂与否,其实反映在人与物的逻辑交互复杂与否上,当然访问量多少也是一种复杂度拷问,但那只是对性能的考量,而且业务逻辑交互类型不同决定了性能可伸缩性解决方案又不同,也就是说:如果支付宝和铁路售票业务类型不一样,那么其解决性能可伸缩性的技术方案也必然是有所区别的。

关键核心是人与物的业务逻辑的区别上。根据我多年经验和思考,从人与物交互的不同程度上对业务有一个大致的划分:

系统选型大概关系如下,其中重轻的意思是:

人的“重轻”:

“重”表示这个业务系统是跟踪操作者Party的各种操作,比如有各种不同角色的操作者,操作者的操作是否是否相当频繁,注意,这里的人(Party)是一个抽象类型概念,不是实际运营系统的访问用户,其实际用户根据其系统面向用户的广度决定的。当然,如果Party操作频繁,实际用户加上访问量根据频繁。

“轻”表示这个业务系统用户类型比较少,主要是管理者的操作,普通大众用户只能浏览读,无法写入,如发表评论等等,相当于Web 1.0,比如新闻门户网站等等,或广播电视等等。

物的“重轻”:

Party要和Object交互,这个Object物的复杂程度也决定了业务类型,物重,有两点表示:

1. Object自己的对象结构复杂,比如ERP系统的物料,半成品或成品,它们涉及几个采购 销售 生产 财务几个系统,每个子系统都有轻微不同,这就表现为其对象本身的复杂性。

2.Object对象资源的争夺性,这是从Party和Object关系来看的,这个资源相当宝贵,需要合理的分配给不同的用户,比如大牛市大牛股,很多人抢买,以前中国证券在牛市中交易系统也当机过,包括前段时间,Facebook刚上市,买卖量太大,纽约交易所出现故障。

具体分类如下,当然也可能有草率的地方,欢迎讨论:

人重-物轻 :例如微博 聊天室,适合采取面向函数FP,支付宝等交易系统也应该属于此类,支付的金额是物,从自己的账户中扣款做个减法而已,高峰时期大量用户频繁提交。

人轻-物重 : 例如CMS 论坛 博客系统,用户并不频繁发命令,内容很重,有复杂的内容关系,还有企业软件,比如BOM物料结构等等,办公OA系统,物是大量的文档。面向对象OO比较擅长了,Java和Ruby都是可以的。

人重-物重: 证券股票交易系统或实时拍卖系统,大量用户频繁交易,物是各种股票或复杂的标的物,LMAX架构比较合适,以事件为主的CQRS架构,面向函数和面向对象两手都要硬。国内12306购票系统也应该属于此类,大家竞购共同资源,而支付宝之类不属于此类原因是,支付扣款不是扣共同资源,而是扣自己账户的钱,自己玩的是自己的东西,不和别人分享抢夺,物不重。

人轻-物轻: dBase大概就可以应付。

总结:业务类型的区分可以说是软件万里长征方向的第一步,这第一步是向南还是向北,是战略性的,很多人由于细节决定成败的影响,反而迷失在细节之中,如果方向性错误,无论你怎么努力,怎么聪明,怎么强大,必然会范错误,错误的代价和你强大程度是呈正比的。

论支付宝与12306的业务类型可比性

相关推荐