前言

记得我刚接触Go这门语言的时候，用到它的网络请求库的时候还不太理解，为什么函数的返回值不直接是请求的响应内容，而是一个http Response，并且，Body字段也并不是实际的响应内容，而是一个io.ReadCloser接口。想要拿到响应内容，需要手动做一次读取操作。刚开始的时候，我觉得这样十分的不便，不像诸如PHP语言的 curl_exec 函数那样来的直接。

Go语言读取一个网络请求的结果简化版大致需要这样：

//1.执行一个请求
response, err := http.Get(...)

//2.使用io包读取body
io.ReadAll(response.Body)

//3.关闭响应
response.Body.Close()

当时我不太明白为什么Go语言要这样设计，直到后来在一次业务场景中，在对性能化时才初见端倪，并不禁感叹这样的设计真是精妙！

这样的设计并不只有Go语言一家。

实际业务场景

在我为StarDots实现图像处理的过程中，我走了与以往相同的常规路线：将原图像获取到本地内存，读取元数据及必要信息，加工处理，然后响应给下游服务。

这一条线路看起来是再正常不过的，然而在实际的生产环境下，我发现服务器内存占用居高不下，且与请求量成正相关。这样一来，显然是一个差劲的设计，并且费用成本高昂。

于是，我开始反思设计的不合理之处。就在我review代码的时候，看到了io.ReadAll(response.Body)这句代码。这让我重新回想起了初遇Go语言的疑惑。接着，我开始思考，read到底操作了一些什么，它的行为是怎样的。

从实战回到理论

从现有代码来看，我是将响应全部读出，也就是使用io.ReadAll，这样一来，响应体有多大，那么就将占用多大的内存空间，并且，还有OOM的风险。
在即需要获取到响应内容，又要保证内存可控这样的既要又要的场景下，能不能保证两者都能满足呢。顺理成章地，我想到了，能不能“一点一点地读取响应内容”。

回到文章最前面提到的代码：

//1.执行一个请求
response, err := http.Get(...)

//2.使用io包读取body
io.ReadAll(response.Body)

//3.关闭响应
response.Body.Close()

这里不再进行io.ReadAll()操作了。反观http Response的定义设计：

type Response struct {
    Status           string
    StatusCode       int
    Proto            string
    ProtoMajor       int
    ProtoMinor       int
    Header           Header
    Body             io.ReadCloser
    ContentLength    int64
    TransferEncoding []string
    Close            bool
    Uncompressed     bool
    Trailer          Header
    Request          *Request
    TLS              *tls.ConnectionState
}

我们已经能从此结构中获取到很大一部分有价值的信息，例如响应头。此时，我想到了Go语言的io包提供的一个函数Copy，这是它的源码定义：

func Copy(dst Writer, src Reader) (written int64, err error)

参数见名知意，可以将源拷贝到目标。这个操作，让我想起了这张图：

小鼹鼠修理工整准备将两根水管进行对接。

阅读了io.Copy源码之后，发现它调用了一个名叫copyBuffer的方法，下面是copyBuffer的具体实现：

func copyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) {
	// If the reader has a WriteTo method, use it to do the copy.
	// Avoids an allocation and a copy.
	if wt, ok := src.(WriterTo); ok {
		return wt.WriteTo(dst)
	}
	// Similarly, if the writer has a ReadFrom method, use it to do the copy.
	if rf, ok := dst.(ReaderFrom); ok {
		return rf.ReadFrom(src)
	}
	if buf == nil {
		size := 32 * 1024
		if l, ok := src.(*LimitedReader); ok && int64(size) > l.N {
			if l.N < 1 {
				size = 1
			} else {
				size = int(l.N)
			}
		}
		buf = make([]byte, size)
	}
	for {
		nr, er := src.Read(buf)
		if nr > 0 {
			nw, ew := dst.Write(buf[0:nr])
			if nw < 0 || nr < nw {
				nw = 0
				if ew == nil {
					ew = errInvalidWrite
				}
			}
			written += int64(nw)
			if ew != nil {
				err = ew
				break
			}
			if nr != nw {
				err = ErrShortWrite
				break
			}
		}
		if er != nil {
			if er != EOF {
				err = er
			}
			break
		}
	}
	return written, err
}

其中，指定buf的大小，就能实现我想要的“一点一点地读”的需求。而默认的buf大小是32*1024，也是适用于我的需求，那么在此场景下使用io.Copy能够有效抑制内存疯涨，让转发操作变得简单清晰。

优化效果

在优化前，当有一定量的图像请求时，观察服务器监控就能发现内存上涨很快且十分不稳定。优化之后，内存占用变得平稳可控。

优化后其中一个pod内容占用情况：

优化后周期性的内存使用情况：

实际业务跑了一段时间，观察到这样的表现十分稳定。