框架的死穴

框架的死穴

吴旻

泰岩网络工作室

以下内容来自网络新闻：

框架有两个问题，它们并不灵活，更坏的是，框架往往将你框住，框架是为大多数人通用而设计的，然而，当很多项目发展到一定程度，他们往往不在需要通用的东西，而是需要一些特定的技术。Django，Ruby on Rails 以及其它框架非常好用，但当你的站点发展到一定规模，问题将接踵而至，框架最终成为你的桎梏。

 

         我不是做web开发的，我做的是Linux下用C++进行实时性极强的数据处理开发的。在我接手之前，公司的架构已经做好了，与同类竞争性产品比，未见任何异常，当然实际上是服务器的在线用户性能比别人差一半吧，但用户是体验不到的。后来因为数据源的数据量多了5倍，我们想方设法绕了过去，框架对付着使用；再后来数据量又变成了最初的10倍，我们终于绕不过去了。

框架中核心的一环----某实时内存数据库----被我们用到了极限以上，无法进行及时的吞吐，而我们所有的数据，都要经过数据库的中转，尽管事实上不经过数据库中转更合理。当我试图与其他部门商议绕过数据库时，我发现我遇到了框架的阻拦：下游的所有开发都是基于数据库的，当初设计架构的时候，数据库被当成了不二的核心！就没设计如果数据不经过数据库的情况！又一个伟大的马其诺防线就此诞生！

事情的结果是倒逼我必须把数据量降下来，至少50%左右；要不然整个系统就不用上线了。好在某些非关键的数据帧的合并并不影响用户体验，而这些数据帧又比较多，问题算是得以对付过去，这只能叫对付，根本不能算是解决。

我恼火的是为什么没有预留绕过数据库的设计，为什么没有人测试数据库的使用极限！

更让我恼火的还在后面！

 

基于以上的教训，当我从头负责一个产品的开发时，我对开发人员强调了架构要可分可合，要灵活精干，要层次清楚。结果进行设计的小兄弟是个中间件的爱好者，喜欢用ACE、BOOST之类的东西，不是说这些东西不好，而是说他用得可笑。

我们的设计有一个要求，就是数据接收模块要能自动切换到备用数据源的，以防万一。恰好公司当时讨论要不要使用DDS中间件（一种数据转发技术，但价格不菲），他便把这个也考虑在了这项功能当中。且不说使用这个DDS中间件要在架构上多配两台服务器，单就设计理念上就让我哭笑不得：我本意就是想盖一个三层小楼，他却给我来了一个地基要打100米深，装修要用最好的德国厨具的理念！根本谈不拢！

他愿意使用DDS技术的真正原因是DDS中已经包含了备用数据自动切换技术，这样我们就不用自己开发了。但是他不知道，照他的设计，本来挖一立方米的土我们付出买把铁锹的代价就够了，但他却要我们付出买一辆挖掘机的代价！

 

在架构设计时堆架构的人非常之多，而且还口口声声讲自己使用了多么先进的技术。国内众多企业在实施ERP时用SAP做数据库，本身我是说不出什么问题的，但成功者少之又少比我说什么都能说明问题！

我个人以为，通用架构其实就像是傻瓜照相机，对于普通百姓，对于非专业需求，确实非常好用！但当你的需求是专业水平时，你要是还误以为傻瓜相机能达到你的预期，你就太可笑了。同样的道理，像堆架构那样以为明星众多的巴西足球队每次都能拿世界冠军也是一厢情愿的想法！

 

框架的极限是你的项目足够小，性能要求足够低，业务逻辑足够简单；一旦过了某个限制，框架就不再适用而且必须修改。这就像中国的改革，开始可以小打小闹，然后就是越来越深入，最终要进行政治体制的改革！