标签 接口 下的文章

Go泛型介绍[译]

本文永久链接 – https://tonybai.com/2022/03/25/intro-generics

Go核心团队在官博上发布了一篇名为《An Introduction To Generics》的文章,该文章基于Robert Griesemer和Ian Lance Taylor在2021年GopherCon大会上的演讲,这是Go团队发布Go 1.18版本后官博发表的首篇有关Go泛型的文章,值得大家认真阅读,这里将全文做一下翻译,供大家参考。


简介

这篇博文是基于我们在2021年GopherCon上的演讲

Go 1.18版本增加了对泛型的支持。泛型是我们自Go语言开源以来对Go做出的一次最大的变更。在这篇文章中,我们将介绍这个新的语言特性。我们不会面面俱到的讲解泛型语法特性的所有细节,但我们会介绍所有我们认为重要的内容。关于Go泛型语法更为详细的描述以及示例,请看Go泛型的提案文件。关于语言变化的更精确描述,请看更新后的Go语言规范。(请注意,实际的1.18实现对提案文件所允许的内容施加了一些限制;现阶段,更新后的语言规范应该是更准确的。未来的Go版本可能会取消Go 1.18实现中的某些限制)。

泛型是一种编程范式,这种范式与特定的类型无关,泛型允许在函数和类型的实现中使用某个类型集合中的任何一种类型。

泛型在Go语言中增加了三个新的重要内容:

  • 函数和类型新增对**类型形参(type parameters)的支持。
  • 将接口类型定义为类型集合,包括没有方法的接口类型。
  • 支持类型推导,大多数情况下,调用泛型函数时可省略类型实参(type arguments)。

类型形参(Type Parameters)

现在,函数和类型被允许拥有类型形参(Type Parameters)。一个类型形参列表看起来和普通的函数形参列表一样,只是它使用的是方括号而不是小括号。

为了说明这一点,让我们先看一个用于浮点值的基本的、非泛型的Min函数:

func Min(x, y float64) float64 {
    if x < y {
        return x
    }
    return y
}

我们可以通过添加一个类型形参列表来使这个函数泛型化,以使其适用于不同的类型。在这个例子中,我们添加了一个仅有一个类型形参T的类型形参列表,并用T替换float64的使用。

func GMin[T constraints.Ordered](x, y T) T {
    if x < y {
        return x
    }
    return y
}

现在我们可以像下面代码那样,用一个类型实参(Type argument)来调用这个函数了:

x := GMin[int](2, 3)

向GMin函数提供类型实参,在本例中是int,称为实例化(instantiation)。实例化分两步进行。首先,编译器在整个泛型函数或泛型类型中把所有的类型形参替换成它们各自的类型实参。第二,编译器验证每个类型实参是否满足各自的约束条件。我们很快就会知道这意味着什么,但是如果第二步失败,实例化就会失败,程序也会无效。

在成功的实例化之后,我们就有一个非泛型的函数了,它可以像其他普通函数一样被调用。比如下面的代码:

fmin := GMin[float64]
m := fmin(2.71, 3.14)

GMin[float64]的实例化产生了一个与Min函数等效的函数,我们可以在函数调用中使用它。

类型参数也可以与类型一起使用。

type Tree[T interface{}] struct {
    left, right *Tree[T]
    value       T
}

func (t *Tree[T]) Lookup(x T) *Tree[T] { ... }

var stringTree Tree[string]

在上面这个例子中,泛型类型Tree存储了类型参数T的值。泛型类型也可以有方法,比如本例中的Lookup。为了使用一个泛型类型,它必须被实例化;Tree[string]是一个用类型实参string来实例化Tree的例子。

类型集合(Type sets)

让我们深入了解一下可以用来实例化一个类型形参的类型实参。

一个普通函数的每个值形参(译注:value parameter,相对于类型形参type parameter)都有一个对应的类型;该类型定义了一组值。例如,上面的非泛型函数Min有一个float64类型的形参,那么函数Min允许的实参值集合就是可以由float64类型表示的浮点值集合。

同样地,类型形参列表中的每个类型形参都有一个类型。因为类型形参本身就是一个类型,所以类型形参的类型定义了类型的集合。这种元类型(meta-type)被称为类型约束(type constraint)

在泛型函数GMin中,类型约束是从constraints包中导入的。Ordered约束描述了所有类型的集合,这些类型的值可以被排序,或者换句话说,用<运算符(或<= , > , 等)进行比较。该约束确保只有具有可排序值的类型才能被传递给GMin。这也意味着在GMin的函数体中,该类型参数的值可以被用于<运算符的比较。

在Go中,类型约束必须是接口。也就是说,一个接口类型可以作为一个值类型使用,也可以作为一个元类型(meta-type)使用。接口定义了方法,所以显然我们可以使用要求某些方法存在的类型约束。但是constraints.Ordered也是一个接口类型,而且<操作符也不是一个方法。

为了使其发挥作用,我们以一种新的方式来看待接口

直到最近(译注:该演讲发生在Go 1.18发布之前,这里的最近是Go 1.18发布之前的某个时间点),Go规范说,一个接口定义了一个方法集合,大略就是接口中列举的方法集合。任何实现了所有这些方法的类型都实现了该接口。

但另一种看法是,接口定义了一个类型集合(type set),即实现这些方法的类型。从这个角度来看,任何属于接口定义的类型集合中的元素的类型都实现了该接口。

两种观点殊途同归。对于每个方法集合,我们可以想象出实现这些方法的类型组成的类型集合,这就是接口所定义的类型集合。

不过对于我们的目的来说,类型集合的观点比方法集合的观点更有优势:我们可以明确地将类型添加到集合中,从而以新的方式控制类型集合

我们已经扩展了接口类型的语法,以使其发挥作用。例如,interface{ int|string|bool }定义了包含int、string和bool的类型集合。

另一种说法是,这个接口只被int、string或bool所满足。

现在我们来看看contraints.Ordered的实际定义。

type Ordered interface {
    Integer|Float|~string
}

这个声明说的是,Ordered接口是所有整数、浮点和字符串类型的集合。竖线表达了类型(或者说这里是类型集合)的联合(union)。Integer和Float是接口类型,在constraints包中也有类似的定义。注意,Ordered接口没有定义任何方法。

对于类型约束,我们通常不关心某一个特定的类型,比如字符串;我们对所有的字符串类型感兴趣。这就是~标记的作用。表达式~string意味着底层类型(underlying type)为string的所有类型的集合。这包括string类型本身,以及所有用类似type MyString string声明的类型。

当然,我们仍然想在接口中指定方法,而且我们想向后兼容。在Go 1.18中,一个接口可以像以前一样包含方法和嵌入接口,但它也可以嵌入非接口类型、联合体(union)和底层类型的集合。

当作为类型约束使用时,由接口定义的类型集合准确地指定了允许作为各自类型形参的类型实参的类型。在一个泛型函数体中,如果一个操作数的类型是带有约束C的类型形参P,那么如果操作被C的类型集合中的所有类型所允许,那么这些操作就是允许的(目前这里有一些实现限制,但是普通代码不太可能遇到这些限制)。

用作约束的接口可以被赋予名称(比如Ordered),也可以是内联到类型形参列表中的接口字面值,比如下面代码:

[S interface{~[]E}, E interface{}]

这里S必须是一个切片类型,切片的元素类型可以是任何类型。

因为这是一种常见的情况,所以对于处于约束位置的接口,用作包围的interface{}可以被省略,我们可以简单地写成下面这样:

[S ~[]E, E interface{}]

因为空接口在类型形参列表中很常见,在普通的Go代码中也是如此,Go 1.18引入了一个新的预声明的标识符any作为空接口类型的别名。这样一来,我们就得到了下面这段符合惯用法的代码:

[S ~[]E, E any]

作为类型集合的接口是一种强大的新机制,是使类型约束在Go中发挥作用的关键。目前,使用新语法形式的接口只能作为约束使用。但不难想象,显式指明类型约束的接口在一般情况下是多么有用。

类型推导(Type inference)

最后一个主要的语言新特性是类型推导。在某些方面,这是语言最复杂的变化,但它很重要,因为它让人们在编写调用泛型函数的代码时使用一种更为自然的风格。

函数实参类型推导(Function argument type inference)

有了类型形参,我们就需要传递类型实参,这可能使代码变得冗长。回到我们的泛型GMin函数:

func GMin[T constraints.Ordered](x, y T) T { ... }

类型形参T用于指定普通non-type参数x和y的类型。正如我们前面所看到的,我们可以用一个显式类型实参来调用它:

var a, b, m float64
m = GMin[float64](a, b) // 显式传递类型实参

在许多情况下,编译器可以从普通参数中推导出T的类型实参。这使得代码更短,同时保持清晰:

var a, b, m float64
m = GMin(a, b) // 没有传入类型实参

其原理是将实际参数a和b的类型与形式参数x和y的类型相匹配。

这种从函数的实参类型推导出类型实参的推导方式,被称为函数实参类型推导

函数实参类型推导只适用于在函数参数中使用的类型形参的情况,不适用于只在函数返回值中使用的类型形参或只在函数主体中使用的类型形参的情况。例如,它不适用于像MakeTT any T这样的函数,它只在返回值参数列表中使用了类型形参T。

约束类型推导(Constraint type inference)

Go语言还支持另一种类型推导,即约束类型推导。为了说明这类推导,让我们从下面这个缩放整数切片的例子开始:

// Scale返回一个s的副本,每个元素都乘以c。
// 这个实现有一个问题,正如我们将看到的。
func Scale[E constraints.Integer](s []E, c E) []E {
    r := make([]E, len(s))
    for i, v := range s {
        r[i] = v * c
    }
    return r
}

这是一个泛型函数,适用于任何整数类型的切片。

现在,假设我们有一个多维的Point类型,其中每个Point只是一个表示该点坐标的整数列表。自然,这个类型会有一些方法。

type Point []int32

func (p Point) String() string {
    // 实现细节不重要
}

有时我们想对一个点进行缩放。因为一个点是一个整数切片,我们可以使用我们之前写的Scale函数。

// ScaleAndPrint将一个点加倍并打印出来。
func ScaleAndPrint(p Point) {
    r := Scale(p, 2)
    fmt.Println(r.String()) // 无法通过编译
}

不幸的是,这无法通过编译,编译器将给出r.String undefined (type []int32 has no field or method String) 这样的错误。

问题在于Scale函数返回一个[]E类型的值,其中E是参数切片的元素类型。当我们用一个Point类型的值调用Scale时,它的底层类型是[]int32,我们得到的是一个[]int32类型的值,而不是Point类型。这是由泛型代码的写法决定的,但这并不是我们想要的。

为了解决这个问题,我们必须改变Scale函数,使其使用一个类型参数来表示分片类型。

// Scale returns a copy of s with each element multiplied by c.
func Scale[S ~[]E, E constraints.Integer](s S, c E) S {
    r := make(S, len(s))
    for i, v := range s {
        r[i] = v * c
    }
    return r
}

我们引入了一个新的类型参数S,用于表示切片参数的类型。我们对它进行了约束,使其底层类型是S而不是[]E,返回值类型现在是S。由于E被约束为一个整数,其效果与之前一样:第一个参数必须是某个整数类型的切片。该函数主体的唯一变化是,现在我们在调用make时传递S,而不是[]E。

如果我们用一个普通的切片来调用它,新函数的作用和以前一样,但是如果我们用Point类型来调用它,我们现在得到一个Point类型的值。这就是我们想要的。有了这个版本的Scale,早先的ScaleAndPrint函数将如我们所期望的那样编译和运行。

但你可能会问:为什么调用Scale时不显式传递类型实参也可以呢?也就是说,为什么我们可以写Scale(p, 2),没有类型实参,而不是必须写Scale[Point, int32](p, 2)?我们的新Scale函数有两个类型参数,S和E。在不传递任何类型实参的Scale调用中,上面描述的函数实参类型推导让编译器推导出s的类型实参是Point。但该函数还有另外一个类型形参E,编译器推导出E的类型实参是切片的元素类型的过程被称为约束类型推导

约束类型推导是从类型形参约束中推导出类型实参。当一个类型形参的约束的定义中包含另一个类型形参时,它就会被使用。当这些类型形参中的一个的类型实参是已知的时候,该约束被用来推导另一个类型形参的类型实参。

约束类型推导通用用于当一个约束对某些类型使用~type的形式时,该type是用其他类型形参写的。我们在Scale的例子中看到了这一点。S是~[]E,~后面的类型[]E用另一个类型形参E来写成的。如果我们知道S的类型实参,我们就可以推导出E的类型实参。S是一个切片类型,而E是该切片的元素类型。

这只是对约束类型推导的一个介绍。完整的细节请参见提案文档文件语言规范

类型推导实践

类型推导的工作原理细节很复杂,但使用它并不复杂:类型推导要么成功要么失败。如果它成功了,类型实参可以被省略,调用泛型函数看起来与调用普通函数没有什么不同。如果类型推导失败,编译器会给出一个错误信息,在这些情况下,我们可以直接提供必要的类型实参。

在向语言添加类型推导时,我们试图在推导能力和复杂性之间取得平衡。我们想确保当编译器推导出类型时,这些类型永远不会令人惊讶。我们试图小心翼翼地站在未能推导出类型的一边,而不是站在推导出错误类型的一边。我们可能没有完全做到这一点,而且我们可能会在未来的版本中继续完善它。其效果是,更多的程序可以无需显式提供类型实参。今天不需要类型实参的程序,明天也不会需要。

小结

泛型是1.18中一个很大的新语言特性。这些新的语言变化需要大量的新代码,这些代码还没有在生产环境中进行过大量的测试。这只会随着越来越多的人编写和使用泛型代码而发生。我们相信这个功能实现得很好,质量很高。然而,与Go的大多数方面不同,我们无法用现实世界的经验来支持这一信念。因此,虽然我们鼓励在有意义的地方使用泛型,但在生产中部署泛型代码时,请使用适当的谨慎措施。

除此以外,我们很高兴能提供泛型,并希望它们能使Go程序员的工作效率更高。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}
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
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

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

聊聊Go应用输出日志的工程实践

配图改自网络

本文永久链接 – https://tonybai.com/2022/03/05/go-logging-practice

Go隶属于后端语言,以开发各类服务、中间件和系统平台见长。日常学习Go语言时,日志不是不可或缺的,甚至是无需考虑的,但是一旦到真正的Go的工程实践中,输出日志便是我们绕不过去的、必须面对的问题。

Go开发的服务大多具有连续和自主运行的属性,通常都是7×24小时运行的,开发运维人员不可能一直盯着服务的运行状态,这就需要记录服务的运行日志。而日志的本质正是留档待查。通过日志,我们可以:

  • 查看系统运行状态
  • 发现异常
  • 审计行为
  • 辅助问题的诊断

在如今云原生时代,可观测性(Observability)大行其道,日志被称为“可观测性的三大支柱”之一(另两个是度量(metrics)与跟踪(tracing)),是云原生系统devops不可或缺的重要组成部分。

那么在Go工程实践中,Go对日志输出支持的现状是怎样的?存在哪些问题?常用的问题解决套路是什么?以及社区的努力与期望又是什么?在这一篇文章中,我就围绕上述这些问题来聊一聊。

一. Go日志现状

Go是“自带电池”的语言,开箱即用。这就意味着在Go标准库中有现成的log包可供开发者使用。

Go标准库log包

作为Go标准库的一部分,Go log包使用起来十分简单,你只需导入log包并无需做任何创建与设置操作即可输出log到标准错误(stderr),这是因为log包内置了一个名为std的默认logger:

// $GOROOT/src/log/log.go
var std = New(os.Stderr, "", LstdFlags)

这种内置一个默认logger实例的模式也被很多第三方log包所效仿。下面是使用默认logger输出日志的简单例子:

import "log"

func main() {
    log.Println("hello, go log")
}

上面示例程序输出:

2022/02/27 14:40:41 hello, go log

我们看到:go log提供的是printf-like风格的log API,这也意味着将代码中的log换成fmt,代码同样可以正常运行。go log支持三类API:

Println/Printf
Panicln/Panicf // 相当于PrintX + panic
Fatalln/Fatalf // 相当于PrintX + exit

go log包通过下面三个导出方法可以实现对logger的一些“定制”:

func SetFlags(flag int)       // 主要用于设置日志的时间戳格式,也可以设置前缀字符串在log输出中的位置,默认flag为LstdFlags
func SetOutput(w io.Writer)   // 设置日志的输出目的地,比如文件、网络socket、syslog等
func SetPrefix(prefix string) // 设置日志前缀

但go log包不支持设置log level并按level输出,内置std logger同样不支持log level。如果对log level有需求,可基于go log包进行二次封装。下面就是一个简单的封装demo:

package main

import (
    "io"
    "log"
    "os"
    "sync/atomic"
)

// log level
const (
    LDEBUG = iota + 1 // 1
    LWARN             // 2
    LINFO             // 3
    LERROR            // 4
    LFATAL            // 5
)

type myLogger struct {
    level       int64
    w           io.Writer
    debugLogger *log.Logger
    warnLogger  *log.Logger
    infoLogger  *log.Logger
    errLogger   *log.Logger
    fatalLogger *log.Logger
}

func New(w io.Writer, level int64, flag int) *myLogger {
    if w == nil {
        w = os.Stderr
    }

    if flag <= 0 {
        flag = log.LstdFlags
    }

    return &myLogger{
        w:           w,
        level:       level,
        debugLogger: log.New(w, "[DEBUG] ", flag|log.Lmsgprefix),
        warnLogger:  log.New(w, "[WARN] ", flag|log.Lmsgprefix),
        infoLogger:  log.New(w, "[INFO] ", flag|log.Lmsgprefix),
        errLogger:   log.New(w, "[ERROR] ", flag|log.Lmsgprefix),
        fatalLogger: log.New(w, "[FATAL] ", flag|log.Lmsgprefix),
    }
}

func (l *myLogger) SetLevel(level int64) {
    if level < LDEBUG || level > LFATAL {
        return
    }

    atomic.StoreInt64(&l.level, level)
}

func (l *myLogger) Debugln(v ...interface{}) {
    if atomic.LoadInt64(&l.level) > LDEBUG {
        return
    }
    l.debugLogger.Println(v...)
}

func (l *myLogger) Debugf(format string, v ...interface{}) {
    if atomic.LoadInt64(&l.level) > LDEBUG {
        return
    }
    l.debugLogger.Printf(format, v...)
}

func (l *myLogger) Infoln(v ...interface{}) {
    if atomic.LoadInt64(&l.level) > LINFO {
        return
    }
    l.infoLogger.Println(v...)
}

func (l *myLogger) Infof(format string, v ...interface{}) {
    if atomic.LoadInt64(&l.level) > LINFO {
        return
    }
    l.infoLogger.Printf(format, v...)
}

func main() {
    logger := New(nil, LWARN, 0)
    logger.Infoln("info level log demo")
    logger.Debugln("debug level log demo")
}

运行这个demo,输出日志如下:(由于设置的是LWARN级别,所以仅会输出info级别的日志,debug级别日志将被忽略):

2022/02/27 15:41:01 [INFO] info level log demo

glog

github的golang组织下还提供了一个Google内部使用的、Go版本的glog

注:glog是google内部自用的log包,不接受外部的添加feature的PR。

glog支持分级日志,并提供了按特定log level输出日志的专用API,比如:InfoXx、WarningXx、ErrorXx、FatalXx等,下面是使用glog的一个示例:

package main

import (
    "flag"

    "github.com/golang/glog"
)

func main() {
    flag.Parse()
    glog.Info("Prepare to repel boarders")

    if glog.V(2) {
        glog.Info("Starting transaction...")
    }
    glog.V(2).Infoln("Processed", 5, "elements")
    glog.Flush()
}

glog通过flag来指定log level,所以在使用glog输出日志前必须先调用Go标准库flag包的Parse函数解析命令行flag。执行这个示例,输出结果如下:

$go run main.go -logtostderr -v=2
I0227 16:14:35.968922   40869 main.go:12] Prepare to repel boarders
I0227 16:14:35.969024   40869 main.go:15] Starting transaction...
I0227 16:14:35.969027   40869 main.go:17] Processed 5 elements

注意:使用-logtostderr使得日志输出到标准错误,否则默认输出到系统临时文件目录的临时文件中;如果要输出日志到特定目录,可以去掉-logtostderr,并指定-log_dir,不过我们无法指定日志文件名,glog有一套内定的日志文件自动命名机制。

虽然glog与标准库log包有很多不同点,但它们总体来说还是属于一类log包,它们具有一个共同的特点:开发者需自己将各个字段通过类Printf API组成一条非结构化的日志,这样的日志便于human阅读,但不便于机器阅读(解析)

结构化日志包

好了,这就引出了另一类log包,它们的特点与上面的标准库log、golang/glog正好相反:开发者使用这一类log包时无需自组织日志格式,只需通过key-value的方式给出要输出的字段,log包就会将这些字段自动整理为一条类似下面这样的结构化的日志

// 以zap包输出为例:

{"level":"info","ts":1646256841.204795,"caller":"zap/testzap.go:13","msg":"failed to fetch URL","url":"http://tonybai.com","attempt":3,"backoff":1}

我们很容易看出这是一条合法的json数据,这类log包多以json作为结构化日志的输出形式。并且,即便某些包提供了类Printf的API,其实也只是将自组的字符串作为一个特定key(比如zap包使用msg)的value。

Go社区开源的第三方log包绝大多数都属于此类结构化日志包,包括github排名最靠前、采用最为广泛的两个包sirupsen/logrusuber-go/zap

笔者在生产中使用的是uber/zap,关于zap包的使用方法,我在之前的一篇《一文告诉你如何用好uber开源的zap日志》有详细讲解,这里就不赘述了。

结构化日志包之所以大受欢迎,主要还是因为其容易被机器“阅读”的特点,如今将日志“灌入”类ELK的集中日志平台中备查已经不是最佳实践了,而是必经之路

有人说性能也是考量因素。也没错,至少我在选型时会重点考虑性能高的log包。比如:在并发benchmark中,zap远胜std log:

goos: linux
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
BenchmarkGolog-4         4126830        290.7 ns/op    24 B/op      1 allocs/op
BenchmarkGooglelog-4     711428    1427 ns/op      216 B/op     2 allocs/op
BenchmarkZap-4      11572719        97.08 ns/op     0 B/op      0 allocs/op
PASS

不过你可能并不知晓:在单goroutine下,zap性能其实不如std log:

goos: linux
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
BenchmarkGolog-4         4470559        273.4 ns/op    24 B/op      1 allocs/op
BenchmarkGooglelog-4     789846    1363 ns/op      216 B/op     2 allocs/op
BenchmarkZap-4       2934202        400.4 ns/op     0 B/op      0 allocs/op
PASS

不过,如今哪个作为后端服务的Go应用不启动几个goroutine呢,并发才是log应用的主场景。

无论是选择非结构化的std log包,还是结构化的、高性能的zap log包,在应用过程中依然会遇到一些问题。接下来,我们就来看看在log的工程实践中存在的主要问题。

二. 工程实践中存在的主要问题

工程实践中,在处理log这块儿你会遇到很多问题,比如:如何日志选型、如何评估日志性能、如何进行日志输出设置(包括:设置日志输出的目的io.Writer、日志格式、日志轮转(rotate)与归档(archive))等。

但这些都不是主要问题,日志选型可参考社区使用最广泛的log包;日志性能用简单的benchmark就可判断;日志设置呢,看看各个包提供的doc与example大多都可以搞定。

那主要问题是什么呢?其实是log适配。为什么来会有log适配问题呢?我来举一个例子大家就明白了。

现在我有一个Go项目P1,P1依赖uber/zap包输出log。通过前面对zap的了解,我们知道zap输出的日志样式是这样的:

{"level":"warn","logtime":"2022-02-27T15:24:57+08:00","caller":"xx/log.go:19","msg":"[f:1,l:33372,t:4,c:33372,a:33372] [00103:00001] t24 cast vote from n00003 index 33373 term 24, log term: 5"}

现在P1要基于dragonboat包实现分布式强一致的数据同步,不过dragonboat采用了自定义的logger,其内部模块输出的日志的样式是这样的:

2022-02-27 16:25:40.259479 I | raft: [f:1,l:33375,t:26,c:33374,a:33374] [00101:00001] t26 became leader

我们看到:问题出现了:P1输出日志一些是zap log格式的,一些是dragonboat自定义格式的,不仅human阅读困难,送给机器也无法解析

好在dragonboat包比较厚道,对外部提供了设置其内部logger的导出函数SetLoggerFactory,但是前提是设置的logger实例的类型应该满足下面接口类型:

// dragonboat包中的logger/logger.go
type ILogger interface {
    SetLevel(LogLevel)
    Debugf(format string, args ...interface{})
    Infof(format string, args ...interface{})
    Warningf(format string, args ...interface{})
    Errorf(format string, args ...interface{})
    Panicf(format string, args ...interface{})
}

好在zap包提供了“Sugar”方式的Printf-like的API,可以用于适配上述ILogger接口,我们以dragonboat提供的dragonboat-example中的helloworld为例,让该项目适配zap风格的log,我们为helloworld项目提供一个log.go文件,源码如下:

//helloworld/log.go

package main

import (
    "github.com/lni/dragonboat/v3/logger"
    "go.uber.org/zap"
)

type LogLevel = logger.LogLevel

type Mylogger struct {
    *zap.Logger
}

func (l *Mylogger) SetLevel(level LogLevel) {
}

func (l *Mylogger) Warningf(format string, args ...interface{}) {
    l.Logger.Sugar().Warnf(format, args...)
}

func (l *Mylogger) Debugf(format string, args ...interface{}) {
    l.Logger.Sugar().Debugf(format, args...)
}

func (l *Mylogger) Errorf(format string, args ...interface{}) {
    l.Logger.Sugar().Errorf(format, args...)
}

func (l *Mylogger) Infof(format string, args ...interface{}) {
    l.Logger.Sugar().Infof(format, args...)
}

func (l *Mylogger) Panicf(format string, args ...interface{}) {
    l.Logger.Sugar().Panicf(format, args...)
}

var _ logger.ILogger = (*Mylogger)(nil)

var factory = func(pkgName string) logger.ILogger {
    logger, _ := zap.NewProduction()
    return &Mylogger{
        Logger: logger,
    }
}

然后在helloworld的main.go中使用dragonboat提供的SetLoggerFactory重新设置一下dragonboat内部所使用的logger实例:

func main() {
    ... ...
    logger.SetLoggerFactory(logger.Factory(factory))

    // change the log verbosity
    logger.GetLogger("raft").SetLevel(logger.ERROR)
    logger.GetLogger("rsm").SetLevel(logger.WARNING)
    logger.GetLogger("transport").SetLevel(logger.WARNING)
    logger.GetLogger("grpc").SetLevel(logger.WARNING)
    ... ...
}

这样修改后再运行helloworld这个示例,我们便可以看到它输出的日志样式已经变成了zap风格的了:

{"level":"warn","ts":1646300185.9349403,"caller":"helloworld/log.go:18","msg":"[f:1,l:4,t:2,c:4,a:4] [00128:00001] t3 received 2 votes and 0 rejections, quorum is 2"}
{"level":"info","ts":1646300185.9352179,"caller":"helloworld/log.go:30","msg":"[f:1,l:5,t:3,c:4,a:4] [00128:00001] t3 became leader"}

到这里,有人可能会说:适配一个log包似乎也还好吧!其实碰到像dragonboat这样的包,只能说明我们运气好,它提供了供你去适配的logger接口,如果它没有提供这样的接口呢?如果zap没有提供Printf-like的API呢?我们都无法像上面这样将zap与dragonboat相融在一起。

此外,我要说这个问题的严重性在于其不确定性,这种不确定来自于无法预料将来与某个新引入的第三方包是否存在日志接口格式上的兼容性,而问题的根源则在于目前Go官方没有一个统一log接口供所有项目去遵守

在前面的log现状中我们说过,Go标准库的Logger是一个结构体,是一个具体的实现,不具备解耦的作用。

三. 临时解决方法、社区努力与期望

那遇到此类工程问题,我们该如何做呢?在Go没有提供统一log接口的情况下,我们可能遇到下面的两种情况(项目P,依赖D):

  • 如果依赖D像上面dragonboat提供了log接口用于适配,且log接口的风格与P自用log包的风格兼容(比如都支持Printf-like API),那么我们需要像上面例子中那样,在项目P中提供一个用于适配D的logger实现;
  • 如果依赖D没有提供log接口用于适配,且其输出的日志风格与P自用log风格不一致或是D的log API风格与P自用log包 API不兼容,这种情况下,要么向D库作者提issue或pr(多数情况可能被拒),要么更实际一点,自己fork D项目并二次开发,替换其中的logger或增加用于适配的接口。

要一劳永逸的解决log工程上的问题,还是需要Go官方定义统一的log接口,社区在这方面不能说不努力,2017年Go社区一批大神就成立了统一log接口委员会,并商讨出了一个proposal试图在Go标准库中增加统一的log接口,但提案没有没Go核心团队接纳(accept)。之后,该话题逐渐沉寂下来,形成如今的现状。

打不进核心,Go社区只能走外围路线,于是出现了许多Go社区版的类java的SLF4J(Simple Logging Facade for Java)的项目,比如logrslf4go等。目前比较活跃的log API是logr项目,它提供了大部分主流log包的适配实现。如果你没有更好的办法,可以考虑一下采用logr的API规范。

四. 小结

log在工程实践中的问题虽然没有被单独拿出来放在Go年度用户调查结果中,但它确是客观存在的,我觉得它应该属于“Missing or immature libraries”调查项的一部分,这样的问题其实越早解决掉越好,将会给开发者带来很大的便利,节省很多花在实现log适配上的时间。


img{512x368}

“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强,欢迎大家加入!

img{512x368}

img{512x368}
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

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 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