序言：  此文的撰写始于国庆期间，当中由于工作过于繁忙而不断终止撰写，最近在设计另一个电商平台时再次萌发了完善此文并且发布此文的想法，期望自己的绵薄之力能够给予各位同行一些火花，共同推进国内的大型在线交易系统的研发工作，本文更多地站在软件工程角度来看待整个问题，有关后续的技术问题研究，将在另外的博文中予以探讨。 
 
一年一度的国庆大假刚落下帷幕，由于这次长假是历史上最长的一次，因此出行问题备受关注，而铁路出行作为最主要的出行方式更是大家讨论的热点，老生常谈的购票难问题又被提起。这几天我在网站上也看到很多关于12306的讨论，很多网友都发表了自己对于铁道部购票网站的不满，更有很多同行讨论了关于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域名地址，显示了两个不同的地址，这已说明12306设计组已经考虑了这些内容： 从美国PING将会发现： ping www.12306 
PING 08911.xdwscache.glb0.lxdns (183.60.136.64) 56(84) bytes of data.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。