发现有同事还不会用 pprof 来排查性能问题。希望看完这篇文章以后能学会。
go 里自带的 pprof 是非常强大的工具。平常可以用来排查线上的 cpu 问题,内存问题。官方的 pprof 使用起来非常简单。如果你的进程是个 web
服务,只要:
import _ "net/http/pprof"
然后你的 web 应用就有了生成 profile 的能力。当线上出现问题的时候,如果是进程 cpu 占用过高,我们可以先用
昨天看到大佬们讨论摩拜和 ofo 谁会成,马化腾提到 ofo 使用的是 token 锁。又想起来半年前和同事们讨论过 ofo
这种离线的会变化的锁密码是怎么实现的。那时候也没有细想,不过现在看着 token 锁这个词。。想起来之前写过的这一篇:关于token
[http://xargin.com/about-token/]。原理应该都是一样的。
这里我们假装 geek。用上一篇讲的 token 原理可以很简单地设计出一套 ofo 这样的系统。先来看看 ofo 的系统有哪些组成要件:
车牌号
这两天想把之前写的工具提交到 awesome go 的 repo 里,所以特意研究了研究 awesome go 的入选 quality standard。
首先你的代码应该要在 goreportcard 上跑个结果:
goreport [https://goreportcard.com/report/github.com/cch123/elasticsql]
goreportcard 其实就是几种 lint 工具跑出来的一个结果集合。先不说代码必须要过 golint 和 go vet,
一般的 web 项目大概会被分为这么几层:
> dao/model
> service/logic/repository
> controller
> view
大多数项目会做前后分离,所以后端作为 api 就剩下了三层。实际上这三层里除了 logic/service
之外都和具体的业务逻辑没什么关系。controller 负责参数绑定/校验,dao 负责和存储打交道。之前在 ast 一文中已经讲了怎么样减少
controller 中的工作。这里来说说怎么能够自动生成 dao 层代码。
可能平常只在固定的框架和 orm
大多数编译型的语言都逃不开词法分析,语法分析(语义分析)、编译链接几个阶段。学生时代如果学习过编译原理,啃过龙书,接触过 lex 或者 yacc
的话,一定还对当初要求一周做出一个编译器这种任性大作业的噩梦记忆犹新。编译原理这个领域本身有一定的门槛,随便给你一段程序,你也不太好说就能很快地给出一个可用的词法分析器语法分析器(里面还有相当的体力活成分)。
幸运的是,我们抱到了亲爹 google 的大粗腿。在 golang
里官方已经提供了一套非常友好的词法分析和语法分析工具链。可以很方便地帮助你得到你想要的语法分析的结果:ast。有了 ast
我们就可以上天了(笑。正经点说,是我们可以基于 ast 做很多静态分析、