Boot+Cloud项目学习：macrozheng.com
最近在知乎上看到这么一个话题，觉得挺有意思的，分享给大家！
原话题地址：zhihu.com/question/315887668
我们来看看知友们都是如何评价我国铁路订票系统的——也就是大名鼎鼎的 12306。会非常有意思。
先来看看这个 1.8 万赞的，我觉得说得非常有道理（狗头必须加上），所以也趁机点了赞。
我只能告诉你，12306，曾经出价10亿，如果不够，可以加，让他们稳固系统，保证大家订票不出问题，结果，全世界最顶尖的计算机团队，折腾几个月，最后结果是，可以解决，但是，解决代价嘛，就是，多加服务器
12306想了下，为了春运与那些节假日这几天，加服务器，不划算，后面也就算了，因为，这种行为跟面子工程差距真的不大 大不了这就，多请点维护人员，大家轮班。
这么说吧，火车站的电脑，需要最高权限，也就是，实时刷新，并且还要预留余票，因为，很多人，并没有网上订票的习惯 这是，基础设施，不能寒了这些人的心。
我国春运时期，用12306买票人数，估计有8亿，什么概念，并且，12306，保证所有人，没有出错！！！！！
这个水平，丢在国外，那就是神话！！！！
再加上，我们那些抢票软件，能够造成一个人刷新10-1000次的访问率甚至更高
也就说，如果这8亿每个人使用抢票软件，最高的刷新率，能够造成8000e的访问记录
然后访问出来了，要买票，这个买票这个动作。要同一时间，确认票，购买票，删除该票的存在（不能重复购买），而不是像双十一，你们先买，订单到了，我再确认仓库，再发货，这就错开了流量峰值
而12306，两个字，实时！！！
8000e，你问问腾讯，阿里，能不能承受！！！！再把这个数值乘上3，能不能搞定这么大流量
要保证不出错，已经很不错了，因为，如果同时买了同一张票，他会自动更改为其他位置，毕竟一个位置只能做一个人！！！
12306是全世界最强网站，没有之一！！！
这或许是一个对你有用的开源项目，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和 2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能！
- Boot项目：https://github.com/macrozheng/mall
- Cloud项目：https://github.com/macrozheng/mall-swarm
- 视频教程：https://www.macrozheng.com/video/
项目演示：
好多知友喷的：
- 你，为什么，要这样，说话。这样子，说话，看的，很难受
- 12306最难解决的是座位（库存）的架构和扣减的问题，瓶颈并不是在服务器上。如果您不是业内人士，最好不要误解他人哈。
但当我看到这些评论都是作者自己加精后，我似乎悟了，这分明是作者在钓鱼。。。。。
再来看看认真答题的，比如说 liujunsong：
非典那年机缘巧合之下，做了个哈尔滨铁路分局的信息化项目，当时从侧面了解了一些铁路订票系统的故事，因时日太久，到底是当时的真实记忆，还是想象补充，都已经无从考证，这里只是写出来仅供参考讨论。
首先以前在铁路信息化之前，票务系统可以说是一片混乱，由于铁路客票一票难求，因此有无数黄牛以此为生，客票是不记名的，也给黄牛带来了滚滚生利。当时采取的对策，主要是采取保留票制度，例如北京发上海的车票，假设有10个车厢，那么中间途径济南南京两个大站的话，那么就给济南站留一个车厢，给南京站留一个车厢，这两个车厢北京站只出售短途车票，不售卖到上海的。这种票务分配是基于政策的，各个车站之间没有联网，互不知晓。
到了90年代，哈尔滨铁路局主持开发了全国第一套基于sco Unix 的，使用c语言开发的票务分配系统，在主机上将客票按照规定的策略将一趟车的所有客票进行分配，就是将上面的逻辑用程序实现。同时各车站加入了抢票功能，先把自己可以售卖的车票抢下来，再按照需要售卖给外面等票的人。
这是一个划时代的成果，在当时的网络条件下，采用上下位之间的通讯，实现了针对车站的订票，售卖，退票功能。当然还有后续的结算功能等等。这套系统是基于小型机开发的。这里车站和票务中心的通讯不是实时的售卖，而是在指定时间点，各车站先把自己能发售的票抢出来，下载到自己的本地服务器上，再在自己这个服务器上一张一张出票，卖不掉的票可以在一定时间段退回去，或者根据…【人工调度命令】把票退回去。
当时听到这个故事的时候很震撼，但当时不懂东西太多，无法理解他们是怎么做到的。
后来到了2000年左右，由于微机价格低廉，应用系统开发到了cs阶段，上面这套系统升级到了cs阶段。客户端用的是pb或者vb ，数据库用的是sybase，中间件选用的是tuxedo. 当时见过这个售票系统的界面，应该是pb开发的。当时仍然采用的是分布式的部署架构，各铁路分局部署自己的售票系统，再通过服务器从总的票务中心下载票务数据，批量订票，再到各个车站出票。这时各个铁路分局所属的各个车站逐渐实现了内部联网。当时联网用的好像是adsl拨号技术。
这套技术应该说很稳定的运行了十几年吧。
至于全国大集中的12306系统出现。
与一般人的理解完全相反的是，各种应用系统其实一开始都是大规模分布式的，尤其这个整体票务系统，一开始是大概三层的票务系统，铁道部一层，各铁路局一层，分局一层，车站一层。各层之间进行数据包传递来协同工作。这个和银行系统也有类似之处。
后来随着信息化的扩展，大约用了二十年的时间完成了大集中。银行业大约是2000年左右实现了全国大集中，央行大约是2010年完成了大集中，代表成果就是二代支付系统，大小额接入系统这些。而铁道部的大集中基本上是在12306之前就完成了，大约也是那个时代的产物。
中国的信息化有着自己鲜明的特色，就是大集中。这个有着行政上执行便利的考虑，也有人们思维惯性的考虑，这里就不细说了。
从这个意义上来讲，只有在中国现有的条件下，才有可能建立一整套的大集中系统，而这在其他地方是不具备条件的。
别的不说，光客票系统直接和公安的人口信息系统连接，在很多国家都是不可能完成的任务。因为绝大部分国家根本没有完整的户籍管理制度。
想当年也是20年前了，曾经接触过一次飞机票的代理系统，当时每个代理点需要拉一条专线到航空公司的票务中心，然后利用telnet登录上远程终端。通过在终端输入命令，来完成飞机票的订票交易。当时订票的逻辑就是先可以锁定一张机票，然后再进行一次确认，或者把这张票退掉，如果超过锁定时间，可能会被强制退掉。这样就有以下几个交易代码：查询，预订，确认，取消。这套票务系统是全球通用的，后台是一套大机系统，然后通过层层分布的前置机推广到全球来使用。这套系统的开发时间，应该是上世纪七八十年代了。
那次交流的时候，订票点给我们详细介绍了飞机票的订票全流程。因此在后来又听别人介绍火车票的订票流程的时候，才有这样的共同点存在。
现在的人一想到票务系统，出于惯性会认为那个系统一定是基于数据库的，然后就掉到事务，数量这些细节里面了，不能自拔。其实最早期的票务系统是基于文件和报文来处理的，那时可能都没有成熟的数据库系统存在，因此也就不存在现在困扰大家的数据一致性问题和事务管理问题。而如果是完全基于文件系统来设计和开发票务系统，那就会走向完全不同的一个架构体系了。
其实，12306 牛逼主要有以下三点：
印象中，总以为是阿里的淘宝团队改变了 12306，似乎是阿里团队的技术太牛逼，所以改变了 12306 经常崩掉的局面。但看了这些回答，我才发现，原来中国计算机领域最牛逼的还是通信部和铁道部。
据知友所说，国铁集团下属的铁科院电子所，领军的牛人叫单杏花，是 12306 的最强大脑。
所以说，小伙伴们有机会的话，可以考虑考虑铁科院电子所。
Github上标星11K的微服务实战项目mall-swarm，全套 视频教程（2024最新版） 来了！全套教程约26小时，共59期，如果你想学习目前最新的微服务技术栈，同时提高自己微服务项目的开发能力的话，不妨了解下，下面是项目的整体架构图，感兴趣的小伙伴可以点击链接 mall-swarm视频教程 加入学习。
整套 视频教程 的内容还是非常完善的，涵盖Spring Cloud核心组件、微服务项目实战、Kubernetes容器化部署等内容，你也可以点击链接 mall-swarm视频教程 了解更多内容。
推荐阅读
