又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太大往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在却几乎看不到它们的踪影，换来的是诸如J2EE和.NET这样的大型web应用。而这期间，RUP、XP、敏捷开发、持续集成••••••一个接一个的新概念层出不穷，令人眼花缭乱。现在想来，恍如隔世。
但更令我印象深刻而难以忘怀的，是我亲自经历的、亲眼目睹的、道听途说的一个又一个的软件项目，它们有的获得了成功，但更多的是令人沮丧的失败。套用一下大文豪托尔斯泰体：幸福的家庭都是一样的，不幸的家庭却各有各的不幸；幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。我常常在想，我们的项目开发到底怎么了，进而把它们一个一个的剥开来深入分析，竟然触目惊心。它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。也许你认为我在危言耸听，好吧，我来举几个典型事例分析分析吧。
我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。多么惨痛的教训啊！我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
第二个故事来自我自己的项目，一个早期的项目。在这个项目中，客户扔给了我们很多他们目前正在使用的统计报表，要我们按照报表的格式做出来。这些报表都是手工报表，许多格式既不规范，又很难于被计算机实现。这些报表令我耗费了不少闹细胞，直到最终项目失败都没法完成。这件事留给我的深刻教训是，不能客户怎么说软件就怎么做。客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。但我们作为技术人员，需求分析必须实事求是地、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
2007年，我参与了一个集团信息化建设的项目。这个项目中的客户是一个庞大的群体，他们分别扮演着各种角色。从机构层次划分，有集团领导、二级机构人员、三级机构人员；从职能角色划分，有高层领导、财务人员、生产管理员、采购人员、销售人员，等等。在这样一个复杂场景中，不同人员对这个项目的需求是各自不同的。非常遗憾的是，我们在进行需求分析的时候没有认真分析清楚所有类型人员的需求。在进行需求调研的时候，总是集团领导带领我们到基层单位，然后基层单位将各方面的人员叫来开大会。这样的大会，各类型的人员七嘴八舌各说各自的需求，还有很多基层人员在大会上因为羞涩根本就没有提出自己的需求。这样经过数次开会，需求调研就草草收场。我们拿着一个不充分的需求分析结果就开始项目开发，最终的结果可想而知。直到项目上线以后，我们才发现许多更加细节的业务需求都没能分析到，系统根本没法运行，不得不宣告失败。一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的最初需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
我的最后一个故事可能典型到几乎每个人都曾经遇到过。我们的项目从需求分析到设计、开发、测试都十分顺利。但到了项目进行的后期，快到达最后期限时，我们将我们的开发成果提交给客户看，客户却对开发不满意，提出了一大堆修改，而且这些修改工作量还不小。怎么办呢？加班、赶工，测试时间被最大限度压缩。最后项目倒是如期上线了，但大家疲惫不堪，并且上线以后才发现许多的BUG。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。以上这个事例，如果我们提早将开发成果给客户看，提早解决问题，后面的情况就将不再发生。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
以上的故事各有各自的不幸，各自都在不同的开发环节出现了问题。但经过深入的分析，各自的问题最终都归结为需求分析出现了问题。为了使我们今后的软件项目不会重蹈覆辙，似乎真的有必要讨论一下我们应该怎样做需求分析。
昨天，2012年1月11日，网友 @fenng 写了一篇文章，批评铁道部火车票网上订购系统，http://www.12306.cn [1]。同时在新浪发了一条言辞激烈的微博，“去你的‘海量事务高速处理系统’”，引起热议 [2]。
春节将到，大家买不着车票，赶不上大年三十与家人团聚，急切心情可以理解。但是拍桌子开骂，只能宣泄情绪，解决不了实际问题。
开发一套订票系统并不难，难在应对春运期间，日均 10 亿级别的洪峰流量。日均 10 亿级别的洪峰请求，在中国这个人口全球第一大国，不算稀罕，不仅火车票订票系统会遇到，而且电子商务在促销时，也会遇到，社交网站遇到新闻热点时，也会遇到。
所以，能够在中国成功运行的云计算系统，推广到全球，一定也能成功。
但是在美国成功运行的云计算系统，移植到中国，却不一定成功。
如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。
于是软件工程师们献计献策，讨论如何改进 12306 网上购票系统
[3]。其中比较有代表性的，有两篇 [4,5]。
网友的评论中，有观点认为，[4] 利用“虚拟排队”的手段，将过程拉长负载降低，是网游的设计思路。而 [5] 利用缓存技术，一层层地降低系统负荷, 是互联网的设计思路。
个人认为，[4] 和 [5] 并不是相互排斥的两种路线，两者着重解决的问题不同，不妨结合起来使用，取长补短。
下面介绍一下我们的设计草案，追求实用，摈弃花哨。抛砖引玉，欢迎拍砖。
图一。12306.cn 网站系统架构设想图。
Courtesy
http://i879.photobucket.com/albums/ab351/kan_deng/12306.png
图一是系统架构图，典型的“展现层”/ “业务层”/ “数据层”的三段论。
用户接入有两类，一个是运行在电脑里的浏览器，例如 IE，另一个是手机。
无论用户用电脑浏览器，还是手机访问 http://www.12306.cn 网站，用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务器，根据各个门户服务器的负载轻重，负载均衡器把用户请求，转发到某一相对清闲的门户服务器。
门户服务器的任务类似于收发室老头儿，它只读每个用户请求的前几个 bytes，目的是确定用户请求的类型，然后把请求投放到相应类型的队列中去。门户服务器的处理逻辑非常简单，这样做的好处，是让它能够快速处理大批量用户请求。
根据 [5] 的分析，12306 处理的用户请求，大致分为三类，
1. 查询。用户订票前，查询车次以及余票。用户下订单后，查询是否已经订上票。
2. 订票，包括确定车次和票数，然后付款。用户付款时，需要在网银等网站上操作。
3. 第一次访问的用户，需要登记，包括姓名和信用卡等信息。
三类请求的业务处理过程，被分为两个阶段，
1. 运行于缓存中的任务队列。设置队列的目的，是防止处理过程耗时太长，导致大量用户请求拥塞于门户服务器，导致系统瘫痪。
2. 业务处理处理器，对于每一类业务，分别有一群业务服务器。不同业务的处理流程，各不相同。
图二。12306.cn 网站查询和订票业务流程设想图。
Courtesy
http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png
图二描述了查询和订票，两个业务的处理流程。登记业务流程从略。
查询的业务流程，参见图二上半部，分五步。
这里有两个问题需要注意，
1. 用户发出请求后，经过短暂的等待时间，能够迅速看到结果。平均等待时间不能超过 1 秒。
2. 影响整个查询速度的关键，是“查询服务器”的设计。
查询任务可以进一步细化，大致分成三种。
1. 查询车次和时间表，这是静态内容，很少与数据库交互，数据量也不大，可以缓存在内存中。
车次和时间表的数据结构，不妨采用 Key-Value 的方式，开发简单，使用效率高。Key-Value 的具体实现有很多产品，[5] 建议使用 Redis。
这些是技术细节，不妨通过对比实验，针对火车票订票系统的实际流量，以及峰值波动，确定哪一个产品最合适。
2. 查询某一班次的剩余车票，这需要调用数据库中不断更新的数据。
[5] 建议把剩余车票只分为两种，“有”或“无”，这样减少调用访问数据库的次数，降低数据库的压力。但是这样做，不一定能够满足用户的需求，说不定会招致网友的批评讥讽。
[4] 建议在订票队列中，增加测算订票队列长度的功能，根据订票队列长度以及队列中每个请求的购票数量，可以计算出每个车次的剩余座位。如果 12306.cn 网站只有一个后台系统，这个办法行之有效。
但是假如 12306.cn 网站采用分布式结构，每个铁路分局设有子系统，分别管理各个铁路分局辖区内的各个车次。在分布式系统下，这个办法面临任务转发的麻烦。不仅开发工作量大，而且会延长查询流程处理时间，导致用户长久等待。
3. 已经下单的用户，查询是否已经成功地订上票。
每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有内容，都缓存在内存里，不仅非常耗用内存空间，内存空间使用效率低下，更严重的问题是，访问数据库过于频繁，数据量大，增大数据库的压力。
解决上述分布式同步，以及数据库压力的两个问题，不妨从订票的流程设计和数据结构设计入手。
假如有个北京用户在网上订购了一套联票，途经北京铁路局和郑州铁路局辖区的两个车次。
用户从北京上网，由北京铁路局的子系统，处理他的请求。
北京铁路局的订票服务器把他的请求一分为二，北京铁路局的车次的订票，在北京子系统完成，郑州铁路局的车次在郑州子系统完成。
每个子系统处理四种 Key-Value 数据组。
1. 用户ID：多个 (订单ID)s。
2. 订单ID：多个 (订票结果ID)s。
3. 订票结果ID: 一个 (用户ID，车次ID)。
4. 车次ID：一个(日期)，多个 (座位，用户ID)。
北京订票服务器完成订票后，把上述四个数据组，写入北京子系统的数据库，同时缓存进北京的查询服务器，参见图二下半部第6步和第7步。
郑州订票服务器完成订票后，把上述四个数据组，写入郑州子系统的数据库，同时缓存进北京的查询服务器，而不是郑州的服务器。
让订票服务器把订票数据，同时写入数据库和查询服务器的缓存，目的是让数据库永久保留订票记录，而让大多数查询，只访问缓存，降低数据库的压力。
北京用户的订票数据，只缓存在北京的查询服务器，不跨域缓存，从而降低缓存空间的占用，和同步的麻烦。这样做，有个前提假设，查询用户与订票用户，基本上是同一个人，而且从同一个城市上网。
但是这里有个缺陷，某用户在北京上网订了票。过了几天，他在北京上网，输入用户ID和密码后，就会看到他订购的所有车票。可是又过了几天，他去了郑州，从郑州上网，同样输入用户ID和密码，却看不到他订购的所有车票。
解决这个缺陷的办法并不麻烦，在用户查询订票信息时，需要注明订票地点，系统根据订票地点，把查询请求转发到相应区域的子系统。
另外，每次订票的时候，网站会给他的手机发送短信，提供订票信息，参见图二下半部第8步和第9步。
以上是一个初步设计，还有不少细节需要完善，例如防火墙如何布置等等。
这个设计不仅适用于单一的集中式部署，而且也适合分布式部署。
或许有读者会问，为什么没有用到云计算？其实上述架构设计，为将来向云计算演变，留下了伏笔。
在上述架构设计中，我们假定每个环节需要用多少服务器，需要多大容量的数据库，预先都已经规划好。
但是假如事先的规划，低于实际承受的流量和数据量，那么系统就会崩溃。
所以，事先的规划，只能以峰值为基准设立。
但是峰值将会是多少？
事先难以确定。即便能够确定峰值，然后以峰值为基准，规划系统的能力，那么春运过后，就会有大量资源冗余，造成资源浪费？
如何既能抗洪，又不造成资源浪费？解决方案是云计算，而且目前看来，除了云计算，没有别的办法。
Reference，
[1] 海量事务高速处理系统。
http://www.douban.com/note/195179318/
[2] 去你*的‘海量事务高速处理系统’。
http://weibo.com/1577826897/y0jGYcZfW
[3] 火车订票系统的设想。
http://weibo.com/1570303725/y0l9Y2mwE
[4] 铁路订票系统的简单设计。
http://blog.codingnow.com/2012/01/ticket_queue.html
[5] 铁路订票网站个人的设计浅见。
http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html
题图来自
Designyoutrust
一、环境
数据库服务器：Oracle 9i2
操作系统：Windows XP SP2
JBoss版本：4.2.2
JDK：Sun 1.5.0.13
网络配置：同一机器的一个网卡上绑定两个ip地址192.168.1.18和192.168.1.147
二、配置
1.配置消息和事务日志持久保存的数据源，从JBoss安装位置的docs\examples\jca目录下拷贝到server\all\deploy目录下，并修改其中的连接配置，这里使用OracleDS作为持久保存的数据源。注意：别忘了把Oracle的jdbc驱动程序拷贝到server\all\lib目录下。
2.修改DestinationManager配置，删除server\all\deploy-hasingleton\jms目录下的hsqldb-jdbc2-service.xml文件，拷贝docs\examples\jms目录下的oracle-jdbc2-service.xml到server\all\deploy-hasingleton目录下，使用OracleDS作为DestinationManager的数据源。
3. 修改StateManager配置，将其中的数据源配置由
jboss.jca:service=DataSourceBinding,name=DefaultDS 改
jboss.jca:service=DataSourceBinding,name=OracleDS 4. 配置测试的Topic，在server\all\deploy-hasingleton\jms目录下新建一个名为jbossweek-jms-service.xml文件，
<mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=jbossweekTopic">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean> 5. 创建node1的服务器配置，将server\all目录复制一份改名为node1
6. 配置完成。
三、验证
1. 分别以run –c all –b192.168.1.17和run –c node1–b192.168.1.148先后启动all和node1配置。此时192.168.1.17为主节点，浏览http://192.168.1.17:8080/jmx-console/。打开JNDIView可以看到jbossweekTopic的JNDI名称。此时192.168.1.17为主节点，浏览http://192.168.1.148:8080/jmx-console/。打开JNDIView就会发现没有jbossweekTopic的JNDI名称。
2. 关闭192.168.1.17上的all服务器，此时在192.168.1.148上的node服务器的控制台上会出现如下信息：
13:11:13,921 INFO [TreeCache] viewAccepted(): [192.168.1.17:2292|2] [192.168.1.148:2327]
13:11:14,015 INFO [TreeCache] viewAccepted(): [192.168.1.17:2288|2] [192.168.1.148:2321]
13:11:14,218 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 2, delta: -1) : [192.168.1.148:1099]
13:11:14,218 INFO [DefaultPartition] I am (192.168.1.148:1099) received members hipChanged event: 13:11:14,218 INFO [DefaultPartition] Dead members: 1 ([192.168.1.17:1099])
13:11:14,218 INFO [DefaultPartition] New Members : 0 ([])
13:11:14,218 INFO [DefaultPartition] All Members : 1 ([192.168.1.148:1099])
13:11:14,453 INFO [TreeCache] viewAccepted(): [192.168.1.17:2279|2] [192.168.1.148:2306]
13:11:16,218 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../deploy-hasingleton/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
13:11:17,406 INFO [jbossweekTopic] Bound to JNDI name: topic/jbossweekTopic
13:11:17,453 INFO [A] Bound to JNDI name: queue/A
13:11:17,453 INFO [B] Bound to JNDI name: queue/B
13:11:17,468 INFO [C] Bound to JNDI name: queue/C
13:11:17,468 INFO [D] Bound to JNDI name: queue/D
13:11:17,468 INFO [ex] Bound to JNDI name: queue/ex
13:11:17,484 INFO [testTopic] Bound to JNDI name: topic/testTopic
13:11:17,500 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
13:11:17,500 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
13:11:17,500 INFO [testQueue] Bound to JNDI name: queue/testQueue
13:11:17,562 INFO [UILServerILService] JBossMQ UIL service available at : /192.168.1.148:8093 13:11:17,609 INFO [DLQ] Bound to JNDI name: queue/DLQ
3. JMS集群的主节点自动切换到192.168.1.148上的node1节点，浏览http://192.168.1.148:8080/jmx-console/。打开JNDIView就会找到jbossweekTopic的JNDI名称。
http://linliangyi2007.iteye.com/blog/316997http://docs.redhat.com/docs/zh-CN/JBoss_Enterprise_Application_Platform/5/html/JBoss_Messaging_User_Guide/index.html
找到你运行的instance的conf/jboss-service.xml, eg: $JBOSS_HOME/server/default/conf/jboss-service.xml
找到
mbean服务中，名字为 ServiceBindingManager 的，里面有个叫做ports-01的内容，打开这个注释，就可以了。
如果你要运行多个，那么就需要有多个ServiceBindingManager ports-02，这是第三个，ports-03这是地四个，
这个文件，对应${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml里面的ports-01部分，ports-02部分，只不过需要在这里启用，启动的同时，$JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml里面的就不起作用了。
提交订票订单的处理流程如下：
1）用户通过浏览器访问系统URL
2）界面集群F5将请求转发至某一节点，通过比较用户数据库的内容进行身份鉴权。
3）鉴权成功后进入订票，提交订票订单（查询流程暂不讨论）界面显示请等待
4）订票消息被发送至总线部件（接口可用web Service、RMI、甚至自定义协议都可以）
5）总线收到订票消息、去Cache集群查询相关车次
6）Cache根据自身维护的车次余票表，返回查询结果，如果有余票，转7）。如果无票了，则总线返回界面集群“没票了”，界面提示用户明天再试。
7）若有余票，则总线返回界面集群“正在出票，请等待”，并将订票请求压入队列。且发消息至Cache，告诉CACHE将订票请求加入队列。
8）Cache收到总线队列增加1个的消息，将自身维护的对应车次余票数减1个。
9）总线另一线程负责从队列中取消息，并发送至出票部件。
10）出票部件产生订票结果，并修改数据库，发送“订票成功”消息回总线。
11）总线将订票成功消息直接回传至界面集群。
12）用户看到订票结果。
