关于”12306 外包给阿里巴巴做是否可行“的问题的想法

为什么80%的码农都做不了架构师？>>>   

    今天快下班的时候，在 知呼 网看到“12306 外包给阿里巴巴做是否可行“的问题，下班在公司班车上想到把12306网站最常用的用例(客户查询余票信息)，拆分成3个系统来完成，各系统可以集群部署的方法。

    我们一起分析下购买火车票的场景，个人来讲我比较喜欢12306，因为火车相对来讲是一个方便、快速、安全的交通工具。我平常台登录12306，一般购买“杭州”到“苍南”，如下图的查询页面

发现1月27号早上还有些剩余的票，主要是苍南的火车有20辆。客户查询火车票这个用例，查询条件包括出发地和目的地，结果包括车次、出发站、到达站、余票（当然还包括其它信息，但是这些信息对场景分析没有任何作用的）。我们可以把出发地、目的地作为唯一键，保存查询结果。我们再看看查询结果有什么特点，不同的车次有相同的出发地和目的地，唯一有变化的只有余票的数量。特定的出发地和目的地的客户查询火车票用例，可以说是没有任何变化的，我们对没有变化的数据定义为火车票查询模型，查询模型只有在新增车次、删除车次、修改车次时，它才会发生变化。我们可以正对查询模型可以做一个查询系统，我们可以根据不同出发地和目的地组合，来分配服务器部署系统，甚至可以相同的出发地和目的地集群部署。

我的想法是把客户查询火车票这个用例，让3个系统来完成（主站，查询系统，余票系统）。余票模型是主键是车次、出发站、到达站，车次决定出发站和到达站的组合。余票系统可以根据不同车次，来分配服务器部署系统，甚至可以一个车次做集群部署。

客户查询余票用例流程1，客户登录主站->打开查询页面->输入出发地和目的地->点击查询按钮->主站根据出发地和目的地向查询系统请求查询结果->主站根据查询结果里的车次、出发站、到达站向余票系统请求余票信息->最后主站把客户查询结果返回给浏览器。

客户查询余票用例流程2，客户登录主站->打开查询页面->输入出发地和目的地->点击查询按钮->主站根据出发地和目的地向查询系统请求查询结果->主站把客户查询结果返回给浏览器->流浪器根据查询结果里的车次、出发站、到达站向余票系统请求余票信息->余票系统把余票信息返回给浏览器。

转载于:https://my.oschina.net/dukous/blog/191463