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

banq 12-11-14
                   

我在上文中已经提到,淘宝支付宝在感性的双十一节曾经服务中断,而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大概就可以应付。

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

[该贴被admin于2012-11-14 10:38修改过]

                   

5
sinaID58617
2012-11-14 10:55

这样看问题是一个角度。不过,我觉得从另外一个角度看,更准确。

老系统,吞吐量瓶领。新系统接入的时候要自己控制自己的吞吐。靠消息队列来解决就行了。现在实际上已经在做了(网上排队已经有了),只是还没到完美。要记住这个12306背后是,十多年以前的数据库技术。几十个分布在全国的数据库。

这在《enterprise integration pattern》里面有讲到。

我之所以认为这更可能是一个系统集成问题,而不必上升到业务层面是基于在铁道系统的朋友的几点阐述。

1.铁路的核心系统是运行在20年以前的技术之上——sybase的很老版本的数据库,从此以后基本上没有升级。
2.全国的铁路局有十多个,这十多个都是独立的数据库。都是最古老的sybase+cs架构的windows程序
3.这些核心系统,铁道系统内部是十分满意的,因为从来没有因为系统的问题出过安全事故。(动车的是另外一套,不管)
4.12306只是卖票的,不能碰这些核心系统。

这样问题就来了,如果说老系统只能支持每分钟处理1k个事务,你的12306用的技术再牛,你也不能超过这个限度。如果你超过了,你会把核心系统拖垮。那就不是卖票卖不出的问题了,春节滞留旅客会出群体性事件的。所以,很明显铁道部的人在新旧两个系统加上了限制。这也是为什么12306老是卖票不出。

这个问题是有解决方案的,火车站排队就是一个方案。如果做成互联网网站,那么网站上的排队则必不可少。如果用integration pattern里面的模式来说,就应该有一个message pattern,把原来的synchronized请求变成asynchronized,然后变成队列,一个一个来。

我相信,支付宝的系统也会有这样的队列。但是支付宝的数据库有一个很强大的团队,可以做到持续交付,不停地提高核心系统的性能。这样可以使得这个等待队列尽量地短。

另外,卖票系统也不是某些人想得那么简单。最起码,原来定好的列车可以加挂车厢。原来定好的线路和时刻表可以增开临时列车。现在的高铁还能并联了。等等。还有一个实时性的要求,要和列车时刻表套上。否则人民一旦走不了,那会闹事的。

banq
2012-11-16 14:17

2012-11-14 10:55 "@sinaID58617"的内容
我觉得从另外一个角度看,更准确 ...


你这个角度主要从集成角度看,实际上支付宝等也需要和银行等系统集成通信,这些当然都是瓶颈所在。

关键问题是要抛弃传统关系数据库观点来看这些高频交易系统,本来业务是分散的,有自己的边界,但是你一旦使用关系数据库,整个RDBMS就成为一个唯一入口,认为造成拥挤,就像商城只开一个门让大批购物者进门,当然会拥挤,不是技术本身问题,而是你采取技术
的思路就不对,垃圾只是放错了地方才是垃圾。

最近一篇文章针对高频交易不适合关系数据库特别Oracle:10件不可以使用关系数据库的场景转第三点:

3. 高频交易:我们大多数人都认为交易系统必须RDBMS,因为它能保证事务性,对吗?错了. 高频交易者往往是采用NoSQL的第一批人,对于HFT低延迟为王,当然,你可以进行高难度篮球投篮,你也能使用关系数据库完成低延迟,但是关系数据库真的不是为这个目标设计的。.

Oracle试图否定上面的结论,他通过购买TimesTen, 试图将基于内存数据库和RDBMS结合, 但是你会捡了芝麻丢了西瓜,我们看到HFT大部分使用key-value存储,泪如Riak,甚至更复杂如Gemfire。

j086924
2013-11-13 17:29

不错!