这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记
1 高质量编程
1.1 简介
- 高质量：编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码
- 正确性：是否考虑各种边界条件，错误的调用是否能够处理
- 可靠性：异常情况或者错误的处理策略是否明确，依赖的服务出现异常是否能够处理
- 简洁：逻辑是否简单，后续调整功能或新增功能是否能够快速支持
- 清晰：其他人在阅读理解代码的时候是否能够清楚明白，重构或者修改功能是否不会担心出现无法预料的问题
- 编程原则：
- 简单性：以简单清晰的逻辑编写代码
- 可读性：使代码可以进行维护
- 生产力：团队整体工作效率非常重要
1.2 编码规范
1.2.1 代码格式
- 可以使用gofmt自动格式化代码，保证代码与官方推荐格式保持一致
- 可以使用goimports对依赖包进行管理，自动增删依赖的包引用，按照字母序排序分类
1.2.2 注释
- 注释应该解释代码作用：适合说明公共符号，比如对外提供的函数注释描述它的功能和用途
- 注释应该解释代码如何做的：对代码中复杂的，并不明显的逻辑进行说明，适合注释实现过程
- 注释应该解释代码实现的原因：适合解释脱离上下文后很难理解的代码的外部因素，提供额外上下文
- 注释应该解释代码什么情况会出错：适合解释代码的限制条件或者会无法处理的情况
- 包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
- 任何既不明显也不简短的公共功能必须予以注释
- 无论长度或复杂程度如何，对库中的任何函数都必须进行注释
1.2.3 命名规范
- 对于变量：
- 简洁胜于冗长
- 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
- 例如使用ServeHTTP而不是ServeHttp
- 使用XMLHTTPRequest或者xmlHTTPRequest
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
- 对于函数：
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
- 当名为 foo 的包某个函数返回类型 T 时（T 并不是 Foo），可以在函数名中加入类型信息
- 比如http包中创建服务的函数命名为Serve比命名为ServeHTTP要好，因为使用http.Serve()比起使用http.ServeHTTP，不携带包名的上下文信息，同时也尽量的简短
- 对于包package：
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如 schema、task 等
- 不要与标准库同名。例如不要使用 sync 或者 strings
- 同时要尽量满足以下规则：
- 不使用常用变量名作为包名，例如使用bufio而不是buf
- 使用单数而不是复数，例如使用encoding而不是encodings
- 谨慎地使用缩写，例如使用fmt在不破坏上下文的情况下比format更加简短
- 核心目标是降低阅读理解代码的成本
- 重点考虑上下文信息，设计简洁清晰的名称
1.2.4 控制流程
- 避免嵌套，保持正常流程清晰
- 比如如果两个分支中都包含return语句，则可以去除冗余的else方便后续维护，else一般是正常流程，如果需要在正常流程新增判断逻辑，避免分支嵌套
- 尽量保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
- 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
- 正常流程代码沿着屏幕向下移动
- 提高代码的可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
1.2.5 错误和异常处理
- 简单错误处理
- 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用errors.New来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用fmt.Errorf
- 错误的Wrap和Unwrap
- 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链，提供简明的上下文信息链，方便定位问题
- 在fmt.Errorf中使用%w关键字来将一个错误关联至错误链中
- Go1.13 在 errors 中新增了三个新 API 和一个新的 format 关键字，分别是 errors.Is、errors.As 、errors.Unwrap 以及 fmt.Errorf 的 %w。如果项目运行在小于 Go1.13 的版本中，导入 golang.org/x/xerrors 来使用。
- 错误判定
- 判定一个错误是否为特定错误，使用errors.Is
- 不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误
- 在错误链上获取特定种类的错误，使用errors.As
- panic
- 不建议在业务代码中使用 panic
- 用于真正异常的情况
- 调用函数不包含recover会造成程序崩溃
- 若问题可以被屏蔽或解决，可以使用error代替panic
- 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic
- recover
- recover只能在当前goroutine的被defer的函数中使用
- 嵌套无法生效
- 只在当前 goroutine 生效
- defer的语句是后进先出
- 如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈。
1.3 性能优化建议
- 简介：
- 性能优化的前提是满足正确可靠、简洁清晰等质量因素
- 性能优化是综合评估，有时候时间效率和空间效率可能对立
- 避免常见的性能陷阱可以保证大部分程序的性能
- 普通应用代码，不要一味地追求程序的性能
- 越高级的性能优化手段越容易出现问题
- 在满足正确可靠、简洁清晰的资料要求的前提下提高程序性能
1.3.1 Benchmark
- 使用命令：
go test -bench=. -benchmem，-benchmem表示也统计内存信息- 示例：
- BenchmarkSelect是测试函数名，-8表示GOMAXPROCS的值为8，48294985表示一共执行的次数，25.4 ns/op表示每次执行花费时间，后面两个参数分别表示每次执行申请多大的内存以及申请几次内存
- 示例：
1.3.2 Slice
- slice在使用时的一个建议是预分配内存，尽可能在使用make()初始化切片时提供容量信息，特别是在追加切片的时候
- 切片本质是一个数组片段的描述，包括了数组的指针，片段的长度、片段容量(不改变内存分配情况下的最大长度)，切片操作并不复制切片指向的元素，创建一个新的切片会复用原来切片的底层数组，因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置cap的值能够避免额外的内存分配，获得最好的性能
- 另一个建议是使用copy替代re-slice，以解决大内存未释放引起的问题
- 原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放，通过copy，指向了一个新的底层数组，当原切片的底层数组在内存中不再被引用时，内存就会被垃圾回收
1.3.3 Map
- map在使用时的一个建议是预分配内存
- 不断向map中添加元素的操作会触发map的扩容
- 提前分配好空间可以减少内存拷贝和Rehash的消耗
- 建议根据实际需求提前预估好需要的空间
1.3.4 字符串处理
- 使用 strings.Builder
- 使用+拼接性能最差，strings.Builder，bytes.Buffer相近，strings.Builder更快
- 字符串在Go语言中是不可变类型，占用内存大小是固定的
- 使用 + 每次都会重新分配内存
- strings.Builder和bytes.Buffer底层都是 []byte 数组
- bytes.Buffer转化为字符串时重新申请了一块空间
- strings.Builder直接将底层的[]byte转换成了字符串类型返回
- 内存扩容策略，不需要每次拼接重新分配内存
- 使用+拼接性能最差，strings.Builder，bytes.Buffer相近，strings.Builder更快
1.3.5 空结构体
- 使用空结构体节省内存
- 空结构体struct{}实例不占据任何的内存空间
- 可作为各种场景下的占位符使用，节省资源
- 实现Set，可以考虑用map来代替
- 只需要用到map的键，而不需要值
- 即使将map的值设置为bool类型，也会多占据1个字节空间
1.3.6 使用atomic包
- 多线程编程场景，可以保证线程安全
- 锁的实现是通过操作系统来实现，属于系统调用
- atomic 操作是通过硬件实现的，效率比锁高很多
- sync.Mutex应该用来保护一段逻辑，不仅仅用于保护一个变量
- 对于非数值系列，可以使用atomic.Value，能承载一个interface{}
2 性能调优实战
2.1 简介
- 性能调优原则
- 要依靠数据不是猜测
- 要定位最大瓶颈而不是细枝末节
- 不要过早优化
- 不要过度优化
2.2 性能分析工具 pprof
- 希望知道应用在什么地方耗费了多少CPU、Memory
- pprof是用于可视化和分析性能分析数据的工具
2.2.1 pprof - 功能简介
- 分析部分：
- 有两种方式：网页、可视化终端
- 工具部分：
- 可以在runtime/pprof中找到源码
- 同时Golang的http标准库中也对pprof做了一些封装，可以在http服务中直接使用
- 采样部分：
- 它可以采样程序运行时的CPU、堆内存、goroutine、锁竞争、阻塞调用和系统线程的使用数据
- 展示部分：
- 用户可以通过列表、调用图、火焰图、源码、反汇编等视图去展示采集到的性能指标，方便分析
2.2.2 pprof - 排查实战
- 实践项目：github.com/wolfogre/go…
- 项目中提前埋入了一些炸弹代码，产生可观测的性能问题
- 浏览器查看指标
- 在项目文件夹目录下，输入命令
go run main.go，然后在浏览器输入http://localhost:6060/debug/pprof/，打开网站，页面展示了可用的程序运行采样数据：- allocs：内存分配情况
- blocks：阻塞操作情况
- cmdline：程序启动命令，显示运行进程的命令
- goroutine：当前所有goroutine的堆栈信息
- heap：堆上内存使用情况（同alloc）
- mutex：锁竞争操作情况
- profile：CPU占用情况
- threadcreate：当前所有创建的系统线程的堆栈信息
- trace：程序运行跟踪信息
- 在项目文件夹目录下，输入命令
- 排查CPU问题：
- 输入命令：go tool pprof + 采样链接
- 示例：go tool pprof 'http://localhost:6060/debug/pprof/profile?seconds=10'，链接结尾的profile代表采样的对象是CPU使用，启动一个10s的采样，最后展示出pprof终端
- 输入top，可以查看占用资源最多的函数，默认会显示10个：
- flat：当前函数本身的执行耗时
- flat%：flat占CPU总时间的比例
- sum%：上面每一行的flat%总和
- cum：指当前函数本身加上其调用函数的总耗时
- cum%：cum占CPU总时间的比例
- 输入topN，可以查看资源占用最高的N个函数
- 输入list+函数，可以查看函数具体问题：
- 输入web，可以生成一张调用关系图，默认使用浏览器打开
- 输入top，可以查看占用资源最多的函数，默认会显示10个：
- 排查Heap - 堆内存：
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/heap"
- 通过-http=:8080参数，可以开启pprof自带的Web UI，以网页的方式呈现
- alloc_objects：程序累计申请的对象数
- alloc_space：程序累计申请的内存大小
- inuse_objects：程序当前持有的对象数
- inuse_space：程序当前占用的内存大小
- 通过-http=:8080参数，可以开启pprof自带的Web UI，以网页的方式呈现
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/heap"
- 排查goroutine - 协程
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/goroutine"
- 可以使用火焰图展示调用关系
- 由上到下表示调用顺序
- 每一块代表一个函数，越长代表占用CPU的时间更长
- 火焰图是动态的，支持点击块进行分析
- 可以使用火焰图展示调用关系
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/goroutine"
- 排查mutex - 锁
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/mutex"
- 可以在Graph视图中定位出现问题的函数
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/mutex"
- 排查block - 阻塞
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"
- 可以在Graph视图中定位出现问题的函数
- 输入命令：go tool pprof -http=:8080 "http://localhost:6060/debug/pprof/block"
2.3 性能分析工具 pprof - 采样过程和原理
- CPU
- 采样对象：函数调用和它们占用的时间
- 采样率：100次/秒，固定值
- 采样时间：从手动启动到手动结束
- 过程：开始采样->设定信号处理函数->开启定时器，停止采样->取消信号处理函数->关闭定时器
- 操作系统：每10ms向进程发送一次SIGPROF信号
- 进程：每次接收到SIGPROF会记录调用堆栈
- 写缓冲：每100ms读取已经记录的调用栈并写入输出流
- Heap - 堆内存
- 采样程序通过内存分配器在堆上分配和释放的内存，记录分配/释放的大小和数量
- 采样率：每分配512KB记录一次，可在运行开头修改，1为每次分配均记录
- 采样时间：从程序运行开始到采样时
- 采样指标：alloc_objects，alloc_space，inuse_objects，inuse_space
- 计算方式：inuse = alloc - free
- Goroutine - 协程
- 记录所有用户发起且在运行中的goroutine（即入口非runtime开头的）runtime.main的调用栈信息
- 过程：Stop The World->遍历allg切片->输出创建g的堆栈->Start The World
- ThreadCreate - 线程创建
- 记录程序创建的所有系统线程的信息
- 过程：Stop The World->遍历allg链表->输出创建m的堆栈->Start The World
- Block - 阻塞
- 采样阻塞操作的次数和耗时
- 采样率：阻塞耗时超过阈值的才会被记录，1为每次阻塞均记录
- 过程：阻塞操作->上报调用栈和消耗时间给Profiler->时间未到阈值则丢弃，否则采样并遍历阻塞记录->统计阻塞次数和耗时
- Mutex - 锁
- 采样争抢锁的次数和耗时
- 采样率：只记录固定比例的锁操作，1为每次加锁均记录
- 过程：锁竞争操作->上报调用栈和消耗时间给Profiler->比例未命中则丢弃，否则采样并遍历锁记录->统计锁竞争次数和耗时
3 性能调优案例
- 基本概念
- 服务：能单独部署，承载一定功能的程序
- 依赖：Service A的功能实现依赖Service B的响应结果，称为Service A依赖Service B，图中的Service B被Service A依赖，同时也依赖了存储和Service D
- 调用链路：能支持一个接口请求的相关服务集合及其相互之间的依赖关系
- 基础库：公共的工具包、中间件
3.1 业务服务优化
- 流程
- 建立服务性能评估手段
- 分析性能数据，定位性能瓶颈
- 重点优化项改造
- 优化效果验证
- 建立服务性能评估手段
- 服务性能评估方式
- 单独benchmark无法满足复杂逻辑分析
- 不同负载情况下性能表现差异
- 请求流量构造
- 不同请求参数覆盖逻辑不同
- 线上真实流量情况
- 压测范围
- 单机器压测
- 集群压测
- 性能数据采集
- 单机性能数据
- 集群性能数据
- 服务性能评估方式
- 分析性能数据，定位性能瓶颈
- 可以通过火焰图进行分析
- 存在的问题可能有：
- 使用库不规范
- 高并发场景优化不足
- 重点优化项分析
- 正确性是基础
- 响应数据diff
- 线上请求数据录制回放
- 新旧逻辑接口数据diff
- 优化效果验证
- 重复压测验证
- 上线评估优化效果
- 关注服务监控
- 逐步放量
- 收集性能数据
- 进一步优化，服务整体链路分析
- 规范上游服务调用接口，明确场景需求
- 分析链路，通过业务流程优化提升服务性能
3.2 基础库优化
- AB实验SDK的优化
- 分析基础库核心逻辑和性能瓶颈
- 设计完善改造方案
- 数据按需获取
- 数据序列化协议优化
- 内部压测验证
- 推广业务服务落地验证
- 分析基础库核心逻辑和性能瓶颈
3.3 Go 语言优化
- 编译器&运行时优化
- 优化内存分配策略
- 优化代码编译流程，生成更高效的程序
- 内部压测验证
- 推广业务服务落地验证
- 优点：
- 接入简单，只需要调整编译配置
- 通用性强
4 个人思考
Go语言的高质量编程需要从编码规范和性能优化两个方面入手，编码规范方面，包括代码格式、注释、命名规范、控制流程、错误和异常处理等，性能优化方面，可以使用Go语言自带的基准测试工具和命令对性能进行测试，可以从Slice、Map、字符串处理、空结构体、使用atomic包方面优化程序性能。可以使用性能分析工具pprof对程序的性能进行分析，排查问题，最后优化性能。
