敏捷开发产品管理系列之八：基于业务设计技术架构（兼谈12306性能问题）

本文是敏捷开发产品管理系列的第八篇。（专栏目录）

在产品开发中，常常遇到产品性能问题，这些性能问题会很大程度上影响到产品的架构。

但解决这些性能问题，切莫认为只是技术人员的事情，产品经理和产品总监也要参与其中，甚至是业务人员（销售、售前）。

下面以12306的售票问题为例，来做一个完整的说明。

本文的目的，不是说技术性优化不必要，而是说作为开发人员不要闷头只想技术，而作为产品经理不要把所有“技术”问题推给开发人员，这一点很重要。

技术方案的局限性

12306为什么崩溃了？

原因众说纷纭，解决方案也众说纷纭。

到网上一搜“12306 性能”http://www.baidu.com/s?wd=12306+%D0%D4%C4%DC&rsv_bp=0&rsv_spt=3&inputT=8540支招者不计其数，但多数集中在技术方面。

本人对数据库一项所知甚少，也不懂如何优化，但下面我们从业务的角度看看有没有什么解决方法。

先看看这个方案：为何不上10倍的服务器？

很多人提出，如果上10倍的服务器（或10倍的内存/硬盘/……），可能就解决了拥堵问题。

实际上我也想过是否可以上10倍的火车，解决中国的春运问题。答案是不能。

因为任何能够满足春运数量的火车，在非春运的时候都会变成很大的负担，只能停在什么地方风吹雨淋等待下一个春运到来。

所以，突发性是核心矛盾，无论用技术方法，解决突发性是主要矛盾。

突发性的放大

除了很多人在这段时间买票之外，有一个正反馈过程加重了突发性，那就是买不到票。

可以说，访问人数无论上升还是下降，只要还有票，多数人都只会登录此网站一次，性能问题至少还是线性的。

但如果买不到票，或买不到某个车次的票，人们就会突然多次访问网站，性能问题就变成非线性的了。比如有一个人就刷新200多次，终于购票成功。

把200变回1，这不是一个简单地利用技术能解决的问题。

在某个攻略中也提到，由于人数太多，登录都需要20～30次才能完成。这些非线性因素，乘上本来就增加的人数，难免崩溃。

从业务角度思考问题

先胡写几个方案看看，先假设我不会编程。

1. 把提前售票时间从10天改为20天

“什么？”是的，这个傻方法差不多可以降低服务器负载50%。

2. 设计一个排队系统，完成登录

以前玩游戏的时候，经常因为部分服务器崩溃而无法登陆，不过，这时候都会出现一个排队系统：“您正在排队登录，前面还有1000人……900人……800人……（别乱动键盘啊，快到你了）”

这个是用来解决雪上加霜的突发性放大问题的。

我相信12306肯定为30亿人次的春运做过准备，只是没为6000人次的春运做准备，排队系统可以把人数重新变回30亿。

3. 设计一个排队系统，完成预订票

进去了，还是没有票，怎么办？每天抽空就上来看看，然后重新登录……刷新……又是一个突发性放大因素。

如果有一个排队系统，你按优先级排列上自己想买的几种票，甚至直接说“某月日，哪到哪，无论车次，有票就给我”，在家等着退票，或者偶然发出临时车次吧。

如果是我，我还会做个短信服务，如果买到了就短信通知；如果还在排队……如果你愿意接收，每排名向前10%，可以再发个短信；你耐不住性子想查询一下，也可以反向发个短信来，实时查询。

不过，短信要付费的，1毛一条，平价的。我听说短信分账是2：8开，电信才拿2分钱，剩下8分归铁道部，不知道现在是否还是这个规矩。

一个春运下来短信还能赚几亿（应该完胜CCTV的春晚），而且客户还挺高兴，毕竟这几毛钱解决了大问题了，免去半夜爬起来/请假/寒风中排队。撇开这些不说，一台台式机开机3小时就是一度电，6毛钱，管保3小时内你买不到票的；而现在能了（如果还有票）。

当然，如果铁道部愿意让利于民，免费发短信就更好了，不过如果能解决这个问题，相信实际上大家都会觉得让不让的都无所谓了；毕竟火车票10年没涨价，这些钱给人家发加班费吧。

另外这个排队系统还能把黄牛的刷票软件干掉，黄牛再多，也跟着十亿人民一起排队吧。

……

等等诸种业务方法，虽然不能解决有没有票的问题，但能解决购票的性能问题。

实际客户体验也要好得多，毕竟无论你怎么上服务器和优化技术，如果我还是上去200次，依旧耽误工作和生活，弄不好还的从黄牛党买票（他们有专业刷票软件，从性能优化的收益远超过我们）。

从业务角度思考技术架构

正题反而很简单了，如果要做技术架构，先要了解业务架构。

这一点要说服产品人员和业务人员参加进来，在http://blog.csdn.net/cheny_com/article/details/7220270里边的案例中提及了如何让商务人员进行架构设计的问题。