小议研究生系统升迁(旧)

| Comments

09年底写的小文,记录一下。回想起来,别有一番滋味。再描述一下,项目小组共5人,3个写代码1个整理需求1个迁移数据,除了我还有2个女孩是写代码。 老系统大约20w行c sharp,改造后1w行不到的ruby。这么少的代码主要得益于ruby的简洁和rails高开发效率。现在认为,在数据库方面没有做大多努力, 有些sql效率需要改进(不过一般的表就也不是百万级的),有信心可以让整体性能提升一个级别。后来,我对oracle印象有改观(我本不愿意使用oracle), 另一同事对ruby印象也大为改观(他认为ruby只能小打小闹),总的来说,这次项目收获很多。

虽然我们还在忙乎着这个系统的升级工作,还在为客户没完没了的需求做努力,我们真是又累又烦了。真是因为这样,我们大多数人(我想应该说团队所有人)都希望逃离这个泥塘。 项目现状虽然是这样,但是咱们也要摆脱这些东西,来说说技术方面的东西。

有幸在项目中担任小小架构师的角色,应该说,我们在这次升级过程中技术上遇到了许多问题,但最终都算解决了,应该不会有什么不满吧? 其实对这样的项目,一开始也是徘徊在所谓强大的j2ee技术和所谓前卫的ruby on rails之间,也不知道最后是哪个领导拍板上ruby on rails了。 对于这种升级性系统(从.net到xx),需求方面还是比较稳定的,用所谓j2ee貌似也是可行的,至少我在前期也的确看不到ruby on rails有太明显的优势。 可是我还是对选择ruby on rails没什么意见,也正好是可以证明一下并非架构只此一家,这也算一个不错的机会吧。

再说到具体的点上,假如你见过原来系统数据库设计的蜘蛛网,就会明白我们在数据迁移方面的工作有多么艰难。 还有其他一些原因,我们没有选择耳熟能详的mysql,而是选择了oracle。也正因为数据方面的原因,我们不得不在程序方面做出让步(即使这样,ruby还算比较优雅)。 至少,我们让程序兼容了数据。ruby on rails+oracle的探索也是比较漫长的,前前后后也修改了几次适配器(如数据类型识别,一些数据库选项), 增加了一些插件来增加特性(如存储过程)。逆其道而行,真是吃力不讨好。虽然相对java来说,这些做法就像无聊的笑话一样,但是至少我们顺利的解决问题了。

随着项目深入带来的多如雨点的细节方面的调整,ruby on rails的优势才逐渐凸显出来。至少从我这个javaer来,区别是很明显的(俺也做过java项目维护,知道那是怎样一种体力活动)。 你不要好奇为什么细如牛毛的调整会这么多,可是事实就是这样了,咱也不解释了。在语言层面的强大真的可以节省不少精力,算起来也有n多功能,也才1w行代码。 按照我的经验,如果不幸用的是java,在这样战乱纷纷,弹尽粮绝的情况下,我们肯定会给java这门大炮压垮了。 在需求变更处理方面,动态语言的优势是相当明显呀,感谢MATZ,感谢DHH,感谢C-C-A-V。

现在项目逐渐稳定下来,我们考虑更多的是如果让我们的系统高效稳定的运行,能够及时处理bug。 关于性能方面,我们的项目是基于流行的lighttpd+fastcgi部署的,也算一个LAMP架构(最大的区别就是oracle代替mysql了), 而作为业务系统,流量到现在最多也是20w动态pv那样子。我们也没有使用什么特别的缓存策略,运行还是相当流畅的(这还是在内存从原来16g减少一半的情况下做到的)。 基本繁忙的时候,都是oracle在那忙活着,这也是普遍情况,瓶颈大多首先出现在数据库IO。 所以,这样的架构性能方面也是没有什么问题,稳定性也很好。还有一次好处,我们的更新非常频繁,而每次更新只用短短3s左右,几乎是无痛更新。 得益于Linux平台,我们在监控,流量分析方面也是游刃有余(不得不赞叹一下shell),另外得益于ruby on rails架构的灵活性, 可以做些调整方便我们监视运行状况(例如在top中查看真实URL,在单独的log中记录exception),这些都大大提高我们的效率。 这方面,大体上是windows和linux之间在服务器端的比较优势了。

现在回过头来看,在一开始打造的时候,我还是有些担心的,担心oracle和ruby的兼容,担心性能,担心处理ms格式(还好,excel和sqlserver至少是没什么大问题的)。 这也是一步步走过来的,现在就淡定多了。在项目前期,任何东西都不会有太大优势,只有到了中后期,才会有强烈的感觉。 另外,也杂七杂八的把以前自学的东西用上了一些,算是厚积薄发了一下,学以致用吧,感觉还是不错的。呵呵,感谢xy,感谢hnjk,感谢C-C-A-V :)

Comments