多线程以外

原文:http://blog.romebuilder.com/2011/10/525/

 

国庆前两天，客户上线的产品突然出现问题，导致几十万用户无法正常享受服务。在日以继夜地奋战了三天后，我们给客户的交待是，没有好的解决方案，只能全部rollback。这样的结果，让整个国庆显得无比悲催了……

问题原因，出在多个方面。

1.版本管理

在 2.0发布时，1.X系列的产品已经稳定运行了很长时间。2.0是从1.2的版本上Cut出来的，发布时，运行的产品已经是1.6.1，在这之间，1.X 已经有了相当多的hotfix，但是这些hotfix却并没有全部merge到2.0中！这导致1.X中一些Critical的Bug又在2.0中出现， 而且在上线的那一刻，由于用户量比较大，问题变得更加严重了。

虽然大家在产品发布之前就已经意识到了这个问题，但是自2.0的从Cut出来后，就再也没有于1.X进行过代码同步，而且2.0的开发已经过了一年多，谁也不敢保证贸然的merge这些hotfix不会出现问题。

于是，最后的折衷方案是，分批分次来merge这些hotfix。但是，在这些merge工作还没有完成时，产品就上线。虽然这也是迫于客户的压力，但是，终归是悲剧。

所以，以后在版本上管理时，运营产品过程中的hotfix一定要以某种方式及时地反应到正在开发的产品中来。这样的事情也应该有人来负责，如果总是要等到将来的某个时间来做，那么就很难有时间来做，而且，随着版本的差异不断地变大，将来做这件事情时，难度就更大了。

2.多线程的使用规则制定

在 排查客户反应过来的问题时，很不幸地，我们发现了很多问题。这些问题似乎在常规的测试中很难发现，以至于精疲力竭的我们还甚至还怀疑过否有某个离职的开发 人员故意使坏了（开个玩笑）。原因在于产品中多线程使用规则并不是每个人都知晓，以至于不小心破坏了其中的线程分配策略而引发大量的死循环（不是死锁）， 从而占用了大量的服务器资源。

现在，服务器开发人员的基本要求是对多线程一定要会灵活应用，但所谓灵活应用，也只是纯技术方面的。技术服务 于业务，业务直接影响到线程规则的制定。可惜这些线程规则并没有文档化，只是在开发人员口中代代相传，相信大多团队都会有这个问题。线程规则没有文档，以 至于失传……

所以，在客户端与服务器之间的交互请求、服务端对客户请求的处理业务、资源分配方式等一定要有明确的文档来规范。这些关键的业 务相对于其它的变更相对要少，一般在开发之前就能可以制定一个框架，后续变更、维护也不多。但变更一定要反馈到文档中，并提醒所有的开发时常关注其中的变 更。

在开发过程，大多数还是喜欢按自己的方式来理解业务，凭自己的经验来给用户分配资源。这样会使看起来合情合理的逻辑，在整个大的环境下出来严重的问题。小则小部分用户无法使用功能，大则会使服务器挂掉。

 

写文档时，不小心按错了键，所有的内容居然全没了……结果又重写了一次，真是个悲催的国庆！！！！