近期在技术上的进步

距离自己来火币也快两个月了,在技术上收获不少。昨天在和老同学聚餐的时候,云铎问起我很久没写文章了,那今天就随手写点东西,分享一下我最近在技术上的进步吧。这篇文章会写的比较流水账,权当是给自己记个日记。我希望在一年之后,我在回顾今天的这篇文章时,能由衷地说道:“哦天啊王雨峰你那时候可是太菜了啊。”

最近主要在使用的编程语言是groovy,这是Java的一种方言,支持Java的全部语法,同时也是解释型的动态语言。这门语言写起来感觉挺好,很多特点能很明显感觉出来是为了程序员的方便而设计的,比如说,默认导入常用的Java库、一些非常方便的遍历语法等。同时也有一种奇妙的体验:我既可以像Java一样严谨地声明每个变量和函数返回值的类型,也可以像Python一样,给自己省点脑细胞,让程序自己去推断类型。

这感觉和golang的赋值有点像,但groovy在数据处理方面比golang更灵活,比如对于json的处理,groovy几乎不用提前声明任何数据的具体结构,但是在golang中(大多数情况下),你是需要先把json的结构声明地非常清楚才行。

由于我最近做的工作主要是数据搬运性质的工作,程序工作起来很过程化,所以还没接触面向对象的要素,不过这也是我自从大二上完Java课之后,距离面向对象语言最近的一次了。

说实话我觉得Java真的挺好的,实际上,我很少觉得什么东西真的不好。一旦当我产生这种想法时,我偶尔告诫自己,既然身为井底之蛙,就要好好琢磨琢磨怎么从井里往外跳,而不是走到哪都背着自己的这口井。

还有就是对Linux的使用有进步。我的工作,也就是数据的处理,主要是在服务器上进行的——因为数据量很大,只能让服务器来处理。

首先,我对tmux的使用熟练多了。其实一直以来我都会使用tmux,但之前都是比较轻量的使用,顶多在一个session里开几个windows而已。但最近的工作,对窗口数量和并发处理工作的要求变大很多,比如,我需要在同一个窗口中,同时运行脚本、观测系统性能、观察日志输出,那么我就需要分panes。其实都是很简单的操作,只是之前确实没有这个需求而已。这也是应了那个总是正确的道理:只有在真实需求和真实问题面前,学习的效果才是最好的。

还有就是对Linux的性能问题有了更多了解,也是被逼着学的。我们的数据在云服务器上进行处理,其实服务器的性能已经很不错了,但是由于种种原因(具体是哪些原因,仍然在探索中),经常能碰到一些性能上的问题。

比如,内存满了、swap满了,磁盘IO负载满了,load负载飙了,之类的。有一些问题解决了,比如磁盘负载的问题有望在下周得到改善,但有些问题,比如swap和load的问题,可能还没有明确地发现解决问题的办法,但是在研究问题的过程中,倒是学到了不少,比如load的值不仅仅包含running的进程,也包括处于io阻塞状态的进程;而swap的问题现在也不是很清楚(内存还有大量cache/buffer空间的情况下,os还是会非常用力地使用swap)。

总之,Linux的性能问题感觉是很有意思的,很多问题往深入看,就发现自己os方面的知识有欠缺,比如内存的交换、进程的调度等等。也许借解决这些性能问题的机会,补一补os方面的知识漏洞。

由性能问题引出的,我最近还给业务搭建了一个基于监控系统,其实监控本身并不复杂,但监控系统对项目的工程化来说是个进步。有了监控后,我们可以全局地、直观地观测系统中各个组成部分的运转状态,尤其将监控数据以时序图形的方式展现出来后,可以发现单独检查系统状况时所难以发现的问题,比如磁盘占用率的发展趋势等。

但是现在的监控仍然有一个缺失,就是对系统组件内部状态观察能力的缺失。比如,我想看到cassandra更详细的运行负载,或者脚本报错的频率等。对于后面这类需求,可能就需要引入日志系统了,这也是后面一个可能要做的事情。

还有一点进步是日志意识。刚开始做数据处理时,脚本的日志输出和日志留存都做的不好,以至于难以通过日志发现问题,甚至因为日志丢失而难以定位程序发生的问题。现在这些脚本的日志还比较简陋,基本都是println出来的,后面看看有没有机会把日志这块完善起来,毕竟如果能把日志集中管理起来,当然是最好的。

正则表达式,也是我最近的一个收获。其实之前也不可谓不会写正则表达式,但总是忘点这个忘点那个。最近用到正则的地方还是挺多的,比如匹配我想要的日志、匹配特定模式的文件名、写监控系统的报警规则等等。我在看《正则指引》这本书,其实只看了前3章就基本上能涵盖我日常工作对正则表达式的所有需求了,也就是字符组、量词和分组。

大概就是这样,也许还有一些边边角角我一时都想不到的东西,但是想不起来可能也就意味着并不重要。我非常喜欢这份新工作,公司的环境、身边的同事、工作内容的挑战,都很好。