做一个 12306.cn 这样的网站成本大概多少？

后端

从 502 的出错信息的只言片语猜测用的是 Nginx 。经 @王亚晖 提醒，服务器的前面使用的应该是低版本的 struts 。

502 说明问题主要集中在 web server ，压力还没有传递到数据库。说明虽然用了 Nginx ，但是负载平衡是否足够有效令人怀疑（铁道部不会连加几台服务器的钱都没有吧）。

这种构架，高并发和“开发成本”的关系并不密切：负载平衡的方案已经很完善了，负责的小公司也能做的很好，并不增加很多开发成本。

如果压力主要在数据库上就是另外一回事了， Oracle 的刀还是磨的很快的。不过，那时出现的错误一般是 505 。有各种优化设置，分库（更新／查询，业务／业务）等办法。

出现误扣款说明虽然报道使用了 Oracle ，但是事务管理可能并没有用好。另外，近几年实践的趋势是尽量避免使用数据库的事务管理。这方面做的比较完善的是基于 Java 的解决方案，比如 Spring 。这种构架可以有效降低成本。 12306 未使用或者有 Bug 。

综上所述， Java 的方案开发成本高一些。使用了 Oracle 也会增加不少成本。如果 真的 经历了完善的压力测试，测试上的成本也应该比较高。

后端的技术选择问题不大，但是构架和实现有问题，很可能无端增加了各种成本。没有具体的需求难以估计金额（比如列车相关数据的汇集方式如何？）

前端

前端的确惨不忍睹。

从页面看，使用的是 10 年前的技术，缺少针对超高并发的优化。本来，在超高并发的情况下，选择好的前端技术是减轻服务器压力的关键。（也是降低成本的关键之一）
（页面如果能减少一次请求，乘以 1 亿，服务器端减少的压力就非常可观了）

美工大概 900 块 rmb 一个月的水平，猪八戒上面的外包貌似都要更好些。

最后的话

当然，如果向下看齐还是很容易找优越感的，毕竟还有那么多明文密码的网站。

但是评价 12306 网站效能的指标，不应该是他抗住了多少 pv ，而是一天内到底完成了多少次有效查询？通过 12306 卖出了多少张票？（每天两百万张票，淘宝一个小时可搞定的交易量）

从这个角度考虑，成本本来可以压的比较低：专门为高并发搜索优化的解决方案配合负荷要求并不高的交易系统。

但是据说是花了上千万的。为何设计和实现的如此奇葩？ Google 一下 “12306 招标”。。。冷笑三声。