论支付宝与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大概就可以应付。

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

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