分类 技术志 下的文章

通过实例理解Go标准库http包是如何处理keep-alive连接的

img{512x368}

HTTP是如今互联网的基础协议,承载了互联网上的绝大部分应用层流量,并且从目前趋势来看,在未来10年,http仍然会是互联网应用的主要协议。Go语言自带“电池”,基于Go标准库我们可以轻松建立起一个http server处理客户端http请求,或创建一个http client向服务端发送http请求。

最初早期的http 1.0协议只支持短连接,即客户端每发送一个请求,就要和服务器端建立一个新TCP连接,请求处理完毕后,该连接将被拆除。显然每次tcp连接握手和拆除都将带来较大损耗,为了能充分利用已建立的连接,后来的http 1.0更新版和http 1.1支持在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭链接,下一次还要复用这个连接以继续传输后续请求和响应。后HTTP协议规范明确规定了HTTP/1.0版本如果想要保持长连接,需要在请求头中加上Connection: keep-alive,而HTTP/1.1版本将支持keep-alive长连接作为默认选项,有没有这个请求头都可以。

本文我们就来一起看看Go标准库中net/http包的http.Server和http.Client对keep-alive长连接的处理以及如何在Server和Client侧关闭keep-alive机制。

1. http包默认启用keep-alive

按照HTTP/1.1的规范,Go http包的http server和client的实现默认将所有连接视为长连接,无论这些连接上的初始请求是否带有Connection: keep-alive

下面分别是使用go http包的默认机制实现的一个http client和一个http server:

默认开启keep-alive的http client实现:

//github.com/bigwhite/experiments/http-keep-alive/client-keepalive-on/client.go
package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
)

func main() {
    c := &http.Client{}
    req, err := http.NewRequest("Get", "http://localhost:8080", nil)
    if err != nil {
        panic(err)
    }
    fmt.Printf("%#v\n", *req)

    for i := 0; i < 5; i++ {
        resp, err := c.Do(req)
        if err != nil {
            fmt.Println("http get error:", err)
            return
        }
        defer resp.Body.Close()

        b, err := ioutil.ReadAll(resp.Body)
        if err != nil {
            fmt.Println("read body error:", err)
            return
        }
        fmt.Println("response body:", string(b))
    }
}

默认开启keep-alive的http server实现:

//github.com/bigwhite/experiments/http-keep-alive/server-keepalive-on/server.go
package main

import (
    "fmt"
    "net/http"
)

func Index(w http.ResponseWriter, r *http.Request) {
    fmt.Println("receive a request from:", r.RemoteAddr, r.Header)
    w.Write([]byte("ok"))
}

func main() {
    var s = http.Server{
        Addr:    ":8080",
        Handler: http.HandlerFunc(Index),
    }
    s.ListenAndServe()
}

现在我们启动上面的http server:

// server-keepalive-on目录下
$go run server.go

我们使用上面的client向该server发起5次http请求:

// client-keepalive-on目录下
$go run client.go
http.Request{Method:"Get", URL:(*url.URL)(0xc00016a000), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{}, Body:io.ReadCloser(nil), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"localhost:8080", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"", RequestURI:"", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.emptyCtx)(0xc00012c008)}
response body: ok
response body: ok
response body: ok
response body: ok
response body: ok

这期间server端输出的日志如下:

receive a request from: [::1]:55238 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
receive a request from: [::1]:55238 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
receive a request from: [::1]:55238 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
receive a request from: [::1]:55238 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
receive a request from: [::1]:55238 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

我们简单分析一下两端的输出结果:

  • 从server端打印的请求的头部字段来看,客户端发来的请求header中并没有显式包含Connection: keep-alive,而仅有Accept-Encoding和User-Agent两个header字段;
  • server端处理的5个请求均来自同一个连接“[::1]:55238”,Server端默认保持了该连接,而不是在处理完一个请求后将连接关闭,说明两端均复用了第一个请求创建的http连接。

即便我们的client端每间隔5秒发送一次请求,server端默认也不会关闭连接(我们将fmt包缓冲log包,输出带有时间戳的日志):

// client-keepalive-on目录下
$go run client-with-delay.go
http.Request{Method:"Get", URL:(*url.URL)(0xc00016a000), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{}, Body:io.ReadCloser(nil), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"localhost:8080", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"", RequestURI:"", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.emptyCtx)(0xc00012c008)}
2021/01/03 12:25:21 response body: ok

2021/01/03 12:25:26 response body: ok
2021/01/03 12:25:31 response body: ok
2021/01/03 12:25:36 response body: ok
2021/01/03 12:25:41 response body: ok

// server-keepalive-on目录下
$go run server.go
2021/01/03 12:25:21 receive a request from: [::1]:58419 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 12:25:26 receive a request from: [::1]:58419 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 12:25:31 receive a request from: [::1]:58419 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 12:25:36 receive a request from: [::1]:58419 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 12:25:41 receive a request from: [::1]:58419 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

2. http client端基于非keep-alive连接发送请求

有时候http client在一条连接上的数据请求密度并不高,因此client端并不想长期保持这条连接(占用端口资源),那么client端如何协调Server端在处理完请求返回应答后就关闭这条连接呢?我们看看在Go中如何实现这一场景需求:

//github.com/bigwhite/experiments/http-keep-alive/client-keepalive-off/client.go
... ...
func main() {
    tr := &http.Transport{
        DisableKeepAlives: true,
    }
    c := &http.Client{
        Transport: tr,
    }
    req, err := http.NewRequest("Get", "http://localhost:8080", nil)
    if err != nil {
        panic(err)
    }

    for i := 0; i < 5; i++ {
        resp, err := c.Do(req)
        if err != nil {
            fmt.Println("http get error:", err)
            return
        }
        defer resp.Body.Close()

        b, err := ioutil.ReadAll(resp.Body)
        if err != nil {
            fmt.Println("read body error:", err)
            return
        }
        log.Println("response body:", string(b))
        time.Sleep(5 * time.Second)
    }

}

http.Client底层的数据连接建立和维护是由http.Transport实现的,http.Transport结构有一个DisableKeepAlives字段,其默认值为false,即启动keep-alive。这里我们将其置为true,即关闭keep-alive,然后将该Transport实例作为初值,赋值给http Client实例的Transport字段。

接下来,我们使用这个client向上面那个http server发送五个请求,请求间间隔5秒(模拟连接空闲的状态),我们得到如下结果(从server端打印信息观察):

// 在client-keepalive-off下面
$go run client.go
2021/01/03 12:42:38 response body: ok
2021/01/03 12:42:43 response body: ok
2021/01/03 12:42:48 response body: ok
2021/01/03 12:42:53 response body: ok
2021/01/03 12:42:58 response body: ok

// 在server-keepalive-on下面

$go run server.go
2021/01/03 12:42:38 receive a request from: [::1]:62287 map[Accept-Encoding:[gzip] Connection:[close] User-Agent:[Go-http-client/1.1]]

2021/01/03 12:42:43 receive a request from: [::1]:62301 map[Accept-Encoding:[gzip] Connection:[close] User-Agent:[Go-http-client/1.1]]

2021/01/03 12:42:48 receive a request from: [::1]:62314 map[Accept-Encoding:[gzip] Connection:[close] User-Agent:[Go-http-client/1.1]]

2021/01/03 12:42:53 receive a request from: [::1]:62328 map[Accept-Encoding:[gzip] Connection:[close] User-Agent:[Go-http-client/1.1]]

2021/01/03 12:42:58 receive a request from: [::1]:62342 map[Accept-Encoding:[gzip] Connection:[close] User-Agent:[Go-http-client/1.1]]

从Server的输出结果来看,来自客户端的请求中增加了Connection:[close]的头字段,当收到这样的请求后,Server端便不再保持这一连接了。我们也看到上面日志中,每个请求都是通过不同的客户端端口发送出来的,显然这是五条不同的连接。

3. 建立一个不支持keep-alive连接的http server

假设我们有这样的一个需求,server端完全不支持keep-alive的连接,无论client端发送的请求header中是否显式带有Connection: keep-alive,server端都会在返回应答后关闭连接。那么在Go中,我们如何来实现这一需求呢?我们来看下面代码:

//github.com/bigwhite/experiments/http-keep-alive/server-keepalive-off/server.go

package main

import (
    "log"
    "net/http"
)

func Index(w http.ResponseWriter, r *http.Request) {
    log.Println("receive a request from:", r.RemoteAddr, r.Header)
    w.Write([]byte("ok"))
}

func main() {
    var s = http.Server{
        Addr:    ":8080",
        Handler: http.HandlerFunc(Index),
    }
    s.SetKeepAlivesEnabled(false)
    s.ListenAndServe()
}

我们看到在ListenAndServe前,我们调用了http.Server的SetKeepAlivesEnabled方法,并传入false参数,这样我们就在全局层面关闭了该Server对keep-alive连接的支持,我们用前面client-keepalive-on下面的client向该Server发送五个请求:

// 在client-keepalive-on下面
$go run client.go
http.Request{Method:"Get", URL:(*url.URL)(0xc000174000), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{}, Body:io.ReadCloser(nil), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"localhost:8080", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"", RequestURI:"", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.emptyCtx)(0xc00013a008)}
2021/01/03 13:30:08 response body: ok
2021/01/03 13:30:08 response body: ok
2021/01/03 13:30:08 response body: ok
2021/01/03 13:30:08 response body: ok
2021/01/03 13:30:08 response body: ok

// 在server-keepalive-off下面
$go run server.go
2021/01/03 13:30:08 receive a request from: [::1]:53005 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 13:30:08 receive a request from: [::1]:53006 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 13:30:08 receive a request from: [::1]:53007 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 13:30:08 receive a request from: [::1]:53008 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 13:30:08 receive a request from: [::1]:53009 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

我们看到该Server在处理完每个请求后就关闭了传输该请求的连接,这导致client测不得不为每个请求建立一个新连接(从server输出的客户端地址和端口看出)。

4. 支持长连接闲置超时关闭的http server

显然上面的server处理方式“太过霸道”,对于想要复用连接,提高请求和应答传输效率的client而言,上面的“一刀切”机制并不合理。那么是否有一种机制可以让http server即可以对高密度传输数据的连接保持keep-alive,又可以及时清理掉那些长时间没有数据传输的idle连接,释放占用的系统资源呢?我们来看下面这个go实现的server:

//github.com/bigwhite/experiments/http-keep-alive/server-keepalive-with-idletimeout/server.go

package main

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

func Index(w http.ResponseWriter, r *http.Request) {
    log.Println("receive a request from:", r.RemoteAddr, r.Header)
    w.Write([]byte("ok"))
}

func main() {
    var s = http.Server{
        Addr:        ":8080",
        Handler:     http.HandlerFunc(Index),
        IdleTimeout: 5 * time.Second,
    }
    s.ListenAndServe()
}

从代码中我们看到,我们仅在创建http.Server实例时显式为其字段IdleTimeout做了一次显式赋值,设置idle连接的超时时间为5s。下面是Go标准库中关于http.Server的字段IdleTimeout的注释:

// $GOROOT/src/net/server.go

// IdleTimeout是当启用keep-alive时等待下一个请求的最大时间。
// 如果IdleTimeout为零,则使用ReadTimeout的值。如果两者都是
// 零,则没有超时。
IdleTimeout time.Duration

我们来看看效果如何,是否是我们期望那样的。为了测试效果,我们改造了client端,放在client-keepalive-on-with-idle下面:

//github.com/bigwhite/experiments/http-keep-alive/client-keepalive-on-with-idle/client.go
... ...
func main() {
    c := &http.Client{}
    req, err := http.NewRequest("Get", "http://localhost:8080", nil)
    if err != nil {
        panic(err)
    }

    for i := 0; i < 5; i++ {
        log.Printf("round %d begin:\n", i+1)
        for j := 0; j < i+1; j++ {
            resp, err := c.Do(req)
            if err != nil {
                fmt.Println("http get error:", err)
                return
            }
            defer resp.Body.Close()

            b, err := ioutil.ReadAll(resp.Body)
            if err != nil {
                fmt.Println("read body error:", err)
                return
            }
            log.Println("response body:", string(b))
        }
        log.Printf("round %d end\n", i+1)
        time.Sleep(7 * time.Second)
    }
}

client端请求分为5轮,轮与轮之间间隔7秒,下面是通信过程与结果:

// 在client-keepalive-on-with-idle下
$go run client.go
2021/01/03 14:17:05 round 1 begin:
2021/01/03 14:17:05 response body: ok
2021/01/03 14:17:05 round 1 end
2021/01/03 14:17:12 round 2 begin:
2021/01/03 14:17:12 response body: ok
2021/01/03 14:17:12 response body: ok
2021/01/03 14:17:12 round 2 end
2021/01/03 14:17:19 round 3 begin:
2021/01/03 14:17:19 response body: ok
2021/01/03 14:17:19 response body: ok
2021/01/03 14:17:19 response body: ok
2021/01/03 14:17:19 round 3 end
2021/01/03 14:17:26 round 4 begin:
2021/01/03 14:17:26 response body: ok
2021/01/03 14:17:26 response body: ok
2021/01/03 14:17:26 response body: ok
2021/01/03 14:17:26 response body: ok
2021/01/03 14:17:26 round 4 end
2021/01/03 14:17:33 round 5 begin:
2021/01/03 14:17:33 response body: ok
2021/01/03 14:17:33 response body: ok
2021/01/03 14:17:33 response body: ok
2021/01/03 14:17:33 response body: ok
2021/01/03 14:17:33 response body: ok
2021/01/03 14:17:33 round 5 end

// 在server-keepalive-with-idletimeout下
$go run server.go

2021/01/03 14:17:05 receive a request from: [::1]:64071 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

2021/01/03 14:17:12 receive a request from: [::1]:64145 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:12 receive a request from: [::1]:64145 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

2021/01/03 14:17:19 receive a request from: [::1]:64189 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:19 receive a request from: [::1]:64189 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:19 receive a request from: [::1]:64189 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

2021/01/03 14:17:26 receive a request from: [::1]:64250 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:26 receive a request from: [::1]:64250 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:26 receive a request from: [::1]:64250 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:26 receive a request from: [::1]:64250 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

2021/01/03 14:17:33 receive a request from: [::1]:64304 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:33 receive a request from: [::1]:64304 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:33 receive a request from: [::1]:64304 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:33 receive a request from: [::1]:64304 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:17:33 receive a request from: [::1]:64304 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

我们看到:
- 在每轮内,client端的所有请求都是复用已建立的连接;
- 但每轮之间,由于Sleep了7秒,超出了server端idletimeout的时长,上一轮的连接被拆除,新一轮只能重建连接。

我们期望的效果实现了!

5. 一个http client可管理到多个server的连接

Go标准库的http.Client与一个server可不是一对一的关系,它可以实现一对多的http通信,也就是说一个http client可管理到多个server的连接,并优先复用到同一server的连接(keep-alive),而不是建立新连接,就像我们上面看到的那样。我们来创建一个向多个server发送请求的client:

//github.com/bigwhite/experiments/http-keep-alive/client-keepalive-on-to-multiple-servers/client.go
... ...
func main() {
    c := &http.Client{}
    req1, err := http.NewRequest("Get", "http://localhost:8080", nil)
    if err != nil {
        panic(err)
    }
    req2, err := http.NewRequest("Get", "http://localhost:8081", nil)
    if err != nil {
        panic(err)
    }

    for i := 0; i < 5; i++ {
        resp1, err := c.Do(req1)
        if err != nil {
            fmt.Println("http get error:", err)
            return
        }
        defer resp1.Body.Close()

        b1, err := ioutil.ReadAll(resp1.Body)
        if err != nil {
            fmt.Println("read body error:", err)
            return
        }
        log.Println("response1 body:", string(b1))

        resp2, err := c.Do(req2)
        if err != nil {
            fmt.Println("http get error:", err)
            return
        }
        defer resp2.Body.Close()

        b2, err := ioutil.ReadAll(resp2.Body)
        if err != nil {
            fmt.Println("read body error:", err)
            return
        }
        log.Println("response2 body:", string(b2))

        time.Sleep(5 * time.Second)
    }

}

我们建立两个默认的http server,分别监听8080和8081,运行上面client:

$go run client.go
2021/01/03 14:52:20 response1 body: ok
2021/01/03 14:52:20 response2 body: ok
2021/01/03 14:52:25 response1 body: ok
2021/01/03 14:52:25 response2 body: ok
2021/01/03 14:52:30 response1 body: ok
2021/01/03 14:52:30 response2 body: ok
2021/01/03 14:52:35 response1 body: ok
2021/01/03 14:52:35 response2 body: ok
2021/01/03 14:52:40 response1 body: ok
2021/01/03 14:52:40 response2 body: ok

server端的输出结果如下:

// server1(8080):
2021/01/03 14:52:20 receive a request from: [::1]:63871 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:25 receive a request from: [::1]:63871 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:30 receive a request from: [::1]:63871 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:35 receive a request from: [::1]:63871 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:40 receive a request from: [::1]:63871 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

// server2(8081):
2021/01/03 14:52:20 receive a request from: [::1]:63872 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:25 receive a request from: [::1]:63872 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:30 receive a request from: [::1]:63872 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:35 receive a request from: [::1]:63872 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]
2021/01/03 14:52:40 receive a request from: [::1]:63872 map[Accept-Encoding:[gzip] User-Agent:[Go-http-client/1.1]]

我们看到client同时支持与多个server进行通信,并针对每个server可以使用keep-alive的连接进行高效率通信。

本文涉及源代码可以在这里(https://github.com/bigwhite/experiments/tree/master/http-keep-alive)下载。


“Gopher部落”知识星球开球了!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!星球首开,福利自然是少不了的!2020年年底之前,8.8折(很吉利吧^_^)加入星球,下方图片扫起来吧!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go语言很无聊…其实它妙不可言![译]

img{512x368}

无聊是一种很奇妙的状态,它可以稀释掉人类的一切情感。- 《古董局中局》马伯庸

GopherCon 2020技术大会上(线上虚拟大会),Jon Bodner为全球gopher们做了主题为“Go Is Boring”的精彩演讲(关注公众号iamtonybai,发送gophercon2020即可得到GopherCon 2020技术大会幻灯片资料)。

img{512x368}

其实早在2020年6月,Jon Bodner就发表过类似主题的文章《Go is Boring…And That’s Fantastic!》。其副标题为:深入探究世界为何依赖简单,可靠且易于理解的技术。本文将在这篇文章的基础上,结合演讲内容做综合翻译与整理,为大家呈现Jon Bodner这个资深程序员对Go语言哲学的理解。

1. 大多编程语言都在堆砌新功能特性

我从事专业软件工程师已有将近23年的时间,而我编写程序的时间也已有38年了。在这个过程中,我使用过很多编程语言。我喜欢编程语言,并且了解它们的新功能特性以及与之前的语言相比所进行的改动。

img{512x368}

如果看一下过去十年的编程语言,您会发现很多变化。C++,Java,Python和JavaScript增加了许多新功能,而一些新编程语言,诸如Rust和Swift等自诞生以来也发生了显著的变化。这一切都非常令人兴奋,但同时也会让你产生一种感觉:有时候,您永远无法跟上这些语言的所有想法。

img{512x368}

图:C到C++,再到更复杂的C++

img{512x368}

图:Java到Java2,再到更复杂的Java3?

JavaScript、Python、Rust、Swift、… …

2. Go没有这么多功能特性

接下来轮到Go了!考量Go的最好方法是思考它没有的功能特性:

img{512x368}

  • Go没有虚拟机或基于LLVM的编译器;
  • Go没有异常(exception);
  • Go没有用户定义的实现继承;
  • Go不支持重载函数、方法或运算符;
  • Go没有不变量;
  • Go没有枚举;
  • Go没有泛型
  • 自2012年Go 1.0发布以来,Go并未添加任何主要功能特性。

Go令人兴奋的一件事是通过goroutine,channel和select原生支持并发。但是,它基于CSP的思想,即Communicating Sequential Processes, 要知道,这可是一个早在1978年就被提出的思想。

这听起来不像是21世纪的编程语言,对吗?

然而,根据Stack Overflow的说法,Go是第三名程序员最想要学习的语言,而且(也许并非巧合)也是第三名最高薪的语言。硅谷的每个创业公司都在使用Go来构建其基础架构。Go语言编写了Docker,Kubernetes,etcd,Terraform,Vault,Consul,Traefik和许多其他前沿项目。那么问题来了?为什么每个人都对这种无聊的语言感兴趣呢?

3. 为什么每个人都对这种无聊的语言感兴趣呢?

在回答这个问题之前,让我们先退一步。

img{512x368}

这是希腊Argolis的Arkadiko桥,它是世界上最古老的桥梁,至今已有3000多年的历史。令人惊讶的是,它仍在使用中。

现在,我们为什么要关心一座古老的桥呢?这是因为软件开发有一个普遍的、但软件工程师们却不喜欢过多谈论的真理:

我们真的不擅长编写软件

我指的不仅仅是办公室里的那个人,你的经理在紧要关头派他去减少bug的数量。我指的是每个人–我,你,还有你能想到的所有著名的开发者。

但那些设计和建造桥梁的人,他们很擅长建桥。桥梁能按时、按预算建成,并能持续服务几十、几百、甚至几千年。造桥,如果你仔细想想,还真有点厉害。而桥梁是这样一种常见的现象,它们也是非常无聊的。当一座桥正常工作的时候,没有人惊奇,而当软件正常工作的时候,大家都有点惊奇。

不幸的是,这个世界非常依赖软件。它对软件的依赖甚至可能比对桥梁的依赖更甚。所以,我们必须以比造桥更快的速度更好地编写软件。

4. 这些年我们对编写软件的了解

在过去的60年中,我们在编写程序方面已经学到了一些东西,其中有很多普遍的共识:

img{512x368}

  • 早发现问题比晚发现问题要好。
  • 人们在管理程序的内存方面很糟糕。
  • 代码评审有助于发现bug。
  • 在任何一个超过一个人的项目中,沟通成本占主导地位。

5. 硬件也不能拯救我们

我们可以把这几件我们知道的事情和另一个已经确定下来的事实结合起来:电脑的速度不再快了。至少不像以前那样了。在20世纪80年代和90年代,CPU每1-2年就会快一倍。但现在情况变了。

img{512x368}

当你看单核性能时,2019年最快的酷睿i9的速度不到2011年最快的酷睿i7的两倍。我们没有变得更快,而是给CPU增加了更多的核心。当你看多核性能时,它更好一些,略微快了2倍多。

限制我们的不仅仅是CPU性能。Forrest Smith写了一篇关于RAM和RAM访问模式对性能影响的精彩博文。其要点如下:

  • RAM比CPU要慢得多,而且差距并没有得到改善,尽管CPU的速度并没有变快多少。

img{512x368}

  • RAM可能是随机访问,但如果你真的这样使用,它的速度很慢。在现代英特尔CPU上,如果数据是顺序的,你可以每秒从RAM中读取40千兆字节左右。如果你进行随机读取,每秒不到半GB。

img{512x368}

  • 有很多指针的代码特别慢。引用Forrest的话。“按顺序将指针后面的值相加的速度低于1GB/秒。随机访问,两次错过缓存,运行速度只有0.1 GB/s。指针追逐的速度要慢10到20倍”。

img{512x368}

6. 无聊带来新的惊喜,我们再来看看Go

鉴于我们知道的这些关于如何构建软件的几个宝贵的东西和我们现有的硬件状况,我们再来重新审视一下Go语言。

1) Go和软件

  • 尽早发现问题

Go语言可能缺乏功能特性,但它却有一套很棒的工具。Go的编译器速度很快,这种快速的编译速度被Go团队认为是一个特点。它可以让你快速查看你的代码是否能编译,如果不能,它可以让你看到问题所在。测试被内置在标准库中,以鼓励开发者测试他们的代码并发现问题。基准测试(benchmark)剖析(profiling)和竞态检查(-race)也是开箱即用的。很少有语言能提供这些工具,它们能让你更容易快速地发现问题。

  • 内存管理

众所周知,Go有一个垃圾收集器。你不用担心跟踪内存,这是一件很奇妙的事情。在编译语言中,垃圾回收是很罕见的。Rust的borrow checker是获得高性能和内存管理的一个迷人的方法,但它实际上把开发者变成了垃圾收集器,这可能很难正确使用;如果你犯了错误,忘记将一些引用声明为弱引用,Swift的ARC仍然会泄漏内存。现在,Go的GC的性能不如这些半自动系统,有些情况下,你需要额外的速度,但在大多数情况下,它肯定是足够的。

  • 代码评审

如果代码评审做得好,代码评审就很重要。为了进行有效的代码评审,你需要确保评审人员专注于正确的事情。低质量的代码评审会把时间花在格式化等事情上。Go在这里提供了很大帮助,因为在评审Go代码时没有有关代码格式的争论,因为所有的Go代码都是按照go fmt的标准代码格式进行格式化。

而代码评审是一个双向的过程。如果你想评审的效果好,你需要确保其他人能够理解你的代码。Go程序应该是简单的,使用一些很好理解的结构,这些结构自语言发布以来就没有改变过。因为没有异常(exception),没有面向方面的编程(AOP),没有继承和方法重写(override),也没有重载(overloading),所以很清楚什么代码在调用什么,在哪里返回值。如果你在Go中减少包级变量的使用,那就很容易看到数据到底是如何被修改的。由于Go的变化很小,你可以避免熔岩流反模式,你可以根据代码中使用的语法特性被引入到Go中的时间点来判断它到底有多老。

  • 沟通成本

Go是如何帮助解决这个问题的呢?我们已经讨论过Go的简单性、稳定性和标准格式化如何让你更容易地传达你的代码正在做什么。虽然这只是其中的一部分,但还有其他的东西。Go的隐式接口帮助团队编写解耦的代码。它们由调用代码定义,以准确描述需要什么功能,这就明确了你的代码在做什么。

2) Go和硬件

让Go成为编译语言的决定得到了回报。当CPU每天都在变快时,在虚拟机(译注:这里所谓的虚拟机是指动态语言的解释器或像jvm之类的字节码运行程序)中运行的解释语言似乎是个好主意。如果你的程序不够快,只要再等一年就可以了。但现在这已经行不通了。编译成原生代码比最新的虚拟机技巧少了很多乐趣,但它能带来很大的性能优势。

让我们用The Benchmark Game的微基准来比较Go与一些在虚拟机中运行的语言的性能。首先我们来看看Python和Ruby与Go的比较。任何小于100%的百分比都意味着比Go快,大于100%意味着慢:

img{512x368}

这里有很多红色(意味着比Go慢的测试)。有一个基准测试是Python更快 (奇怪的是,它不仅是Go的两倍,而且在这个测试中比其他所有语言都快),而Ruby则没有一个测试比Go快。除了那一个情况,这两种语言产生的代码都比Go慢了17%到60多倍。

现在让我们再看看Java和JavaScript与Go的比较:

img{512x368}

这两门语言与Go的性能更为接近。JavaScript在一个基准上比Go快,在其他基准上比Go慢,但JavaScript最坏的情况是比Go慢了三倍左右。

Java和Go的性能相当接近。Java在四种情况下比Go快,在两种情况下差不多,在四种情况下比Go慢。Go做的最差的情况是比Java慢三倍左右,Go做的最好的情况是比Java快50%左右。

我们看到的是,唯一能跟上Go的虚拟机是Java的。Hotspot是令人惊异的技术,但你需要一个世界上最好的工程软件,才能与一个优先考虑编译速度而非优化的编译器达到平衡,这说明了一些问题。而且你要为这种惊人的技术付出代价。Java应用程序的内存使用量要比Go应用程序大出很多很多倍。

还有第二个优势。垃圾收集器管理的垃圾都是不使用的指针。与隐藏指针的语言不同,Go给了你控制权。它让你避开指针,并以一种允许快速访问RAM的方式布局你的数据结构。这也让Go可以使用更简单的垃圾收集器,因为Go程序只是简单地制造更少的垃圾。枯燥无味的工作就是少了。

而我们都知道,CPU正在用更多的内核来弥补速度提升的不足。所以,使用一种能够利用这一点的语言是很好的。这就是Go内置并发支持的目的。有了对并发的语言级支持和一个在多个线程中调度goroutine的运行时库,意味着当你有多个CPU核时,这些线程可以被自然地映射到这些核上。

7. 我不想要我没有得到的那些功能特性

我们已经看到,Go专注于我们所知道的使创建软件更容易、更适合现代计算机的内存和CPU架构的功能和工具。但是其他语言有而Go没有的功能特性呢?也许Go的开发者错过了,那些Go没有的特性能帮助开发者写出了更少错误、更容易维护的代码?好吧,研究人员的研究结果告诉我们,事实并非如此。

2017年一篇名为《Github中编程语言与代码质量的大规模研究》的论文,该论文研究了17种语言的729个项目、8000万行代码、2.9万名作者、150万次提交,并试图回答这个问题:编程语言对软件质量的影响是什么?他们的答案是,差别不大。

“值得注意的是,这些因语言设计而产生的微弱影响,绝大多数是由项目规模、团队规模和提交规模等过程因素主导的。”

另一组研究人员对这些数据进行了第二次研究,并在2019年做了一项名为“关于编程语言对代码质量的影响”的论文。他们的发现更令人惊讶:

“根据手头的数据,不仅无法建立编程语言和代码质量之间的因果关系,甚至它们之间的相关性也被证明是值得怀疑的。”

如果编程语言的选择并不重要,那为什么要选择Go?这些研究表明的是,流程很重要。工具、测试、性能和长期维护的便利性比时髦的功能特性更重要。如果使用得当,Go内置的工具支持更好的流程,同时提供久经考验的功能特性。

这并不是说新功能不好。在过去的几个世纪和几千年里,桥梁建设技术当然在不断进步。但是,你想成为第一个走过一座用全新的理念和未经测试的技术建造的桥梁吗?你会想等一下,让人们测试一下再采用。

软件也是如此。如果我们要建立像桥梁一样可靠的软件基础架构,我们就需要使用像物理基础架构一样经过充分测试和理解的软件技术。这就是为什么Go主要使用20世纪70年代设计的功能特性,我们知道它们是有效的。

Go很无聊….其实它妙不可言。让我们都来用它来构建明天的精彩应用吧。

img{512x368}


“Gopher部落”知识星球开球了!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!星球首开,福利自然是少不了的!2020年年底之前,8.8折(很吉利吧^_^)加入星球,下方图片扫起来吧!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats