一年一度的国庆大假刚落下帷幕，由于这次长假是历史上最长的一次，因此出行问题备受关注，而铁路出行作为最主要的出行方式更是大家讨论的热点，老生常谈的购票难问题又被提起。这几天我在网站上也看到很多关于12306.cn的讨论，很多网友都发表了自己对于铁道部购票网站的不满，更有很多同行讨论了关于12306网站的设计问题，期待能够贡献自己的绵薄之力，我仔细拜读了其中至少10篇文章，很多同行多是站在技术的角度来考虑，其中不乏很多有创意的想法，纯粹的技术设计能解决一些问题，不过似乎不能够全面地解决这个庞大的、堪称瞬间流量“世界第一”的实时交易网站，目前12306的问题与其说是一个技术问题，还不如说它是个软件工程问题，道理非常简单，请看如下的新闻报导：

[[[回望12306网站在2011年12月底以来的表现，铁道部高层也直呼想不到。

铁道部副部长胡亚东介绍，今年第一次在全国铁路实行网络电话订票，截至1月8日已经达到每天200万张，12306网站的注册用户已超过1000万人。1月1日至7日，“12306”网站日均点击次数已经超过了10亿次，专家认为瞬间点击可能达到了“世界第一”。

高度的关注、巨大的访问量，导致12306网站频繁出现系统崩溃、无法登陆、无法支付等情况。

“像春运这样庞大的需求量，难道铁道部没有预想到并有所准备？”隆梅资本管理有限公司副总经理马宏兴对此困惑不解。

在探究12306网站问题的深层原因以及解决之道时，各家看法不同，“12306网站的问题最终还是系统架构的问题。因为用户有大量的动态、交互式访问，所有的请求都会发送到12306网站的服务器端，同时在线并发用户数量太多，导致网站无力承载，造成拥堵。”华南师范大学计算机学院副院长单志龙认为。

又有说法认为，如果给12306网站增加服务器和带宽，也能够缓解拥堵的症状。这一观点铁道部内部颇为认同。

“得承认，我们对访问量估计得不足。”铁道部信息技术中心一位中层向记者透露，12306网站曾在2011年春运期间试运行，高峰时段访问量约在1亿点击量，因此，信息中心估计2012年春运期间的访问量约在3亿至4亿。

但是，结果却大大出乎人们的预料。“12306”网站在1月9日的日点击量达到14亿次，是原来料想峰值的5倍之多。“崩溃”在所难免！]]]

笔者连日来也萌发了一个想法，假如让我来设计12306网站，我作为总架构师，该当如何考虑呢？自己虽然经历过众多的大项目的全生命周期跟踪管理，对于软件工程应该是有一定的研究，但像如此巨型项目，应该如何来设计、管控与实施？ 确实也颇伤脑筋，下面就笔者根据自己多年根植于IT研发的经验，特别是近年来对于巨型网站譬如国内的淘宝、京东等，国外的Facebook、Google等的跟踪研究经验谈谈自己的看法。

1. 需求分析阶段

需求分析是至关重要的，对于12306而言，需求分析的重点应该需要得出如下方面的关键数据才算需求分析基本结束：
终端用户方面的：

访问用户数量、总体注册用户数量、平时访问用户的峰值、平时访问用户的谷值、大假期访问用户的峰值、大假期访问用户的谷值、小假期访问用户的峰值、小假期访问用户的谷值；

用户的地域分布性、用户可能介入的设备、用户接入的网络状况统计分析；

后台服务方面的：

关键购票流程业务分析：

购票的基本流程分析、一次购票的TPS数量分析、一次购票的用户流量分析、一次购票的用户静态流量分析、一次购票的用户动态流量分析；

这其中又分为初次购票与再次购票两种情况，流程稍微有些不同；

系统提供的其他服务统计分析；

前面所说的的大假在国内目前只有2个即春节与国庆，小假较多譬如清明、端午、中秋等。

对于用户访问用户数、流量、网络、后台的TPS数量能够建立一个数学预测模型那就非常的清晰了，对于后续的设计指导意义至关重要；

对于如此大的网站在安全性方面的需求需要做重点调研，另外由于是实时交易网站，还需要考虑金融安全问题，安全方面还得从如下两个方面来全面考虑：

内部安全，主要关注资金以及交易的安全，特别是防止内部人员尤其是系统管理员；

外部安全，主要关注如何确保拒绝外部恶意入侵与攻击成为一个核心，特别是类似DDOS之类的攻击；

对照笔者的论述以及前面的新闻内容，不难发现，12306的设计组非常明显没有充分深入地进行需求调研与数据模型分析，特别是预案设计，因此笔者才敢说这更是个工程问题，而不完全是个纯粹的技术问题。

2. 系统原型设计阶段

国内很多的软件公司不太重视原型设计，这点对于小软件开发无关紧要，可是一旦到了大型软件的开发之时，不重视原型设计会失败得很惨，笔者曾经在后期救过一个ITSM管理系统的开发，究其原因，其中很重要的一条是对于原型设计不太重视，特别是在应用了大量的新技术而未进行原型设计是一件风险极大的事情，在笔者亲身带的几十个项目中有一部分就是这种情况，其中几个项目的痛苦经历（通宵达昼的加班长达1-2个月）更是令我终生难忘；

根据前面的需求方面的分析讨论，不难发现12306的原型设计中需要解决的问题如下：

前端Web服务器基于巨量访问的（秒均访问千万级别）可伸缩性模式验证：

这块可供选择的技术包括如下一些：基于CDN的Internet缓存加速技术、基于Apache Server+JBoss(Weblogic)的组合服务不同的、基于不同接口的调用原型研究、请求排队技术等的原型研究；

后端数据库读写基于火车票应用的可扩展模式；

大家都知道，借鉴Facebook的巨量数据处理经验，必须基于现代数据库的分区技术、分布式处理技术并且通过后续的查询结果集成技术来实现巨量交易数据的可扩展性，基于巨量数据应用的可扩展模式通常有如下模式：

水平扩展技术，通常是基于分区技术来实施，维度是分区技术进行选择时的关键，针对于火车票的交易数据而言，时间维度是最好的选择，具体执行而言，可以将每天的车票交易信息放到某一分区上来执行，这样对于后续的数据维护（存储备份等）都将带来极大的方便；

垂直扩展技术，通常是基于地域等实现的分布式扩展，针对于火车票的交易数据而言，如何将不同地域的车票、车次信息划归为不同的数据库服务器来执行，确保在数据交易上的广域可并行性；

对于12306系统，笔者建议最好能够按照列车始发与到达站的地域性进行垂直切割，而交易数据按照时间来进行横向水平扩展形成不同的子数据库，同时通过中间的缓存服务器、索引服务器、集成服务器将不同的数据进行地整合过来，提供给前端的应用服务器，因此从系统架构上来看这个结构图形如下：

3. 原型验证阶段

针对系统的原型设计，需要针对相应的子系统来验证原型的技术稳定性与成熟度，具体而言分别分为如下几段：

针对前端访问的巨量级别的HTTP负载均衡子系统验证，特别是验证针对单个数据农场的服务响应能力，需要验证单个服务器的HTTP极限响应数量、动态扩展机制、网络带宽占用情况等；

针对中间访问的缓存子系统、索引子系统、集成子系统，需要验证依照前端的用户请求如何将连接到后端不同的数据库上进行相应的数据分布化集成服务；

针对后端访问的数据库垂直、水平切割技术，基于地域的垂直切割与基于时间的水平切割技术并且结合存储方面的分布式来扩充数据库系统的事务能力；

4. 系统正式设计阶段

正式设计整个系统时要考虑的设计方面还是挺多的，分别列出如下。

功能性设计：

前端Web服务器设计，可以按照Apache来负责静态页面响应处理、JBOSS/WEBLOGIC负责动态页面响应处理来进行设计，同时可以考虑将整个资源放到内存里面而使得Apache服务器对于静态资源的调用彻底离开磁盘I/O的制限，从而最大程度上提升前端Web服务器响应能力，这点笔者在一个游戏网站的后端服务器上曾经使用过，整体的web server响应能力提升了好几倍；

具体的业务设计需要依照个业务的流程来拆解实施，此设计的关键是在于将前段的业务如何能够跟后端的高度扩展的分布数据库能够集成对应起来；

后端数据库处理系统可以考虑按照如下的模式来予以完善设计： 将前段系统的运算分解与将各服务器进行（结果集成子系统）、使用成熟的反向搜索引擎系统作为前端的车站查询系统（搜索引擎子系统）、中间基于车次的具体查询可以使用缓存系统来实现（缓存子系统）、交易数据将写入到RDBMS之中（可水平、垂直扩展的事务处理子系统）； 这样设计的好处主要是将各种交易以及访问能够最大程度上的并行化，实现分布式集成化处理，从而最大程度上提升系统的整体处理能力；

存储子系统的设计：

主要是如何在RDMMS之间能够最大化各数据库的I/O处理能力同时提供不同地域（数据农场）的数据同步服务支持，同时对于从网络条件来看，建议将不同数据中心互联的光纤与用户请求的光纤分开了确保后端的数据同步响应不受前端的密集巨量请求服务之影响。

安全性设计：

前端的安全性设计主要包括防止诸如拒绝访问攻击(DDOS)、脚本注入攻击、用户信息安全、系统入侵等，后端的安全性设计主要是要考虑账户信息、交易的安全等；

通常来说，前端可以考虑基于防火墙以及各种访问监测技术来做统计分析监控各种异常情况，而后端主要是基于数据加密、交易通道安全、数据库防篡改设计等来实施。

冗余设计：

包括依照地域、用户群建立不同的数据中心的设计、基于DNS区域解析规划设计、基于各服务器角色进行的冗余设计（WEB服务器、搜索服务器、缓存服务器、集成服务器、数据库服务器、存储服务器等）所进行的数据的冗余设计，譬如常见的集群技术、热备以及热切技术等均可考虑在此应用；

其实笔者使用了中国国内的服务器以及美国的服务器分别解析了12306.cn域名地址，显示了两个不同的地址，这已说明12306设计组已经考虑了这些内容：

从美国PING将会发现：

ping www.12306.cn

PING 08911.xdwscache.glb0.lxdns.com (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 www.12306.cn

Pinging 08911.xdwscache.glb0.lxdns.com [211.144.81.22] with 32 bytes of data:

Reply 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. 开发实施阶段

针对于此巨型交易系统的开发，在开发阶段的关键因素是代码品质控制，建议采用软件工程成熟的Coding->Review->UT控制技术（基于TDD的开发模式）来完成个模块以及集成子系统的品质管控，在此特别提醒的是对于Review、UT段的密度需要做硬性的规定，流程裁剪时建议采用高密开发模式确保此阶段的品质管控目标，在此不得不多说一句的是很多时候很多的公司、开发人员总是错误地认为这些流程过于复杂，浪费时间，其实从各种实际的项目实施经历来看，此处多花了2-3倍的开发时间可以避免后续5-10甚至数十倍调试时间(Bug fix)的投入，整体上来算还是非常值得的，对于大型项目尤其如此，笔者在很多大型项目的集成阶段碰到集成不畅、无法按时完成集成任务时，开发、测试人员都是通宵达昼地加班，这其中很多的工作都是无用功，何不在开发实施阶段将系统的测试密度进行加大呢？构建质量上更好的组件（部件、模块），这样到集成的时候就不手忙脚乱了。

由于此系统的规模非常大，因此在详细设计、开发时，应该考虑到各子系统必须设计得非常易于测试，特别是易于进行单体测试与自动化测试，这点可以大幅降低项目的执行成本;

6. 测试阶段

对此巨型系统的构建完毕后需要经历子系统集成测试、系统总集成测试两个阶段，并且需要按照如下不同的测试种类来进行逐个测试确认：
功能测试、性能测试、安全测试、破坏性测试、持久运行能力测试等

功能测试需要针对多服务器角色集成后按照设计所提供的功能清单依据测试密度以及测试的分布性来确定不同方面的测试case，依据此来分步执行此功能测试，并且依照测试执行的结果来分析各个模块的缺陷密度以及缺陷的消化曲线，以此指导后期的开发设计工作，并藉此可尽快完成功能方面的验收确认；

性能测试针对这个案列相对比较复杂，由于服务器角色很多，其基本的思路还是分析确定前端各业务的使用比例，编写开发自动化测试脚本来模拟用户的操作行为，并且在测试环境下针对特定的服务器数量的集群发起服务请求，同时完整地检测每个角色服务器的CPU/Memory/Disk I|O/Network方面的性能参数值，通过不断增减客户端请求数（伴随客户端机器的增加、譬如初期使用100台，逐步增加到200台测试机）来观察服务器的性能反应，分析出拐点，同时需要测试出系统的极限吞吐量(RPS,TPS等值)，并且测试出增加不同的服务器角色对于这些吞吐量的影响，同时在此阶段需要开发人员的协助来针对不同的角色根据测试结果进行性能调优工作；

安全测试，需要针对以下不同的场景进行模拟攻击测试：

外部安全而言： 包括脚本注入攻击、端口扫描、拒绝服务攻击、主机入侵等安全测试都需要逐个进行验证，确保系统的外部安全；

内部安全而言： 包括各服务器的数据的安全、密码安全等进行测试；

破坏性测试，需要就各个角色服务器所对应的物理服务器进行不同部位失效、移除等试验，看看整个服务器集群的监控、维护服务以及服务输出吞吐的影响，并且完善后续的各种系统对应的维护流程；

持久运行能力测试需要，待系统达到Beta测试版本要求之后，需要针对待部署的系统进行一定负载量持续运行至少2周以上，并且观测系统的稳定性方面的反应，同时就数据库的增长、日志的增长等各种情况进行综合评估并且需要结合后续的部署维护做适当完善性调整；

7. 部署阶段

对于如此巨型系统的部署调试工作，也是个不大不小的工程，那么如何确保部署调试工作进展的顺利，根据笔者多年维护广域网系统的经验，有如下几点需要注意：

-> 如何管理好不同的服务器之间的发行版本问题，确保发布不会乱，特别是小版本的升级上部署不会乱是个关键，否则对于数以千计的服务器那绝对是个灾难；

->如何能够快速解决单次发布的升级与回退问题同样是很重要，这当中笔者的经验是使用一个经过验证的发布部署流程以及校验流程，整个过程最后放在一个发布脚本中，对于具体的升级与回退，维护人员只需要执行一次命令即可完成，并且对于每个版本发布完毕后的校验工作尤其重要，必须在脚本中予以体现；

->最后一点对于部署而言，任何部署都必须要有回滚方案配套，确保任何时间点上系统皆可用；

8. 运行维护阶段

在运行维护阶段有很多细节需要配套考虑：

->系统整体的实时状态监控，包括各种角色的应用主机的监控、网络设备的监控、用户访问流量的监控、服务可用性监控、安全监控等；

->系统巨量的交易数据转储、交易日志的转储问题， 这个问题的解决需要结合前面在设计时的 数据库垂直（按时间维度）扩展以及日志按照天的维度来进行维护的方式进行有计划地转储到不同时间段的历史库中，并且通过数据的清洗、整理将部分重要数据转入到OLAP/OLTP系统中，为后续系统基于实时交易数据的联机分析改进业务提供帮助；

9. 优化阶段

->业务流程优化：这块最主要的问题是将购票这个核心业务按照计算机易于执行计算的模型来进行不断地优化，同时体验，譬如异步事务提交优化、排队技术等皆可以使用在用户的模型上，同时可以向用户提供预订业务等来降低某个时段的网站流量压力，使得流量的整体峰值、谷值差距缩小很多；

>架构设计优化：在数据库的分区（垂直、水平分区）方面不断地进行优化，同时对于单数据库，就事务处理能力方面进行优化存储方面的操作，譬如使用固态硬盘替代传统的SCSI盘等，并行虚拟写技术等大幅提升磁盘I/O操作能力、或者采用内存数据库技术来管理好读写分离（读自内存、写到内存与磁盘同时），这样可以在数据库层面上获得性能的大幅提升；如果能够配合系统压力测试模型来获取其性能衰减曲线图针对性地优化，其效果将更加明显；

在中间层服务器上，如何将不同的车次分布在大小几百个数据库上，并且使用反向搜索引擎技术来连接前端的访问请求到后端的数据库服务器之间的映射与集成（这点可以参考MapReduce并行算法）；

在应用层服务器上，如何将静态内容与动态内容予以剥离，并且无需保存的内容（只读）内容全放在内存中，如何平衡CDN加速与后端Web server的服务架构也是不断提升单个农场集群服务能力的关键与核心；

->性能优化： 这些优化是非常之多的，譬如针对Web server的socket连接池优化、日志优化，针对中间集成服务器的并行任务分解与结果集成优化，基于后端数据库服务器的数据计算模型、访问方式、冗余与数据同步、传递优化、数据分区优化等；

->其他调优：其他方面的调优譬如基于监控的优化、基于大并发量的快速响应与扩展优化等等；

写到此，感觉上似乎已经设计完毕了，不过突然回头一望，还真发现内容非常之多，可能有实战经验的朋友肯定会提到此系统属于“过度设计”了，不过笔者在此要说的是，确实这个最后的提醒是非常有必要的，任何系统的设计特别是如此复杂的系统的设计只能是需要通过时间来循序渐进，先原型后实际系统并且遵循几轮研发调优（含架构设计调优），最后逐渐演变到一个真实成熟的系统，任何超前的设计最终都被证明是无用功而遭废弃；

很多的网友对于12306的网站的技术议论纷纭，并且提出了众多的创造性想法，笔者在提出自己的想法后还有几点补充想法供大家参考：

1. 其实此网站的需求不是一个纯粹的技术问题，试想一下，真的按照国庆、春节的高峰访问需求来设计、部署整个系统的时候，在平时的时候大部分机器都是浪费的，如何平衡峰值与谷值时矛盾是个技术问题，可背后掩盖着的是全中国13亿多人口在短短的10-15天内完成众多的人口迁徙，如此巨大的工程放在任何一个国家都是难于解决的问题，如何从需求层面来化解这个短期内的巨量人口流动问题才是此问题的命根； 正所谓 “ 解决火车票购买过程容易，而解决人人能买到火车票难！！！”

2. 此问题的求解永远是个迭代过程，需要看到的是很难有人能够在短期内设计并且实现这么一个巨量系统，这个工程问题的求解是拆解为不同的子模块来分步实现，并且逐步迭代优化求解的过程；

3. 此问题的解决必须是个系统工程，牵涉到资金、技术、人才、时间 这4个基本要素，很多的同行过于看重人才与技术，而忽略了资金等前提性因素，试想如果只有3000万预算让你来设计实现这个巨型交易系统，你能解决么？ 不说别的，光性能模拟测试就需要调动数以万计的前端机器来在全国范围内不同的典型区域发起海量请求，这些是个小资金能够解决得了的问题么？

后记： 笔者深知，任何技术的讨论必然会引起一些争议，整个技术的发展必须要经历这样的纷争才能进步与提高，在此博文发布的几天内，备受各位同行的关注，笔者非常感谢，也发现了诸多不友好的言辞， 对于有类似架构经验、大项目经历的同行一看就明白，而无此经历的同行看起来相对比较而言没有感觉，笔者在此期望技术纷争的同行不要爆粗，大家共同的目的是为了推动技术交流，推动你我的技术进步，推动国家与民族的技术发展

需求分析是至关重要的，对于每个系统而言，需求是生命线，是一切后续工作的源头，笔者在大量的项目实践中发现成功的项目往往在需求定义上相对比较清晰，双方的沟通很顺畅，而死搅难缠的项目往往在需求阶段就能发现苗头，沟通上也困难重重，从某种意义上来讲，一个系统的开发其实就是系统开发商与客户的一次“恋爱”行为，系统从某种程度上就是双方“恋爱”的结果，能否有好的结果，取决于双方是否投入了充足的精力，是否有高度统一的认识以及一致的协调配合，在这里笔者个人非常反对如下两种片面的认识

->系统开发是开发供应商（俗称“乙方”）的事情。这种思路在客户（“甲方”）中很普遍存在，甲方很多时候都认为签好合同付好钱后就等待系统上线了，这个对于跨行业过来对IT几无了解的客户存在得极为普遍，其实客户在整个过程中起着极为关键的作用，可以毫不夸张地讲，一个系统的成功是甲方的成熟度+乙方的成熟度的和值能够达到成熟的结果。

->需求是调研出来的，这种思路在开发商（“乙方”）中普遍存在，开发人员总是认为需求应该是客户的事情，这些认识都是片面与有害的，需求来源于调研，但又要基于现实的模型进行适度的优化并且设计后的出来的结果，这个也是很多系统失败的一个极为重要的原因，毕竟电脑系统的操作跟纸张操作模型存在着巨大的差距。

很多的项目经理，做了很多年的项目，然而对于需求的重要作用，依然认识不清，当项目成功的时候，归于客户“好说话”，当项目碰到困难或者失败的时候，归于客户“不讲道理”，当然鉴于国内目前的信息业现状，我们只能说应用科学合理的管理方式来提高项目的成功概率，但确实无法保证项目百分之百成功。

笔者认为，为了确保一个项目的需求阶段能够取得成功，如下方面是必不可少的：

a. 合同中有关工作任务的定义，即俗称的SOW定义必须很清晰，很多的开发公司的合同在这块定义极度不清晰，笔者见过的最极端的例子就是只有寥寥数语来简单介绍此合同对应的工作范围，如果各位有幸碰到这样的合同，唯一能做的就是紧紧拉住客户关系，烧香拜佛了，乞求客户控制需求欲望了，不要将一个几十万的MIS系统演变为一个数百万的ERP系统了。 那什么样的定义才能称为清晰的范围定义呢？ 笔者认为必须满足如下标准：

-> 流程定义清晰，板块划分明确； 如果无法划分的部分建议不要放到合同中，否则害人也害己；

-> 角色分明，功能点定义明确；如果都不知道有几个用户需要使用此系统，那角色定义以及功能点定义肯定就是一塌糊涂；

-> 必须量化每个功能点，建议大家使用业务信息字段数量以及页面数量、流程数量、报表数量的定义放到此SOW，量化是最好的去模糊手段；

b. 定义好项目的管理组织结构，梳理好双方的项目管理组织结构，建立通畅的项目沟通渠道，并且将决策人员在关键点确认上必须予以加入，此处理论上很好解释，实践中的难处在于如何真实地确定这些实际的内容，笔者的建议是直接咨询付款决定人由他/她来直接告诉你这个结构是最为合适的；

c. 控制好需求确认流程以及需求变更流程，并且严格形成文档， 此处的流程与文档是需求的关键环节，很多的年轻项目经理，由于阅历比较浅，总是依赖于口头上的确认，以至于日后发生争执时，只能顿足捶胸地说，悔当初没能记下来这个那个；其实严格的流程是保证效率的关键，而文档是证据管理的根子，同时证据管理又是项目管理的关键环节，忽视证据管理的项目管理失败是在所难免的；

d. 跟客户的干系人必须讲清楚项目的最终目标是什么，很多时候这些关键控制人总是热衷于尽力提需求，总是尽力将系统变为一个尽善尽美的系统，这个时候必须得统一大家的思路，双方的目标不是构建尽善尽美的系统，而是构建一个可用、适用系统，能够满足大多数目前能够看到的清晰需求（在合同当中严格定义过的系统），另外特别需要强调的是，尽善尽美的系统本来就不存在，人类对事物的认识总是按照哲学规律在逐步深入的，此处笔者常用的例子就是乔布斯做iPhone与iPad，在此之前他失败过多少回，何况iPhone/iPad也经历了这么多代，如果他老人家能构造一个近乎完美的iPhone，哪儿还来iPhone3, iPhone4, iPhone5这么多代的发展呢？

结合本文的主题，假如我来架构12306网站，如何来实施需求调研工程呢？笔者根据自己的经验，大体可以分为如下几方面：

功能需求：

从12306设计的功能角度来看，主要需实现如下2大块业务：

主营业务需求： 此处包含了如下几个大块的基本需求。

客运服务需求，此处系统需求的核心是构建一个以用户为中心，围绕用户在铁路旅行方面的服务需求来进行展开的各项服务，其基础服务包含如下几块：

出行服务： 用户注册、车票预订、退票服务、余票查询、列车时刻表查询、车次查询、发到站查询、票价查询、中转查询、车站经过、车次查询、起售时间查询、正晚点查询、客票代售点、铁路旅程规划等；

接行服务： 车次查询、列车时刻表查询、发到站查询、正晚点查询、旅客信息查询、列车信息、乘务服务信息查询、接行信息服务等；

托运服务： 提供货物交运、状态监控、到站提取、安全保证服务等；

用户支付服务： 便捷支付（主流银行以及网银支付）、支付账单、对账查询、退款、支付投诉等各种支付服务；

货运服务需求，此处系统需求的核心是构建一个以服务于货运主的货运需求为核心的各项服务，其基础服务包含如下几块：

货运服务：其中包含整车、散货、小件物品运输业务办理、跟货运相关的理赔业务的办理等；

货运信息服务：其中包含货运路线、车辆运输参数、运输能力、运价、保价、运输时刻信息、货物安全保障信息、运输方案等各种运输信息服务，其目的是帮助货主寻求合适的运输方案，提供便捷的货运服务；

支付服务： 企业支付服务（含线上与线下支付服务），个人支付服务、支付安全等；

信息发布需求，此处提供是铁路运输相关的各类法律、法规、发文、消息、新闻等各类信息；

后台管理需求，包含如下几部分：

客运管理后台，提供各类客运相关的基础数据譬如列车班次信息、时刻表信息、票价信息、车票分配策略调控、列车运行时刻信息、各种起售时刻信息等；

货运管理后台，提供各类货运相关的基础数据譬如列车的车辆运输参数、线路信息、运力、运能、时刻、运价等各类跟货运相关的信息；

信息发布管理后台，提供跟铁路运输相关的各种法规、规程、信息集装、新闻、公告信息等的录入、维护等；

各类角色的管理，提供各种级别的角色管理，并且这些角色还需要跟各列车车次以及路局等直接相关联；

其他系统级别的后台管理服务，譬如用户管理、用户投诉、角色管理、系统维护服务、系统监控服务等；

增值业务需求：

目前的12306网站暂时不提供此类业务，但笔者认为凭借着铁路在全国齐全的路网以及运价、运能的优势，在中长途的货物运输上面，公路以及民航几乎无力与其进行全面竞争，因此此处的增值业务还是大有作为的。

物流增值服务： 考虑到铁路的布局全面性，因此建设现代化的大型物流基地，培养形成一批网络化、链条化、规模化、具有知名品牌的大型现代物流企业，为目前的货运服务提供延伸的现代物流服务而不仅仅局限于铁路运输服务是非常有切入价值的，此块增值业务为其最大的增值服务；

电子商务服务： 由于铁路几乎掌握全国70%以上的大宗货物运输服务，因此对于供需双方的信息以及货物信息以及季节性具有非常强的全局掌握性，由此引发的信息匹配增值服务也可以极大地服务于各大型制造、物流、贸易类型的企业，由此而引发的各类电子商务增值服务也是独具天然优势的；

其他类型的增值服务： 针对服务的个人、企业等提供各类增值服务，譬如各类出行方案挖掘、VIP服务、运输类数据挖掘带来的运输方案优化等各类增值服务将极大地带动铁路的运营活力的发挥，同时为铁路带来大量的增值收益。

性能需求：

精度方面的需求： 其中包括了用户的数据精度，特别是时间、金额、密码等重要敏感数据的精度要求以及各类计量规则方面的需求（含四舍五入规则等），依照铁道部的要求制定出相应的精度方面的要求；

响应时间与时间特性方面的需求： 由于此系统服务的用户数量非常巨大，初步估算都是在数千万并发用户级别，并且考虑到后面的交易系统依然沿用了诸多旧的交易系统，因此在响应时间方面过去的基于TPS的计算模型比较难于精确地预估到在响应速度方面的需求，此处笔者建议通过原型系统的演绎方式来做，具体地来说先投入一部分资金依照目前的核心业务需求开发出一个原型交易系统，依照铁道路内部的系统架构来部署一个小型测试系统（譬如20台服务器规模）实施测试，然后做适量的服务器增减来测算CPU/Memory/Disk IOPS/Network bandwidth与用户数量的变化关系曲线图来测试用户的响应时间等方面的需求，逐步求精，但在实际的用户需求规划时依然需要坚持平时用户的单个页面响应速度<2秒，高峰时<5s这样的计算与设计标准，达到优良的用户体验；

安全性需求：

外部安全需求

防黑客入侵，需要防止黑客从外部入侵的如下几种手段：

用操作系统以及防火墙的漏洞等进行入侵获取高级别的权限；

利用特洛伊木马程序来感染并且获取系统的高级别权限或者窃取敏感的交易数据；

口令猜测，通过暴力破解以及字典攻击等方式来实施管理员口令猜测，以期实现对系统的入侵；

缓冲区溢出攻击技术；

扫描探测技术；

防拒绝服务攻击(DDOS)，多人同时向主机提出Web请求，在流量到达一定的程度之后导致系统无法为真实正常的用户提供访问服务；

防页面注入攻击，通过HTML、Javascript、SQL等人为地构造计算逻辑来攻入系统导致系统的崩溃或者数据异常；

防IP伪装技术，通过截获、分析数据传送包来分析同时构造新的数据包发送到服务器来实施攻击；

内部安全需求

防止数据丢失与被盗的安全机制，需要杜绝生产环境下的数据丢失以及被盗，建立起一整套数据的储运、销毁等的数据安全保障机制；

防止管理员密码遗失与被盗的安全机制，对于管理员密码，必须以一定强度的加密格式予以安全存放，同时建立严格的管理制度，禁止管理员私自将自己的密码在未经流程许可的前提下告知他人等行为发生，避免密码的传播与遗失、被盗等情形；

防止交易数据篡改，特别是要防止超级管理员（含应用管理员与数据库管理员）在未经许可的流程下私自篡改系统数据，另外更改数据的行为系统都要有可以审核的记录，特别是账户与交易信息必须具备修正历史可供查阅；

高可用性方面需求（HA)： 可以确定的是在高可用的规划方面，应该将此系统的定位确定在7*12小时的可用度在99.9%这个级别，用户的系统可访问度定义在95%以上，这样整体的高可用能够达到大多数用户的心理预期。

系统接口方面的需求：12306系统由于关联了众多的铁路局的内部管理系统以及调度系统，另外也关联了众多的支付接口，因此系统的接口部分内容极为众多，大体上按照性质可以划分为两个大类 即内部系统接口以及外部系统结构，另外按照提供与调用的关系 分为12306提供给其他系统的接口与调用其他系统的接口， 对于提供接口，需要明确接口标准，建议采用Restful格式来提供给其他系统并且对于普通信息可以走HTTP通道，而交易信息必须走HTTPS通道来实施，对于调用其他系统的接口将依照既有系统的接口形式来逐个细化实施；

软件的其他部分需求： 其他方面的需求主要包括如下几块：

运行环境方面的需求： 这当中包括了服务器端的硬件环境（服务器）、软件环境（操作系统、数据库、应用服务器、中间件）、网络环境（包括数据中心的布局以及分布式设计、网络连接以及容量设计）等方面的需求；另外对于客户端，需要明确指出支持的浏览器的种类以及版本、需要安装的安全组件（插件）等。 笔者特别需要提到的是很多需求调研都忘记确认运行环境， 结果到上线前用户使用Firefox甚至IE6等来检验发现根本无法进行验证运行的情况，其中的苦只有自己能够知晓了。

系统可维护方面的需求： 其中包括Bug修复流程、系统发布流程、系统升级部署流程、系统扩容流程方面的需求，考虑到此系统的服务器数量众多、地域分布有一定的广度，因此在设计此部分维护性需求时必须考虑到凡此种种情况。

系统可监控性方面的需求： 其中包含服务器端的常规监控（CPU/Memory/Disk I/O)以及网络流量监控，另外需要特别增加对于交易事务队列及请求队列的队列长度、去化速度等方面的监控，从HTTP方面需要监控每个request的去化速度以及队列长度，从而从各个方面全面地了解系统的当前性能指标。

其他需求包含了可移植性、可扩张性等各个方面的需求。

需求文档的写法： 此处列出需求文档的全部目录结构供大家参考，具体的文档内容就不贴出来了。

1. 引言

1.1 编写的目的

1.2 背景说明

1.3 术语定义

2. 任务概述

2.1 目标描述

2.2 功能性需求

2.3 业务信息定义

2.4 约束条件

3. 数据流图

3.1 全局数据流图

3.2 各子块数据流图

4. 系统接口

4.1 用户接口

4.2 硬件接口

4.3 软件接口

5. 性能需求

5.1 精度要求

5.2 时间特征

5.3 灵活性

6. 软件属性

6.1 可使用性

6.2 系统安全性

6.3 可维护性

6.4 可移植性

7. 系统配置需求

7.1系统硬件和软件配置

7.2网络配置

7.3网络拓扑图

8. 其他需求

8.1 数据库需求

8.2 故障及其处理需求

可以毫不夸张地说，需求确定的清晰程度以及双方的认可度，直接决定最终项目的成败与否，很多的同事总是抱怨客户在最后不讲道理，不留情面，其实仔细分析发现项目开始的时候项目组就已经沟通很不充分了，存在了巨大的隐患，留给整个项目的执行是无穷尽的遗憾。

项目需求的沟通可以简单、形象地总结为一句话： 需求调研就是了解在什么环境下（服务器、客户端环境、网络环境）实现怎么样的一个系统（功能列表），其可用度如何（性能、安全、可靠度）？

理论虽是如此，可实际执行的时候大家还是发现存在如下的诸多问题：

1. 跟客户的一个领导将需求讨论清楚了，可是后面换了新领导，整个思路全变了，系统也必须大改， 如何控制需求？

2. 跟客户下面的项目管理人员定义得很清楚了，可是等到最后给高层领导一看，才发现需求根本偏向了，怎么办？

3. 在设计、开发过程中，客户总是想方设法变着法子来添加需求，还会有种种这样那样子的理由，需求想控也控不住；

4. 碰到极端客户，就算你一开始跟他谈得很好，也签字认可了，到了后面一翻脸就说，这事儿我还得改，否则我就不打算让你上线？

如此种种，令很多理论派PMP的管理人员手足无措，也不知何从处理，根据笔者的个人经验来看，如果真的出现上述情况了，那我们还得必须考虑一下，任何项目管理都是寄生于企业的管理生态与社会的交往生态当中，此处从PMP的经典理论已经无法来解决上述问题了，必须升华为管理生态以及客户关系生态来解决了，此时项目经理必须借助销售以及公司的其他各种途径来突破解决此问题了。