专家探寻12306出路：建自己的公有云

  优化建议：用户体验为核心 互动式运营

  在分析完需求和特点之后，我们需要了解现有的系统存在哪些问题?要解决这些问题的核心思路是什么?邱爵荣表示，目前最大的问题在于瞬间流量过大，他建议以用户的体验为中心，通过互动式运营不断改进，这也是任何一个网站建设所需要遵从的思路。

  主持人：您认为目前的12306订票网站在哪些方面可能存在问题?您的优化建议是什么?

  邱爵荣： 12306存在哪些存在的问题?它最主要造成问题的核心原因就是它的瞬间流量，流量太大是一个症状，症状产生的原因就是我们现在要讨论的细节——服务器的部署、带宽、负载均衡、数据架构、应用程序等等。

  从终端用户的动作来去分析每一个阶段发生的问题，第一个问题是是否有足够的带宽和服务器来承载Web的瞬间流量?早上六点开放定票，六点到六点零五分之间，它的瞬间流量一定是最大的。以前我有处理过类似的火车定票系统，服务的IT人员告诉我他们遇到的问题：在一瞬间，系统有十万张票要卖，放票的前面五分钟就全部卖完，所以算一下，每秒钟的连线数量是相当惊人的。

  负载均衡的系统肯定要去计算一次这样的连线需求量有多少，然后再去加减一些编译器，比如说前一分钟里面有10000个连线，可是实际上前端服务Web的服务器连线容许值有15000个连线，加了15%。

  12306订票网站，我个人认为并不是一种问题，而是一种经验学习。在服务器准备、带宽、负载平衡这些东西，一开始做的一个假设，就是总量计算的假设，预期从第二年、第三年甚至到第四年、第五年，这样不断地优化，让它的服务慢慢到位，能够达到在开放的时候，所有用户都可以得到想要的服务质量。

  主持人：那么究竟如何才能让用户基本满意呢?

  邱爵荣：如何让用户满意，也就是说每一步的响应时间要能让用户接受。首先，在页面呈现的时候，当用户连到12306的时候，可以接受的页面呈现时间是3秒。我们架设把整个Webpage的传输量是300KB，那每秒钟就需要为每个连线传输100KB数据，如果一秒钟有10万个同时连线，用一秒钟100K乘以10万个，就得到每一秒钟所需要传输的数据量。当然，终端用户也知道，过年时间订票的难度要高，所以可以容忍本来预期三秒钟更长的时间，我可以容忍到二十秒，二十秒传完我也可以接受。也就是说20秒钟之内传完网页可以让用户基本满意。所以，从技术上来说，如果不能二十秒还未传完，一个数据都没有呈现出来，就不能让用户满意了，至少是慢慢呈现，图片、广告稍微慢一点。

  其次，要让用户看到计算的进程。等到画面出来的时候，用户开始填资料的时候。把名字、身份填进去以后，这时候送进去，通常一个包送进去，就接到后面去处理，后面的应用跟数据库要去检查中间的包里面资料，而且这个资料可能通常还有加密，做了检查了以后，还要到其他的数据库去核对，核对完以后才能送出来。假设在一分钟之内完成，其实等一分钟是可以接受的，但是中间一定要跟他说你的身份正在验证中等等，不能让呆呆的等，可以用一个横杆，慢慢的变长。所以在网站设计上，要有一些额外的东西，让用户不会觉得等不及，因为一旦用户等不及，就有可能进行另外一个连线，导致多余的流量。

  后端的数据库，在三十秒内或者一分钟内他可以算完十万个人进来的包，十万个连接送进来的包里面的身份，但是万一现在的总量就不是一分钟内完成十万个，而是要一分钟内完成一百万个，那怎么办?这个时候就是第一个，先从数据运营上面的优化;第二个要加硬件配置，或者说要采用分散式的方式来做——使用者身份验证是一个数据库，身份验证以后，他要查哪一个火车的时候，他这个需求要送到另外一个数据库，在数据库的方向、架构上面要去做分层，并不是所有数据库都是在一块。当然我们相信12306他们当时设计的数据库也一定有做这样的事情，万一还没有办法满足使用者的期望，就回到刚才前一个问题，就是要学习，使用者要得更快，一分钟等不了，三十秒就要得到，这时候依照使用者给的反馈，进行数据库上的优化或者加强硬件配置，这是一种互动式的运营。

  其实不管是12306还是很小的千人网站，其实优化的程序都是差不多的，首先，在我们后端还没有完成工作之前，要不让前端使用者觉得停下来，那至于说使用者多久会等多久，那就是互动，当然不可能在第一年提供服务的时候，在这么大的压力下就可以做得很好。

  那您觉得经过这样的这种不断的优化和改进之后，在目前现在现有的技术之上，有没有办法达到用户的体验需求?

  邱爵荣： 12306是新网站，很多人在上面还没有建立自己的帐号，所以他从建立帐号开始，然后开始去查询车票，车票查询完了以后，他决定要坐哪一班车，接下来控制多少钱，然后连线资金流，连线银行，确定信用卡或者说其它付款，都完成以后，才会把票在系统里面登记完已经给他了，然后再通知这个使用者到车站去拿票等等。

  这些动作一共有三十几个步骤，也就是说在数据库上面，如果说现在不是单一数据库，还要整合身份的数据库、车票的数据库、银行的数据库，再加上所有的操作的数据库，数据库就应该会有好几个有关联的，不是单一的。

  所以，如果说要提供的服务等级是可以满足终端用户，让他不会觉得慢或者崩溃，数据库都应该放在本地，而不用去等待其他的系统处理完。可是事实上这个东西又不见得可以放在本地，比如说检查信用卡是不是有效的，信用卡资料在银行，不在本地。所以在整个优化上面，除非12306也学习类似支付宝这个动作，可以事先在我这儿存一些款，然后下次要买票的时候，就直接从你存到我这儿的钱去扣，这样就可以确保这个数据都在我这儿，在处理上面就不需要等，不会因为银行的反馈太慢，导致没有办法提供给终端用户一个满意的服务质量。