浅谈12306核心模型设计思路和架构设计
51 浏览量
2021-02-26
06:35:38
上传
评论
收藏 159KB PDF 举报
浅谈浅谈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个商品。
为了方便后面的讨论，我们先明确一下票是什么？
评论0