比如说某网站有一个文件列表，用户点哪个就可以下载哪个，如果用户想下载多个，无非就是多点几次而已。于是需求来了：当用户想下载多个文件的时候，可以通过一次点击完成打包下载操作。

听起来似乎并不复杂，服务端可以把用户想要下载的文件打包成一个新文件，然后用户点一次就可以下载了，但是这样做有以下几个缺点：

• 浪费了时间，多了创建新文件的流程。
• 浪费了空间，同样的文件被多次存储。
• 用户体验差，下载必须要等到新文件创建好才能开始。

不难得出结论：动态流式下载才是正解，同事提到 tar 可以搞定，于是研究一下：

shell> cat test_0.txt 
xxx
xxx
shell> cat test_1.txt 
yyy
yyy
shell> tar cf test.tar test_0.txt test_1.txt
shell> cat test.tar 
test_0.txt00006440...01014257504126011510 0ustar rootrootxxx
xxx
test_1.txt00006440...01014257504241011507 0ustar rootrootyyy
yyy

如上可见，tar 文件的格式非常简单，多个文件的内容从上到下依次排列，只不过每个文件内容的前面附加了一个头，其中保存了诸如文件名，权限之类的信息。

看上去用 tar 的话确实可以搞定动态流式下载，不过 tar 有个缺点，普通用户搞不清 tar 文件类型是什么东西，相比较而言，他们更乐于接受 zip 文件类型。

不过 zip 文件类型的格式可要比 tar 复杂，我从 wikipedia 找到下图：

zip

对于凡夫俗子的我来说，想要通过手撸 zip 格式来实现动态流式下载绝非易事，就在举棋不定之际，我突然发现 golang 的 zip 标准库已经实现了 Writer 接口，这就意味着，我们只要结合使用 zip.NewWriter 和 http.ResponseWriter 就能实现我们的目的：

package main

import (
	"archive/zip"
	"fmt"
	"io"
	"net/http"
	"os"
)

func main() {
	http.HandleFunc("/test", test)
	http.ListenAndServe(":8080", nil)
}

func test(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/zip")
	w.Header().Set("Content-Disposition", "attachment; filename=test.zip")
	writer := zip.NewWriter(w)
	for i := 0; i < 2; i++ {
		name := fmt.Sprintf("test_%d.txt", i)
		srcFile, err := os.Open(name)
		if err != nil {
			panic(err)
		}
		defer srcFile.Close()
		dstFile, err := writer.Create(name)
		if err != nil {
			panic(err)
		}
		if _, err := io.Copy(dstFile, srcFile); err != nil {
			panic(err)
		}
	}
	writer.Close()
}

如上代码编译运行后，打开浏览器，执行 http://localhost:8080/test 即可看到效果。

为了降低使用 eBPF 的门槛，社区开发了 bcc，bpftrace 等工具，因为 bpftrace 在语法上贴近 awk，所以我一眼就爱上了，本文将通过它来讲解如何用 eBPF 分析 Golang 应用。

通过 bpftrace 分析 golang 方法的参数和返回值

下面是演示代码 main.go，我们的目标是通过 bpftrace 分析 sum 方法的输入输出：

package main

func main() {
	println(sum(11, 22))
}

func sum(a, b int) int {
	return a + b
}

在编译的时候，记得关闭内联，否则一旦 sum 被内联了，eBPF 就没法加探针了：

shell> go build -gcflags="-l" ./main.go
shell> objdump -t ./main | grep -w sum
000000000045dd60 g F .text 0000000000000033 main.sum

准备工作做好之后，我们就可以通过如下 bpftrace 命令来监控 sum 的输入输出了：

shell> bpftrace -e '
    uprobe:./main:main.sum {printf("a: %d b: %d\n", sarg0, sarg1)}
    uretprobe:./main:main.sum {printf("retval: %d\n", retval)}
'
a: 11 b: 22
retval: 33

不过测试发现，如上 bpftrace 命令仅在 go1.17 之前的版本工作正常，在 go1.17 之后的版本，sargx 变量取不到数据，这是因为从 go.1.17 开始，参数不再保存在栈里，而是保存在寄存器中，关于这一点在 Go internal ABI specification 中有详细的描述：

amd64 architecture
The amd64 architecture uses the following sequence of 9 registers for integer arguments and results:
RAX, RBX, RCX, RDI, RSI, R8, R9, R10, R11

让我们通过 gdb 来验证这一点：

shell> gdb ./main
(gdb) # 设置断点
(gdb) b main.sum
(gdb) # 运行
(gdb) r
(gdb) # 查看寄存器
(gdb) i r
rax 0xb 11
rbx 0x16 22

如上可见：main.sum 的第一个参数保存在 rax 寄存器，第二个参数保存在 rbx 寄存器，和 Go internal ABI specification 中的描述一致。

搞清楚这些之后，我们就知道在 go1.17 以后的版本，如何用 bpftrace 监控输入输出了：

shell> bpftrace -e '
    uprobe:./main:main.sum {printf("a: %d b: %d\n", reg("ax"), reg("bx"))}
    uretprobe:./main:main.sum {printf("retval: %d\n", retval)}
'
a: 11 b: 22
retval: 33

说到这，细心的读者可能已经发现：我们一直在讨论整形，如果是字符串该怎么办？我们不妨构造一个字符串的例子再来测试一下，本次测试是在 go1.17 下进行的：

下面是演示代码 main.go，我们的目标是通过 bpftrace 分析 concat 方法的输入输出：

package main

func main() {
	println(concat("ab", "cd"))
}

func concat(a, b string) string {
	return a + b
}

让我们通过 gdb 来看看 go1.17 中字符串参数是怎么传递的：

shell> go build -gcflags="-l" ./main.go
shell> gdb ./main
(gdb) # 设置断点
(gdb) b main.concat
(gdb) # 运行
(gdb) r
(gdb) # 查看参数
(gdb) i args
x = 0x461513 "ab"
y = 0x461515 "cd"
(gdb) # 查看寄存器
(gdb) i r
rax 0x461513 4592915
rbx 0x2 2
rcx 0x461515 4592917
rdi 0x2 2
(gdb) # 检查地址 0x461513
(gdb) x/2cb 0x461513
0x461513: 97 'a' 98 'b'
(gdb) # 检查地址 0x461515
(gdb) x/2cb 0x461515
0x461515: 99 'c' 100 'd'
(gdb) # 查看寄存器
(gdb) i r
rax 0xc00001a0e0 824633827552
rbx 0x4 4
(gdb) # 检查地址 0xc00001a0e0
(gdb) x/4cb 0xc00001a0e0
0xc00001a0e0: 97 'a' 98 'b' 99 'c' 100 'd'

如上可见：当我们给 main.sum 方法传递两个字符串参数的时候，实际上是占用 4 个寄存器，每个字符串参数占用两个寄存器，分别是地址和长度，正好贴合字符串的数据结构：

type StringHeader struct {
	Data uintptr
	Len  int
}

了解了相关知识之后，我们就可以通过如下 bpftrace 命令来监控 sum 的输入输出了：

shell> bpftrace -e '
    uprobe:./main:main.concat {
        printf("a: %s b: %s\n",
            str(reg("ax"), reg("bx")),
            str(reg("cx"), reg("di"))
        )
    }
    uretprobe:./main:main.concat {
        printf("retval: %s\n", str(reg("ax"), reg("bx")))
        // printf("retval: %s\n", str(retval))
    }
'
a: ab b: cd
retval: abcd

以上，我们介绍了当参数和返回值是整形或字符串时，如何用 bpftrace 分析 golang 程序，如果类型更复杂的话，比如说是一个 struct，那么原理也是类似的，篇幅所限，本文就不再赘述了，有兴趣的读者可以参考文章后面的相关链接。

补充说明：通过 uretprobe 检查 golang 方法的返回值可能存在风险。这是因为 uretprobe 是通过修改栈来加入探针的， 这和 golang 本身对栈的管理存在冲突的可能：

• runtime: ebpf uretprobe support
• Go crash with uretprobe

虽然在 golang 程序中使用 uretprobe 是不安全的，但是好在 uprobe 还可以放心用。其实换个角度看，即便我们不使用 uretprobe，依然有办法获取返回时，比如我们可以通过在 本方法 return 的时候或者在一个方法开始的时候设置一个 uprobe 来获取返回值。

通过 bpftrace 分析 golang 中 slice 是如何扩容的

本例代码依然以 go1.17 版本为例，它的逻辑就是不断追加数据，迫使 slice 扩容：

package main

import "time"

func main() {
	var s []int
	for range time.Tick(time.Microsecond) {
		s = append(s, 1)
	}
	_ = s
}

控制 slice 扩容行为的方法是 runtime.growslice，对应的签名如下：

// It is passed the slice element type, the old slice,
// and the desired new minimum capacity,
func growslice(et *_type, old slice, cap int) slice

type slice struct {
	array unsafe.Pointer
	len   int
	cap   int
}

这里面，看上去 cap 是我们最关心的参数，不过从源代码注释中看，此 cap 的含义是「the desired new minimum capacity」，并不是真正的 cap，实际上 old 参数里也有一个 cap，它才是我们需要的 cap：

• et *_type 是一个指针，占用一个寄存器
• old slice 是一个 struct，占用三个寄存器，分别是 slice 类型定义中的 array, len, cap
• cap int 是一个整形，占用一个寄存器

所以我们需要的 cap 实际保存在第 4 个寄存器，也就是 RDI，我们用 reg(“di”) 就可以拿到对应的数据：

shell> bpftrace -e '
    uprobe:./main:runtime.growslice {printf("cap: %d\n", reg("di"))}
'
cap: 0
cap: 0
cap: 2
cap: 0
cap: 1
cap: 2
cap: 0
cap: 0
cap: 0
cap: 1
cap: 2
cap: 4
cap: 8
cap: 16
cap: 32
cap: 64
cap: 128
cap: 256
cap: 512
cap: 1024
cap: 1280
cap: 1696
cap: 2304
cap: 3072
cap: 4096
cap: 5120
cap: 7168
cap: 9216

前面有一些噪音数据，可以忽略，从 1 开始，每次扩容都会翻倍，一直到 1024，接着从 1024 扩容到 1280，是 1.25 倍，然后从 1280 扩容到 1696，是 1.325 倍。整个分析过程中，我们没有手动加任何日志，仅依赖 bpftrace 观测到的数据。

本文介绍了 eBPF 最基本的用法，想深入了解 eBPF 的话推荐大家继续阅读如下资料：

• 聊聊风口上的 eBPF
• eBPF 与 Go，超能力组合
• BPF 在 Golang 中 Crash 导致用户进程奔溃
• bpf study
• Golang bcc/BPF Function Tracing
• BPF and Go: Modern forms of introspection in Linux
• Challenges of BPF Tracing Go

我会不定期的汇总上面的资料，大家如果有好的资料也请告诉我，谢谢。

既然是白话，那么我们得想一个通俗易懂的例子，就拿普通人来说吧：活着是为了什么，好好学习，买房，结婚，任意一个环节出现意外，整个人生就会偏离轨道。下面我用 Golang 代码来描述活着的过程，其中好好学习，买房，结婚都可能受到不可控外界因素的影响，比如好好学习遇上教培跑路，买房遇上银行限贷，结婚遇上彩礼涨价。

下面问题来了：请为「Live」编写单元测试，要求覆盖率达到 100%。

package main

import (
	"errors"
	"math/rand"
)

// Live 活着
func Live(money1, money2, money3 int64) error {
	if err := GoodGoodStudy(money1); err != nil {
		return err
	}
	if err := BuyHouse(money2); err != nil {
		return err
	}
	if err := Marry(money3); err != nil {
		return err
	}
	return nil
}

// GoodGoodStudy 好好学习
func GoodGoodStudy(money int64) error {
	if rand.Intn(100) > 0 {
		return errors.New("error")
	}
	_ = money
	return nil
}

// BuyHouse 买房
func BuyHouse(money int64) error {
	if rand.Intn(100) > 0 {
		return errors.New("error")
	}
	_ = money
	return nil
}

// Marry 结婚
func Marry(money int64) error {
	if rand.Intn(100) > 0 {
		return errors.New("error")
	}
	_ = money
	return nil
}

既然单元测试要求达到 100% 的覆盖率，那么我们就必须测试每一个可能的分支：

• GoodGoodStudy 异常
• GoodGoodStudy 正常；BuyHouse 异常
• GoodGoodStudy 正常；BuyHouse 正常；Marry 异常
• GoodGoodStudy 正常；BuyHouse 正常；Marry 正常

第一版单元测试

对 Live 而言，GoodGoodStudy，BuyHouse 和 Marry 都属于外部依赖，通过使用 gomonkey，我们可以在运行时动态替换掉他们的实现，从而确保流程进入预定分支。在断言部分我们使用了 testify，它比直接使用标准库中的 testing 包方便很多。

package main

import (
	"errors"
	"testing"

	"github.com/stretchr/testify/assert"

	. "github.com/agiledragon/gomonkey/v2"
)

func Test_Live1(t *testing.T) {
	patches := NewPatches()
	// GoodGoodStudy error
	patches.ApplyFunc(GoodGoodStudy, func(int64) error {
		return errors.New("error")
	})
	assert.Error(t, Live(100, 100, 100))
	patches.Reset()
	// BuyHouse error
	patches.ApplyFunc(GoodGoodStudy, func(int64) error {
		return nil
	})
	patches.ApplyFunc(BuyHouse, func(int64) error {
		return errors.New("error")
	})
	assert.Error(t, Live(100, 100, 100))
	patches.Reset()
	// Marry error
	patches.ApplyFunc(GoodGoodStudy, func(int64) error {
		return nil
	})
	patches.ApplyFunc(BuyHouse, func(int64) error {
		return nil
	})
	patches.ApplyFunc(Marry, func(int64) error {
		return errors.New("error")
	})
	assert.Error(t, Live(100, 100, 100))
	patches.Reset()
	// ok
	patches.ApplyFunc(GoodGoodStudy, func(int64) error {
		return nil
	})
	patches.ApplyFunc(BuyHouse, func(int64) error {
		return nil
	})
	patches.ApplyFunc(Marry, func(int64) error {
		return nil
	})
	assert.NoError(t, Live(100, 100, 100))
	patches.Reset()
}

第一版单元测试存在的问题：原始代码十几行，单元测试代码几十行。在大话西游中，至尊宝在梦中叫了晶晶的名字 98 次，叫了紫霞的名字 784 次。而在我们的单元测试中，GoodGoodStudy 正常的状态写了三次，BuyHouse 正常的状态写了两次，虽然远比至尊宝重复的次数少，但重复始终是个坏味道。

第二版单元测试

通过使用 OutputCell，我们可以一次性控制多个状态变化，从而去除重复的坏味道：

package main

import (
	"errors"
	"testing"

	"github.com/stretchr/testify/assert"

	. "github.com/agiledragon/gomonkey/v2"
)

func Test_Live2(t *testing.T) {
	patches := NewPatches()
	defer patches.Reset()
	output := []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 3},
	}
	patches.ApplyFuncSeq(GoodGoodStudy, output)
	output = []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 2},
	}
	patches.ApplyFuncSeq(BuyHouse, output)
	output = []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 1},
	}
	patches.ApplyFuncSeq(Marry, output)
	// GoodGoodStudy error
	assert.Error(t, Live(100, 100, 100))
	// BuyHouse error
	assert.Error(t, Live(100, 100, 100))
	// Marry error
	assert.Error(t, Live(100, 100, 100))
	// ok
	assert.NoError(t, Live(100, 100, 100))
}

第二版单元测试存在的问题：原始代码逻辑中不同分支是有层次感的，浏览代码的时候可以很自然的看出流程的走向，但是在单元测试代码中，这种层次感消失了，如果不写注释，单纯看断言代码，那么我们很可能搞不清楚自己在干什么。

第三版单元测试

虽然 testify 的断言很强大，但是在表达的层次感上却是无力的，此时我们可以考虑用 goconvey 取代 testfy，它支持嵌套，这正是我们想要得到的层次感。

package main

import (
	"errors"
	"testing"

	. "github.com/agiledragon/gomonkey/v2"
	. "github.com/smartystreets/goconvey/convey"
)

func Test_Live3(t *testing.T) {
	patches := NewPatches()
	defer patches.Reset()
	output := []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 3},
	}
	patches.ApplyFuncSeq(GoodGoodStudy, output)
	output = []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 2},
	}
	patches.ApplyFuncSeq(BuyHouse, output)
	output = []OutputCell{
		{Values: Params{errors.New("error")}, Times: 1},
		{Values: Params{nil}, Times: 1},
	}
	patches.ApplyFuncSeq(Marry, output)
	Convey("Live", t, func() {
		t.Log("LOG: Live")
		Convey("GoodGoodStudy error", func() {
			t.Log("LOG: GoodGoodStudy error")
			So(Live(100, 100, 100), ShouldBeError)
		})
		Convey("GoodGoodStudy ok", func() {
			t.Log("LOG: GoodGoodStudy ok")
			Convey("BuyHouse error", func() {
				t.Log("LOG: BuyHouse error")
				So(Live(100, 100, 100), ShouldBeError)
			})
			Convey("BuyHouse ok", func() {
				t.Log("LOG: BuyHouse ok")
				Convey("Marry error", func() {
					t.Log("LOG: Marry error")
					So(Live(100, 100, 100), ShouldBeError)
				})
				Convey("Marry ok", func() {
					t.Log("LOG: Marry ok")
					So(Live(100, 100, 100), ShouldBeNil)
				})
			})
		})
	})
}

补充说明： 如果你没看过 goconvey 的文档，那么很可能会误解其运行机制，我在代码里加了很多 t.Log，大家不妨猜猜它们的输出顺序是什么样的。了解这一点对实现 setup，teardown 很重要，篇幅所限，本文就不深入讨论了，有兴趣的朋友请自行查阅。

第三版单元测试存在的问题：虽然 gomonkey 可以通过 OutputCell 一次性控制多个状态变化，但是这些状态却是静态的，被替换方法的参数和返回值没有关联。

关于 Gomonkey 的原罪

在单元测试领域，关于如何替换掉外部依赖，主要有两种技术，分别是 mock 和 stub：mock 通过接口可以动态调整外部依赖的返回值，而 stub 只能在运行时静态调整外部依赖的返回值，可以说 mock 包含了 stub，或者说 stub 是 mock 的子集，从本质上讲，gomonkey 属于 stub 技术，它存在诸多缺点，比如：

• 它违反了开闭原则。
• 运行时必须关闭内联「go test -gcflags=all=-l」。
• 运行时需要很高的权限，并且不同的硬件需要不同的黑科技实现。

对 gomonkey 来说，我的看法很明确：虽然黑科技很神奇，但是能不用就不用！一旦发现不得不用，那么多半意味着你的代码设计本身存在问题。

最终版单元测试

很多人买电脑的时候为了省钱买了集成显卡的电脑，结果等到需要换显卡的时候才发现可拔插性的重要性，如果上天再给他们一次机会，我猜他们一定会买独立显卡的电脑。

Golang 崇尚接口，有了接口，我们就可以很自然的使用 mock 技术，而不是 stub 技术。在这里，mock 就相当于独立显卡，而 stub 就相当于集成显卡。

下面让我们通过接口重构原始代码，其中使用 gomock 生成了 mock 对象：

package main

//go:generate mockgen -package main -source foo.go -destination=foo_mock.go

// Life 人生
type Life interface {
	// GoodGoodStudy 好好学习
	GoodGoodStudy(money int64) error
	// BuyHouse 买房
	BuyHouse(money int64) error
	// Marry 结婚
	Marry(money int64) error
}

// Person 普通人
type Person struct {
	life Life
}

// Live 活着
func (p *Person) Live(money1, money2, money3 int64) error {
	if err := p.life.GoodGoodStudy(money1); err != nil {
		return err
	}
	if err := p.life.BuyHouse(money2); err != nil {
		return err
	}
	if err := p.life.Marry(money3); err != nil {
		return err
	}
	return nil
}

有了 mock 对象以后，我们就好像置身在元宇宙中一样，不再有 stub 的限制：

package main

import (
	"errors"
	"testing"

	gomock "github.com/golang/mock/gomock"

	. "github.com/smartystreets/goconvey/convey"
)

func Test_Live(t *testing.T) {
	ctrl := gomock.NewController(t)
	life := NewMockLife(ctrl)
	handler := func(money int64) error {
		if money <= 0 {
			return errors.New("error")
		}
		return nil
	}
	life.EXPECT().GoodGoodStudy(gomock.Any()).AnyTimes().DoAndReturn(handler)
	life.EXPECT().BuyHouse(gomock.Any()).AnyTimes().DoAndReturn(handler)
	life.EXPECT().Marry(gomock.Any()).AnyTimes().DoAndReturn(handler)
	Convey("Live", t, func() {
		person := &Person{
			life: life,
		}
		Convey("GoodGoodStudy error", func() {
			So(person.Live(0, 100, 100), ShouldBeError)
		})
		Convey("GoodGoodStudy ok", func() {
			Convey("BuyHouse error", func() {
				So(person.Live(100, 0, 100), ShouldBeError)
			})
			Convey("BuyHouse ok", func() {
				Convey("Marry error", func() {
					So(person.Live(100, 100, 0), ShouldBeError)
				})
				Convey("Marry ok", func() {
					So(person.Live(100, 100, 100), ShouldBeNil)
				})
			})
		})
	})
}

最后让我们讨论一下到底哪些依赖需要 mock，哪些不需要 mock。简单点说：所有可能出现不可控情况的依赖都需要 mock，这里的不可控主要分两种：

• 一种是运行时间的不可控：比如一个高 CPU 任务，单次执行需要一分钟，但是有一百个测试用例要跑，此时就需要 mock。
• 一种是运行结果的不可控：比如 mysql，redis 之类的 IO 请求，虽然它们可能运行的很快，但是因为网络本身的限制有可能失败，此时需要 mock。

不过 mock 虽好，但不要贪杯，千万不要手里拿着锤子，看哪都像钉子。举个例子：Golang 里最流行的配置工具 Viper，其最常用的使用方式都是静态调用，比如：「viper.GetXxx」，并没有使用接口，自然 mock 也就无从谈起，不过我们可以通过「viper.Set」很简单的替换方法的返回值，此时 mock 与否也就不再重要了。

shell> echo '{"content": "$(base64 foo.docx)", "type": "docx"}'

如上，我想把文件 foo.docx 的内容通过 base64 编码，然后放到 json 字符串里，但是它并不能正常工作，因为它是一个单引号字符串，命令在单引号里的是不能展开的，那换成双引号可不可以？当然可以，但是因为 json 本身包含很多双引号，所以免不了转义：

shell> echo "{\"content\": \"$(base64 foo.docx)\", \"type\": \"docx\"}"

不瞒大家说，我最开始写出如上代码的时候，脑瓜子嗡嗡的，好在最后我想到了一个绝妙的解决方法：既然用双引号字符串不可避免会带来转义问题，那么就放弃双引号字符串，而是使用单引号字符串，然后把里面的命令用单引号包起来：

shell> echo '{"content": "'$(base64 foo.docx)'", "type": "docx"}'

为什么这样可以？其实如上单引号字符串实际上是三个字符串，分别是：

• 「'{“content”: “‘」
• 「$(base64 foo.docx)」
• 「'”, “type”: “docx”}’」

与其说是用单引号把命令包起来，倒不如说是用单引号把命令隔离出来，有点四两拨千斤的感觉，脑瓜子再也不会嗡嗡的了，整个世界清静了…

让我们看看问题代码，类似的 string 和 []byte 转换代码在网上非常常见：

func StringToSliceByte(s string) []byte {
	l := len(s)
	return *(*[]byte)(unsafe.Pointer(&reflect.SliceHeader{
		Data: (*(*reflect.StringHeader)(unsafe.Pointer(&s))).Data,
		Len:  l,
		Cap:  l,
	}))
}

大家之所以不愿意直接通过 []byte(string) 把 string 转换为 []byte，是因为那样会牵扯内存拷贝，而通过 unsafe.Pointer 来做类型转换，没有内存拷贝，从而达到提升性能的目的。

问题代码到底有没有问题？其实当我把代码拷贝到 vscode 之后就有提示了：

SliceHeader is the runtime representation of a slice. It cannot be used safely or portably and its representation may change in a later release. Moreover, the Data field is not sufficient to guarantee the data it references will not be garbage collected, so programs must keep a separate, correctly typed pointer to the underlying data.

首先，reflect.SliceHeader 作为 slice 的运行时表示，以后可能会改变，直接使用它存在风险；其次，Data 字段无法保证它指向的数据不被 GC 垃圾回收。

前一个问题还好说，但是后面提的 GC 问题则是个大问题！为什么会存在 GC 问题，我们不妨看看 reflect.SliceHeader 和 reflect.StringHeader 的定义：

type SliceHeader struct {
	Data uintptr
	Len  int
	Cap  int
}

type StringHeader struct {
	Data uintptr
	Len  int
}

如上所示，Data 的类型是 uintptr，虽然有一个 ptr 后缀，但是它本质上还是一个整型，并不是指针，也就是说，它并不会持有它指向的数据，所以数据可能会被 GC 回收。

知道了前因后果，那么让我们构造一段代码来证明存在 GC 问题：

package main

import (
	"fmt"
	"reflect"
	"runtime"
	"unsafe"
)

func main() {
	fmt.Printf("%s\n", test())
}

func test() []byte {
	defer runtime.GC()
	x := make([]byte, 5)
	x[0] = 'h'
	x[1] = 'e'
	x[2] = 'l'
	x[3] = 'l'
	x[4] = 'o'
	return StringToSliceByte(string(x))
}

func StringToSliceByte(s string) []byte {
	l := len(s)
	return *(*[]byte)(unsafe.Pointer(&reflect.SliceHeader{
		Data: (*(*reflect.StringHeader)(unsafe.Pointer(&s))).Data,
		Len:  l,
		Cap:  l,
	}))
}

注：因为静态字符串存储在 TEXT 区，不会被 GC 回收，所以使用了动态字符串。

当我们运行上面的代码，并不会输出 hello，而是会输出乱码，原因是对应的数据已经被 GC 回收了，如果我们去掉 runtime.GC() 再运行，那么输出大概率会恢复正常。

由此可见，因为 Data 是 uintptr 类型，所以任何对它的赋值都是不安全的。原本问题到这里就应该告一段落了，但是 unsafe.Pointer 文档里恰好就有一个直接对 Data 赋值的例子：Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer.

var s string
hdr := (*reflect.StringHeader)(unsafe.Pointer(&s))
hdr.Data = uintptr(unsafe.Pointer(p))
hdr.Len = n

到底是文档有误，还是我们的推断错了，继续看文档里的说明：

the reflect data structures SliceHeader and StringHeader declare the field Data as a uintptr to keep callers from changing the result to an arbitrary type without first importing “unsafe”. However, this means that SliceHeader and StringHeader are only valid when interpreting the content of an actual slice or string value.

也就是说，只有当操作实际存在的 slice 或 string 的时候，SliceHeader 或 StringHeader 才是有效的，回想最初的代码，因为操作 reflect.SliceHeader 的时候，并没有实际存在的 slice，所以是不符合 unsafe.Pointer 使用规范的（golang-nuts），按照要求调整一下：

func StringToSliceByte(s string) []byte {
	var b []byte
	l := len(s)
	p := (*reflect.SliceHeader)(unsafe.Pointer(&b))
	p.Data = (*reflect.StringHeader)(unsafe.Pointer(&s)).Data
	p.Len = l
	p.Cap = l
	return b
}

再用测试代码跑一下，结果发现输出正常了。不过有人可能会问了，之前不是说了 uintptr 不是指针，不能阻止数据被 GC 回收，可是为什么 GC 没有效果？实际上这是因为编译器对 *reflect.{Slice,String}Header 做了特殊处理，具体细节不展开了。

如果你想验证是否存在特殊处理，可以使用自定义的类型反向验证一下：

type StringHeader struct {
	Data uintptr
	Len  int
}

type SliceHeader struct {
	Data uintptr
	Len  int
	Cap  int
}

func StringToSliceByte(s string) []byte {
	var b []byte
	l := len(s)
	p := (*SliceHeader)(unsafe.Pointer(&b))
	p.Data = (*StringHeader)(unsafe.Pointer(&s)).Data
	p.Len = l
	p.Cap = l
	return b
}

你会发现，如果没有使用 reflect 里的类型，那么输出就又不正常了。从而反向验证了编译器确实对 *reflect.{Slice,String}Header 做了特殊处理。

现在，我们基本搞清楚了 string 和 []byte 转换中的各种坑，下面看看如何写出准确的转换代码，虽然编译器在其中耍了一些小动作，但是我们不应该依赖这些暗箱操作。

既然 uintptr 不是指针，那么我们改用 unsafe.Pointer，如此数据就不会被 GC 回收了：

type StringHeader struct {
	Data unsafe.Pointer
	Len  int
}

type SliceHeader struct {
	Data unsafe.Pointer
	Len  int
	Cap  int
}

func StringToSliceByte(s string) []byte {
	var b []byte
	l := len(s)
	p := (*SliceHeader)(unsafe.Pointer(&b))
	p.Data = (*StringHeader)(unsafe.Pointer(&s)).Data
	p.Len = l
	p.Cap = l
	return b
}

上面的代码稍显臃肿，更简单的写法可以参考 gin 或 fasthttp 中的实现：

// gin
func StringToBytes(s string) []byte {
	return *(*[]byte)(unsafe.Pointer(
		&struct {
			string
			Cap int
		}{s, len(s)},
	))
}

func BytesToString(b []byte) string {
	return *(*string)(unsafe.Pointer(&b))
}

// fasthttp
func s2b(s string) (b []byte) {
	/* #nosec G103 */
	bh := (*reflect.SliceHeader)(unsafe.Pointer(&b))
	/* #nosec G103 */
	sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
	bh.Data = sh.Data
	bh.Cap = sh.Len
	bh.Len = sh.Len
	return b
}

func b2s(b []byte) string {
	/* #nosec G103 */
	return *(*string)(unsafe.Pointer(&b))
}

至此，我们完美解决了 string 和 []byte 的转换问题。

既然是在介绍 CPU 缓存一致性的时候举的例子，那么理所应当与此有关，看代码：

package main

import "time"

func main() {
	running := true
	go func() {
		println("start thread1")
		count := 1
		for running {
			count++
		}
		println("end thread1: count =", count)
	}()
	go func() {
		println("start thread2")
		for {
			running = false
		}
	}()
	time.Sleep(time.Hour)
}

当我们通过「go run main.go」运行代码的时候，会发现第一个 goroutine 永远不会结束，就好像 running = false 没有生效一样。对此，文章把原因归结为 CPU 缓存一致性中的线程可见性问题，可是我前后看了几遍也没有看出个所以然来。细心的小伙伴不难发现代码存在 data race 问题：多个 goroutine 并发读写 running 变量，不过当我们通过「go run -race main.go」再次运行代码的时候，有趣的事情发生了，第一个 goroutine 正常结束了！

理论上，既然存在 data race 问题，那么出现什么结果都可能，但是好奇心驱使我继续研究了一下，这次使用的工具是 SSA（how to read），它可以展现出从源代码到汇编的过程中，编译器都做了哪些工作，并且可以把结果生成 html 文件：

shell> GOSSAFUNC=main go build -gcflags="-N -l" ./main.go

SSA 工具最方便的地方是它可以把源代码和汇编通过颜色对应起来：

main 函数的 ssa

说明：Golang 中的汇编一般指 Plan9 汇编，推荐阅读「plan9 assembly 完全解析」。

不过为什么「running = false」这行源代码没有对应的汇编呢？这是因为 SSA 的工作单位是函数，上面的结果是 main 函数的结果，而「running = false」实际上属于 main 函数里第 2 个 goroutine，相当于 main.func2，重新运行 SSA：

shell> GOSSAFUNC=main.func2 go build -gcflags="-N -l" ./main.go

如此一来就能看到「running = false」这行源代码对应的汇编了：

main.func2 函数的 ssa

其中，PCDATA 是编译器插入的和 GC 相关的信息，在本例中可以忽略，剩下的几个 JMP 跳来跳去，好像是个圈哦，就是一个空 for，和「running = false」完全没有关系。

不过既然带有 race 检测的代码工作正常，那么不妨一并生成 SSA 看看结果如何：

shell> GOSSAFUNC=main.func2 go build -race -gcflags="-N -l" ./main.go

结果如下图所示，除了 JMP，还有 MOV 操作，正好对应「running = false」：

main.func2 函数的 ssa

如此一来，我们的困惑终于解开了。问题代码中的循环之所以不会结束，和所谓的「CPU 缓存一致性中的线程可见性问题」并没有任何关系，只是因为编译器把部分代码看成死代码，直接优化掉了，这个过程称之为「Dead code elimination」，不过当激活 race 检测的时候，编译器并没有执行优化死代码的流程，所以看上去又正常了。

最后，推荐一篇文章，和本文的例子相似：谈谈 Golang 中的 Data Race（及续），还有一篇：Go 中一个非典型不加锁读写变量案例分析。

有病没病走两步，让我们写一段代码来验证一下：

package main

import "sync/atomic"

var v = int32(0)

func main() {
	var x int32
	x = v // main.go:9
	_ = x
	x = atomic.LoadInt32(&v) // main.go:11
	_ = x
}

通过「go tool compile」运行代码，拿到对应的汇编结果：

shell> go tool compile -N -l -S main.go

0x0016 00022 (main.go:9)        MOVL    "".v(SB), AX
0x001c 00028 (main.go:9)        MOVL    AX, "".t+4(SP)
0x0020 00032 (main.go:11)       MOVL    "".v(SB), AX
0x0026 00038 (main.go:11)       MOVL    AX, "".t+4(SP)

不管是「x = v」还是「x = atomic.LoadInt32(&v)」，对应的汇编结果一摸一样，带着困惑，让我们继续看看是否能从 sync/atomic 的源代码中找到答案：

Golang 代码中只有函数声明，实际上是使用汇编实现的：

// doc.go
func LoadInt32(addr *int32) (val int32)

// asm.s
TEXT ·LoadInt32(SB),NOSPLIT,$0
	JMP runtime∕internal∕atomic·Load(SB)

顺着路径，跳转到 runtime/internal/atomic，会发现每个平台都有独立的 Load 实现：

在 amd64 平台，Load 是用 Golang 实现的，等价于直接读取：

func Load(ptr *uint32) uint32 {
	return *ptr
}

在 arm64 平台，Load 是用汇编实现的，并不是简单的一次操作：

TEXT ·Load(SB),NOSPLIT,$0-12
	MOVD	ptr+0(FP), R0
	LDARW	(R0), R0
	MOVW	R0, ret+8(FP)
	RET

如上可见，atomic.LoadInt32 之所以存在，是因为某些平台存在特殊性，所以我们需要封装一个统一的操作，如此更有利于我们写出平台无关的代码。

本文仅讨论了 atomic 的原子性，实际上它还保证了可见性，有序性，有兴趣的朋友可以搜索内存屏障相关内容，这是一个很复杂的主题，我就不献丑了，推荐阅读：Golang Memory Model。

让我们回想一下 groupcache 和 sync.WaitGroup 中的做法，为了规避在 32 位环境下 atomic 操作 64 位数的 BUG，它们采取了截然不同的做法：

// groupcache
type Group struct {
	name string
	getter Getter
	peersOnce sync.Once
	peers PeerPicker
	cacheBytes int64
	mainCache cache
	hotCache cache
	loadGroup flightGroup
	_ int32 // force Stats to be 8-byte aligned on 32-bit platforms
	Stats Stats
}

// sync.WaitGroup
type WaitGroup struct {
	noCopy noCopy

	// 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
	// 64-bit atomic operations require 64-bit alignment, but 32-bit
	// compilers do not ensure it. So we allocate 12 bytes and then use
	// the aligned 8 bytes in them as state, and the other 4 as storage
	// for the sema.
	state1 [3]uint32
}

func (wg *WaitGroup) state() (statep *uint64, semap *uint32) {
	if uintptr(unsafe.Pointer(&wg.state1))%8 == 0 {
		return (*uint64)(unsafe.Pointer(&wg.state1)), &wg.state1[2]
	} else {
		return (*uint64)(unsafe.Pointer(&wg.state1[1])), &wg.state1[0]
	}
}

问题：为什么 groupcache 不用考虑外部地址，只要内部对齐就可以实现 64 位对齐？

为了搞清楚这个问题，让我们回想一下 atomic 文档最后关于 64 位对齐的相关描述：

On ARM, 386, and 32-bit MIPS, it is the caller’s responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.

其中我们关心的是最后一句话：变量、结构体、数组、切片的第一个字是 64 位对齐的。为了验证这一点，我构造了一个包含 int64 的 struct，看它的地址是否是 8 的倍数：

package main

import (
	"fmt"
	"time"
	"unsafe"
)

type foo struct {
	bar int64
}

// GOARCH=386 go run main.go
func main() {
	for range time.Tick(time.Second) {
		f := &foo{}
		p := uintptr(unsafe.Pointer(f))
		fmt.Printf("%p: %d, %d\n", f, p, p%8)
	}
}

按照常理来说，当我们在 32 位环境（GOARCH=386）下运行的时候，struct 的地址应该只能满足 32 位对齐，也就是 4 的倍数，不过测试发现，struct 的地址竟然满足 64 位对齐，也就是是 8 的倍数。既然外部已经是对齐的了，那么只要内部对齐就可以实现 64 位对齐。

问题：为什么 sync.WaitGroup 不像 groupcache 那样实现 64 位对齐。

两者之所以采用了不同的 64 位对齐实现方式，是因为两者的使用场景不同。在实际使用的时候，sync.WaitGroup 可能会被嵌入到别的 struct 中，因为不知道嵌入的具体位置，所以不可能通过预先加入 padding 的方式来实现 64 位对齐，只能在运行时动态计算。而 groupcache 则不会被嵌入到别的 struct 中，如果你硬要嵌入，可能会出问题：

package main

import (
	"github.com/golang/groupcache"
)

type foo struct {
	bar int32
	g groupcache.Group
}

// GOARCH=386 go run main.go
func main() {
	f := foo{}
	f.g.Stats.Gets.Add(1)
}

当我们在 32 位环境（GOARCH=386）下运行的时候，会看到如下 panic 信息：

panic: unaligned 64-bit atomic operation

当我们在 32 位环境，按 4 字节对齐，所以 g 的偏移量是 4 而不是 8，如此一来，虽然 groupcache 内部通过 _ int32 实现了相对的 64 位对齐，但是因为外部没有实现 64 位对齐，所以在执行 atomic 操作的时候，还是会 panic（如果 bar 是 int64 就不会 panic）。

问题：为什么 sync.WaitGroup 中的 state1 不换成 一个 int64 加一个 int32？

更新：之前解释有误，现在新版已经换了

问题：为什么 sync.WaitGroup 中的 state1 不换成 一个[12]byte？

原方案中 state1 的类型是 [3]uint32，取两个 uint32 做 statep，剩下的一个 uint32 做 semap。为什么不换成 [12]byte，取 8 个 byte 做 statep，剩下的 4 个 byte 做 semap？

想要搞清楚这个问题，我们需要回顾一下 golang 关于内存对齐保证的描述：

• For a variable x of any type: unsafe.Alignof(x) is at least 1.
• For a variable x of struct type: unsafe.Alignof(x) is the largest of all the values unsafe.Alignof(x.f) for each field f of x, but at least 1.
• For a variable x of array type: unsafe.Alignof(x) is the same as the alignment of a variable of the array’s element type.

其中的重点是：对 struct 而言，它的对齐取决于其中所有字段对齐的最大值；对于 array 而言，它的对齐等于元素类型本身的对齐。因为 noCopy 的大小是 0，所以 struct 的对齐实际上就取决于 state1 字段的对齐。

• 当 state1 的类型是 [3]uint32 的时候，那么 struct 的对齐就是 4。
• 当 state1 的类型是 [12]byte 的时候，那么 struct 的对齐就是 1。

如果 state1 换成 [12]byte，那么因为 struct 的对齐是 1，会导致 struct 的地址不再是 4 的倍数，uintptr(unsafe.Pointer(&wg.state1))%8 的结果可能是从 0 到 7 的任意数，如此一来需要 padding 的时候，你就无法实现剩余空间恰好可以充当 padding 的效果了。

Computer architectures may require memory addresses to be aligned; that is, for addresses of a variable to be a multiple of a factor, the variable’s type’s alignment. The function Alignof takes an expression denoting a variable of any type and returns the alignment of the (type of the) variable in bytes. For a variable x:

uintptr(unsafe.Pointer(&x)) % unsafe.Alignof(x) == 0

The following minimal alignment properties are guaranteed:

• For a variable x of any type: unsafe.Alignof(x) is at least 1.
• For a variable x of struct type: unsafe.Alignof(x) is the largest of all the values unsafe.Alignof(x.f) for each field f of x, but at least 1.
• For a variable x of array type: unsafe.Alignof(x) is the same as the alignment of a variable of the array’s element type.

当然，如果你以前没有接触过内存对齐的话，那么对你来说上面的内容可能过于言简意赅，在继续学习之前我建议你阅读以下资料，有助于消化理解：

• 内存布局
• 图解 Go 之内存对齐
• Dig101-Go之聊聊struct的内存对齐
• 在 Go 中恰到好处的内存对齐
• Go 结构体的内存布局
• Golang 是否有必要内存对齐

测试

我构造了一个 struct，它有一个特征：字段按照一小一大的顺序排列，如果不看注释中的 Sizeof、Alignof、Offsetof 信息（通过 unsafe 获取），你能否说出它占用多少个字节？

package main

import (
	"fmt"
	"unsafe"
)

type memAlign struct {
	a byte     // Sizeof: 1  Alignof: 1 Offsetof: 0
	b int      // Sizeof: 8  Alignof: 8 Offsetof: 8
	c byte     // Sizeof: 1  Alignof: 1 Offsetof: 16
	d string   // Sizeof: 16 Alignof: 8 Offsetof: 24
	e byte     // Sizeof: 1  Alignof: 1 Offsetof: 40
	f []string // Sizeof: 24 Alignof: 8 Offsetof: 48
}

func main() {
	var m memAlign
	fmt.Println(unsafe.Sizeof(m))
}

初学者往往会认为 struct 的大小应该等于内部各个字段大小的和，于是得出本例的答案是 51（1+8+1+16+1+24=51），不过实际上答案却是 72！究其原因是因为内存对齐的缘故导致各个字段之间可能存在 padding。那么有没有简单的方法来减少 padding 呢？我们不妨把字段按照从大到小的顺序排列，再试一试：

package main

import (
	"fmt"
	"unsafe"
)

type memAlign struct {
	f []string // Sizeof: 24 Alignof: 8 Offsetof: 0
	d string   // Sizeof: 16 Alignof: 8 Offsetof: 24
	b int      // Sizeof: 8  Alignof: 8 Offsetof: 40
	a byte     // Sizeof: 1  Alignof: 1 Offsetof: 48
	c byte     // Sizeof: 1  Alignof: 1 Offsetof: 49
	e byte     // Sizeof: 1  Alignof: 1 Offsetof: 50
}

func main() {
	var m memAlign
	fmt.Println(unsafe.Sizeof(m))
}

结果答案变成了 56，比 72 小了很多，不过还是比 51 大，说明还是存在 padding，这是因为不仅字段要内存对齐，struct 本身也要内存对齐。

另：我刚学 golang 的时候一直有一个疑问：为什么切片的大小是 24，字符串的大小是 16 呢？我估计别的初学者也会有类似的问题，一并解释一下，这是因为切片和字符串也是 struct，其定义分别对应 SliceHeader 和 StringHeader，它们的大小分别是 24 和 16：

type SliceHeader struct {
	Data uintptr
	Len  int
	Cap  int
}

type StringHeader struct {
	Data uintptr
	Len  int
}

因为 uintptr 的大小等于 int，所以切片的大小等于 3*8=24，字符串的大小等于 2*8=16。

工具

只要我们写点代码，调用 unsafe 包的 Sizeof、Alignof、Offsetof 等方法，那么就可以搞清楚 struct 内存对齐的各种细节，不过这毕竟是个没有技术含量的体力活，有没有相关工具可以提升我们的工作效率呢？答案是 go-tools：

shell> go install honnef.co/go/tools/cmd/structlayout@latest
shell> go install honnef.co/go/tools/cmd/structlayout-pretty@latest
shell> go install honnef.co/go/tools/cmd/structlayout-optimize@latest

其中，structlayout 是用来分析数据的，pretty 是用来图形化显示的，optimize 是用来优化建议的，这里就用文章开头优化前的代码给出一个 structlayout-pretty 的例子：

shell> structlayout -json ./main.go memAlign | structlayout-pretty

structlayout-pretty

虽然 structlayout-pretty 我们可以很直观的看到在哪里存在 padding，不过它是 ascii 风格的，有时候不太方便，此时另外一个图形化工具 structlayout-svg 更爽：

shell> go install github.com/ajstarks/svgo/structlayout-svg@latest

把文章开头优化前后的代码分别用 structlayout-svg 生成结果：

shell> structlayout -json ./main.go memAlign | structlayout-svg

优化前：

优化前

优化后：

优化后

效果超赞是不是！不过如果我们要把工具集成到 CI 里，那么此类图形化工具就不合适了，好在我们的工具箱里还有宝贝，它就是 fieldalignment：

shell> go install golang.org/x/tools/...@latest

把文章开头优化前后的代码分别用 fieldalignment 生成结果：

shell> awk '$1 == "module" {print $2}' ./go.mod | xargs fieldalignment

优化前：struct of size 72 could be 56；优化后：struct with 32 pointer bytes could be 24。

实际集成到 CI 的时候，通常不会直接使用 fieldalignment，而是使用 golangci-lint：

shell> cat .golangci.yaml

linters-settings:
  govet:
    enable-all: true

shell> golangci-lint run --disable-all -E govet

如上可见，fieldalignment 准确判断出优化前代码的 struct size 存在优化空间；但是优化后代码的 pointer bytes 是什么鬼？按照文档中的说明，pointer bytes 的含义如下：

Pointer bytes is how many bytes of the object that the garbage collector has to potentially scan for pointers, for example:

struct { uint32; string }

have 16 pointer bytes because the garbage collector has to scan up through the string’s inner pointer.

struct { string; *uint32 }

has 24 pointer bytes because it has to scan further through the *uint32.

struct { string; uint32 }

has 8 because it can stop immediately after the string pointer.

看到这里，不禁让人产生疑惑：GC 不会这么傻吧，难道它还要一个字节一个字节的扫描内存么？让我们做个实验测试一下 pointer bytes 有没有影响，正所谓有病没病走两步：

package main

import (
	"runtime"
	"time"
)

// pointer bytes: 8
type foo struct {
	s string
	u uint32
}

// pointer bytes: 16
type bar struct {
	u uint32
	s string
}

// GODEBUG=gctrace=1 go run main.go
func main() {
	v := make([]foo, 1e8)
	// v := make([]bar, 1e8)
	for range time.Tick(time.Second) {
		runtime.GC()
	}
	runtime.KeepAlive(v)
}

代码里构造了一个巨大的切片变量，栈必然保存不了，于是变量会逃逸到堆，接着周期性的调用 runtime.GC 来手动触发 GC，然后执行的时候通过 GODEBUG=gctrace=1 获取实时的 GC 相关信息。结果显示，不管是小 pointer bytes 的 foo，还是大 pointer bytes 的 bar，最终 GC 消耗的时间差不多。换句话说，pointer bytes 的大小对 GC 的影响很小很小，在 golang 的相关 issue 的讨论中，也能印证此结论，篇幅所限，这里就不多说了。

另：命令输出的 gctrace 信息比较多，相关格式说明可以参考 runtime 中的注释信息。

例子

了解了内存对齐的相关知识后，让我们看看现实世界中的例子，首先是 groupcache：

type Group struct {
	name string
	getter Getter
	peersOnce sync.Once
	peers PeerPicker
	cacheBytes int64
	mainCache cache
	hotCache cache
	loadGroup flightGroup
	_ int32 // force Stats to be 8-byte aligned on 32-bit platforms
	Stats Stats
}

通过注释我们可以看到，为了强制让 Stats 在 32 位平台上按 8 字节对齐，在 Stats 字段的前面加了一个「_ int32」，换句话说，就是加了 4 个字节，那么为什么要这么做？

原因是 Stats 字段要参与 atomic 原子运算，关于 atomic，文档最后记录了如下内容：

On ARM, 386, and 32-bit MIPS, it is the caller’s responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.

也就是说，在 32 位平台，调用者有责任自己保证原子操作是 64 位对齐的，此外，struct 中第一个字段可以被认为是 64 位对齐的。在本例中，因为 Stats 字段要参与 atomic 运算，而且不是第一个字段，所以我们必须手动保证它是 64 位对齐的，不过加了 _ int32 就能保证是 64 位对齐的么？让我们写代码验证一下：

package main

import (
	"fmt"
	"unsafe"

	"github.com/golang/groupcache"
)

// GOARCH=386 go run main.go
func main() {
	var g groupcache.Group
	fmt.Println(unsafe.Offsetof(g.Stats))
}

结果显示在 32 位下运行，Stats 的 offset 是 176，是 8 的倍数，满足 64 位对齐。如果没有「_ int32」做 padding，那么 Stats 的 offset 将是 172，就不再是 8 的倍数了。

…

再看看 sync.WaitGroup 中内存对齐的例子：

type WaitGroup struct {
	noCopy noCopy

	// 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
	// 64-bit atomic operations require 64-bit alignment, but 32-bit
	// compilers do not ensure it. So we allocate 12 bytes and then use
	// the aligned 8 bytes in them as state, and the other 4 as storage
	// for the sema.
	state1 [3]uint32
}

func (wg *WaitGroup) state() (statep *uint64, semap *uint32) {
	if uintptr(unsafe.Pointer(&wg.state1))%8 == 0 {
		return (*uint64)(unsafe.Pointer(&wg.state1)), &wg.state1[2]
	} else {
		return (*uint64)(unsafe.Pointer(&wg.state1[1])), &wg.state1[0]
	}
}

首先，noCopy 是什么鬼，其实它的作用就像名字一样，它是如何实现的呢，看注释：

// noCopy may be embedded into structs which must not be copied
// after the first use.
//
// See https://golang.org/issues/8005#issuecomment-190753527
// for details.
type noCopy struct{}

// Lock is a no-op used by -copylocks checker from `go vet`.
func (*noCopy) Lock()   {}
func (*noCopy) Unlock() {}

实际上它只是起到标识的作用，以便 go vet 能够借此发现问题，详细说明在 issue 中有描述，如果你在自己的项目里有类似 noCopy 的需求，那么也可以照猫画虎，

接下来是内存对齐相关的重头戏了，state1 字段是一个有 3 个元素的 uint32 数组，它会保存两种数据，分别是 statep 和 semap，其中，statep 要参与 atomic 运算，所以我们要保证它是 64 位对齐的。如果「uintptr(unsafe.Pointer(&wg.state1))%8 == 0」成立，那么取前两个 int32 做 statep，否则取后两个 int32 做 statep。

为什么这样做？因为「uintptr(unsafe.Pointer(&wg.state1))%8 == 0」成立的时候，前两个 int32 自然满足 64 位对齐；当「uintptr(unsafe.Pointer(&wg.state1))%8 == 0」不成立的时候， 其运算结果必然等于 4，此时我们正好可以把第一个 int32 当作是一个 4 字节的 padding，于是后两个字节的 int32 就又满足 64 位对齐了。

如果你认为自己理解了，那么思考一下，在定义 state1 的时候，如果不用 [3]int32，而是换成一个 int64 加上一个 int32，或者是一个 [12]byte，它们都是 12 个字节，是否可以？

如果你搞定了上面的问题，那么不妨再想想，为什么 groupcache 通过增加一个 _ int32 来实现 64 位对齐，而 sync.WaitGroup 却是通过运行时判断来实现 64 位对齐呢？我本想一并写出答案，不过我遇到了和费马一样的问题，这里空白太少了，写不下

实际动手前，最好熟读官方文档，特别是基础概念和基础通讯协议部分，假设你已经了解了这些内容，那么不妨让我们虚拟一个例子：给商城里的用户加积分！然后我们要构建一个 Shop（App），其中有一个 User（Server），其中有一个 Credit（Servant），可以简单的把 App、Server、Servant 这些概念理解成命名空间的几个层级，下面让我们用 tarsgo 内置的 create_tars_server_gomod.sh 脚本来生成项目！

shell> export GOPATH=$(go env GOPATH)
shell> go env -w GO111MODULE=auto
shell> go get -u github.com/TarsCloud/TarsGo/tars
shell> $GOPATH/src/github.com/TarsCloud/TarsGo/tars/tools/create_tars_server_gomod.sh Shop User Credit foo

因为 tarsgo 依赖 GOPATH 和 GO111MODULE，所以务必按照上面的步骤来操作，完成后会生成一个名为 User 的目录，其中的大概内容如下：

shell> tree ./User
./User
├── Credit.tars
├── Credit_imp.go
├── client
│   └── client.go
├── config.conf
├── debugtool
│   └── dumpstack.go
├── go.mod
├── main.go
├── makefile
└── start.sh

编辑 Credit.tars 文件，定义好我们加积分的 Add 方法：

module Shop
{
    interface Credit
    {
        int Add(int a,int b,out int c); // Some example function
    };
};

接下来就可以通过 tars 文件来生成 golang 文件了（其中调用了 tars2go 工具）：

shell> cd User
shell> go mod tidy
shell> make TARSBUILD

文件生成好之后，编辑 Credit_imp.go 文件，加入我们的业务逻辑：

func (imp *CreditImp) Add(ctx context.Context, a int32, b int32, c *int32) (int32, error) {
	log.Println("call add")
	return 100, nil
}

编译服务端和客户端代码，运行就能看到效果了：

shell> go build -o user_server
shell> go build -o user_client ./client/client.go
shell> ./user_server -config config.conf
shell> ./user_client

BTW：缺省生成的客户端代码 client.go 导入的包路径不正确，需要手动调整一下。

总结一下，tarsgo 的开发过程比较简单，基本上就是：编写 tars 文件；用 tars2go 生成代码；实现业务逻辑。当然了，实际部署的时候会有一个管理平台，服务治理等复杂的问题都隐藏在平台里，这些细节就不是本文所考虑的了，再见。

让我们搞一段简单的代码来重现一下当时我遇到的问题：

package main

import "sync"

func main() {
	var wg sync.WaitGroup
	foo := make(chan int)
	bar := make(chan int)
	closing := make(chan struct{})
	wg.Add(1)
	go func() {
		defer wg.Done()
		select {
		case foo <- <-bar:
		case <-closing:
			println("closing")
		}
	}()
	// bar <- 123
	close(closing)
	wg.Wait()
}

运行后报错，提示死锁：

fatal error: all goroutines are asleep – deadlock!

因为「foo <- <-bar」的写法不太常见，所以第一感觉是不是 select 的 case 语句只能操作一个 chan，不能同时操作多个 chan，于是我改了一下，每个 case 只读写一个 chan：

package main

import "sync"

func main() {
	var wg sync.WaitGroup
	foo := make(chan int)
	bar := make(chan int)
	closing := make(chan struct{})
	wg.Add(1)
	go func() {
		defer wg.Done()
		select {
		case v := <-bar:
			foo <- v
		case <-closing:
			println("closing")
		}
	}()
	close(closing)
	wg.Wait()
}

果然死锁消失了！似乎 select 中，每个 case 确实只能读写一个 chan。为了确认到底是不是这个原因，我又修改了一下最初有问题的代码，加上了「bar <- 123」，结果死锁也消失了。看来虽然我找到了解决问题的方法，但是并没有找到解释问题的原因。

周末在家躺在床上，想起我认识的一个 golang 大神总对我说的：一切问题的答案都在 spec 里。于是挣扎着爬起来仔细翻阅关于 select 的说明，终于发现了问题真正的原因：

For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the “select” statement. The result is a set of channels to receive from or send to, and the corresponding values to send. Any side effects in that evaluation will occur irrespective of which (if any) communication operation is selected to proceed. Expressions on the left-hand side of a RecvStmt with a short variable declaration or assignment are not yet evaluated.

结合这段话，让我们再来看看 case 中的这行代码「foo <- <-bar」，因为所有 chan 表达式都会被求值、所有被发送的表达式都会被求值，所以右手边表达式（<-bar）会被先执行，如果拿到结果后再选择 case 执行，如果拿不到结果就会一直堵塞，于是死锁。

如果你还是想不明白，那么你可以认为问题代码实际上等价于如下的写法：

package main

import "sync"

func main() {
	var wg sync.WaitGroup
	foo := make(chan int)
	bar := make(chan int)
	closing := make(chan struct{})
	wg.Add(1)
	go func() {
		defer wg.Done()
		v := <-bar
		select {
		case foo <- v:
		case <-closing:
			println("closing")
		}
	}()
	// bar <- 123
	close(closing)
	wg.Wait()
}

如果你觉得自己已经完全明白了，那么不妨看看下面这段代码：

package main

import (
	"fmt"
	"time"
)

func talk(msg string, sleep int) <-chan string {
	ch := make(chan string)
	go func() {
		for i := 0; i < 5; i++ {
			ch <- fmt.Sprintf("%s %d", msg, i)
			time.Sleep(time.Duration(sleep) * time.Millisecond)
		}
	}()
	return ch
}

func fanIn(input1, input2 <-chan string) <-chan string {
	ch := make(chan string)
	go func() {
		for {
			select {
			case ch <- <-input1:
			case ch <- <-input2:
			}
		}
	}()
	return ch
}

func main() {
	ch := fanIn(talk("A", 10), talk("B", 1000))
	for i := 0; i < 10; i++ {
		fmt.Printf("%q\n", <-ch)
	}
}

当然会出现死锁，我的问题是为什么每次都是不多不少输出一半数据才死锁？请回答。

让我们重回案发现场，看看问题是怎么产生的：

首先是 .gitlab-ci.yml 文件，其相关代码片段内容如下：

build_job:
  stage: build
  script:
    - make docker-build

然后是 Makefile 文件，其相关代码片段内容如下：

.PHONY: docker-build
docker-build:
	@docker-compose build

接着是 docker-compose.yml 文件，其相关代码片段内容如下：

build:
  context: .
  dockerfile: Dockerfile

最后是 Dockfile 文件，其相关代码片段内容一下：

FROM golang:1.17 AS builder
WORKDIR /go/src/app
COPY . .
RUN go build

结果在 build 的时候报错了：

fatal: could not read Username for ‘https://git.domain.com’: terminal prompts disabled

因为 git.domain.com 是一个私有仓库，所以问题乍一看上去会以为是 GOPRIVATE 和 GOPROXY 的配置有问题，不过我的配置都是 OK 的：

shell> go env -w GOPRIVATE=git.domain.com
shell> go env -w GOPROXY=https://goproxy.cn,direct

实际上，根本原因是因为访问私有仓库的时候是需要用户名和密码的，但是在 docker 容器里获取不到用户名密码，所以就报错了。下面看看我是如何解决问题的：

第一次尝试

既然问题出在用户名密码上，那么把仓库改成公开的不就可以了么？可惜结果报错：

Visibility level public is not allowed in a private group.

我用的是 gitlab，它不允许在私有组里搞一个公开项目。

第二次尝试

既然搞不成公开项目，那么就想办法传递用户名密码吧，不过我们在使用 git 的时候，一般不会直接使用用户名密码，而是使用 KEY 来访问仓库，下面举例说明一下如何传递私钥参数 SSH_PRIVATE_KEY（其中牵扯到一个 docker 构建参数的概念）：

首先因为此类信息比较敏感，所以应该避免硬编码，我们选择在 gitlab 里创建它：

Secret variables: settings > Pipelines

接着是 docker-compose.yml 文件，其相关代码片段内容如下：

build:
  context: .
  dockerfile: Dockerfile
  args:
    - SSH_PRIVATE_KEY

最后是 Dockfile 文件，其相关代码片段内容一下：

FROM golang:1.17 AS builder
ARG SSH_PRIVATE_KEY
WORKDIR /go/src/app
COPY . .
RUN umask 0077 \
    && mkdir -p ~/.ssh \
    && echo "${SSH_PRIVATE_KEY}" > ~/.ssh/id_rsa \
    && ssh-keyscan git.domain.com >> ~/.ssh/known_hosts \
    && git config --global url."git@git.domain.com:".insteadOf https://git.domain.com/
RUN go build

此方法可以解决问题，但是把敏感信息传来传去总觉得不安心，容易出问题，资料：Access Private Repositories from Your Dockerfile Without Leaving Behind Your SSH Keys。

第三次尝试

如果不想把敏感信息传来传去，那么还有没有安全的解决方案呢？答案是肯定的！我们只要在 gitlab runner 里执行「go mod vendor」就可以了，这是因为 gitlab runner 已经缓存了 git 认证信息，它可以访问所有的私有仓库，当执行「go mod vendor」后，项目依赖就都被放到 vendor 目录里了，接下来当执行到 Dockerfile 的 COPY 指令时，依赖就被自然而然的拷贝到了容器中，从而不用再联网执行 git 下载。

下面是修改后的 .gitlab-ci.yaml 文件，其相关代码片段内容如下：

build_job:
  stage: build
  script:
    - go mod vendor
    - make docker-build

也就是说，我们只加了一行代码「go mod vendor」，就解决了问题，是不是很简洁。最后友情提示一下：记得把 vendor 目录放到 .gitignore 里哦。

让我们先把问题的来龙去脉搞清楚，在 Golang 项目里，一般推荐在根目录创建一个名为 tools.go 的文件，里面记录本项目依赖的相关工具，比如我的某个项目的 tools.go 如下：

// +build tools

package tools

import (
	// _ "github.com/cosmtrek/air"
	// _ "github.com/goreleaser/goreleaser"
	_ "github.com/bufbuild/buf/cmd/buf"
	_ "github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway"
	_ "github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2"
	_ "github.com/securego/gosec/v2/cmd/gosec"
	_ "github.com/tomwright/dasel/cmd/dasel"
	_ "google.golang.org/grpc/cmd/protoc-gen-go-grpc"
	_ "google.golang.org/protobuf/cmd/protoc-gen-go"
)

如此一来，当执行「go mod tidy」的时候，依赖工具的版本信息就会记录到 go.mod，接下来一般推荐在 Makefile 里创建一个 dep 操作，用来安装（make dep）依赖工具：

.PHONY: dep
dep:
	@go install \
		github.com/bufbuild/buf/cmd/buf \
		github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway \
		github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2 \
		github.com/securego/gosec/v2/cmd/gosec \
		github.com/tomwright/dasel/cmd/dasel \
		google.golang.org/grpc/cmd/protoc-gen-go-grpc \
		google.golang.org/protobuf/cmd/protoc-gen-go

看上去不错，但是细心的你估计已经发现重复代码的坏味道了：tools.go 和 Makefile 文件内容重复了，以后如果想要增加一个依赖工具的话，那么两个文件都要改！

下面让我们看看如何重构：tools.go 和 Makefile 比起来，肯定 tools.go 更重要，它是不能改的，所以我们要去掉 Makefile 里的重复代码，更具体点来说是最好能在 Makefile 里通过 解析 tools.go 来确定想要执行的 go install 操作，这不就是 awk 擅长的工作么：

.PHONY: dep
dep:
	@awk '$$1 == "_" { print $$2 | "xargs go install" }' ./tools.go

看，通过一行 awk 代码，我们神奇的去掉了原本一坨重复代码，完美！

假设有一个名为 foo 的项目，用 golang 开发，在 docker 上部署，其 Makefile 如下：

APP = $(shell basename ${CURDIR})
TAG = $(shell git log --pretty=format:"%cd.%h" --date=short -1)

.PHONY: build
build:
	go build -ldflags "-X 'main.version=${TAG}'" -o ./tmp/${APP} .

.PHONY: docker-config
docker-config: env
	TAG=${TAG} docker-compose config

.PHONY: docker-build
docker-build: env
	TAG=${TAG} docker-compose build

.PHONY: docker-push
docker-push: env
	TAG=${TAG} docker-compose push

.PHONY: docker-up
docker-up: env
	TAG=${TAG} docker-compose up

.PHONY: docker-down
docker-down:
	TAG=${TAG} docker-compose down

看上去很简洁，唯一需要说明的是在操作 docker-compose 的时候，传递了一个名为 TAG 的环境变量，表示项目当前所属的标签，看一下对应的 docker-compose.yml 文件：

version: "3.0"
services:
  server:
    image: docker.domain.com/foo:${TAG}
    build:
      context: .
      dockerfile: build/docker/Dockerfile
    ports:
      - "9090:9090"
      - "6060:6060"

此时出现了一个有待改进的地方：ports 信息重复，看一下对应的 config.toml 文件：

[rpc]
port = 9090

[debug]
port = 6060

其中，rpc 端口 9090，debug 端口 6060 最初是在 config.toml 文件里配置的，但是在 docker-compose.yml 文件又重复了一次，假设要修改的话，就需要修改多个地方。

此时我们很容易想到的解决方案是把端口信息也通过环境变量传递，就像 TAG 变量那样，确定了解决方案，让我们再看一下对应的 docker-compose.yml 文件：

version: "3.0"
services:
  server:
    image: docker.domain.com/${APP}:${TAG}
    build:
      context: .
      dockerfile: build/docker/Dockerfile
    ports:
      - "${RPC_PORT}:${RPC_PORT}"
      - "${DEBUG_PORT}:${DEBUG_PORT}"

让我们再看看对应的 Makefile 文件，其中用 dasel 来解析配置文件：

APP = $(shell basename ${CURDIR})
TAG = $(shell git log --pretty=format:"%cd.%h" --date=short -1)
RPC_PORT   = $(shell dasel -f configs/production.toml rpc.port)
DEBUG_PORT = $(shell dasel -f configs/production.toml debug.port)

.PHONY: build
build:
	go build -ldflags "-X 'main.version=${TAG}'" -o ./tmp/${APP} .

.PHONY: docker-config
docker-config: env
	APP=${APP} TAG=${TAG} RPC_PORT=${RPC_PORT} DEBUG_PORT=${DEBUG_PORT} docker-compose config

.PHONY: docker-build
docker-build: env
	APP=${APP} TAG=${TAG} RPC_PORT=${RPC_PORT} DEBUG_PORT=${DEBUG_PORT} docker-compose build

.PHONY: docker-push
docker-push: env
	APP=${APP} TAG=${TAG} RPC_PORT=${RPC_PORT} DEBUG_PORT=${DEBUG_PORT} docker-compose push

.PHONY: docker-up
docker-up: env
	APP=${APP} TAG=${TAG} RPC_PORT=${RPC_PORT} DEBUG_PORT=${DEBUG_PORT} docker-compose up

.PHONY: docker-down
docker-down:
	APP=${APP} TAG=${TAG} RPC_PORT=${RPC_PORT} DEBUG_PORT=${DEBUG_PORT} docker-compose down

不得不说，长长的环境变量实在是太丑了，好在 docker-compose 支持 .env 文件，于是我们可以把环境变量写入 .env 文件，然后让 docker-compose 命令从其中取数据：

APP = $(shell basename ${CURDIR})
TAG = $(shell git log --pretty=format:"%cd.%h" --date=short -1)
RPC_PORT   = $(shell dasel -f configs/production.toml rpc.port)
DEBUG_PORT = $(shell dasel -f configs/production.toml debug.port)

.PHONY: env
env: build
	echo "APP=${APP}" > .env; \
		echo "TAG=${TAG}" >> .env; \
		echo "RPC_PORT=${RPC_PORT}" >> .env; \
		echo "DEBUG_PORT=${DEBUG_PORT}" >> .env

.PHONY: build
build:
	go build -ldflags "-X 'main.version=${TAG}'" -o ./tmp/${APP} .

.PHONY: docker-config
docker-config: env
	docker-compose config

.PHONY: docker-build
docker-build: env
	docker-compose build

.PHONY: docker-push
docker-push: env
	docker-compose push

.PHONY: docker-up
docker-up: env
	docker-compose up

.PHONY: docker-down
docker-down: env
	docker-compose down

在 Makefile 里，我们定义了一个 env 操作，并把它作为所有 docker-compose 操作的前置操作来执行，终于不用再写长长的环境变量了，不过记得把 .env 写到 .gitignore 里！

流程图

看上去很简单，不过我还是遇到不少问题，虽然这些问题主要都是一些细枝末节，基本上和 OCR 没什么关系，但是对别的项目还是会有所帮助的，下面让我一一道来。

代码冗长

编程里最常见的坏味道就是代码冗长，比如我的 main.go 就是如此，它足足有几百行代码之多，里面充斥着各种初始化配置，日志之类的操作。

为了规避此类问题，我引入了一个 initializer 的概念，用来统一初始化操作，比如 viper：

package initializer

import (
	"strings"

	"github.com/fsnotify/fsnotify"
	log "github.com/sirupsen/logrus"
	"github.com/spf13/viper"
)

func Viper(env string) error {
	if env == "" {
		env = "development"
	}
	viper.AutomaticEnv()
	viper.SetConfigName(env)
	viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))
	viper.AddConfigPath(".")
	viper.AddConfigPath("./configs")
	viper.AddConfigPath("../configs")
	if err := viper.ReadInConfig(); err != nil {
		return err
	}
	viper.WatchConfig()
	viper.OnConfigChange(func(e fsnotify.Event) {
		log.Debugf("config file changed: %s", e.Name)
	})
	return nil
}

有了 initializer 之后，原本挤在一起的代码就可以分而治之，同时因为函数签名统一返回 error，所以可以统一进行错误处理，最终 main.go 代码行数大大降低：

var version string

func main() {
	var env string
	cobra.EnableCommandSorting = false
	cobra.OnInitialize(func() {
		check(initializer.Viper(env))
		check(initializer.Logrus())
		// ...
	})
	rootCmd := &cobra.Command{
		Use:     filepath.Base(os.Args[0]),
		Version: version,
	}
	rootCmd.PersistentFlags().StringVarP(
		&env, "env", "e", os.Getenv("SERVICE_ENV"), "env",
	)
	rootCmd.AddCommand(cmd.NewServerCmd())
	check(rootCmd.Execute())
}

func check(err error) {
	if err != nil {
		panic(err)
	}
}

除了 initializer 以外，其实我还引入了一个 provider 的概念，用来获取 sarama 等实例，也可以降低代码冗长的坏味道，提升复用性，篇幅所限，本文就不做赘述了。

同步异步

因为我之前一直在学习 Kafka，所以最初在架构选型的时候完全忽略了 gRPC 之类的同步架构，一门心思的想要以 Kafka 为中心打造一个基于事件的异步架构。此类极端的思想往往是个坏信号，实际上这就跟政治一样，不管是极左还是极右，通常都不可取。关于同步和异步，各取所长才是最合理的选择，判断方法：如果是业务逻辑的实现部分，那么倾向于选择使用同步；如果是业务逻辑完成之后的后续通知部分：强烈建议选择使用异步。具体请参考「走出微服务误区：避免从单体到分布式单体」。

Kafka 客户端

既然 Kafka 在架构中的地位如此重要，那么需要选择一下用哪个客户端，其 Golang 客户端主要有：sarama、confluent-kafka-go、kafka-go，优缺点如下：

• sarama：它是最流行也是最难用的，文档很烂，API 封装太低级，暴露了过多 Kafka 协议的细节，而且还不支持 context 等新的 Golang 特色，实现上它把所有值都当指针传递，导致过多的动态内存分配，频繁的垃圾回收，大量的内存使用。
• confluent-kafka-go：它是基于 librdkafka 实现的 CGO，这意味着使用了这个包，你的代码就会依赖 C 库，和 sarama 相比，它的文档更好，但是同样不支持 context。
• kafka-go：前面关于 saram 和 confluent-kafka-go 的坏话都是它说的。

看上去似乎 kafka-go 最好，confluent-kafka-go 次之，sarama 最烂，可是当我问一个鹅厂小伙伴的时候，他说他们都用 sarama，信大厂得永生，于是乎我也决定选 sarama 了，事后证明这可能是一个糟糕的选择，sarama 虽然很流行，但是确实很难用。但是不管怎么说，使用 sarama 的案例相对更多，用起来也更安心些，不过用之前要清楚坑在哪：

• • Golang中如何正确的使用sarama包操作Kafka？
  • 为什么不推荐使用Sarama Go客户端收发消息？

Sarama 的版本

一开始用 sarama 的时候，就遭到了当头棒喝，遇到了如下错误：

ERROR: Failed to open Kafka producer: kafka: client has run out of available brokers to talk to (Is your cluster reachable?)

反复确认才发现是版本问题，我们的服务端版本比较低（0.11.0.0），翻看 sarama 的 changelog，发现是在 1.27.1 开始切换到高版本的，如此说来只要使用 1.27.0 就可以了，同时务必记得把版本依赖写入 go.mod 文件中：

replace github.com/Shopify/sarama => github.com/Shopify/sarama v1.27.0

多个 goroutines 的协同

前面提到 sarama 有一个问题是暴露了过多 Kafka 协议的细节，这一点在使用 consumer 的时候可见一斑：因为 sarama 暴露了分区的细节，所以带来了很多麻烦，比如要关闭 consumer 的话，不得不先关闭每一个分区上的 PartitionConsumer，最后才可以关闭 consumer。不过话说回来，正好可以借机练习一下多个 goroutines 的协同：

type Watchman struct {
	waitGroup sync.WaitGroup
	consumer  sarama.Consumer
	closing   chan struct{}
}

func NewWatchmanFromConsumer(c sarama.Consumer) *Watchman {
	return &Watchman{
		consumer: c,
		closing:  make(chan struct{}),
	}
}

func (w *Watchman) Watch(topic string) (<-chan *sarama.ConsumerMessage, error) {
	msg := make(chan *sarama.ConsumerMessage)
	pids, err := w.consumer.Partitions(topic)
	if err != nil {
		return nil, err
	}
	for _, pid := range pids {
		pc, err := w.consumer.ConsumePartition(topic, pid, sarama.OffsetNewest)
		if err != nil {
			return nil, err
		}
		w.waitGroup.Add(1)
		go func() {
			defer w.waitGroup.Done()
			for {
				select {
				case message := <-pc.Messages():
					msg <- message
				case <-w.closing:
					pc.Close()
					return
				}
			}
		}()
	}
	return msg, nil
}

func (w *Watchman) Close() {
	close(w.closing)
	w.waitGroup.Wait()
	w.consumer.Close()
}

说明：留意代码中是如何通过 waitGroup 和 closing 来处理多个 goroutines 的协同的。

编译错误

一般编译 Golang 代码不会遇到什么错误，但是因为我们的项目牵扯到 C++，所以在编译过程中还是遇到了一些莫名其妙的问题，下面逐一记录一下：

error adding symbols: DSO missing from command line：

在老版本的 binutils 里，ld 会自动递归地解析链接的 lib，不过从 2.22（ld -v）开始，ld 缺省激活了 –no-copy-dt-needed-entries 选项，如此一来，ld 不会再自动递归地解析链接的 lib，而是需要由用户来手动指定。知道了来龙去脉，不难想到如下解决方案：

• 手动：通过 -l 选项手动加载需要的库，比如需要 libz.so，就设置 -lz
• 自动：在 LDFLAGS 里添加 -Wl,–copy-dt-needed-entries 选项

推荐资料：libpthread.so.0: error adding symbols: DSO missing from command line

undefined reference to `__cxa_throw_bad_array_new_length’：

编译 libstdc++ 时，会使用命令 msgfmt。而 msgfmt 依赖 libstdc++.so.6，但编译时，gcc的编译系统会把 msgfmt 的依赖指向其自身的 libstdc++.so.6，而不是系统自带的libstdc++.so.6。如果 gcc 的版本比较老，就会导致 libstdc++.so.6 与 msgfmt 不兼容。

知道了来龙去脉，不难想到解决方案就是使用新版 gcc，更具体一点说是使用版本不低于 4.9 的 gcc（CentOS 7 上的 gcc 版本一般是 4.8.5），不过不推荐直接从源代码安装新版 gcc，其困难程度不是一般人能接受的，相对更可取的方法是通过 scl 安装 devtoolset：

shell> gcc -v
gcc version 4.8.5
shell> yum install centos-release-scl
shell> yum install devtoolset-7
shell> scl enable devtoolset-7 bash
shell> gcc -v
gcc version 7.3.1
shell> exit
shell> gcc -v
gcc version 4.8.5

关于 devtoolset 还有一个冷知识：devtoolset 和 gcc 的版本对应关系如下：

• devtoolset-3: gcc 4.9
• devtoolset-4: gcc 5
• devtoolset-6: gcc 6
• devtoolset-7: gcc 7
• devtoolset-8: gcc 8

你会发现没有版本 5，原因在 Release Notes for Red Hat Developer Toolset 6.0 里说了：

The version number of Red Hat Developer Toolset has been raised from 4.1 to 6.0 to align with the major version of GCC. There is no Red Hat Developer Toolset 5.

嗯，我承认这个无聊的问题困扰了我好几年，最终知道原因后感觉真是怅然若失啊。

条件编译

因为我们的服务底层是 FineReader 引擎，而且我们只有其 Linux 版本的 SDK，加上我们的本地开发环境是 MAC 系统，所以一开始我们在本地是没办法编译的，每次修改完代码我都会把代码传到 Linux 上编译，真是让人焦躁啊，好在 Golang 支持通过文件名来进行条件编译，比如我把原本的 abbyy.go 文件按操作系统拆分出 _linux.go 和 _darwin.go：

abbyy_linux.go：

package doc

// #cgo CFLAGS: -I .
// #cgo LDFLAGS: ${SRCDIR}/vendor/libabbyy.a -L /opt/ABBYY/FREngine12/Bin -lFREngine -lPortLayer -lstdc++
// #include <stdlib.h>
/*
void loadAbbyy();
int runAbbyy(const char *source, const char *destination, const char *status);
void unloadAbbyy();
*/
import "C"
import "unsafe"

func doJob(source, destination, status string) bool {
	csource := C.CString(source)
	cdestination := C.CString(destination)
	cstatus := C.CString(status)
	C.loadAbbyy()
	defer func() {
		C.unloadAbbyy()
		C.free(unsafe.Pointer(csource))
		C.free(unsafe.Pointer(cdestination))
		C.free(unsafe.Pointer(cstatus))
	}()
	return C.runAbbyy(csource, cdestination, cstatus) == 0
}

abbyy_darwin.go：

package doc

func doJob(source, destination, status string) bool {
	return false
}

拆分后，虽然我的 MAC 系统还是不能使用 FineReader 引擎，但是至少能够在本地开发环境正常编译了，处理一些非 CGO 类的问题绰绰有余了。

测试 gRPC

开发完成 gRPC 服务后，免不了要时不时的测试它，最开始我用的是 grpcurl，类似：

shell> grpcurl -plaintext -emit-defaults \
    -d '{"source":"/tmp/01.pdf","destination":"/tmp/02.pdf"}' \
    <address> doc.v1.AbbyyService.OCR

不过命令行用起来总是不如 web 方便，于是借助 grpc-gateway 集成了 swagger：

syntax = "proto3";

package doc.v1;

option go_package = "gitlab.test.com/doc/pkg/proto/doc/v1";

import "google/api/annotations.proto";
import "protoc-gen-openapiv2/options/annotations.proto";

option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_swagger) = {
    info: {
        version: "1.0";
    };
};

service AbbyyService {
    rpc OCR(OCRRequest) returns (stream OCRResponse) {
        option (google.api.http) = {
            post: "/ocr"
            body: "*"
        };
    }
}

message OCRRequest {
    string source = 10;
    string destination = 20;
}

message OCRResponse {
    string action = 10;
    int32 percentage = 20;
}

通过 protoc 编译：

shell> protoc -I /path/to/proto \
    --go_out=./pkg/proto \
    --go_opt=paths=source_relative \
    --go-grpc_out=./pkg/proto \
    --go-grpc_opt=paths=source_relative \
    --grpc-gateway_out=./pkg/proto \
    --grpc-gateway_opt=paths=source_relative \
    --openapiv2_out=./api \
    /path/to/proto/*.proto

其中 protoc-gen-openapiv2 插件能够生成 swagger 所需的 json文件，更多 openapiv2 的使用例子可以参考：Complete list of swagger options to protobuf file，最终效果如下：

swagger

顺便说一句，为了部署方便，我用「//go:embed *」语法把整个 swagger ui 打包进二进制文件了，不得不说，embed 真是爽啊，有兴趣的可以参考：Go embed 简明教程。

公共 proto

在编写 proto 的时候，我们用到了 googleapis，grpc-gateway 等项目里的公共 proto，这里牵扯到一个如何导入公共 proto 的问题，最常见的方法是把这些公共 proto 直接拷贝到项目目录中，但是如果有很多的项目需要用到这些公共 proto 的话，那么就不得不拷贝很多个副本，于是又有人把公共 proto 统一保存到独立的仓库中，然后其他项目在构建的时候都引用它，如此也不错，不过总觉得差点啥，最终我发现了完美的解决方案 buf：

先编写 buf.yaml 文件，主要用来声明依赖那些公共 proto：

version: v1beta1
deps:
  - buf.build/beta/googleapis
  - buf.build/grpc-ecosystem/grpc-gateway
build:
  roots:
    - ./pkg/proto

再编写 buf.gen.yaml 文件，主要用来声明使用哪些插件，如何生成需要的文件：

version: v1beta1
plugins:
  - name: go
    out: ./pkg/proto
    opt:
      - paths=source_relative
  - name: go-grpc
    out: ./pkg/proto
    opt:
      - paths=source_relative
  - name: grpc-gateway
    out: ./pkg/proto
    opt:
      - paths=source_relative
  - name: openapiv2
    out: ./api

准备好后，先用「buf mod update」命令生成 buf.lock 锁定版本信息，再用「buf generate」命令就可以生成我们要的各种 go 文件和 json 文件了：

shell> buf mod update
shell> buf generate

可见使用 buf 比直接使用 protoc 要方便很多，而且还有很多高级功能，详见 buf 文档。

依赖工具

在使用 grpc-gateway 的时候，我们用到了其中的 protoc-gen-openapiv2 工具，实际上，grpc-gateway 有两个大版本，protoc-gen-openapiv2 在 v2 版本中，而在 v1 版本中对应的工具叫做 protoc-gen-swagger，很容易混淆，可见明确依赖工具的版本非常重要。

目前推荐的方法是在项目根目录创建名为 tools.go 的文件来记录依赖工具，比如：

// +build tools

package tools

import (
	// _ "github.com/cosmtrek/air"
	// _ "github.com/Shopify/sarama/tools/kafka-console-consumer"
	// _ "github.com/Shopify/sarama/tools/kafka-console-producer"
	_ "github.com/bufbuild/buf/cmd/buf"
	_ "github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway"
	_ "github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2"
	_ "google.golang.org/grpc/cmd/protoc-gen-go-grpc"
	_ "google.golang.org/protobuf/cmd/protoc-gen-go"
)

如此一来，当执行「go mod tidy」的时候，依赖工具的版本信息也会被 go.mod 记录下来，后续别人接手项目后，就很清楚的知道依赖什么工具，分别是什么版本了。

在 K8S 下部署服务，缺省情况下会被分配一个地址（也就是 ClusterIP），客户端的请求会发送给它，然后再通过负载均衡转发给后端某个 pod：

ClusterIP

如果是 HTTP/1.1 之类的服务，那么 ClusterIP 完全没有问题；但是如果是 gRPC 服务，那么 ClusterIP 会导致负载失衡，究其原因，是因为 gRPC 是基于 HTTP/2 的，多个请求在一个 TCP 连接上多路复用，一旦 ClusterIP 和某个 pod 建立了 gRPC 连接后，因为多路复用的缘故，所以后续其它请求也都会被转发给此 pod，结果其它 pod 则完全被忽略了。

看到这里，有的读者可能会有疑问：HTTP/1.1 不是实现了基于 KeepAlive 的连接复用么？为什么 HTTP/1.1 的复用没问题，而 HTTP/2 的复用就有问题？答案是 HTTP/1.1 的 复用是串行的，当请求到达的时候，如果没有空闲连接那么就新创建一个连接，如果有空闲连接那么就可以复用，同一个时间点，连接里最多只能承载一个请求，结果是 HTTP/1.1 可以连接多个 pod；而 HTTP/2 的复用是并行的，当请求到达的时候，如果没有连接那么就创建连接，如果有连接，那么不管其是否空闲都可以复用，同一个时间点，连接里可以承载多个请求，结果是 HTTP/2 仅仅连接了一个 pod。

了解了 K8S 下 gRPC 负载均衡问题的来龙去脉，我们不难得出如下解决方案：

在 Proxy 中实现负载均衡：采用 Envoy 做代理，和每台后端服务器保持长连接，当客户端请求到达时，代理服务器依照规则转发请求给后端服务器，从而实现负载均衡。

Proxy

在 Client 中实现负载均衡：把服务部署成 headless service，这样服务就有了一个域名，然后客户端通过域名访问 gRPC 服务，DNS resolver 会通过 DNS 查询后端多个服务器地址，然后通过算法来实现负载均衡。

Client

两种方案的优缺点都很明显：Proxy 方案结构清晰，客户端不需要了解后端服务器，对架构没有侵入性，但是性能会因为存在转发而打折扣；Client 方案结构复杂，客户端需要了解后端服务器，对架构有侵入性，但是性能更好。

Hello World

让我们看看一个 CGO 版本的 Hello, world 大概长什么样：

package main

/*
#include <stdio.h>

void say(const char *s) {
    puts(s);
}
*/
import "C"

func main() {
    hello()
}

func hello() {
    s := C.CString("Hello, World\n")
    C.say(s)
}

如上所示，通过「import “C”」来激活 CGO，并且所有 C 语言相关的代码都以注释的形式放在此行之上，中间不允许有空行，这样我们就可以在 Golang 代码里使用 C 模块了,看上去很简单，不过代码里存在内存泄漏，让我们修改一下代码，使问题更明显一点：

package main

/*
#include <stdio.h>

void say(const char *s) {
    puts(s);
}
*/
import "C"

func main() {
    for {
        hello()
    }
}

func hello() {
    s := C.CString("Hello, World\n")
    C.say(s)
}

运行程序后，我们可以单独开一个命令行窗口，通过运行 top 命令来监控进程的内存变化，会发现在循环调用 C 模块之后，进程的内存占用不断增加，究其原因，是因为通过 C.CString 创建的变量，会在 C 语言层面上分配内存，而在 Golang 语言层面上是不会负责管理相关内存的，所以我们需要通过 C.free 手动释放相关内存：

package main

/*
#include <stdio.h>
#include <stdlib.h>

void say(const char *s) {
    puts(s);
}
*/
import "C"
import "unsafe"

func main() {
    for {
        hello()
    }
}

func hello() {
    s := C.CString("Hello, World\n")
    defer C.free(unsafe.Pointer(s))
    C.say(s)
}

说明：代码中的 unsafe.Pointer 相当于 C 语言中的 void *。

In Action

有些读者看到这里可能会有疑问：虽然 CGO 让我们可以在 Golang 里使用 C，但是文章开头提到的 ABBYY 并没有 C 的 SDK，只有 C++ 的 SDK，那么 CGO 支持 C++ 么？答案是否定的，不过我们可以通过 C 来适配 C++。

以 ABBYY 为例，假设它的安装目录是 /opt/ABBYY/FREngine12，并且通过 ldconfig 把 /opt/ABBYY/FREngine12/Bin 目录加入到动态链接库的查找目录：

shell> echo "/opt/ABBYY/FREngine12/Bin" > /etc/ld.so.conf.d/abbyy.conf
shell> ldconfig

准备工作做好后使用 /opt/ABBYY/FREngine12/Samples/Hello 例子做代码范本：

先编写 OCR.cpp 文件的内容，不用在意技术细节，我放这些代码只是为了备份：

#include <string>
#include "AbbyyException.h"
#include "BstrWrap.h"
#include "FREngineLoader.h"
#include "./OCR.h"

using namespace std;

void load() {
    LoadFREngine();
}

void unload() {
    UnloadFREngine();
}

void process(const char *inPath, const char *outPath) {
    string file = outPath;
    string extension = file.substr(file.find_last_of(".") + 1);
    FileExportFormatEnum format;

    if (extension == "pdf") {
        format = FEF_PDF;
    } else if (extension == "doc" || extension == "docx") {
        format = FEF_DOCX;
    } else if (extension == "ppt" || extension == "pptx") {
        format = FEF_PPTX;
    } else if (extension == "xls" || extension == "xlsx") {
        format = FEF_XLSX;
    } else {
        return;
    }

    const wchar_t *language = L"ChinesePRC,ChineseTaiwan,English";
    CSafePtr<IFRDocument> frDocument = 0;
    CSafePtr<IDocumentProcessingParams> documentProcessingParams;
    CSafePtr<IPageProcessingParams> pageProcessingParams;
    CSafePtr<IRecognizerParams> recognizerParams;

    try {
        CheckResult(FREngine->CreateFRDocumentFromImage(CBstr(inPath), 0, &frDocument));
        CheckResult(FREngine->CreateDocumentProcessingParams(&documentProcessingParams));
        CheckResult(documentProcessingParams->get_PageProcessingParams(&pageProcessingParams));
        CheckResult(pageProcessingParams->get_RecognizerParams(&recognizerParams));
        CheckResult(recognizerParams->SetPredefinedTextLanguage(CBstr(language)));
        CheckResult(frDocument->Process(documentProcessingParams));
        CheckResult(frDocument->Export(CBstr(outPath), format, 0));
    } catch (...) {
        return;
    }
}

再编写 OCR.h 文件的内容，要特别注意其中的「extern “C”」，有了它，当编译的时候，就会把 C++ 中的方法名链接成 C 的风格，如此一来，CGO 才能识别它：

#ifdef __cplusplus
extern "C" {
#endif
void load();
void unload();
void process(const char *inPath, const char *outPath);
#ifdef __cplusplus
}
#endif

我们可以通过 nm 命令查看某个方法名在使用 extern “C” 前后的差异：

// Before
shell> nm OCR.o | grep process
0000000000000016 T _Z7processPKcS0_
// After
shell> nm OCR.o | grep process
0000000000000016 T process

最后编写 OCR.go 文件的内容，因为 C/C++ 代码量比较大，所以在使用 CGO 的时候直接把 C/C++ 代码写在注释中就显得不合适了，此时更合适的方法是链接库：

package main

// #cgo CFLAGS: -I .
// #cgo LDFLAGS: -L . -L /opt/ABBYY/FREngine12/Bin/ -lFREngine -lOCR -lstdc++
// #include <stdlib.h>
// #include "OCR.h"
import "C"
import (
	"flag"
	"os"
	"unsafe"
)

func main() {
	flag.Parse()

	if flag.NArg() != 2 {
		os.Exit(1)
	}

	C.load()
	inPath := C.CString(flag.Arg(0))
	outPath := C.CString(flag.Arg(1))

	defer func() {
		C.unload()
		C.free(unsafe.Pointer(inPath))
		C.free(unsafe.Pointer(outPath))
	}()

	C.process(inPath, outPath)
}

假设目标文件都已经就绪，那么让我们分别看看如何构建静态链接库和动态链接库：

先看静态链接库，只要通过如下 ar 命令即可，在最终编译程序的时候，静态链接库会被编译到程序里，所以运行时不存在依赖问题，当然代价就是文件尺寸相对较大：

shell> ar -r libOCR.a *.o

再看动态链接库，只要通过如下 gcc 命令即可，和静态链接库相比，虽然它运行时存在依赖问题，但是它生成的文件尺寸相对较小，不过需要提醒的是，在之前编译目标文件的时候，需要在 CFLAGS 或 CXXFLAGS 参数中需要加入 -fpic 或者 -fPIC 选项，以便实现地址无关，至于 -fpic 和 -fPIC 的区别，可以参考 Shared Libraries：

shell> gcc -shared -o libOCR.so *.o
shell> cp libOCR.so /opt/ABBYY/FREngine12/Bin/

动态链接库还有一个优点是更新方便，如果多个程序依赖同一个动态链接库的时候，那么当动态链接库有问题的时候，直接更新它即可，相反如果多个程序依赖同一个静态链接库，那么当静态链接库有问题的时候，你不得不重新编译每一个程序。不过动态链接库的依赖关系本身很容易出问题，下图是我的 OCR 程序依赖关系，有点复杂啊：

动态链接

本文仅是 CGO 的入门笔记，想进一步了解的话，推荐阅读「CGO 编程」，收摊儿。

• runtime/pprof：采集工具型应用运行数据进行分析
• net/http/pprof：采集服务型应用运行时数据进行分析

命令行工具「go test」就包含了 runtime/pprof，相关参数请参考「go help testflag」：

shell> go test -cpuprofile cpu.out -memprofile mem.out -bench .

不过和 runtime/pprof 相比，更常用的是 net/http/pprof，接下来我们主要通过它来解决一些常见问题，想要激活 net/http/pprof 的话很简单，只要导入对应的包并启动服务即可：

import _ "net/http/pprof"

func main() {
	_ = http.ListenAndServe("localhost:6060", nil)
}

需要注意的是，千万别让外网访问到 pprof，否则可能会导致出现安全问题。有兴趣的读者可以尝试通过 google 搜索「intitle:/debug/pprof/ inurl:/debug/pprof/」看看反面例子。

Profile

pprof 预置了很多种不同类型的 profile，我们可以按照自己的需要选择：

• allocs：A sampling of all past memory allocations
• block：Stack traces that led to blocking on synchronization primitives
• goroutine：Stack traces of all current goroutines
• heap：A sampling of memory allocations of live objects
• mutex：Stack traces of holders of contended mutexes
• profile：CPU profile
• threadcreate：Stack traces that led to the creation of new OS threads

其中最常用的是 profile 和 heap，分别用来诊断 CPU 和内存问题。

CPU Profiling

演示代码模拟了 CPU 密集型任务（onCPU）和耗时的网络请求（offCPU）：

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
	"runtime"
	"time"

	"github.com/felixge/fgprof"
)

const cpuTime = 1000 * time.Millisecond

func main() {
	runtime.SetBlockProfileRate(1)
	runtime.SetMutexProfileFraction(1)

	go func() {
		http.Handle("/debug/fgprof", fgprof.Handler())
		log.Println(http.ListenAndServe(":6060", nil))
	}()

	for {
		cpuIntensiveTask()
		slowNetworkRequest()
	}
}

func cpuIntensiveTask() {
	start := time.Now()

	for time.Since(start) <= cpuTime {
		for i := 0; i < 1000; i++ {
			_ = i
		}
	}
}

func slowNetworkRequest() {
	resp, err := http.Get("http://httpbin.org/delay/1")

	if err != nil {
		log.Fatal(err)
	}

	defer resp.Body.Close()
}

通过 go tool pprof 查看 /debug/pprof/profile：

go tool pprof -http :8080 http://localhost:6060/debug/pprof/profile

结果发现 profile 只能检测到 onCPU（也就是 cpuIntensiveTask）部分，却不能检测到 offCPU （也就是 slowNetworkRequest）部分：

profile

为了检测 offCPU 部分，我们引入 fgprof，通过 go tool pprof 查看 /debug/fgprof：

go tool pprof -http :8080 http://localhost:6060/debug/fgprof

结果发现 fgprof 不仅能检测到 onCPU（也就是 cpuIntensiveTask）部分，还能检测到 offCPU （也就是 slowNetworkRequest）部分：

fgprof

实际应用中，最好对你的瓶颈是 onCPU 还是 offCPU 有一个大体的认识，进而选择合适的工具，如果不确定就直接用 fgprof，不过需要注意的是 fgprof 对性能的影响较大。

Memory Profiling

演示代码模拟了一段有内存泄漏问题的程序：

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
	"time"
)

func main() {
	go func() {
		log.Println(http.ListenAndServe(":6060", nil))
	}()

	for {
		leak()
	}
}

func leak() {
	s := make([]string, 10)

	for i := 0; i < 10000000; i++ {
		s = append(s, "leak")

		if (i % 10000) == 0 {
			time.Sleep(1 * time.Second)
		}

		_ = s
	}
}

通过 go tool pprof 查看 /debug/pprof/heap（这次不用 web，用命令行）：

heap

通过 top 命令可以很直观的看出哪里可能出现了内存泄漏问题。不过这里有一个需要说明的问题是内存占用大的地方本身可能是正常的，与内存的绝对值大小相比，我们更应该关注的是不同时间点内存相对变化大小，这里可以使用参数 base 或者 diff_base：

heap with base

需要说明的是，内存采样大小依据的是 runtime.MemProfileRate，缺省值是 512KB，也就是说每分配 512KB 内存，采样一次。有时候，我们查询 heap 的结果为空，多半就是因为这个配置太大的缘故，可以通过类似 GODEBUG=”memprofilerate=1″ 来调整大小。

本文篇幅有限，无法列举更多的例子，有兴趣的读者推荐参考「golang pprof 实战」。

INSTALLATION

服务端 nats-server，客户端 nats，监控工具 nats-top，性能测试工具 nats-bench：

shell> go get github.com/nats-io/nats-server/v2

shell> git clone https://github.com/nats-io/natscli.git
shell> cd natscli/nats
shell> go get .

shell> go get github.com/nats-io/nats-top

shell> git clone https://github.com/nats-io/nats.go.git
shell> cd nats.go/examples/nats-bench
shell> go get .

需要说明的是，关于 stream 有新旧两种架构的服务端实现，其中旧的 NATS Streaming Server 架构已经过时，如果你是初学者，直接使用新的 NATS JetStream 架构即可。

BENCH

开多个命令行窗口，分别启动 nats-server，nats-top，nats-bench：

shell> nats-server -js -m 8222
shell> nats-top
shell> nats-bench -n 100000000 -np 10 -ms 1 a

nats-top

如上所示，高达一千万的 MPS，我就问你 OK 不 OK！Beautiful 不 Beautiful！

MODE

PUBLISH SUBSCRIBE：

NATS 实现了一对多发布订阅消息模型。当 publisher 往 subject 上发布一条消息后，此 subject 上所有 subscriber 都能收到 此消息，属于一种广播。

Publish Subscribe

shell> nats sub source.subject
Subscribing on source.subject
[#1] Received on "source.subject"
ZNQz8dCWc5
[#2] Received on "source.subject"
d1EggZJYVT

shell> nats sub source.subject
Subscribing on source.subject
[#1] Received on "source.subject"
ZNQz8dCWc5
[#2] Received on "source.subject"
d1EggZJYVT

shell> nats pub source.subject "{{Random 10 10}}" --count 2
Published 10 bytes to "source.subject"
Published 10 bytes to "source.subject"

QUEUE GROUPS：

如果我们把 subscriber 分组，那么当 publisher 往 subject 上发布一条消息后，同一组里只有一个 subscriber 会收到此消息，从而实现了负载均衡。

Queue Groups

shell> nats sub source.subject --queue foo
Subscribing on source.subject
[#1] Received on "source.subject"
LFuJZBjnxV

shell> nats sub source.subject --queue foo
Subscribing on source.subject
[#1] Received on "source.subject"
76kAIoUYCI

shell> nats pub source.subject "{{Random 10 10}}" --count 2
Published 10 bytes to "source.subject"
Published 10 bytes to "source.subject"

REQUEST REPLY：

一般来说，消息系统是以异步的形式工作，也就是说，publisher 往 subject 上发布一条消息后，并不在意 subscriber 的 reply 是什么。如果 publisher 在意 subscriber 的 reply 是什么的话，那么消息系统就应该以同步的形式工作，在具体实现中，是通过两次发布订阅来完成的：当 publisher 发布消息后，它会订阅一个特定的 subject，当 subscriber 处理完消息后，它会把 reply 发布到这个特定的 subject。当然，整个过程对使用者是透明的。

Request Reply

shell> nats reply 'weather.>' --command "curl -s wttr.in/{{1}}?format=1"
Listening on "weather.>" in group "NATS-RPLY-22"
[#0] Received on subject "weather.beijing":

shell> nats request weather.beijing ''
Sending request on "weather.beijing"
Received on "_INBOX.7mc3ox00ma7WYWyNjuBSsw.NBtCmYbp"
☀ +30°C

通过 weather 例子，我们可以发现 request reply 模式已经有了 RPC 的味道。

MICROSERVICE

正是因为 NATS 具备了 RPC 的能力，所以在微服务中采用 NATS 后，系统会更清晰。

传统微服务架构

采用 NATS 的微服务架构

说明：以上图片来自于「The Zen of High Performance Messaging with NATS」。

MONITOR

说到监控，除了前面提到的 nats-top 之外，还有诸如 natsboard 之类的 UI 可供选择：

natsboard

现实中，大家都知道，徐志摩和林徽因的结局，终究还是错付了，不过我对 NATS 的爱不会变，她是我的不二之选，至少在更好的消息系统出现前如此。

假设我们正在开发一个在线购物项目，其主要功能包括商城、推荐、评论、用户等，它是一个典型的单体架构：不同团队的技术人员工作在同一个版本库上，系统功能按模块划分，不同模块之间通过本地函数调用，通常操作同一个数据库。

微服务

在项目早期，单体架构往往能很好的适应快速迭代的需求，不过随着项目的发展，项目本身会变得复杂，其弊端不可避免的出现，比如下面列举的一些情况：

• 因为大家都工作在同一个版本库上，所以可能会遇到：商城模块完成了新功能，准备上线，结果推荐模块刚提交了还没来得及测试的代码，于是不得不推迟上线。
• 不同的需求采用不同的技术栈：负责评论模块的同事想用 PHP + MySQL 来构建系统，负责用户模块的同事却想用 Golang + PostgreSQL 来构建系统。
• 有的模块需要高性能 CPU，有的模块需要大内存，因为不同的模块是耦合在一起的，所以我们的服务器不得不同时具备高性能 CPU，大内存，从而增加了成本。

如何解决此类问题？康威定律给出了很好的建议：「设计系统的架构受制于产生这些设计的组织的沟通结构」，通俗点说就是：「有什么样的组织架构就会设计出什么样的系统架构」。在本例中，因为不同的团队负责不同的模块，所以很自然的可以通过模块来把系统切分成商城、推荐、评论、用户等几个独立的服务：每个服务有自己独立的版本库和数据库，服务之间通过 RPC 来通信。不同的服务拥有自己的版本库，可以使用适合自己的技术栈和硬件，独立开发独立部署。

一个需要注意的问题是如何确定服务粒度的大小，虽然按照康威定律的描述只要按照组织架构的大小来确定服务的大小即可，但是如何规划一个合理的团队规模呢？实际上并没有一个精确的答案，我们需要按照客观情况来确定一个适合自己的大小适中的服务粒度，过小的粒度会导致服务之间强耦合，过大的粒度则背离了微服务的初衷，Uber 甚至还针对服务粒度大小问题发明了一个宏服务的概念，有兴趣的读者不妨看看。

微服务

当我们把单体架构切分成独立的服务之后，原本模块间本地的函数调用变成了服务间远程的 RPC 调用，我们不得不处理服务治理之类的问题，随着微服务数量的增加，问题会变得越来越棘手，好在随着云原生的发展，特别是 K8S 和 istio 等技术的成熟，我们的架构可以演化到 service mesh 阶段，通过 sidecar 透明实现服务治理。

微服务

如果仅仅是把原本模块间本地的函数调用变成了服务间远程的 RPC 调用的话，那么我们的微服务很可能会沦为「分布式单体」。问题的症结在于过度使用 RPC，导致服务与服务之间强耦合，解决方法是引入 Event，通过 Event 实现服务与服务的解耦。

看看如何实现下面的业务逻辑：当一个用户注册后，要在商城里给用户一张优惠券。

• 使用 RPC（强调做什么）：当用户模块创建了一个新用户的时候，通过 RPC 调用商城模块给用户一张优惠券，过程中用户模块和商城模块是强耦合的。
• 使用 Event（强调发生了什么）：当用户模块创建了一个新用户的时候，它发出一个 UserCreated 事件，商城模块观察到对应的事件后，给用户一张优惠券，过程中用户模块和商城模块是弱耦合的。

实际情况中应该按需求来选择使用 RPC 或者 Event：如果是业务逻辑的实现部分，倾向于选择使用 RPC；如果是业务逻辑完成之后的后续通知部分，强烈建议选择使用 Event。

微服务

服务部署好了之后，接下来我们还需要考虑如何暴露服务以供前端调用，比如用户浏览某个商品的详情页，内容包括商品数据、以及对应的推荐数据和评论数据，如果直接操作服务的话，那么需要多次查询商品服务、推荐服务、评论服务，并不可取，此时可以加入 API Gateway 充当代理，前端只要请求 API Gateway 一次就可以拿到数据。

微服务

有了 API Gateway 之后，它可以帮我们完成聚合之类的逻辑。不过有一个问题是前端可能有多种不同的类型，比如 PC 前端，Mobile 前端，它们的业务逻辑不可避免的会有各种各样的差异，如果在 API Gateway 中处理这些差异的话，那么会出现坏味道，为了解决此类问题，我们引入 BFF（Backend For Frontend），每一种前端都有属于自己的 BFF，用来处理专属于自己的业务逻辑，至于 API Gateway，则只处理鉴权，日志等公共业务逻辑。

微服务

微服务是个极其复杂的概念，本文仅就一些表面问题浅谈一二，其他诸如 SAGA 之类的复杂问题，由于篇幅所限，并未涉猎，大家如果有兴趣的话请自行查阅。

最后把 Martin Fowler 在 PoEAA 中提出的分布式对象第一定律送给大家：不要分布你的对象！套用这个说法的话，不难引申出微服务第一定律：不要使用微服务！虽然话里有一些戏虐的成份，但是它至少告诫我们在面对微服务的时候要怀揣着一颗敬畏的心。