微信号:yurii-says

介绍:我是这么以为的,当然你也可以那么以为

程序开发的“问题与主义”

2015-12-22 08:08 余晟

大概在五年前,我接手了一套遗留系统。这套系统是公司初创时期,为了保证迅速上线而找外包公司开发的,当时已经日益成为业务增长的瓶颈。我们要做的就是“开着飞机修飞机”,让这个系统变得稳定、健壮、安全,用我的话说,就是“把不正常变为正常”。

有过类似经验的人都知道,这样系统的内幕是相当骇人的。更糟糕的是,骇人的内幕刚刚对我露出一个角,业务那边就扔过来一个大雷:每天都需要大量用到的某个页面查询很慢,结果大家整天在各种群里大呼小叫,搞得IT部门灰头土脸,老大说不着急,其实脸色也不好看。赶紧把查询速度提升上去,就成了当务之急。

从软件开发的角度来看,问题真是太多了:

  • 架构一团糟,各级缓存失效,大量业务逻辑直接落在数据库层;

  • 数据库连接池的分配有问题,不是按业务操作来分配连接,而是按照HTTP请求来分配连接;

  • 数据库的表结构一团糟,拆分起来简直要了命了;

  • 命名空间有问题,经常有两个一模一样的类,干的却是不同的事情;

总之,随便从哪套软件工程的基本观点来看,都会知道现在的系统真是千疮百孔、千奇百怪,能跑到现在简直是奇迹了。“把不正常变正常”的选择也相当自然:釜底抽薪,来个彻底改造,否则不但风险巨大,自己看着都相当不爽,道不同,不相为谋嘛。

然而,现实情况却是紧张而急迫的。我根本没有这么多时间,公司也压根没有那么多资源,甚至合格的程序员都没多少。就是得在这些前提下,迅速、有效地提高这个页面的查询速度。这个问题搞不定,估计工作都难保,更谈不上施展软件开发的基本功了。

怎么办呢?

首先是了解,给系统加上日志,看看每天大家都是以什么样的方式访问这个页面,进行怎样的查询?然后是观察,观察到底是什么时候速度会慢,怎么慢下来的?再次在分析,分析速度慢的原因,想想要如何解决。最后,就是实施了。

通过分析日志,我们发现,这个页面主要是针对一张表的查询,这张表大概有200万条数据,最高查询速度不超过10次/秒。查询中每次要出现的条件是创建时间,其它条件是订单号、包裹号、客户代码之中的一个(坑爹的是这是个模糊查询,程序员偷懒直接用like “%xx%” 去匹配每个字段)。另外,查询结果每页显示15条,有一半的查询停止在第一页,剩下大概还有30%停止在第二页,15%左右停止在第三页。

看来这个性能问题并没有超越单机性能的物理限制,所以各种表分区、分布式暂时都用不上(而且时间和资源也不容许)。螺狮壳里做道场,把几个要紧的点抓到,应该就好了。

创建时间与订单ID(主键)是单调增加的,也就是说,订单ID靠后的,创建时间一定靠后。既然表上面已经有太多索引了,订单ID又是主键,查询的最小时间单位是天而不是时分秒,那么索性把创建时间的索引拿掉,另建一张索引表,记录每天最小的订单ID,这样200万数据的表,只需要一个不到400条数据(1年多)的索引,程序启动时一次性都出来放在内存里,用程序每次把创建时间查询映射为ID范围查询。

既然用户输入的主要内容是订单号、包裹号、客户代码,那么针对订单号、包裹号、客户代码定做三套专门优化的查询逻辑,前端根据输入简单判断一下到底走哪个分支。界面上看起来还是模糊查询,真正的实现却大有不同。

超过90%的查询都只要显示3页。那么好办,把每页显示的记录数从15条调整为45条,一次就显示原来3页的内容,数据还是那些数据,查询的压力却减少了一大半。

另外,每次打开这页面时,默认是显示时间上最近的那一页。仔细了解之后发现这个功能对用户的意义只是告诉大家“系统没坏”,既然创建时间和订单ID(主键)的单调增加的,那么干脆专门写个“第一次打开(没有选择任何限制条件)”的逻辑,按ID从大到小选择45条显示出来即可。

数据库的表结构基本没动,代码也几乎是原来一团糟的代码,结果却相当让人满意:整个开发时间不到2天,查询速度却提高了100倍——对你没有看错,就是100倍。

然后,我们可以赢得很多时间,来做数据库的优化,来做程序结构的优化,来让系统看起来更正常一些。

我本来以为这没什么好稀奇的,后来发现似乎又不是这样,这样的“雕虫小技”说出来很多人都觉得太简单,他们心心念念就是要做各种百年大计。仔细问原因,往往是“网上(书上)说了,就应该这么做”。

当然,我自己也不能保证自己就做得很好:不久前Caoz分享的经验真是让我拍案叫绝,因为数据库的主从同步可能会有1秒的延迟,为避免论坛用户发帖之后看不到自己的帖,先给用户看一个“发帖成功,3秒后跳转”的页面——这个巧妙的思路,我一时还真想不到。

回想这些问题的时候,我常常会想到将近一百年前的“问题与主义”之争。

那时候,胡适先生主张“多研究问题,少谈主义”,从一点一滴做起;相反,李大钊先生主张对各种问题“应当有一个根本的解决”,也就是“主义”优先。

按照历史书的说法,这是“马克思主义与非马克思主义在中国的第一场交锋”,“标志着马克思主义者与改良派的彻底决裂”。结果,许多简单问题复杂化的来源就在“主义”优先:种庄稼这么简单的问题,也要区分主义——宁要社会主义的草,不要资本主义的苗。

痴迷于争论“宁要社会主义的草,不要资本主义的苗”,却对“种庄稼”的问题视而不见,今天人人都觉得可笑。但这种可笑很可能来自“社会主义”和“资本主义”,而不是来自问题本身。在软件开发中,我们不是经常面对这种争论吗?

  • Java好还是.NET好?

  • Windows好还是Linux好?

  • 一方说这样性能不好,另一方说性能没问题。争来争去,引用各种资料,找来各种名人言论站台,就是没有人想过,我们到底在解决什么类型的问题,对这个问题来说什么样的性能是足够的……

  • 一套系统用了很强壮的框架,有很完美的设计……总之,各方面都相当不错,唯一的问题就是产不出问题。如果你问问“你这个系统到底要解决什么问题,能不能真正解决呢”,多半得不到满意的答复。

怎么解决这类问题?秦晖老师曾经提到过一个说法,我非常赞同:主义可拿来,问题须土产。如果不愿意拿来其他人的主义,就会掉进“自己发明轮子”的陷阱;但如果问题却不能一起拿来,原有的问题脱离了所处环境充其量是个标本,新环境里的真正问题没有被发现,结果多半是南辕北辙。

“主义可拿来,问题须土产”。在下次大家面对技术争论不知所措的时候,不妨在心里把这句话默念几遍,看看有没有真正土产的问题。如果没有,这样的争论,不关心也罢。

 
余晟以为 更多文章 我把程序献给你 想清楚你要什么 IT是种资源 校招经验——写给找工作的同学们 全面且实用的IT管理教科书——评《知人善用》
猜您喜欢 Operator 并发原语: producers(四),RangeProducer 优化 一周阅读推荐 #2 还有人用么?数据显示Windows Phone用户正集体转用Android 万亿级调用系统:微信序列号生成器架构设计及演变 晋升的为什么不是你