HTML5技术

浅谈个人对12306的核心用户诉求的核心模型设计思路和架构设计 - netfocus

字号+ 作者:H5之家 来源:H5之家 2016-02-13 11:00 我要评论( )

前言 春节期间,无意中看到一篇文章,文章中讲到12306的业务复杂度远远比淘宝天猫这种电商网站要复杂。后来自己想想,也确实如此。所以,很想挑战一下12306这个系统的核心领域模型的设计。一般的电商网站,购买都是基于商品的概念,每个商品有一定量的库存,

前言

春节期间,无意中看到一篇文章,文章中讲到12306的业务复杂度远远比淘宝天猫这种电商网站要复杂。后来自己想想,也确实如此。所以,很想挑战一下12306这个系统的核心领域模型的设计。一般的电商网站,购买都是基于商品的概念,每个商品有一定量的库存,用户的购买行为是针对商品的。当用户发起购买行为时,系统只需要生成订单并对用户要购买的商品减库存即可。但是,12306就不是那么简单了,具体复杂在哪里,我下面会进一步分析。

另外一个让我写这篇文章的原因,是我发现也许是否是因为目前12306的核心领域模型设计的不够好,导致用户购票时要处理的业务逻辑异常复杂,维护数据一致性的难度也几百倍的上升,同时面对高并发的订票也难以支持很高的TPS。我觉得,越是复杂的业务,就越要重视业务分析,重视领域模型的抽象和设计。如果不假思索,凭以往经验行事,则很可能会被以往的设计经验先入为主,陷入死胡同。我发现技术人员往往更注重技术层面的解决方案,比如一上来就分析如何集群、如何负载均衡、如何排队、如何分库分表、如何用锁,如何用缓存等技术问题,而忽略了最根本的业务层面的思考,如分析业务、领域建模。我认为越是复杂的业务系统,则越要设计一个健壮的领域模型。如果一个系统的架构我们设计错了,还有补救的余地,因为架构最终沉淀的只是代码,调整架构即可(一个系统的架构本身就是不断演进的);而如果领域模型设计错了,那要补救的代价是非常大的,因为领域模型沉淀的是数据结构及其对应的大量数据,对任何一个大型系统,要改核心领域模型都是成本非常高的。

本文的重点不是在如何解决高并发的问题,而是希望从业务角度去分析,12306的理想模型应该是怎么样的。网上目前谈12306的文章貌似都是千篇一律的只谈技术,不谈业务分析和如何建模的。所以我想写一下自己的设计和大家交流学习。

需求简述

12306这个系统,核心要解决的问题是网上售票。涉及到2个角色使用该系统:用户、铁道部。用户的核心诉求是查询余票、购票;铁道部的核心诉求是售票。购票和售票其实是一个场景,对用户来说是购票,对铁道部来说是售票。因此,我们要设计一个在线的网站系统,解决用户的查询余票、购票,以及铁道部的售票这3个核心诉求。看起来,这3个场景都是围绕火车票展开的。

查询余票:用户输入出发地、目的地、出发日三个条件,查询可能存在的车次,用户可以看到每个车次经过的站点名称,以及每种座位的余票数量。

购票:购票分为订票和付款两个阶段,本文重点分析订票的模型设计和实现思路。

其实还有很多其他的需求,比如给不同的车次设定销售座位数配额,以及不同的区段设置不同的限额。我觉得这个需求不是核心最重要的诉求,所以,本文针对这个需求不做具体讨论,也不是本文分析设计的重点。

需求分析

确实,12306也是一个电商系统,而且看起来商品就是票了。因为如果把一张票看成是一个商品,那购票就类似于购买商品,然后每张票都有库存,商品也有库存的概念。但是如果我们仔细想想,会发现12306要复杂很多,因为我们无法预先确定好所有的票,如果非要确定,那只能通过穷举法了。

我们以北京西到深圳北的G71车次高铁为例(这里只考虑南下的方向,不考虑深圳北到北京西的,那是另外一个车次,叫G72),它有17个站(北京西是01号站,深圳北是17号站),3种座位(商务、一等、二等)。表面看起来,这不就是3个商品吗?G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员(包括某些中等规模公司的专家、CTO)就是在这里栽第一个跟头的。实际上,G71有136*3=408种商品(408个SKU),怎么算来的?如下:

如果卖北京西始发的,有16种卖法(因为后面有16个站),北京西到:保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品,同理,石家庄上车的,有15种下车的可能,以此类推,单以上下车的站来计算,有136种票:16+15+14....+2+1=136。每种票都有3种座位,一共是408个商品。

为了方便后面的讨论,我们先明确一下票是什么?

一张票的核心信息包括:出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证,该凭证表示持有它的人可以坐某个车次的某个座位号,从某地到某地。所以,一张票,对用户来说是一个凭证,对铁道部来说是一个承诺;那对系统来说是什么呢?不知道。这就是我们要分析业务,领域建模的原因,我们再继续思考吧。

明白了票的核心信息后,我们再看看G71这个车次的高铁,可以卖多少张票?

讨论前先说明一下,一辆火车的物理座位数(站票也可以看成是一种座位,因为站票也有数量配额)不等于可用的最大配合。所有的物理座位不可能都通过12306网站来销售,而是只会销售一部分,比如40%。其余的还是会通过线下的方式销售。不仅如此,可能有些站点上车的人会比较多,有些比较少,所以我们还会给不同的区间配置不同的限额。比如D31北京南至上海共有765张,北京南有260张,杨柳青有80张,泰安有76张。如果杨柳青的80张票售完就会显示无票,就算其他站有票也会显示无票的。每个车次肯定会有各种座位的配额和限额的配置的,这种配置我目前无法预料,但我已经把这些规则都封装近车次聚合根里了,所有的配置策略都是基于座位类型、站点、区间配置的。所以,不管如何做配额和限额,我们总是针对车次进行配置,这些配置只是车次内部售票时的一些额外的判断条件(业务规则),不影响车次模型的核心地位和对外暴露的功能。所以,为了本文讨论的清楚起见,我后续的讨论都不涉及配额和限额的问题,而是认为任何区段都可以享受火车最大的物理座位数。

为了讨论问题方便,我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间,系统会分配给001一个座位x;但是因为001坐到B站点后会下车,所以相当于x这个座位又空出来了,也就是说,从B站点开始,系统又可以认为x这个座位是可用的。所以,我们得出结论:同一个座位,其实可以同时出售AB,BC这两张票。通过这个简单的分析,我们知道,一列火车虽然只有有限的座位数,比如1000个座位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例,假如火车总共有1000个座位,那AB可以卖1000张,BC也可以卖1000张,同样,CD也可以卖1000张。也就是说,理论上最多可以卖出3000张票。但是如果换一种卖法,所有人都是买ABCD的票,也就是说所有的票都是经过所有站点的,那就是最多只能卖出1000张票了。而实际的场景,一定是介于1000到3000之间。然后实际的G71这个车次,有17个站,那到底可以卖出多少个票,大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段,都可以出售为一张票。我数学不好,算不太清楚,麻烦有数学好的人帮我算算,呵呵。

 

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
  • 基于CSS的个人网页 - 汕大-吴广林

    基于CSS的个人网页 - 汕大-吴广林

    2017-04-21 12:00

  • 面向个人的技术咨询服务 - 思想瞭望者

    面向个人的技术咨询服务 - 思想瞭望者

    2017-04-05 12:07

  • 车大棒浅谈jQuery源码(二) - 车大棒

    车大棒浅谈jQuery源码(二) - 车大棒

    2017-04-02 10:07

  • 大数据云计算学习路线图(纯属个人看法和观点) - 别先生

    大数据云计算学习路线图(纯属个人看法和观点) - 别先生

    2017-03-30 13:00

网友点评
d