标签 平台 下的文章

聊聊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

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

2014小结

2014年的最后一个工作日,这里写下有关2014年的一份小结。

年终总结本无固定格式,但写了若干年后,便有了自己的格式。但今年不打算遵循这个格式了,跳出自己的舒适区,随意写写。

2014年12月底,随着亚航QZ8501航班的最后一掉,航空史上都为数不多的灾难年终于画上了句号,留给人们的是久久的惊恐不安,留给遇难者 家属们的是无法释怀的悲伤。2014年12月31日15点,随着A股上证指数最后一个交易日收涨68.86点,稳稳站上3200点,让广大股民们 看到了2015年牛市持续赚钱的希望。不知为何,这个世界几乎总是同时上演着冰与火两种剧本。

短信与微信(包括其他X信)的博弈亦是如此。

短信,这一红极一时的让移动运营商赚得盆满钵满的廉价沟通工具如今却早已成明日黄花。不妨打开手机,翻看一下你的手机通信录,短信列表中是不是除 了验证码(登录、支付业务),就是各种营销垃圾广告,或者是移动运营商自有的客服信息呢。我相信我的情况应该可以代表广大群众了。

随着微信今年推出“企业号”,微信几乎完成了对短信的业务合围:

点对点短信 vs. 联系人、朋友圈、群
SP短信    vs. 订阅号、服务号
行业短信  vs. 服务号、企业号 (营销、售后、内部OA、CRM等)

今年年初招商银行信用卡将300以内的消费提醒短信取消,改为微信提醒,其实就是一个看高微信,看空短信的行为。只是考虑到到达率(用户未开网络时),没 有将大额消费全部转到微信上,而是短信和微信都做提醒。一旦无线网络接入、资费门槛下降、网络速度提升、终端实时在线不再是问题,达到率也将 不是问题时,微信会对短信发起最后的总攻。

这么对比其实也不公平,因为短信和微信本不是一个重量级的对手。从出生的那天起,微信就被赋予了崇高的使命,非短信可比。微信试图连接一切,做统 一入口,建立庞大生态圈;而短信仅仅是一个通道工具罢了。

面对移动短信市场的衰败,移动运营商也在挣扎,也在试图翻盘,或至少平起平坐,但就我了解到的移动运营商产品开发与运营的风格,想和互联网巨头T 掰手腕,下场必输无疑。中国移动年初也蛮拼的,喊出了"RCS(融合通信)"与微信抢手机社交入口,但这都到了2014最后一天了,RCS依旧不见踪 影。

短信免费或退出历史舞台就像周鸿祎在其书《周鸿祎自述:我的互联网方法论》中说的那样是“趋势”,不可违!

我们就是为中国移动短信业务提供服务端软件和方案的。短信若是没了(或变成鸡肋),我们干啥?冰冷的现实摆在大家面前,领导跟我 们说:“转型”。

2014年,至少我们依旧在转型中。老板们把“转型”依旧约束在“移动运营商”这棵大树下面,这让我们转的不那么纯粹,有些拖泥带水,可持续盈利 的业务方向并不明显。从目前来看,今年收入依旧靠传统业务渠道获得。

虽说要“转型”,但领导今年给我的任务却是做好守门员,守住现有市场份额,保证产品线上无事。这并非如我所愿,在一个业务线耕耘多年,业务和技术 能力均到达了天花板,对我个人来说,这不是一个很好的发展规划。但考虑到下面的技术负责人、员工在技术和业务火候儿还欠缺那么一些,我答应了留 守,但会投入部分精力做个人技术转型储备。

业务的转型需要技术做支撑,局限于传统后台服务系统的我们需要张开怀抱,拥抱那些“流行”的新玩意儿。我首先试水!从2014年我的博客中你也许 可以看得出来我试水过的技术,我在尝试跳出自己的各种舒适区,向一些近两年兴起的、将来比较有前途的技术方向靠拢,学习移动互联网的思维和潮流。

上半年曾尝试过终端产品开发的技术,还为此购入若干数码装备,但试过后才发现这仍然不是我的主菜,就和10年前Windows GUI程序开发不是我的菜一样。但这个过程并非没有收获,未来任何业务不与终端开发打交道是不可能的,这个接触过程让我了解到了终端开发的重点和难点,于 是总结经验,整理教训。

正当准备调整方向、重新上路之际,家里出现重大变故,耗费了我整整1个多月的时间,一切几乎都停滞了,直到10月份我才渐渐重新进入状态。

在公司内部技术社区看到公司CTO的一篇文章,讲述移动互联网正在由消费者驱动向企业驱动转变(来自麦肯锡报告),结合微信推出企业号、用友软件的转型来 看(今天听说用友软件更名为“用友网络”了,决心向互联网转型),这个趋势也是我比较认同的,这个方向以及相关技术也是我在正在涉猎以及即将涉猎的。不过 关于企业互联网服务以及平台,自己的相关业务经验、技术和积累还是甚少,征途必然坎坷,自己还需“拼”一下!关于微信这个平台,这个入口,它是腾讯未来战 略的核心,靠着腾讯这棵大树,至少未来几年发展应该还是不错的。

公司的大BOSS这两年一直提倡“创业者的精神",学会在逆境中成长,在困境中成功。但作为在短信这个行业内浸淫了十多年的部门,我们不免产生一些惰性, 更愿意躺在现有的温床上“享受生活”,立足于现有的平台做舒服的事情。经历过2014年的严峻形势,现在的我们应该清醒的认识到这样的舒服生活,温床和平 台都可能将远离我们。如果我们再不主动站起来,我们将再无力站起了。

2014年在个人发展方面做出了“妥协”,2015我打算轻装前行,这对我、对团队成员的成长都是有好处的。年底给领导发总结时,已经和领导书面提出退出 当前业务线的想法。虽然目前还没有收到回复,不过无论怎样,我都坚定了决心,自己作为这个产品线的负责人,已经起不到领路的作用了,是时候退出了。

2015,给自己的关键字是“创业”。《精益创业》一书中作者似乎有这样一句话:“你不一定非要在车库里折腾才算是创业”,在企业内部也可以“创业”,为创造某种新产品或新服务为目的而组建的一个团队或组织内的人都是“创业者”。

以往年份的小结,我总会总结一些数据,比如blog文章、读过多少本书等等。但今年这些数据就不统计了,自己对自己的考核指标"KPI"有所调整,以前哪些指标已经不算数了,列出也就无意义了。

2014这一年,LP给了我很大压力!我能理解,她期望我能取得更大的成功。这让我“亚历山大”啊,这回可是真的。

要说新年的愿望是什么?希望2015年年末时能为自己2015年的所作所为,所取得的进步和成果点个赞

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系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