标签 容器 下的文章

TB一周萃选[第6期]

本文是首发于个人微信公众号的文章“TB一周萃选[第6期]”的归档。

img{512x368}
图:第6期封面

凡事欲其成功,必须付出代价——奋斗。
— 美国作家 爱默生

每期挑选“封面图”都是一件颇为“费工夫”的事情,本期的封面图来自于一个投资界大V发送的微博内容,因为当我第一眼看到这幅图片时,感觉它颇为契合我当时的心境

“未来的一年里,连睡觉都是浪费时间”这句话的最原始的出处在哪里我还没有查到,但最近与这句话“勾搭”上关系的是小米公司,因为坊间传闻小米公司要开启上市计划了。但小米公司绝对不是这句话的“始作俑者”,因为我查到著名的投资人孙正义先生在2017中旬举行的SoftBank World大会中的一次演讲中也提到过:”未来让我激动,感觉睡觉都是在浪费时间”这一同义的说法。

先不管人们对这句话是否感同身受,实际情况是当今人们用于睡觉的时间真的是越来越少了。已经成功的人为了追求更大的成功或让企业长期利于不败之地而殚精竭虑,他们不能睡;正走在通往成功道路上的奋斗者们,加班加点,兢兢业业,亲力亲为,他们不愿睡;大多安于现状、不愿折腾的打工族们则贪恋红尘,吃喝唱K、刷剧吃鸡、答题聊天的时间还不够呢,哪忍心放下手机或电脑去呼呼大睡呢,他们不舍得睡

由此看来,似乎这个“网红句子”在不同人内心中的含义是可以不同的。但无论怎样,我敢肯定的是这幅图会让那些新的一年中心中目标满满并欲为之奋斗的人振奋不已。大家都说刚刚新年伊始,其实已经过去了半个多月了,时间真的不等人:学习要速度,发展要速度,增长要速度,那么多工作和目标等待着你去完成,抓紧这本应该是睡眠的时间,努力奋斗吧。

img{512x368}
图:2018.1.18雾凇景观(沈阳)

一、一周文章精粹

1. AWS Lambda正式宣布对Go的支持

在2017年末举办的AWS re:Invent大会上,AWS的技术人员就剧透了Lambda将对Go提供正式支持。本月15号,AWS官方正式宣布了Lambda对Go的支持,并在github上发布了aws-lambda-go1.0.0版本。现在全世界的gopher们就可以使用自己心仪的语言来编写自己的第一个Function as a Service例子了。

img{512x368}

文章链接:“Announcing Go Support for AWS Lambda”

2. Cloudflare公司的TCP协议栈深入理解系列

Cloudflare是世界知名的CDN服务商,这些年Cloudflare公司的主要技术栈也转移到了Go语言,包括其DNS系统等。Cloudflare在TCP/IP网络方面有了较为深入的理解,其研发人员经常在其官方blog发表有关互联网协议方面的技术文章,这里将其中几篇抽取汇总出来,形成“TCP协议栈深入理解系列”,包括:

3. 高性能Go语言编程

印象中,高性能Go编程这个topic,大胡子Dave Cheney在几个技术大会上都讲过,Dave自己关于这方面的认知也在演化,这次在QCon大会上的演讲应该他对Go高性能编程的最新理解。

文章链接:“High performance Go by Dave Cheney”

4. 为什么Go中会有nil channel?

Francesc Campoy是Go core team前成员,他的“just for fun”系列播客在广大Gopher圈里十分受欢迎,其最新一期“为什么Go中会有nil channel?”讲解了nil channel在实际编码中的妙用。

img{512x368}

文章链接:为什么Go中会有nil channel?

5. 将Kubernetes集群扩展到2500个节点

容器与Kubernetes等容器管理基础设施的出现改变的不仅仅企业的业务应用架构和开发模式,对近两年火热的人工智能、机器学习也是一种赋能。当前Kubernetes支撑的人工智能/机器学习环境是目前一个流行的趋势,比如发布不久的Kubeflow。不过2015年末的成立的openai组织则早就将Kubernetes运用于人工智能领域的研究,截止目前该组织运行管理的Kubernetes集群已经达到2500个节点。本周openai发表文章讲述了他们是如何将Kubernetes集群管理的节点数量扩展到2500个的,他们的下一个目标是5000个节点。

文章链接:“Scaling Kubernetes to 2,500 Nodes”

6、Kubernetes的引力

2017年,Kubernetes战胜了swarm和mesos,成为容器管理和服务编排方面的事实标准。

img{512x368}

“Kubernetes引力”这篇文章从标准、容器管理编排、适配多云平台、适用于分布式系统部署等多方面论述Kubernetes对IT世界的改变。

文章链接:“The Gravity of Kubernetes”

二、一周资料分享

1. 人工智能标准化白皮书(2018版)

2018年1月18日,在国家人工智能标准化总体组、专家咨询组成立大会上,大会发布了“人工智能标准化白皮书2018版”,对人工智能技术的历史、发展现状及趋势、人工智能的标准体系以及国内外标准化的现状做了系统的阐述。

人工智能标准化白皮书2018: 链接: https://pan.baidu.com/s/1qZTPyCc 密码: x3qn

三、一周项目推荐

1. tview

tview是用纯Go语言编写的一款终端UI组件库,用于实现基于terminal的文本式交互界面。类似于传统的C语言ncurses库。tview提供了许多widget,并且有对应的demo代码对应,使用起来十分方便:

  • 输入框(包括密码字段输入、下拉选择、选择框、按钮)
  • 可导航的多色文字视图
  • 导航表视图
  • 可选列表
  • Flexbox和页面布局
  • 模态消息窗口

img{512x368}

项目地址:tview

2. colly

数据在移动互联网时代以及即将到来的AI时代都是具有核心价值的。数据的获取途径之一就是通过爬虫工具获取公共数据,并作为数据价值挖掘的输入。colly就是一款用于编写爬虫工具的框架,它使用Go语言实现,提供优雅、简洁的API接口、高效的性能、并发爬取管理、缓存、robots.txt支持等功能,同时colly还提供了详尽的使用文档以及丰富的examples

img{512x368}

项目地址:colly

四、一周图书推荐

1.《迁移到云原生应用架构》

img{512x368}
图:Migrating to Cloud-Native Application Architectures封面

就好比00后被称为是互联网时代“原住民”一样,近几年的一些应用架构演化模式被称为“云原生”应用(cloud-native application),换句好理解的话来说,就是这些应用天生就是应该跑在云上的,而且具有诸多契合云计算平台的特征,而不仅仅是简单地将传统单体应用从单机挪到虚拟机或容器中部署。

云原生(Cloud Native)这个概念最初是由Pivotal公司Matt Stine在 2013年提出的,是他对多年架构和咨询经验进行总结后的一个成果。2015年,他操刀编写了“Migrating to Cloud-Native Application Architectures”,也就是这里推荐的这本短小的开源书。

这本书的脉络十分清晰,首先Matt告诉我们什么是云原生架构以及为什么要用云原生架构。不过Matt并没有给出精确的云原生的定义,而是告诉我们云原生应用架构具有哪些特征,包括:”twelve factor app“、微服务、自服务敏捷架构、基于API写作等;接下来Matt告诉我们如果企业要接纳云原生架构,应该如何从文化、组织和技术等三个方面进行变革;最后的一个小章节则是迁移到云原生应用的实操mini手册。

随着kubernetes、容器进一步发展以及对应用的进一步赋能,人们对云原生应用的认识还在进一步深刻中,pivotal在官网上对cloud-native的概念做了进一步总结归纳,建议结合这本书一并学习一下。

img{512x368}
图:Pivotal对云原生概念进一步阐述

图书链接:
《迁移到云原生应用架构》中译版
《Migrating to Cloud-Native Application Architectures》


著名云主机服务厂商DigitalOcean于1月17日发布了其新的主机计划(New Droplet Plan),此次发布是对其原有主机计划的优化,其中入门级Droplet的内存容量从512M升级为1G,SSD磁盘空间从20G升级到25G,但价格不变,依旧是5$/月。如果你已经使用了DigitalOcean服务,可以到后台手动进行Resize以享受增容后的主机性能。如果您还没有使用DigitalOcean,可以去看看DO的vps plan是否满足你的需求。 链接地址:https://m.do.co/c/bff6eed92687

img{512x368}
图:New Plan的价格表


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

TB一周萃选[第5期]

本文是首发于个人微信公众号的文章“TB一周萃选[第5期]”的归档。

img{512x368}

人生十鉴

大喜易失言
大怒易失礼
大惊易失态
大哀易失颜
大乐易失察
大惧易失节
大思易失爱
大醉易失德
大话易失信
大欲易失命

下雪,是北方城市冬天的“常规操作”,是最不需要被单独关注的的事情。但今年冬天的“雪”却成为了这边的热门话题,原因:自从入冬以来一直就没下一场像样儿的雪!

雪的姗姗来迟让病毒细菌异常活跃,医院发热门诊尤其是儿科人满为患,笔者入冬后也是连续感冒了两次。好在2018年元旦后没几天,在三九天到来之前,大家期盼已久的“像样儿的雪”终于落了下来。

img{512x368}
图:小区里的初雪

2018年的这第一场雪注定是一场“瑞雪”,它不仅降低了空气的病毒浓度,提升了空气湿度,帮助人们有效抵御病毒入侵人体,而且让缺雪的北方城市瞬间焕发出那冬天独有的“魅力”。

很多事情看起来很难,但一旦捅破了那层窗户纸之后,也就感觉没那么难了。下雪这事儿似乎也是如此,在被第一场雪打了个“样儿”之后,一场场雪便接踵而至了。在笔者撰写本文的时候,窗外还飞舞着洁白的雪花。

一、一周文章精粹

1. Go“不足够好”文章大集合

就像世界上其他事物一样,编程语言也没有完美的,每一门编程语言都有优点,也有“不够好”的地方。Go诞生以来,虽然赞美之声此起彼伏,但对Go的“批评”之声也从未中断过。因此有人就整理了Go“不足够好”文章大集合,供Go设计者反思,供Gopher学习,以更好地、更深刻地理解Go这门语言。

文章链接:“Go is not good enough”

2. 好的Go代码库应该具备的“特征”

Go是一门简洁的编程语言,入门容易,上手快。但写出好的Go代码还是需要一番功夫的。国外的一名gopher总结了“一个好的Go代码库应该具备的特征”,文章中按照依赖、API、错误处理、并发、调试等几个方面列举了诸如:给库打语义版本标签(semantic versioning tag)、除了标准库之外没有第三方依赖、一旦有非标准库的第三方依赖如何应对、不用使用vendor、使用包依赖管理工具、最小化public functions、接收iterface返回struct、避免创建goroutine、避免在公共API中使用channel等特征,强烈推荐每一个gopher阅读学习。

文章链接:好的Go代码库应该具备的“特征”

3. Apollo 2.0发布

在2018 美国消费电子展CES上,百度发布了其无人车平台Apollo的2.0版本,该版本将平台之前宣布的四大模块全部开放,并支持了简单城市道路的自动驾驶。

文章链接:Apollo 2.0

这是我之前写过的一篇文章Apollo 1.0的入门,可以帮助你了解Apollo。

img{512x368}

4. 2018,微服务将结束疯狂

微服务近两年在容器和k8s的赋能下迅速发展,成为架构师口中的“时尚词汇”,每每涉及系统设计,就会首先问是否要做成微服务。一个新事物的出现和发展,有人唱好,自然就会有人看衰。这不,“2018,微服务将结束疯狂”这篇文章就是给“微服务”泼冷水降温的!文章从微服务架构对开发者、运维人员、devops的影响、需要专家级技能、真实世界系统边界模糊、状态复杂性、通信复杂性、版本管理、分布式事务等方面探讨了微服务的劣势,并给出了一个问题列表,建议大家在决定采用微服务之前,用这些问题问问自己,以避免陷入“微服务”泥潭中去。

文章链接:《The Death of microservice madness in 2018》

5. 2017 Google Brain Team的总结 by Jeff Dean

在人工智能的工程领域,Google大神Jeff Dean领导的Brain Team具有举足轻重的地位,也可以说是世界上最好的人工智能实践和研究团队之一了。在2018年伊始,Jeff Dean代表Google Brain Team撰文对团队在2017年的工作及成果进行了总结:包括AutoML、语言理解、机器学习算法、机器学习系统等核心研究工作,以及开源软件Tensorflow、数据集和新的机器学习硬件TPU等方面的最新进展。 对非人工智能领域而言,文章中满满的都是“黑科技”啊,能真正看懂文章中这些内容的朋友你一定也是人工智能领域的大牛了。

img{512x368}
图:Tensorflow用户分布

文章链接:
“2017 Google Brain Team的总结- part1″
“2017 Google Brain Team的总结- part2″
Part1 中文版

6. Javascript工作原理

Javascript诞生之后,估计没人想到过js能像今天这么流行:统治了前端,渗透到了后端,并成为后端服务开发的重要技术栈之一。Js语言也十分简单,但外延也很大,你要至少要深入理解浏览器原理才能更好地发挥JS的威力。sessionstack公司官方blog曾发表了几篇有关Javascript工作原理的文章,可以系统地帮助Javascript了解Js的运行机制。

img{512x368}

文章链接:
Javascript工作原理: 引擎、运行时与调用栈
Javascript工作原理: V8引擎和优化技巧
Javascript工作原理: 内存管理与避免内存泄露的技巧
Javascript工作原理: event loop与async编程

二、一周资料分享

1. 斯坦福大学面向Tensorflow深度学习研究课程

欧美一流大学在计算机技术方面的“与时俱进”的能力与速度真的是十分值得我们学习和借鉴的,尤其是斯坦福这样靠近硅谷的大学,其技术课程更新的速度非常快。Tensorflow于2015年末开源,2017年2月正式发布1.0版本。斯坦福大学在2017年就开了一门新课:“CS 20SI: Tensorflow for Deep Learning Research”,教授学生如何使用Tensorflow进行深度学习研究。

这门课程涵盖了用于深入学习研究的Tensorflow基本原理和使用用法。 目标是帮助学生们理解TensorFlow的graphical computational model,探索它提供的各种功能,并学习如何构建最适合深度学习项目的模型。 课程中学生将使用TensorFlow建立不同复杂度的模型,从简单的线性/逻辑回归到卷积神经网络和递归神经网络,解决词嵌入,单词翻译,光学字符识别,强化学习等任务。 学生还将学习到构建模型和研究实验管理的最佳实践。

资料链接:
CS 20SI: Tensorflow for Deep Learning Research 课程主页
CS 20SI: Tensorflow for Deep Learning Research 2017课程归档

三、一周工具推荐

1. stackedit

自从我的博客转到使用Markdown格式进行编辑后,我就一直使用stackedit提供的在线所见即所得的Markdown编辑器进行内容的编辑。最初的stackedit v4表现的还不强大,随着stackedit v5在线版本的推出,stackedit已经可以满足绝大多数Markdown编辑的功能需求了。

img{512x368}

  • 支持在线/离线管理多个markdown文件
  • 支持多种文件格式导出,包括HTML、PDF、WORD、EPUB
  • 支持文件的云同步,支持Google Drive, Dropbox等主流云存储系统
  • 支持将Markdown直接上传到Blogger/Blogspot, WordPress, Zendesk
  • 支持将Markdown直接发布到GitHub, Gist, Google Drive, Dropbox
    … …

更难得的是stackedit还是一个受关注度极高的开源项目(stars over 1w),你可以自己本地部署一个专用的stackedit。

工具链接:stackedit.io
工具开源项目链接:stackedit

四、一周图书推荐

1.《演讲模式:演讲的技巧与禁忌》

img{512x368}

技术人升级到一定level后,可能少不了要做些演讲、做些培训之类的活动。但对多数技术人而言,演讲这事并不是“舒适区”范围内。市面上有关介绍演讲技巧方面的书可谓是“汗牛充栋”,但这Neal Ford领衔编写的这本书《演讲模式》却独具特色。Neal Ford是Thoughtworks的大神,其他两位作者也是IT圈中的牛人。与其他作者相比,他们更熟悉IT技术人的思维方式,他们也以IT人独特的思维方式,创造性地将建筑和软件开发领域“模式”的概念引入演讲领域,围绕演讲的全过程总结了能迅速有效提升演讲技能的88个模式(应该掌握的技巧)和反模式(应该避免的不好的做法)。对于IT人而言,“模式”这词再熟悉不过了,因此这本书更像是IT技术人员间地手把手地传道解惑。

图书链接:
中文版:《演讲模式:演讲的技巧与禁忌》
英文版:《Presentation Patterns: Techniques for Crafting Better Presentations》


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

写Go代码时遇到的那些问题[第1期]

程序员步入“大龄”,写代码的节奏也会受到影响。以前是长时间持续地写,现在写代码的节奏变成了“波浪形”:即写一段时间,歇一段时间。当然这里的“歇”并不是真的歇,而是做其他事情了,比如:回顾、整理与总结。

平时写Go代码,时不时就遇到一些问题,或是写出一些让自己还算满意的代码,这里全部列为“问题”行列。这些“问题”(以及其解决方法)往往比较“小”、比较“碎片”,不适合以自己“擅长”的“长篇”风格写出来分享,也不知道以什么样的“题目”去分享更好,但这样的“问题”在日常又总是会遇到。考量来考量去,赶脚还是用一系列的文章去分享比较合适,即每隔一段时间,积累了一些问题后,就写一篇文章分享一下。

这是第一篇,后续不确定时间地(注意:这不是weekly的哦)发布新篇,直到没啥可写了或不写Go代码了^0^。

一、Go包管理

首当其冲的是Go包管理

1. vendor的“传染性”带来的问题

Go从1.5版本开始引入vendor机制以辅助Go的包管理。随着vendor机制的应用日益广泛,我们会发现:有些时候你要是不用vendor(在不借助第三方包管理工具的前提下),很多编译问题是解决不了的,或者说vendor机制有一定的传染性。比如下面这个例子:

img{512x368}

如上图所示:app_c包直接调用lib_a包中函数,并使用了lib_b包(v0.2版本)中的类型,lib_a包vendor了lib_b包(v0.1版本)。在这样的情况下,当我们编译app_c包时,是否会出现什么问题呢?我们一起来看一下这个例子:

在$GOPATH/src路径下面我们查看当前示例的目录结构:

$tree
├── app_c
    ├── c.go
├── lib_a
    ├── a.go
    └── vendor
        └── lib_b
            └── b.go
├── lib_b
    ├── b.go

各个源文件的示例代码如下:

//lib_a/a.go
package lib_a

import "lib_b"

func Foo(b lib_b.B) {
    b.Do()
}

//lib_a/vendor/lib_b/b.go

package lib_b

import "fmt"

type B struct {
}

func (*B) Do() {
    fmt.Println("lib_b version:v0.1")
}

// lib_b/b.go
package lib_b

import "fmt"

type B struct {
}

func (*B) Do() {
    fmt.Println("lib_b version:v0.2")
}

// app_c/c.go
package app_c

import (
    "lib_a"
    "lib_b"
)

func main() {
    var b lib_b.B
    lib_a.Foo(b)
}

进入app_c目录,执行编译命令:

$go build c.go
# command-line-arguments
./c.go:10:11: cannot use b (type "lib_b".B) as type "lib_a/vendor/lib_b".B in argument to lib_a.Foo

我们看到go compiler认为:app_c包main函数中定义的变量b的类型(lib_b.B)与lib_a.Foo的参数b的类型(lib_a/vendor/lib_b.B)是不同的类型,不能相互赋值

2. 通过手工vendor解决上述问题

这个例子非常有代表性,那么怎么解决这个问题呢?我们需要在app_c中也使用vendor机制,即将app_c所需的lib_a和lib_b都vendor到app_c中。

按照上述思路解决后的示例的目录结构:

$tree
├── app_c
    ├── c.go
    └── vendor
        ├── lib_a
        │   └── a.go
        └── lib_b
            └── b.go
├── lib_a
    ├── a.go
    └── vendor
        └── lib_b
            └── b.go
├── lib_b
    ├── b.go

不过要注意的是:app_c/vendor下面的库中的vendor目录要被删除掉的,我们只保留顶层vendor。现在我们再来编译c.go就可以顺利编译通过了。

3. 使用dep

对于demo或规模不大、依赖不多的小项目,手工进行vendor还是蛮有效的。一个可行的手工vendor步骤:

  • 在项目顶层创建vendor;
  • 通过go list -json ./…查看项目依赖 “deps”;
  • 逐一下载各个依赖,并确定要使用的版本(tag or branch),将特定版本cp到顶层的vendor目录下,至少要做到vendor所有直接依赖包;
  • 可以在顶层vendor下创建dependencies.list文件,手工记录vendor的依赖包列表以及版本信息。

但是对于稍大一点的项目,手工vendor就会费时费力,有时仅能顾及到“直接依赖包”的vendor,“数不清”的间接依赖/传递依赖会让你头疼不已。这个时候我们会想到使用第三方的包管理工具。在现在这个时间点,如果你再和我提godepglide等,那你就out了,dep是首选。

《初窥dep》一文中,我们对当时的dep进行了较为详细的工作机制分析,如今dep已经演化到0.3.2版本了,并且commandline交互接口已经稳定了。dep init默认采用network mode,即到各个依赖包的upstream上查找版本信息并下载;dep init也支持-gopath模式,即在本地$GOPATH下获取依赖包的元信息并分析。

不过,对于在国内的gopher,dep init的过程依然是一道很难逾越的“坎”。问题多出在:第三方包特别喜欢依赖的golang.org/x下的那些包,常见的包有:net、text、crypto等。golang.org/x/{package_name}仅仅是canonical import path,真正的代码存储在go.googlesource.com上,而在国内get这些包,我们会得到如下错误:

$go get -u golang.org/x/net
package golang.org/x/net: unrecognized import path "golang.org/x/net" (https fetch: Get https://golang.org/x/net?go-get=1: dial tcp 216.239.37.1:443: i/o timeout)

这将导致dep init命令长期阻塞,给国内gopher带来极为糟糕的体验。更为糟糕的是,即便是采用了一些fan qiang方式,有些时候go.googlesource.com依旧无法连接。因此,我一般的作法是在国外的主机上进行dep init,然后将vendor checkin到代码仓库中。这样其他人在得到你的代码后,也不需dep ensure(也要下载依赖包)即可实现reproducable build。

有些朋友可能会将从github.com/golang上下载的net包来代替golang.org/x/net,并使用dep init -v -gopath=true的模式。但这种替换会被dep分析出来,因为dep会尝试去读取代码库的元信息,结果依然会是失败。

二. 非容器化应用的本地日志管理

微服务、容器化大行其道的今天,单个应用的日志处理变得简单化了,应用只需要将要输出的信息输出到stdout、stderr上即可。logging基础设施会收集容器日志,并做后续归档、分析、过滤、查找、展示等处理。但是在非容器环境、在没有统一的logging基础设施的前提下,日志的管理就又交还给应用自身了。浅显的日志管理至少要包含日志的rotate(轮转)、压缩归档以及历史归档文件的处理吧。这里我们就来探讨一下这个问题的几种解决方法。

1. 托管给logrotate

在主流的Linux发行版上都有一个logrotate工具程序,应用程序可以借助该工具对应用输出的日志进行rotate、压缩、归档和删除历史归档日志,这样可大幅简化应用的日志输出逻辑,应用仅需要将日志输出到一个具名文件中即可,其余都交给logrotate处理。

我们建立一个输出log的demo app:

//testlogrotate.go

package main

import (
    "log"
    "os"
    "time"
)

func main() {
    file, err := os.OpenFile("./app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)
    if err != nil {
        log.Fatalln("Failed to open log file:", err)
    }
    defer file.Close()

    logger := log.New(file,
        "APP_LOG_PREFIX: ",
        log.Ldate|log.Ltime|log.Lshortfile)

    for {
        logger.Println("test log")
        time.Sleep(time.Second * 1)
    }
}

该程序每隔1s向app.log文件写入一行日志。

# tail -f app.log
APP_LOG_PREFIX: 2018/01/12 19:14:43 testlogrotate.go:22: test log
APP_LOG_PREFIX: 2018/01/12 19:14:44 testlogrotate.go:22: test log
APP_LOG_PREFIX: 2018/01/12 19:14:45 testlogrotate.go:22: test log
APP_LOG_PREFIX: 2018/01/12 19:14:46 testlogrotate.go:22: test log
APP_LOG_PREFIX: 2018/01/12 19:14:47 testlogrotate.go:22: test log
... ..

接下来,我们就要用logrotate对该app.log文件进行定期的rotate、压缩归档以及历史归档清理了,我们需要为app.log定制一个配置。logrotate读取配置的目录是/etc/logrotate.d,我们在/etc/logrotate.d下面建立applog文件(当然你也可以在任意其他目录下建立配置文件,不过其他目录下的配置文件无法被logrotate的cron任务感知到,不过这样的配置文件可以手工与logrotate程序结合使用),文件内容如下:

# cat /etc/logrotate.d/applog

/data/tonybai/test/go/app.log {
  rotate 7
  daily
  size=10M
  compress
  dateext
  missingok
  copytruncate
}

这个配置的大致含义是:
* 每天rotate一次
* 日志保留7天(rotate=7, daily rotate)
* 归档日志采用压缩形式
* 归档日志带有时间戳
* 当当前日志size > 10M时,会进行一次rotate
* 最重要的是copytruncate这个配置,这个配置的含义是将app.log当前日志copy到一个归档文件后,对app.log进行truncate操作,这样app.log的open file fd并不改变,不会影响到原app继续写日志。当然这个copy的过程中可能会有少量日志lost。

如果你觉得logrotate在时间粒度和精确度上依旧无法满足你的要求,你可以结合crontab自己定时执行logrotate(crontab -e编辑crontab的配置):

# logrotate -f /etc/logrotate.d/applog

下面是rotate时,tail -f中看到的情况:

APP_LOG_PREFIX: 2018/01/12 20:25:59 testlogrotate.go:21: test log
APP_LOG_PREFIX: 2018/01/12 20:26:00 testlogrotate.go:21: test log
tail: app.log: file truncated
APP_LOG_PREFIX: 2018/01/12 20:26:01 testlogrotate.go:21: test log
APP_LOG_PREFIX: 2018/01/12 20:26:02 testlogrotate.go:21: test log
APP_LOG_PREFIX: 2018/01/12 20:26:03 testlogrotate.go:21: test log

可以看到tail可以检测到file truncate事件。

2. 使用自带rotate功能log包

在go技术栈中众多的logging包中,logrus是使用较为广泛的一个包,支持与std库 log API兼容的结构化日志、支持logging level设置、支持安全地并发写日志以及hook等。但logrus自身并不具备auto rotate功能,需要结合其他工具才能实现。这里用nate finchlumberjack,我们来看一个简单的例子:

// testlogrusAndlumberjack.go

package main

import (
    "time"

    "github.com/natefinch/lumberjack"
    log "github.com/sirupsen/logrus"
)

func main() {
    logger := log.New()
    logger.SetLevel(log.DebugLevel)
    logger.Formatter = &log.JSONFormatter{}

    logger.Out = &lumberjack.Logger{
        Filename:   "./app.log",
        MaxSize:    1, // megabytes
        MaxBackups: 3,
        MaxAge:     1,    //days
        Compress:   true, // disabled by default
        LocalTime:  true,
    }

    for {
        logger.Debug("this is an app log")
        time.Sleep(2 * time.Millisecond)
    }
}

从代码里,我们看到:通过设置logger.Out为一个lumberjack.Logger的实例,将真正的Write交给了lumberjack.Logger,而后者实现了log的rotate功能,与logrotate的配置有些类似,这里也包括日志最大size设定、保留几个归档日志、是否压缩、最多保留几天的日志。不过当前lumberjack实现的rotate判断条件仅有一个:MaxSize,而没有定时rotate的功能。

我们执行一下该程序,等待一会,并停止程序。可以看到目录下的日志文件发生了变化:

$ls -lh
-rw-r--r--  1 tony  staff   3.7K Jan 12 21:03 app-2018-01-12T21-03-42.844.log.gz
-rw-r--r--  1 tony  staff   3.7K Jan 12 21:04 app-2018-01-12T21-04-15.017.log.gz
-rw-r--r--  1 tony  staff   457K Jan 12 21:04 app.log

lumberjack每发现app.log大于MaxSize就会rotate一次,这里已经有了两个归档压缩文件,并被lumberjack赋予了时间戳和序号,便于检索和查看。

3. 关于对日志level的支持以及loglevel的热更新

对日志level的支持是logging包选项的一个重要参考要素。logrus支持设置六个log level:

    PanicLevel
    FatalLevel
    ErrorLevel
    WarnLevel
    InfoLevel
    DebugLevel

并且对不同的leve的日志,logrus支持设定hook分别处理,比如:放到不同的日志文件中。通过logrus.Logger.SetLevel方法可以运行时更新logger实例的loglevel,这个特性可以让我们在生产环境上通过临时打开debuglevel日志对程序进行更细致的观察,以定位问题,快速定位bug,非常实用。

结合系统Signal机制,我们可以通过USR1和USR2两个signal来运行时调整程序的日志级别,我们来看一个示例:

img{512x368}

从上面图片可以看到,日志级别从高到低分别为:Panic, Fatal, Error, Warn,Info和Debug。如果要调高log level,我们向程序发送USR1来调高日志级别,相反,发送USR2来调低日志级别:

我们在testlogrusAndlumberjack.go上面做些修改:增加对signal: USR1和USR2的监听处理,同时循环打印各种级别日志,以后续验证日志级别的动态调整:

// testloglevelupdate.go

import (
    log "github.com/sirupsen/logrus"
    ... ...
)

func main() {
    logger := log.New()
    logger.SetLevel(log.DebugLevel)
    logger.Formatter = &log.JSONFormatter{}

    logger.Out = &lumberjack.Logger{
        Filename:   "./app.log",
        MaxSize:    1, // megabytes
        MaxBackups: 3,
        MaxAge:     1,    //days
        Compress:   true, // disabled by default
        LocalTime:  true,
    }

    c := make(chan os.Signal, 1)
    signal.Notify(c, syscall.SIGUSR1, syscall.SIGUSR2)
    go watchAndUpdateLoglevel(c, logger)

    for {
        logger.Debug("it is debug level log")
        logger.Info("it is info level log")
        logger.Warn("it is warning level log")
        logger.Error("it is warning level log")
        time.Sleep(5 * time.Second)
    }
}

watchAndUpdateLoglevel函数用于监听程序收到的系统信号,并根据信号类型调整日志级别:

// testloglevelupdate.go
func watchAndUpdateLoglevel(c chan os.Signal, logger *log.Logger) {
    for {
        select {
        case sig := <-c:
            if sig == syscall.SIGUSR1 {
                level := logger.Level
                if level == log.PanicLevel {
                    fmt.Println("Raise log level: It has been already the most top log level: panic level")
                } else {
                    logger.SetLevel(level - 1)
                    fmt.Println("Raise log level: the current level is", logger.Level)
                }

            } else if sig == syscall.SIGUSR2 {
                level := logger.Level
                if level == log.DebugLevel {
                    fmt.Println("Reduce log level: It has been already the lowest log level: debug level")
                } else {
                    logger.SetLevel(level + 1)
                    fmt.Println("Reduce log level: the current level is", logger.Level)
                }

            } else {
                fmt.Println("receive unknown signal:", sig)
            }
        }
    }
}

运行该程序后,你可以通过如下命令向程序发送信号:

$ kill -s USR1|USR2 程序的进程号

通过日志的输出,可以判断出日志级别调整是否生效,这里就不细说了。

不过这里还要提一点的是logrus目前对于输出的日志中双引号内的一些字符(比如双引号自身)会做转义处理,即在前面加上“反斜杠”,比如:

{"level":"debug","msg":"receive a msg: {\"id\":\"000002\",\"ip\":\"201.108.111.117\"}","time":"2018-01-11T20:42:31+08:00"}

这个问题让日志可读性大幅下降,但这个问题似乎尚处于无解状态

三. json marshal json string时的转义问题

之前写过这样一个function,用于统一marshal内部组件通信的应答消息:

func marshalResponse(code int, msg string, result interface{}) (string, error) {
    m := map[string]interface{}{
        "code":   0,
        "msg":    "ok",
        "result": result,
    }

    b, err := json.Marshal(&m)
    if err != nil {
        return "", err
    }

    return string(b), nil
}

不过当result类型为json string时,这个函数的输出带有转义反斜线:

//testmarshaljsonstring.go
... ...
func main() {
    s, err := marshalResponse(0, "ok", `{"name": "tony", "city": "shenyang"}`)
    if err != nil {
        fmt.Println("marshal response error:", err)
        return
    }
    fmt.Println(s)
}

运行这个程序输出:

{"code":0,"msg":"ok","result":"{\"name\": \"tony\", \"city\": \"shenyang\"}"}

怎么解决掉这个问题呢?json提供了一种RawMessage类型,本质上就是[]byte,我们将json string转换成RawMessage后再传给json.Marshal就可以解决掉这个问题了:

//testmarshaljsonstring.go
func marshalResponse1(code int, msg string, result interface{}) (string, error) {
    s, ok := result.(string)
    var m = map[string]interface{}{
        "code": 0,
        "msg":  "ok",
    }

    if ok {
        rawData := json.RawMessage(s)
        m["result"] = rawData
    } else {
        m["result"] = result
    }

    b, err := json.Marshal(&m)
    if err != nil {
        return "", err
    }

    return string(b), nil
}

func main() {
    s, err = marshalResponse1(0, "ok", `{"name": "tony", "city": "shenyang"}`)
    if err != nil {
        fmt.Println("marshal response1 error:", err)
        return
    }
    fmt.Println(s)
}

再运行这个程序的输出结果就变成了我们想要的结果了:

{"code":0,"msg":"ok","result":{"name":"tony","city":"shenyang"}}

四. 如何在main包之外使用flag.Parse后的命令行flag变量

我们在使用Go开发交互界面不是很复杂的command-line应用时,一般都会使用std中的flag包进行命令行flag解析,并在main包中校验和使用flag.Parse后的flag变量。常见的套路是这样的:

//testflag1.go
package main

import (
    "flag"
    "fmt"
)

var (
    endpoints string
    user      string
    password  string
)

func init() {
    flag.StringVar(&endpoints, "endpoints", "127.0.0.1:2379", "comma-separated list of etcdv3 endpoints")
    flag.StringVar(&user, "user", "", "etcdv3 client user")
    flag.StringVar(&password, "password", "", "etcdv3 client password")
}

func usage() {
    fmt.Println("flagdemo-app is a daemon application which provides xxx service.\n")
    fmt.Println("Usage of flagdemo-app:\n")
    fmt.Println("\t flagdemo-app [options]\n")
    fmt.Println("The options are:\n")

    flag.PrintDefaults()
}

func main() {
    flag.Usage = usage
    flag.Parse()

   // ... ...
   // 这里我们可以使用endpoints、user、password等flag变量了
}

在这样的一个套路中,我们可以在main包中直接使用flag.Parse后的flag变量了。但有些时候,我们需要在main包之外使用这些flag vars(比如这里的:endpoints、user、password),怎么做呢,有几种方法,我们逐一来看看。

1. 全局变量法

我想大部分gopher第一个想法就是使用全局变量,即建立一个config包,包中定义全局变量,并在main中将这些全局变量绑定到flag的Parse中:

$tree globalvars
globalvars
├── config
│   └── config.go
├── etcd
│   └── etcd.go
└── main.go

// flag-demo/globalvars/config/config.go

package config

var (
    Endpoints string
    User      string
    Password  string
)

// flag-demo/globalvars/etcd/etcd.go
package etcd

import (
    "fmt"

    "../config"
)

func EtcdProxy() {
    fmt.Println(config.Endpoints, config.User, config.Password)
    //... ....
}

// flag-demo/globalvars/main.go
package main

import (
    "flag"
    "fmt"
    "time"

    "./config"
    "./etcd"
)

func init() {
    flag.StringVar(&config.Endpoints, "endpoints", "127.0.0.1:2379", "comma-separated list of etcdv3 endpoints")
    flag.StringVar(&config.User, "user", "", "etcdv3 client user")
    flag.StringVar(&config.Password, "password", "", "etcdv3 client password")
}

.... ...

func main() {
    flag.Usage = usage
    flag.Parse()

    go etcd.EtcdProxy()

    time.Sleep(5 * time.Second)
}

可以看到,我们在绑定cmdline flag时使用的是config包中定义的全局变量。并且在另外一个etcd包中,使用了这些变量。

我们运行这个程序:

./main -endpoints 192.168.10.69:2379,10.10.12.36:2378 -user tonybai -password xyz123
192.168.10.69:2379,10.10.12.36:2378 tonybai xyz123

不过这种方法要注意这些全局变量值在Go包初始化过程的顺序,比如:如果在etcd包的init函数中使用这些全局变量,那么你得到的各个变量值将为空值,因为etcd包的init函数在main.init和main.main之前执行,这个时候绑定和Parse都还未执行。

2. 传参法

第二种比较直接的想法就是将Parse后的flag变量以参数的形式、以某种init的方式传给其他要使用这些变量的包。

$tree parampass
parampass
├── etcd
│   └── etcd.go
└── main.go

// flag-demo/parampass/etcd/etcd.go
package etcd
... ...

func EtcdProxy(endpoints, user, password string) {
    fmt.Println(endpoints, user, password)
}

// flag-demo/parampass/main.go
package main

import (
    "flag"
    "fmt"
    "time"

    "./etcd"
)

var (
    endpoints string
    user      string
    password  string
)

func init() {
    flag.StringVar(&endpoints, "endpoints", "127.0.0.1:2379", "comma-separated list of etcdv3 endpoints")
    flag.StringVar(&user, "user", "", "etcdv3 client user")
    flag.StringVar(&password, "password", "", "etcdv3 client password")
}

... ...

func main() {
    flag.Usage = usage
    flag.Parse()

    go etcd.EtcdProxy(endpoints, user, password)

    time.Sleep(5 * time.Second)
}

这种方法非常直观,这里就不解释了。但注意:一旦使用这种方式,一定需要在main包与另外的包之间建立某种依赖关系,至少main包会import那些使用flag变量的包。

3. 配置中心法

全局变量法直观,而且一定程度上解除了其他包与main包的耦合。但是有一个问题,那就是一旦flag变量发生增减,config包就得相应添加或删除变量定义。是否有一种方案可以在flag变量发生变化时,config包不受影响呢?我们可以用配置中心法。所谓的配置中心法,就是实现一个与flag变量类型和值无关的通过配置存储结构,我们在main包中向该结构注入parse后的flag变量,在其他需要flag变量的包中,我们使用该结构得到flag变量的值。

$tree configcenter
configcenter
├── config
│   └── config.go
└── main.go

//flag-demo/configcenter/config/config.go
package config

import (
    "log"
    "sync"
)

var (
    m  map[string]interface{}
    mu sync.RWMutex
)

func init() {
    m = make(map[string]interface{}, 10)
}

func SetString(k, v string) {
    mu.Lock()
    m[k] = v
    mu.Unlock()
}

func SetInt(k string, i int) {
    mu.Lock()
    m[k] = i
    mu.Unlock()
}

func GetString(key string) string {
    mu.RLock()
    defer mu.RUnlock()
    v, ok := m[key]
    if !ok {
        return ""
    }
    return v.(string)
}

func GetInt(key string) int {
    mu.RLock()
    defer mu.RUnlock()
    v, ok := m[key]
    if !ok {
        return 0
    }
    return v.(int)
}

func Dump() {
    log.Println(m)
}

// flag-demo/configcenter/main.go

package main

import (
    "flag"
    "fmt"
    "time"

    "./config"
)

var (
    endpoints string
    user      string
    password  string
)

func init() {
    flag.StringVar(&endpoints, "endpoints", "127.0.0.1:2379", "comma-separated list of etcdv3 endpoints")
    flag.StringVar(&user, "user", "", "etcdv3 client user")
    flag.StringVar(&password, "password", "", "etcdv3 client password")
}
... ...
func main() {
    flag.Usage = usage
    flag.Parse()

    // inject flag vars to config center
    config.SetString("endpoints", endpoints)
    config.SetString("user", user)
    config.SetString("password", password)

    time.Sleep(5 * time.Second)
}

我们在main中使用config的SetString将flag vars注入配置中心。之后,我们在其他包中就可以使用:GetString、GetInt获取这些变量值了,这里就不举例了。

4、“黑魔法”: flag.Lookup

flag包中提供了一种类似上述的”配置中心”的机制,但这种机制不需要我们显示注入“flag vars”了,我们只需按照flag提供的方法在其他package中读取对应flag变量的值即可。

$tree flaglookup
flaglookup
├── etcd
│   └── etcd.go
└── main.go

// flag-demo/flaglookup/main.go
package main

import (
    "flag"
    "fmt"
    "time"

    "./etcd"
)

var (
    endpoints string
    user      string
    password  string
)

func init() {
    flag.StringVar(&endpoints, "endpoints", "127.0.0.1:2379", "comma-separated list of etcdv3 endpoints")
    flag.StringVar(&user, "user", "", "etcdv3 client user")
    flag.StringVar(&password, "password", "", "etcdv3 client password")
}

......

func main() {
    flag.Usage = usage
    flag.Parse()

    go etcd.EtcdProxy()

    time.Sleep(5 * time.Second)
}

// flag-demo/flaglookup/etcd/etcd.go
package etcd

import (
    "flag"
    "fmt"
)

func EtcdProxy() {
    endpoints := flag.Lookup("endpoints").Value.(flag.Getter).Get().(string)
    user := flag.Lookup("user").Value.(flag.Getter).Get().(string)
    password := flag.Lookup("password").Value.(flag.Getter).Get().(string)

    fmt.Println(endpoints, user, password)
}

运行该程序:

$go run main.go -endpoints 192.168.10.69:2379,10.10.12.36:2378 -user tonybai -password xyz123
192.168.10.69:2379,10.10.12.36:2378 tonybai xyz123

输出与我们的预期是一致的。

5、对比

我们用一幅图来对上述几种方法进行对比:

img{512x368}

很显然,经过简单包装后,“黑魔法”flaglookup应该是比较优异的方案。main包、other packages只需import flag即可。

注意:在main包中定义exported的全局flag变量并被其他package import的方法是错误的,很容易造成import cycle问题。并且任何其他package import main包都是不合理的

五. 小结

以上是这段时间遇到的、收集的一些Go问题以及solution。注意:这些solution不一定是最优方案哦!如果您有更好方案,欢迎批评指正和互动交流

本文章中涉及到的所有源码和配置文件在这里可以下载到。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

微信赞赏:
img{512x368}

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

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




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

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

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


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

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多