gopher china 2019小结

gopher china是go语言实践的线下分享,旨在促进go语言在国内的发展。今年本人有机会参加了一次。主讲的工程师来自于滴滴、知乎、哔哩哔哩等互联网公司。这里结合个人的工作经验谈谈我的感悟。

1.着眼于细节

我以前不管写代码还是设计表结构,并没有深入地考虑一些细节,比如表的命名是否能自释义、字段含义是否与别人的认知有偏差、代码是否易于理解、执行顺序是否直观、抽象是否恰当。这样或多或少挖了一些坑,比如多个逻辑处理有少许相似之处,就强行写成一段代码,这样虽然可能减少了部分代码量,但是非常不利于后期的维护和扩展。
本次gopher china有工程师分享了一些代码,这些代码有的其实是很简单的,但是重要的是为什么这么做。举个例子,redis的操作随便找个第三方库就可以实现,但是不建议在业务代码中直接引用redis第三方库,最好再引入一层中间层,业务代码调用中间层,中间层调用redis第三方库,这个中间层可以是一个接口,抽象出最基本的redis操作即可。其实不加中间层也可以实现业务功能,但是仔细思考,如果我们需要hack下redis的读写操作(不要以为用不到),修改第三库当然是一种解决方案,但不是最佳方案,可能还会带来一些问题,将hack的代码侵入到业务代码显然也不合适,这时中间层的作用就体现出来了。再细想下,如果底层redis的第三方库更换了,或者redis服务本身升级了(新版的总是会在性能方面有优化,并且还引入了一些新的特性),第三库的协议不能支持最新协议(这里是举个例子,一般而言都会向下兼容,但是新的特性第三方库就很可能就不支持了),那么就面临着底层驱动库的更换,如果不引入中间层,业务代码可能需要大面积的改动,有中间层,就可以在业务代码无感知的情况下完成替换。我工作工程中也遇到了类似的例子,当时情况是需要对memcached实例做迁移,考虑缓存预热的问题,需要对新实例进行数据写入,当时并没有合适的数据迁移方案,所以同事采用了双写的方案。如果没有中间这一层,想要优雅地解决memcached双写的问题是比较难的。这个事是我同事操作的,你当然也可以从中学习点东西。
上述的例子中实现的代码确实是很简单的,简单到我们直接就忽略了,拿来就用,但是背后的细节慢慢咀嚼,总会有一些味道的。本次gopher china很多工程师都分享了一些代码的细节,从代码实现难易程度来讲,拿来面试可能都不够格,但是这里面的细节我们需要关注,为什么这么做,可以避免什么问题,都是值得借鉴学习的。

2.基础很重要

操作系统、网络、算法、计算机语言这些都要了解一点,这样当bug来临时才不会感觉到无从下手,另外一方面当需要对程序进行性能优化时可以准确地定位瓶颈。
gopher china 有位探探的工程师分享了他们技术团队对minio的实践,讲述了如何搭建minio服务,完成对小图片存储性能的优化。在实践过程中遇到了一些问题,测试环境与线上环境的性能差异较大,测试环境比较完成,上了正式环境rt翻倍,是什么造成这种差异的?持久化存储服务和磁盘读写相关,磁盘读写又和os cache相关,是不是测试环境下的os cache命中率非常高,但是生产环境的命中率比较低?还是测试环境的磁盘读写较快,那么是不是测试环境中是顺序读写,生产环境是随机读写,磁盘都是ssd吗?这些都是可能导致差异的点,了解操作系统,可以让自己站在更高的角度看待这个问题。
面试是比较注重基础的,所以有面试造航母,工作拧螺丝一说。业务实现层面可能不需要太多的基础知识,但是了解下总是有好处的。

3.完善知识体系

后端工程的知识体系涉及很多,比如数据库、redis、缓存、队列、搜索等等,尽可能都去深入了解一下,并且需要了解这些技术是为了解决什么问题。目前为止我还未深入接触过微服务架构、k8s,这些事实上已经成为部分互联网公司技术体系重要的一部分,本次gopher china也有好几场在谈微服务架构。
不管何种技术架构,上述提到的基本都会在互联网公司用到,所以学会这些,到哪都是通用的。语言方面需要深入掌握一门,语言与语言之间的差异最好还是能多了解下,尝试用不同语言实现相同的一段代码。框架方面也需要了解一些业界常用的。

推荐阅读更多精彩内容