共计 6881 个字符,预计需要花费 18 分钟才能阅读完成。
情谊提醒:此篇文章大概须要浏览 20 分钟 33 秒,不足之处请多指教,感激你的浏览。订阅本站
此文章首发于 Debug 客栈 |https://www.debuginn.cn
Go 语言是一种强类型、编译型的语言,在开发过程中,代码标准是尤为重要的,一个小小的失误可能会带来重大的事变,领有一个良好的 Go 语言开发习惯是尤为重要的,恪守开发标准便于保护、便于浏览了解和减少零碎的健壮性。
以下是咱们项目组开发标准加上本人开发遇到的问题及补充,心愿对你有所帮忙:
注:咱们将以下束缚分为三个等级,别离是:【强制】、【举荐】、【参考】。
Go 编码相干
【强制】代码格调标准遵循 go 官网规范:CodeReviewComments,请应用官网 golint lint 进行格调动态剖析;
【强制】代码格局标准按照 gofmt
,请装置相干 IDE 插件,在保留代码或者编译时,主动将源码通过gofmt
做格式化解决,保障团队代码格局统一(比方空格,递进等)
【强制】业务解决代码中不能开 goroutine
,此举会导致goroutine
数量不可控,容易引起零碎雪崩,如果须要启用 goroutine
做异步解决,请在初始化时启用固定数量 goroutine
,通过channel
和业务解决代码交互,初始化 goroutine
的函数,原则上应该从 main
函数入口处明确的调用:
func crond() {defer func() {if err := recover(); err != nil {// dump stack & log}
}()
// do something
}
func main() {
// init system
go crond()
go crond2()
// handlers
}
【强制】异步开启 goroutine
的中央(如各种 cronder
),须要在最顶层减少recover()
,捕获panic
,防止个别cronder
出错导致整体退出:
func globalCrond() {
for _ := ticker.C {projectCrond()
itemCrond()
userCrond()}
}
func projectCrond() {defer func() {if err := recover(); err != nil {// 打日志,并预警}
}
// do
}
【强制】当有并发读写 map
的操作,必须加上读写锁 RWMutex
,否则go runtime
会因为并发读写报 panic
,或者应用sync.Map
代替;
【强制】对于提供给内部应用的 package
,返回函数里必须带上err
返回,并且保障在 err == nil
状况下,返回后果不为nil
,比方:
resp, err := package1.GetUserInfo(xxxxx)
// 在 err == nil 状况下,resp 不能为 nil 或者空值
【强制】当操作有多个层级的构造体时,基于 防御性编程 的准则,须要对每个层级做空指针或者空数据判断,特地是在解决简单的页面构造时,如:
type Section struct {
Item *SectionItem
Height int64
Width int64
}
type SectionItem struct {
Tag string
Icon string
ImageURL string
ImageList []string
Action *SectionAction
}
type SectionAction struct {
Type string
Path string
Extra string
}
func getSectionActionPath(section *Section) (path string, img string, err error) {
if section.Item == nil || section.Item.Action == nil { // 要做好足够进攻,防止因为空指针导致的 panic
err = fmt.Errorf("section item is invalid")
return
}
path = section.Item.Action.Path
img = section.Item.ImageURL
// 对取数组的内容,也肯定加上防御性判断
if len(section.Item.ImageList) > 0 {img = section.Item.ImageList[0]
}
return
}
【举荐】生命期在函数内的资源对象,如果函数逻辑较为简单,倡议应用 defer
进行回收:
func MakeProject() {conn := pool.Get()
defer pool.Put(conn)
// 业务逻辑
...
return
}
对于生命期在函数内的对象,定义在函数内,将应用栈空间,缩小 gc
压力:
func MakeProject() (project *Project){project := &Project{} // 应用堆空间
var tempProject Project // 应用栈空间
return
}
【强制】不能在循环里加 defer
,特地是defer
执行回收资源操作时。因为 defer
是函数完结时能力执行,并非循环完结时执行,某些状况下会导致资源(如连贯资源)被大量占用而程序异样:
// 反例:for {row, err := db.Query("SELECT ...")
if err != nil {...}
defer row.Close() // 这个操作会导致循环里积攒许多长期资源无奈开释
...
}
// 正确的解决,能够在循环完结时间接 close 资源,如果解决逻辑较简单,能够打包成函数:for {func () {row, err := db.Query("SELECT ...")
if err != nil {...}
defer row.Close()
...
}()}
【举荐】对于可预感容量的 slice
或者 map
,在make
初始化时,指定 cap
大小,能够大大降低内存损耗,如:
headList := make([]home.Sections, 0, len(srcHomeSection)/2) tailList := make([]home.Sections, 0, len(srcHomeSection)/2)
dstHomeSection = make([]*home.Sections, 0, len(srcHomeSection))
….
if appendToHead {headList = append(headList, info)
} else {tailList = append(tailList, info)
}
….
dstHomeSection = append(dstHomeSection, headList…)
dstHomeSection = append(dstHomeSection, tailList…)
【举荐】逻辑操作中波及到频繁拼接字符串的代码,请应用 bytes.Buffer
代替。应用 string
进行拼接会导致每次拼接都新增 string
对象,减少 GC
累赘:
// 正例:var buf bytes.Buffer
for _, name := range userList {buf.WriteString(name)
buf.WriteString(",")
}
return buf.String()
// 反例:var result string
for _, name := range userList {result += name + ","}
return result
【强制】对于固定的正则表达式,能够 在全局变量初始化时实现预编译,能够无效放慢匹配速度,不须要在每次函数申请中预编译:
var wordReg = regexp.MustCompile("[w]+")
func matchWord(word string) bool {return wordReg.MatchString(word)
}
【举荐】JSON 解析时,遇到不确定是什么构造的字段,倡议应用 json.RawMessage
而不要用 interface
,这样能够依据业务场景,做二次unmarshal
而且性能比 interface
快很多;
【强制】锁应用的粒度须要依据理论状况进行把控,如果变量只读,则无需加锁;读写,则应用读写锁sync.RWMutex
;
【强制】应用随机数时 (math/rand
),必须要做随机初始化(rand.Seed
),否则产生出的随机数是可预期的,在某些场合下会带来平安问题。个别状况下,应用math/rand
能够满足业务需要,如果开发的是平安模块,倡议应用crypto/rand
,安全性更好;
【举荐】对性能要求很高的服务,或者对程序响应工夫要求高的服务,应该防止开启大量 gouroutine
;
阐明:官网尽管号称 goroutine
是便宜的,能够大量开启 goroutine
,然而因为goroutine
的调度并没有实现优先级管制,使得一些关键性的goroutine
(如网络 / 磁盘 IO,管制全局资源的goroutine
)没有及时失去调度而拖慢了整体服务的响应工夫,因此在零碎设计时,如果对性能要求很高,应防止开启大量goroutine
。
打点标准
【强制】打点应用. 来做分隔符,打点名称须要蕴含业务名,模块,函数,函数解决分支等,参考如下:
// 业务名. 服务名. 模块. 性能. 办法
service.gateway.module.action.func
【强制】打点应用场景是监控零碎的实时状态,不适宜存储任何业务数据;
【强制】在打点个数太多时,展现时速度会变慢。倡议单个服务打点的 key 不超过 10000 个,key
中单个维度不同值不超过 1000 个(千万不要用 user_id 来打点);
【举荐】如果展现的时候须要拿成千盈百个 key
的数据通过 Graphite
的聚合函数做聚合,最初失去一个或几个 key
。这种状况下能够在打点的时候就把这个要聚合的点聚合好,这样展现的时候只有拿这几个 key,对展现速度是微小的晋升。
日志相干
【强制】日志信息需带上下文,其中 logid
必须带上,同一个申请打的日志都需带上 logid
,这样能够依据logid
查找该次申请相干的信息;
【强制】对debug/notice/info
级别的日志输入,必须应用条件输入或者应用占位符形式,防止应用字符拼接形式:
log.Debug("get home page failed %s, id %d", err, id)
【强制】如果是解析 json
出错的日志,须要将报错 err
及原内容一并输入,以不便核查起因;
【举荐】对 debug/notice/info
级别的日志,在打印日志时,默认不显示调用地位(如 /path/to/code.go:335)
阐明:go
获取调用栈信息是比拟耗时的操作(runtime.Caller
),对于性能要求很高的服务,特地是大量调用的中央,应尽量避免开发人员在应用该性能时,需知悉这个调用带来的代价。
Redis 相干
【举荐】对立应用 :
作为前缀后缀分隔符,这里能够依据 Redis
中间件 key proxy
怎么解析剖析 Key
进行自定义,便于根底服务的数据可视化及问题排查;
【强制】防止应用 HMGET/HGETALL/HVALS/HKEYS/SMEMBERS
阻塞命令这类命令在 value
较大时,对 Redis 的 CPU/ 带宽耗费较高,容易导致响应过慢引发零碎雪崩;
【强制】不可把 Redis 当成存储,如有统计相干的需要,能够思考异步同步到数据库进行统计,Redis 应该回归缓存的实质;
【举荐】防止应用大 key,按教训超过 10k 的 value,能够压缩 (gzip/snappy
等算法)后存入内存,能够缩小内存应用,其次升高网络耗费,进步响应速度:
value, err := c.RedisCache.GetGzip(key)
….
c.RedisCache.SetExGzip(content, 60)
【举荐】Redis 的分布式锁,能够应用:
lock: redis.Do("SET", lockKey, randint, "EX", expire, "NX")
unlock: redis.GetAndDel(lockKey, randint) // redis 暂不反对,能够用 lua 脚本
【举荐】尽量避免在逻辑循环代码中调用 Redis,会产生流量放大效应,申请量较大时需采纳其余办法优化(比方动态配置文件);
【举荐】key
尽量离散读写,通过 uid/imei/xid
等跟用户 / 申请相干的后缀摊派到不同分片,防止分片负载不平衡;
【参考】当缓存量大,申请量较高,可能超出 Redis 接受范畴时,可充分利用本地缓存 (localcache)+redis
缓存的组合计划来缓解压力,削减峰值:
应用这个办法须要具备这几个条件:
- cache 内容与用户无关,key 状态不多,属于公共信息;
- 该 cache 内容时效性较高,然而访问量较大,有峰值流量。
key := "demoid:3344"
value := localcacche.Get(key)
if value == "" {value = rediscache.Get(key)
if value != "" {
// 随机缓存 1~5s,各个机器间错开峰值,只有比 redis 缓存短即可
localcache.SetEx(key, value, rand.Int63n(5)+1)
}
}
if value == "" {
....
// 从其余零碎或者数据库获取数据
appoint.GetValue()
// 同时设置到 redis 及 localcache 中
rediscache.SetEx(key, content, 60)
localcache.SetEx(key, content, rand.Int63n(5)+1)
}
【参考】对于申请量高,实时性也高的内容,如果纯正应用缓存,当缓存生效霎时,会导致大量申请穿透到后端服务,导致后端服务有雪崩危险:
如何兼顾扛峰值,爱护后端系统,同时也能放弃实时性呢?在这种场景下,能够采纳随机更新法更新数据,办法如下:
- 失常申请从缓存中读取,缓存生效则从后端服务获取;
- 在申请中依据随机概率 1%(或者依据理论业务场景设置比率)会跳过读取缓存操作,间接从后端服务获取数据,并更新缓存。
这种做法能保障最低时效性,并且当访问量越大,更新概率越高,使得内容实时性也越高。
如果联合上一条 localcache+rediscache
做一二级缓存,则能够达到扛峰值同时放弃实时性。
数据库相干
【强制】操作数据库 sql 必须应用 stmt 格局,应用占位符代替参数,禁止拼接 sql;
【强制】SQL 语句查问时,不得应用 SELECT (即形如 SELECT FROM tbl WHERE),必须明确的给出要查问的列名,防止表新增字段后报错;
【强制】对于线上业务 SQL,需保障命中索引,索引设计基于业务需要及字段区分度,个别可辨别状态不高的字段(如 status 等只有几个状态),不倡议加到索引中;
【强制】在成熟的语言中,有实体类,数据拜访层 (repository / dao
) 和业务逻辑层 (service
);在咱们的标准中存储实体struct
搁置于 entities
包下;
【强制】对于联结索引,需将区分度较大的字段放后面,区分度小放前面,查找时能够缩小被检索数据量;
-- 字段区分度 item_id > project_id
alter table xxx add index idx_item_project (item_id, project_id)
【强制】所有数据库表必须有主键 id;
【强制】主键索引名为 pk 字段名; 惟一索引名为 uk 字段名; 一般索引名则为 idx_字段名;
【强制】避免因字段类型不同造成的隐式转换,导致索引生效,造成全表扫描问题;
【强制】业务上有惟一个性的字段,即便是多字段的组合,也必须建成惟一索引;
【强制】个别事务规范操作流程:
func TestTXExample(t *testing.T) {
// 关上事务
tx, err := db.Beginx()
if err != nil {log.Fatal("%v", err)
return
}
// defer 异样
needRollback := true
defer func() {if r := recover(); r != nil { // 解决 recover,防止因为 panic,资源无奈开释
log.Fatal("%v", r)
needRollback = true
}
if needRollback {xlog.Cause("test.example.transaction.rollback").Fatal()
tx.Rollback()}
}()
// 事务的逻辑
err = InsertLog(tx, GenTestData(1)[0])
if err != nil {log.Fatal("%v", err)
return
}
// 提交事务
err = tx.Commit()
if err != nil {log.Fatal("%v", err)
return
}
needRollback = false
return
}
【强制】执行事务操作时,请确保 SELECT ... FOR UPDATE
条件命中索引,应用行锁,防止一个事务锁全表的状况;
【强制】禁止超过三个表的 join
,须要join
的字段,数据类型必须统一,多表关联查问时,保障被关联的字段有索引;
【强制】数据库 max_open
连接数不可设置过高,会导致代理连接数打满导致不可用情况;