原创：谈谈12306铁路客运售票系统的架构问题（三）

rfcd12

  为了优化12306.cn网站的性能，软件开发单位也没少费脑筋。前几天我在“IT专家网”上看到一篇文章，题为《12306：分布式内存数据技术为查询提速75倍》（http://www.ctocio.com.cn/cloud/1 ... e86b9237b4c58adde9d），里面提到了这样一组对比数字：“根据系统运行数据记录，技术改造之后，在只采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。”从结果上看，这的确是一个很了不起的成绩！

       总的来看，这个成绩是通过实施硬件改造及外部组件方案取得的，而不是通过改造12306.cn系统自身架构得来的。简单说就是使用了一个第三方的组件，将系统数据全部加载到内存，依赖超高速的内存计算来提升性能。这个外部组件就是文中所提到的GemFire分布式内存数据平台，技术原理是通过云计算平台虚拟化技术，将若干X86服务器的内存集中起来，组成最高可达数十TB的内存资源池，将全部数据加载到内存中，进行内存计算。计算过程本身不需要读写磁盘，只是定期将数据同步或异步方式写到磁盘。

       这样一个依靠外力来实现性能提升的方案，在我看来应该是在软件架构已经调无可调、优无可优的情况下，不得已才动用的一种手段。个人主张，修炼内功，打通任督二脉才是提升实力的根本途径。那么12306.cn的软件架构是不是已经调无可调、优无可优了呢？我觉得没有到这种地步，还可以再试着优化一下。

       在说具体优化方案之前，我觉得有必要先提一下软件性能优化的策略。在这里我想请问大家一个问题：启动一个软件开发项目，最迟应该在什么时间点上就必须进行性能优化？上线一年后？上线两年后？都不是，我觉得一个系统从开始编写详细设计说明书时就要考虑性能优化问题，最迟在编写第一行代码的时候就必须考虑性能问题！性能优化的最好方法是认真设计系统和应用程序，性能提高主要是通过优化应用程序获得的。只要有可能，就应该从应用程序设计和编程阶段开始优化，完善的设计可以避免很多优化问题。像12306.cn这样，系统已经上线并产生了海量数据的时候，再来考虑性能调整，再来考虑修改系统框架和底层不合理代码，怎么说呢，不改就是等死、改就是找死！

       那么就有很多人说了，在系统开发阶段也没有实际的生产数据啊，都不知道会发生什么样的性能问题，怎么开展性能调优？拍脑壳吗？

       说到这个问题，我想起十多年前我刚入行时，我师父教我的“地狱式开发”。什么叫“地狱式开发”？这个名字是我后来给取的，当时做这项工作的时候并没有取这个名字。具体做法就是在正式开始编程之前，先做好如下准备工作：（1）首先根据用户的业务量评估一下系统的数据量。这个评估工作不难，找来用户的生产经理、销售经理等各部门负责人，请他们根据最近一两年的工作情况，说说每年各自有多少笔业务，不需要很精确，大致差不多就行。（2）然后把评估出来的数字分别乘以20，自己编写一个小工具（或者使用PowerDesigner等工具）向各个数据库表里插入这么多条数据。（3）接下来再评估系统会有多少人来使用。（4）把系统的使用人数乘以20，然后布置几台PC机，运行LoadRunner或者WinTest、WebTest之类的工具，在PC机上模拟这个数量的人登录系统随机执行各项业务操作。

       准备工作做好了，现在开始编程开发吧。什么？你说服务器系崩溃了、干不了活了，好不容易弄起来了又奇慢无比、做一个单元测试都要等半天……这工作简直没法干了！没错，要的就是这个效果！性能问题肯定会有，在开发阶段发现，总好过系统正式上线后被用户发现、然后被用户一天到晚的奚落要好吧？没说的，发现问题就赶紧解决，不管是架构上的不合理，还是编码方面的不合理，在开发阶段都要解决掉。这样进行软件开发，程序猿和攻城狮们少不了要扒几层皮下来，一天写不了几行新代码，老的程序代码总是要反复改反复调，心理素质不好的同志肯定会心情烦躁、血压升高……这就是“地狱式开发”。

       如果项目组能够坚持下去，在这种数据量和并发量的压力下，编写出来的程序还能够满足正常使用需求，让人感觉不到性能问题，那么这个项目正式上线后，最起码五到八年之内不会有性能问题！就像冯小刚《私人定制》里说的那样，“恶心自己，成全别人。”

       但“地狱式开发”方案的代价是工期延长和预算增加。一般情况下，如果是甲方支付一定费用给乙方，委托乙方进行软件开发工作，那么基本上乙方是不会采取这种开发方案的。原因很简单，首先，甲方一般不能容忍项目延期。一般在合同里都会规定，如果乙方延期交付产品，每延期一天就扣除费用若干。乙方也是自负盈亏的经济实体，自然巴不得项目早日完工，早一天完工就少支出一天的成本。其次，关于软件开发费用，甲方不懂软件开发过程，只求花钱越少越好。尤其当甲方是政府部门或事业单位时，要财政拨款的，这种压价更厉害；另一方面，软件开发这一行竞争也很激烈，血拼价格是常事。价格战打到最后，对每个软件开发单位来说，都只能是保本微利。而且，假设乙方为提高质量而采取“地狱式开发”方案，中途要求变更合同、提高合同金额，有多少甲方会同意？

      所以在现实面前，如果一个系统运行一两年之后发现有严重的性能问题，不能光埋怨乙方技术水平不够，甲方也要反思一下，你有没有支付足够的开发费用给乙方？就好比买车，从外观上看，吉利和奔驰差不太多，但如果你只肯花吉利的钱，你能买到奔驰车吗？有的甲方单位说，不对呀，我明明给的是买奔驰的钱，为什么他只给我一辆吉利？……，好吧，对于这样懂得软件开发流程、追求软件开发质量、尊重软件开发成果、肯花钱、有实力又不幸遭到无良乙方欺骗的甲方单位们，我只说一句：请联系我！

       那么12306.cn的架构具体要怎样进行优化呢？请看下文《原创：谈谈12306铁路客运售票系统的架构问题（最终篇）》。