上文说了不要自己造轮子,要使用别人的轮子,这一文就说下使用别人的轮子要注意的事项。

上文的最后也说了,选择轮子的时候,要选择有人维护的,使用者多的轮子,这样可以避免一些问题。但是如果你的需求或者功能比较小众,这个领域轮子少,用的人也少,那么该如果选择?

我推荐如下几个策略。

  1. 向该领域的专家、前辈、同事请教,问下这个领域内大家都使用哪些轮子来处理的
  2. 同等条件下,优先使用大厂(比如Google,Alibaba)或大机构(如Apache)的轮子
  3. 同等条件下,优先使用issue活跃的轮子,这样至少出了问题,大家可以一起讨论,一起解决
  4. 同等条件下,优先使用代码逻辑清晰、优雅的代码,这样无论是对排查问题,甚至自行修改都是好的
  5. 最后的办法,就是自己造一个轮子了,但是如果能依赖别人的轮子来造,也是推荐的

选好的轮子,那么如果防范别人的轮子里有炸呢?我也推荐如下几条策略。

- 阅读剩余部分 -

不要自己造轮子

Don't repeat yourself

DRY这句话大家可能耳朵都听出茧子了。不过,这个确实是非常重要的一个填坑要诀。

拿正常的开发(非填坑)来说,使用别人造好的轮子可以大大提高效率和开发进度。
我上次用的别人的大轮子是开发微信公众号和小程序的时候,用的wechat这个开源lib。使得集成微信的工作量大大减少,不必看微信那么多的文档和接口。

专门拿填坑来说,使用别人造好的轮子比正常开发要显得还重要一些。当然这里的轮子主要是原来工程中使用的轮子了。尽量使用工程中原来使用的轮子,别自己造,更别使用其他人的轮子。

我见过最常最轮子的方法就是类似于StringUtils和CollectionUtils这种,用来判断empty,用来split等。


- 阅读剩余部分 -

本周开始做搜索功能优化,这边的搜索功能主要用的是ES。代码写好提测给测试同学的时候,测试同学说搜不出东西,我排查了下,是ES的索引的mapping同线上不一致,线上的mapping增加了三个分词插件,分别是ik,NGram,pinyin,搜索的时候对这些插件扩展字段进行的搜索。

现在就是要把测试环境的索引mapping修改成同线上一致的,我采用的是下面的方案:

  1. 新建一个原索引(index)的备份索引(index_bak),这个备份索引采用线上一致的settings和mappings,可以直接将线上的settings和mappings复制到json文件里。

    curl -XPUT 'http://127.0.0.1:9200/index_bak' -d '@create_index_bak.json'

- 阅读剩余部分 -

我转到现在这个海外事业部的时候,这边使用的开发环境和测试环境都是docker。每个开发者都有自己的docker开发环境,自测通过后,部署到测试环境。

但是使用的时候,发现开发环境和测试环境都有一个问题,就是不论是service还是portal的日志,每30分钟就被清空了,我以为是被log4j归档了,看了下归档文件夹,里面有这个日志文件,但是文件为空。

这个问题实实在在困扰我了好久,因为无法追查历史日志,导致测试报问题的时候,只能去重现实时tail日志,非常麻烦。

我一开始以为就是log4j配置的归档时间是每30分钟,但是我看了log4j的配置文件,是1个小时,线上也是这个配置,线上没有这个问题。

后来我怀疑,是不是这个docker本身对某些卷定时操作,但是我看了下docker的启动配置,也没有。

并且,每个人的开发环境和测试的测试环境都有这个问题,很很很很奇怪!

再来后,开发任务紧张,这件事就放下了。

- 阅读剩余部分 -

首先,crontab要执行的任务要有输出日志,表明任务执行过。

然后,另起一个crontab任务,去监控上面的这个日志,比较日志的更新时间,判断任务是否执行,从而提醒。

下面是我在实际生产环境中使用的一个脚本示例:

timestamp() {
  date +"%s"
}
url="http://报警url"

last_mofidy_timestamps="$(stat -c %Y /home/example/example.log)"
echo $last_mofidy_timestamps

current_timestamps="$(timestamp)"
echo $current_timestamps

if (($current_timestamps - $last_mofidy_timestamps > 3600)); then
    curl $url
fi