对铁路网站问题分析的博文

《对铁路网站问题分析的博文》由会员分享，可在线阅读，更多相关《对铁路网站问题分析的博文（14页珍藏版）》请在金锄头文库上搜索。

1、序言： 此文的撰写始于国庆期间，当中由于工作过于繁忙而不断终止撰写，最近在设计另一个电商平台时再次萌发了完善此文并且发布此文的想法，期望自己的绵薄之力能够给予各位同行一些火花，共同推进国内的大型在线交易系统的研发工作，本文更多地站在软件工程角度来看待整个问题，有关后续的技术问题研究，将在另外的博文中予以探讨。 一年一度的国庆大假刚落下帷幕，由于这次长假是历史上最长的一次，因此出行问题备受关注，而铁路出行作为最主要的出行方式更是大家讨论的热点，老生常谈的购票难问题又被提起。这几天我在网站上也看到很多关于 的讨论，很多网友都发表了自己对于铁道部购票网站的不满，更有很多同行讨论了关于 12306 网

2、站的设计问题，期待能够贡献自己的绵薄之力，我仔细拜读了其中至少 10 篇文章，很多同行多是站在技术的角度来考虑，其中不乏很多有创意的想法，纯粹的技术设计能解决一些问题，不过似乎不能够全面地解决这个庞大的、堪称瞬间流量“世界第一”的实时交易网站，目前 12306 的问题与其说是一个技术问题，还不如说它是个软件工程问题，道理非常简单，请看如下的新闻报导：回望 12306 网站在 2011 年 12 月底以来的表现，铁道部高层也直呼想不到。铁道部副部长胡亚东介绍，今年第一次在全国铁路实行网络电话订票，截至 1月 8 日已经达到每天 200 万张，12306 网站的注册用户已超过 1000 万人。1

3、月1 日至 7 日， “12306”网站日均点击次数已经超过了 10 亿次，专家认为瞬间点击可能达到了“世界第一” 。高度的关注、巨大的访问量，导致 12306 网站频繁出现系统崩溃、无法登陆、无法支付等情况。 “像春运这样庞大的需求量，难道铁道部没有预想到并有所准备？”隆梅资本管理有限公司副总经理马宏兴对此困惑不解。 在探究 12306 网站问题的深层原因以及解决之道时，各家看法不同，“12306 网站的问题最终还是系统架构的问题。因为用户有大量的动态、交互式访问，所有的请求都会发送到 12306 网站的服务器端，同时在线并发用户数量太多，导致网站无力承载，造成拥堵。 ”华南师范大学计算机学

4、院副院长单志龙认为。 又有说法认为，如果给 12306 网站增加服务器和带宽，也能够缓解拥堵的症状。这一观点铁道部内部颇为认同。 “得承认，我们对访问量估计得不足。 ”铁道部信息技术中心一位中层向记者透露，12306 网站曾在 2011 年春运期间试运行，高峰时段访问量约在 1 亿点击量，因此，信息中心估计 2012 年春运期间的访问量约在 3 亿至 4 亿。 但是，结果却大大出乎人们的预料。 “12306”网站在 1 月 9 日的日点击量达到14 亿次，是原来料想峰值的 5 倍之多。 “崩溃”在所难免！笔者连日来也萌发了一个想法，假如让我来设计 12306 网站，我作为总架构师，该当如何考虑

5、呢？自己虽然经历过众多的大项目的全生命周期跟踪管理，对于软件工程应该是有一定的研究，但像如此巨型项目，应该如何来设计、管控与实施？确实也颇伤脑筋，下面就笔者根据自己多年根植于 IT 研发的经验，特别是近年来对于巨型网站譬如国内的淘宝、京东等，国外的 Facebook、Google 等的跟踪研究经验谈谈自己的看法。 1. 需求分析阶段 需求分析是至关重要的，对于 12306 而言，需求分析的重点应该需要得出如下方面的关键数据才算需求分析基本结束： 终端用户方面的： 访问用户数量、总体注册用户数量、平时访问用户的峰值、平时访问用户的谷值、大假期访问用户的峰值、大假期访问用户的谷值、小假期访问用户的

6、峰值、小假期访问用户的谷值； 用户的地域分布性、用户可能介入的设备、用户接入的网络状况统计分析； 后台服务方面的： 关键购票流程业务分析： 购票的基本流程分析、一次购票的 TPS 数量分析、一次购票的用户流量分析、一次购票的用户静态流量分析、一次购票的用户动态流量分析； 这其中又分为初次购票与再次购票两种情况，流程稍微有些不同； 系统提供的其他服务统计分析； 前面所说的的大假在国内目前只有 2 个即春节与国庆，小假较多譬如清明、端午、中秋等。 对于用户访问用户数、流量、网络、后台的 TPS 数量能够建立一个数学预测模型那就非常的清晰了，对于后续的设计指导意义至关重要； 对于如此大的网站在安全性

7、方面的需求需要做重点调研，另外由于是实时交易网站，还需要考虑金融安全问题，安全方面还得从如下两个方面来全面考虑： 内部安全，主要关注资金以及交易的安全，特别是防止内部人员尤其是系统管理员； 外部安全，主要关注如何确保拒绝外部恶意入侵与攻击成为一个核心，特别是类似 DDOS 之类的攻击； 对照笔者的论述以及前面的新闻内容，不难发现，12306 的设计组非常明显没有充分深入地进行需求调研与数据模型分析，特别是预案设计，因此笔者才敢说这更是个工程问题，而不完全是个纯粹的技术问题。 2. 系统原型设计阶段 国内很多的软件公司不太重视原型设计，这点对于小软件开发无关紧要，可是一旦到了大型软件的开发之时，

8、不重视原型设计会失败得很惨，笔者曾经在后期救过一个 ITSM 管理系统的开发，究其原因，其中很重要的一条是对于原型设计不太重视，特别是在应用了大量的新技术而未进行原型设计是一件风险极大的事情，在笔者亲身带的几十个项目中有一部分就是这种情况，其中几个项目的痛苦经历（通宵达昼的加班长达 1-2 个月）更是令我终生难忘； 根据前面的需求方面的分析讨论，不难发现 12306 的原型设计中需要解决的问题如下： 前端 Web 服务器基于巨量访问的（秒均访问千万级别）可伸缩性模式验证： 这块可供选择的技术包括如下一些：基于 CDN 的 Internet 缓存加速技术、基于 Apache Server+JBo

9、ss(Weblogic)的组合服务不同的、基于不同接口的调用原型研究、请求排队技术等的原型研究； 后端数据库读写基于火车票应用的可扩展模式； 大家都知道，借鉴 Facebook 的巨量数据处理经验，必须基于现代数据库的分区技术、分布式处理技术并且通过后续的查询结果集成技术来实现巨量交易数据的可扩展性，基于巨量数据应用的可扩展模式通常有如下模式： 水平扩展技术，通常是基于分区技术来实施，维度是分区技术进行选择时的关键，针对于火车票的交易数据而言，时间维度是最好的选择，具体执行而言，可以将每天的车票交易信息放到某一分区上来执行，这样对于后续的数据维护（存储备份等）都将带来极大的方便； 垂直扩展技术

10、，通常是基于地域等实现的分布式扩展，针对于火车票的交易数据而言，如何将不同地域的车票、车次信息划归为不同的数据库服务器来执行，确保在数据交易上的广域可并行性； 对于 12306 系统，笔者建议最好能够按照列车始发与到达站的地域性进行垂直切割，而交易数据按照时间来进行横向水平扩展形成不同的子数据库，同时通过中间的缓存服务器、索引服务器、集成服务器将不同的数据进行地整合过来，提供给前端的应用服务器，因此从系统架构上来看这个结构图形如下3. 原型验证阶段 针对系统的原型设计，需要针对相应的子系统来验证原型的技术稳定性与成熟度，具体而言分别分为如下几段： 针对前端访问的巨量级别的 HTTP 负载均衡子

11、系统验证，特别是验证针对单个数据农场的服务响应能力，需要验证单个服务器的 HTTP 极限响应数量、动态扩展机制、网络带宽占用情况等； 针对中间访问的缓存子系统、索引子系统、集成子系统，需要验证依照前端的用户请求如何将连接到后端不同的数据库上进行相应的数据分布化集成服务； 针对后端访问的数据库垂直、水平切割技术，基于地域的垂直切割与基于时间的水平切割技术并且结合存储方面的分布式来扩充数据库系统的事务能力； 4. 系统正式设计阶段 正式设计整个系统时要考虑的设计方面还是挺多的，分别列出如下。 功能性设计： 前端 Web 服务器设计，可以按照 Apache 来负责静态页面响应处理、JBOSS/WEB

12、LOGIC 负责动态页面响应处理来进行设计，同时可以考虑将整个资源放到内存里面而使得 Apache 服务器对于静态资源的调用彻底离开磁盘 I/O 的制限，从而最大程度上提升前端 Web 服务器响应能力，这点笔者在一个游戏网站的后端服务器上曾经使用过，整体的 web server 响应能力提升了好几倍； 具体的业务设计需要依照个业务的流程来拆解实施，此设计的关键是在于将前段的业务如何能够跟后端的高度扩展的分布数据库能够集成对应起来； 后端数据库处理系统可以考虑按照如下的模式来予以完善设计： 将前段系统的运算分解与将各服务器进行（结果集成子系统） 、使用成熟的反向搜索引擎系统作为前端的车站查询系统

13、（搜索引擎子系统） 、中间基于车次的具体查询可以使用缓存系统来实现（缓存子系统） 、交易数据将写入到 RDBMS 之中（可水平、垂直扩展的事务处理子系统） ；这样设计的好处主要是将各种交易以及访问能够最大程度上的并行化，实现分布式集成化处理，从而最大程度上提升系统的整体处理能力； 存储子系统的设计： 主要是如何在 RDMMS 之间能够最大化各数据库的 I/O 处理能力同时提供不同地域（数据农场）的数据同步服务支持，同时对于从网络条件来看，建议将不同数据中心互联的光纤与用户请求的光纤分开了确保后端的数据同步响应不受前端的密集巨量请求服务之影响。 安全性设计： 前端的安全性设计主要包括防止诸如拒绝

14、访问攻击(DDOS)、脚本注入攻击、用户信息安全、系统入侵等，后端的安全性设计主要是要考虑账户信息、交易的安全等； 通常来说，前端可以考虑基于防火墙以及各种访问监测技术来做统计分析监控各种异常情况，而后端主要是基于数据加密、交易通道安全、数据库防篡改设计等来实施。 冗余设计： 包括依照地域、用户群建立不同的数据中心的设计、基于 DNS 区域解析规划设计、基于各服务器角色进行的冗余设计（WEB 服务器、搜索服务器、缓存服务器、集成服务器、数据库服务器、存储服务器等）所进行的数据的冗余设计，譬如常见的集群技术、热备以及热切技术等均可考虑在此应用； 其实笔者使用了中国国内的服务器以及美国的服务器分别

15、解析了 域名地址，显示了两个不同的地址，这已说明 12306 设计组已经考虑了这些内容：从美国 PING 将会发现： ping PING (183.60.136.64) 56(84) bytes of data.64 bytes from 183.60.136.64: icmp_seq=1 ttl=49 time=171 ms 64 bytes from 183.60.136.64: icmp_seq=2 ttl=49 time=171 ms 从上海 PING 将会发现： ping Pinging 211.144.81.22 with 32 bytes of data: Reply

16、from 211.144.81.22: bytes=32 time=11ms TTL=59 Reply from 211.144.81.22: bytes=32 time=10ms TTL=59 部署与维护设计： 部署设计的关键是确保各种角色的服务器如何能够实现快速复制扩展，在紧急需要时能够快速部署实施，同时对于服务器集群在进行升级时如何快速批量地更新整个执行包； 维护设计的关键考虑因素是系统运行的监控与报警系统设计，监控的指标就前端包括整个系统的访问数量、单个客户端的访问频率、访问的URL 分布等，后端需要监控的是各服务器的使用量、负载量同时以此进行上报到监控服务器来决定相应的服务器是否需要进行动态扩展； 5. 开发实施阶段 针对于此巨型交易系统的开发，在开发阶段的关键因素是代码品质控制，建议采用软件工程成熟的 C