【IT168 专稿】2012年的春运潮造就了中国铁路客户服务中心12306网络购票系统一夜蹿红，从传统购票方式到电子商务，2012年1月1日开通的12306网络购票系统成为了铁道部改革的重要一步。
但是随着12306系统的上线，各种关于12306系统的抱怨声也层出不穷，不少人抱怨网上订票系统十分“龟速” 网络运行奇慢，网页不时“崩溃”，平均刷新500次才能购到一张票，而且订票过程十分繁琐，从用户注册到支付成功，要13道“工序”，让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票，而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服，并引发了一些讨论和思考，应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯，对于大型高并发高性能网站的建设和优化，他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战？
12306订票网站具有分时段、分区域、高并发等特点，如何确保在高峰时段正常提供服务是一个非常大的挑战，放眼春运期间网上订票系统，表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素，也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿，在高峰时段有千万PV的访问量，应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等，12306的访问模式和淘宝、京东存在哪些异同？
相同点都可以理解成电子商务网站，无论是业务逻辑还是应用特点都非常相似，唯一的差别是12306的流量因时段、区域更为集中，有人说像淘宝、京东搞促销，比如”秒杀”。但”秒杀”的对象往往比较固定，后端可以通过缓存机制或静态化来缓解数据库I/O压力，而12306需要每隔10分钟更新票务信息，同时还要保持与集团其它业务系统对接，这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件，这些宕机事件和12306网站崩溃有何异同？
此类宕机事件原因都是相似的，无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上，促销活动可以推迟或重新组织，但12306订票系统不行。反之，12306有其它辅助的补救、缓解方案，如电话预定、代售点等，传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题？在以上谈到的问题上是否都有一些相应的优化建议呢？
个人认为更有价值是体现在数据分析上，如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等，这些数据对优化、改良现有架构非常有帮助。抛开宽带因素，以下是对12306平台系统架构的几点建议：
一、前端优化
具体参考：yahoo前端优化34条规则，针对12306平台，个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离，静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现，这对动态CDN加速是一个挑战，因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性，可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力，从一个普通用户订票轨迹来看，查询读往往是入库写的好几倍，如何减少数据库的读I/O对提高平台的整体性能至关重要，比较流行的缓存技术有针对页面及数据级，页面级缓存有varnish、squid等，如使用CDN，页面级的缓存可以不用考虑，重点将精力放在数据级的缓存规划上，技术方面可以用Nosql来实现，比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区，这样可以很好地提高缓存命中率，减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务，目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测，不一定准确)来对外提供服务，比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等，只要其中一个功能模块出现堵塞，影响必定是全局性的。一个好的方法是优化、规范各业务URI，在代理层实现业务的划分，可用的技术有Haproxy、Nginx等，如将/otsweb/regitNote/映射到注册组WEB服务器，/otsweb/AppQuery/映射到查询组WEB服务器，/otsweb/Pay/映射到支付组WEB服务器等等，如此一来，当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务，数据库服务器往往都使用一台高端的硬件，比如小型机，在互联网行业，尤其是类似于12306订票系统，这往往是最致命的，理由很简单，在大流量并发下处理能力再强的服务器也吐不出数据，因为受网络I/O、磁盘I/O、业务逻辑等方面的限制，所以必须将数据打散，方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离，大部分数据库都支持这点，除此之外还建议使用分区模式，分区策略可以根据业务特点进行，按地域进行分区是一个好主意，因为每个区域都是一个大分区，还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性，采用负载均衡策略必不可少，即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等，也有开源的LVS，看成本的投入来选择，此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件，业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口，与电话订票、代售点都是平级的，后端肯定还关联着很多复杂的业务系统，在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现)，可以将网站业务平台剥离出来，当然，完全剥离也不太实际，至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比，因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站，在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升，设计得再好的架构也很难一步到位，也是随着业务的高速增长，不断积累经验、优化、改良的过程。12306的流量达到千万PV 级，但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构，首先必须以了解业务特点作为出发点,架构的目的是支撑业务，需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面，这些层面看似一个整体，任何一个环节出问题都可能导致整个网站崩溃，所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性，解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题，对于考验一个成功的架构提出了更高的要求，也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入，我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站，以便提高资源利用率节省成本，您是如何看待的?
云计算是未来一个趋势，优点不多说，它具有动态伸缩、灵活性强等特点，可以让资源利用最大化，可以更好节约成本，非常适用于12306平台。
虚拟化(不局限于服务器虚拟化，也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石，可以降低企业运营成本，提高资源利用率，个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化，比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点，使物理实体机处于低功耗状态下运行，绿色环保，高峰来临时可以迅速部署上线来提供服务。
原文：http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
但是随着12306系统的上线，各种关于12306系统的抱怨声也层出不穷，不少人抱怨网上订票系统十分“龟速” 网络运行奇慢，网页不时“崩溃”，平均刷新500次才能购到一张票，而且订票过程十分繁琐，从用户注册到支付成功，要13道“工序”，让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票，而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服，并引发了一些讨论和思考，应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯，对于大型高并发高性能网站的建设和优化，他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战？
12306订票网站具有分时段、分区域、高并发等特点，如何确保在高峰时段正常提供服务是一个非常大的挑战，放眼春运期间网上订票系统，表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素，也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿，在高峰时段有千万PV的访问量，应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等，12306的访问模式和淘宝、京东存在哪些异同？
相同点都可以理解成电子商务网站，无论是业务逻辑还是应用特点都非常相似，唯一的差别是12306的流量因时段、区域更为集中，有人说像淘宝、京东搞促销，比如”秒杀”。但”秒杀”的对象往往比较固定，后端可以通过缓存机制或静态化来缓解数据库I/O压力，而12306需要每隔10分钟更新票务信息，同时还要保持与集团其它业务系统对接，这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件，这些宕机事件和12306网站崩溃有何异同？
此类宕机事件原因都是相似的，无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上，促销活动可以推迟或重新组织，但12306订票系统不行。反之，12306有其它辅助的补救、缓解方案，如电话预定、代售点等，传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题？在以上谈到的问题上是否都有一些相应的优化建议呢？
个人认为更有价值是体现在数据分析上，如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等，这些数据对优化、改良现有架构非常有帮助。抛开宽带因素，以下是对12306平台系统架构的几点建议：
一、前端优化
具体参考：yahoo前端优化34条规则，针对12306平台，个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离，静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现，这对动态CDN加速是一个挑战，因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性，可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力，从一个普通用户订票轨迹来看，查询读往往是入库写的好几倍，如何减少数据库的读I/O对提高平台的整体性能至关重要，比较流行的缓存技术有针对页面及数据级，页面级缓存有varnish、squid等，如使用CDN，页面级的缓存可以不用考虑，重点将精力放在数据级的缓存规划上，技术方面可以用Nosql来实现，比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区，这样可以很好地提高缓存命中率，减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务，目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测，不一定准确)来对外提供服务，比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等，只要其中一个功能模块出现堵塞，影响必定是全局性的。一个好的方法是优化、规范各业务URI，在代理层实现业务的划分，可用的技术有Haproxy、Nginx等，如将/otsweb/regitNote/映射到注册组WEB服务器，/otsweb/AppQuery/映射到查询组WEB服务器，/otsweb/Pay/映射到支付组WEB服务器等等，如此一来，当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务，数据库服务器往往都使用一台高端的硬件，比如小型机，在互联网行业，尤其是类似于12306订票系统，这往往是最致命的，理由很简单，在大流量并发下处理能力再强的服务器也吐不出数据，因为受网络I/O、磁盘I/O、业务逻辑等方面的限制，所以必须将数据打散，方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离，大部分数据库都支持这点，除此之外还建议使用分区模式，分区策略可以根据业务特点进行，按地域进行分区是一个好主意，因为每个区域都是一个大分区，还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性，采用负载均衡策略必不可少，即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等，也有开源的LVS，看成本的投入来选择，此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件，业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口，与电话订票、代售点都是平级的，后端肯定还关联着很多复杂的业务系统，在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现)，可以将网站业务平台剥离出来，当然，完全剥离也不太实际，至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比，因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站，在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升，设计得再好的架构也很难一步到位，也是随着业务的高速增长，不断积累经验、优化、改良的过程。12306的流量达到千万PV 级，但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构，首先必须以了解业务特点作为出发点,架构的目的是支撑业务，需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面，这些层面看似一个整体，任何一个环节出问题都可能导致整个网站崩溃，所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性，解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题，对于考验一个成功的架构提出了更高的要求，也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入，我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站，以便提高资源利用率节省成本，您是如何看待的?
云计算是未来一个趋势，优点不多说，它具有动态伸缩、灵活性强等特点，可以让资源利用最大化，可以更好节约成本，非常适用于12306平台。
虚拟化(不局限于服务器虚拟化，也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石，可以降低企业运营成本，提高资源利用率，个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化，比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点，使物理实体机处于低功耗状态下运行，绿色环保，高峰来临时可以迅速部署上线来提供服务。
原文：http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
受CU管理员的邀请参考“千万级pv高性能高并发网站架构与设计交流探讨帖”主题的交流，发表了一案例与大家分享。
一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面，有兴趣也可以讨论)。现抛出一个系统层面的架构，不保证是最优的方案，但也许适合你。理由是再优秀的架构都不具备通用性，需要根据每种应用特点针对性来设计。希望起到抛砖引玉的作用，大家多多参与，发表意见。
(点击放大)
架构说明：
1）架构中直接引入软件名称的模块，是个人推荐使用的，如Haproxy、Hadoop等；
2）关于全局负载均衡，看成本投入情况，可以使用商业的产品，如F5-GTM，开源方案便是自搭智能DNS；
3）本地负载均衡方案，可以考虑F5-LTM或成熟的开源解决方案LVS；
4）代理层为什么推荐大家使用Haproxy？Haproxy是一个非常优秀的反向代理软件，十分高效、稳定。国内top 10的互联网公司都有在使用；
5）缓存层可以使用Squid或Varnish，个人更倾向Varnish。配置灵活、运行稳定，提供非常便利的管理接口。为啥在缓存层前面加一层代理？优点非常多，列举如下：
- 根据应用配置URI路由规则，集中热点来提高后端缓存的命中率；
- 轻松划分网站频道、版块，更好对应用进步组织、规划；
- 对URI进行一般性安全过滤，抵御注入攻击；
- 弹性调配硬件资源，应对突发事件产生大流量；
- 可回收宝贵的公网IP资源；
6）应用层开源技术方案非常多且成熟，在此不详细描述；
7）数据库层主流开源解决方案Mysql是首选，主从复制（一主对多从）是目前比较靠谱的模式；
8）关于Nosql，应用场景不多说，可参考“给部门做的Mongodb技术交流PPT”文章，redis、memcached等作为热点数据存储、数据库缓存都非常理想；
9）内网DNS扮演的角色非常重要，一定要消灭code中出现的内网IP地址，很大程度减少因IP变更、服务器故障而修改源码的情况，同时也便于维护；
10）内网LB适用在内部WEB接口、多台数据库Slave、多台Nosql Slave、公共服务等应用的负载均衡，可以使用LVS、Haproxy来实现，可用性要求不高的应用可行直接使用Localhost DNS轮询；
11）hadoop适合海量数据的存储与处理，如做网站日志分析、用户数据挖掘等；
12）管理集群，平台的核心，运维的阵地；
以上粗略介绍了架构的几个组成部分，如大家有对哪块有疑问或感兴趣都可以展开来讨论，也可以通过weibo与我交流：http://t.qq.com/yorkoliu
