标签 Linux 下的文章

究竟是什么让Go语言成为恶意软件作者的最爱

2020年5月份,Go语言之父Rob Pike接受了evrone.com的专访。当Rob Pike老爷子被问及多年来他看到过最奇怪、最有创意或有趣的Go用法或最让他惊讶的是什么时,老爷子是这么回答的:

Rob:最大的惊喜是当我们得知Go被用于编写恶意软件时。您无法控制谁将使用您的作品或他们将如何使用它。

近期安全技术公司Intezer发布了一份名为《Year of the Gopher, A 2020 Go Malware Round-Up》的报告,该报告称在过去几年中,安全人员发现的用Go编写的新恶意软件几乎增加了2000%,这一标题迅速引爆程序员社区,有人唾弃Go踏入“歧途”,也有人膜拜Go的niubility:能被黑客看中和使用的都是精华!

那么究竟是什么让黑客们这么青睐Go并用之去编写恶意软件呢?估计但那份几十页的报告没几个人会完整的读一遍,本文我们就结合报告的内容(分类、整理、摘录)做一些探究。

1. Go语言的简介

报告首先简单介绍了Go的前世今生

Go是一种开源的编程语言,由Robert Griesemer、Rob Pike和Ken Thompson于2007年在Google开发。它于2009年11月向公众发布。开发新语言的动机来自于使用当前编程语言(当时三巨头都是用C++)的挫折感。由于CPU不再通过增加时钟周期的数量来提高速度。相反,更多的速度开始通过添加更多的CPU核并允许更多的并行执行来获得。这种硬件上的进化并没有很好地反映在通用编程语言中。虽然C、C++和Java等语言提供了在多核上并行执行事务的功能,但它们为程序员提供的帮助却很少,无法高效、安全地完成这项工作。

Google的程序员们于是开始设计一种新的编程语言,为方便和安全的使用并发或并行提供“原生/一等公民地位”的支持。另一个目标则是要将解释型语言的编程便利性与静态类型和编译型语言的效率和安全性结合起来。另外在设计时,Google是将其用于Google基础设施运行的一部分网络服务中,因此对网络的支持也很重要。

为了提供在解释语言中编程的感觉,Go使用垃圾收集并处理所有的内存管理。所有的Go二进制文件都包含一个称为运行时的通用库,这导致Go二进制文件的大小比用C语言编写的类似的静态链接的程序要大。该库负责处理垃圾收集、执行线程的调度以及该语言的所有其他关键功能。虽然它被称为运行时,但比起Java运行时,它更像C语言的libc,它已经与二进制文件进行了静态编译。Go二进制文件被编译成本地机器代码,但也可以被编译成以JavaScript为运行时的WebAssembly。

Go 1.4版本及更早版本的编译器是用C语言实现的,但随着2015年1.5版本的发布,编译器完全用Go语言编写,并实现了自举。转为自举编译器后,给用户在交叉编译方面的体验带来了巨大的改善。之前使用基于C语言的编译器时,需要在编译代码的机器上安装一个针对目标操作系统和架构的C编译器。和针对不同目标的C代码进行交叉编译时的方式非常相似。从1.5版本开始,只需要向编译器指明它的编译目标架构,就可以实现对不同操作系统和架构的交叉编译。不需要针对目标的特殊编译器。Go可以通过不依赖主机上的库来执行例如syscalls(系统调用)。本来由libc提供的功能由Go的标准库提供和处理。这种方便的交叉编译有一个限制,那就是当Go程序需要通过其外函数接口(FFI)与C语言编写的库进行交互时。

新的功能和解决方案使得程序员在新项目中采用Go。2016年,TIOBE授予Go“年度最佳编程语言”,这是一个授予评分上升幅度最高的语言的奖项。随着软件开发者因其功能而开始采用Go,恶意软件作者也开始采用Go也就不足为奇了。

人们注意到使用Go开发的恶意软件增多是从2019年Palo Alto Networks公司发布的一份分析报告开始的。2019年7月,Palo Alto Networks公司的Unit 42发布了对当时发现的用Go编写的恶意软件的分析报告。研究发现,2017年至2019年期间,人们发现的Go恶意软件样本增加 了1944%,这量化了一个很容易发现的趋势。在2019年之前,发现用Go编写的恶意软件更多的是一种罕见的现象,而在2019年期间,这成为了一种日常现象。报告中分析的恶意软件中,大部分,92%的恶意软件针对Windows,而4.5%针对Linux,3.5%针对macOS。
人们观察到的另一点是,渗透测试(pen-testing)团队采用Go来开发他们的工具,这在Unit 42的研究中很突出。

最常见的恶意软件家族类型是开源或渗透测试后门。其次是coinminer(挖矿)、窃取者和僵尸网络。这篇报告涵盖了2020年期间活跃的用Go编写的已知恶意软件的活动。

2. 使用Go的嵌入文件功能实现恶意加载器

与其他语言产生的二进制文件相比,Go编译器产生的二进制文件相对较大。例如,一个Hello World二进制文件有1700多个函数。由于二进制文件中有这么多的常用代码,因此在寻找可疑代码时就像大海捞针一样。这可能是为什么恶意Go二进制文件有时不被 反病毒引擎检测到的原因之一。这导致一些威胁行为者在Go中开发加载器,并利用它们来提供其他较老的、易被检测到的恶意软件。这种技术可以降低被检出率,甚至有时会使恶意软件完全无法被检测到。在Go二进制文件中嵌入其他二进制文件相对容易。有很多开源库已经解决了这个问题。下面是其中的一些列表:

  • https://github.com/gobuffalo/packr
  • https://github.com/rakyll/statik
  • https://github.com/GeertJohan/go.rice
  • https://github.com/UnnoTed/fileb0x
  • https://github.com/mjibson/esc
  • https://github.com/kevinburke/go-bindata
  • https://github.com/lu4p/binclude
  • https://github.com/omeid/go-resources
  • https://github.com/pyros2097/go-embed
  • https://github.com/wlbr/mule
  • https://github.com/miscing/embed
  • https://github.com/kyioptr/gassets

上述包的大部分的设计都是为了允许嵌入网络服务的静态资源文件(asset),但使用案例并不限于此。嵌入文件的功能受到了广泛的好评,以至于今年2020年早些时候有人建议将该功能直接添加到Go编译器中。该建议已被接受,并已与2021年2月发布的Go 1.16版本一起发布了。从这个角度来看,Go 1.16版本加入嵌入文件功能,颇有些“助纣为虐”之嫌^_^。

3. 使用Go标准库强大的加密库和便捷的跨主机交叉编译特性实现恶意加密器和勒索软件

Go的标准库提供了一套非常强大的加密库,允许开发者在不需要使用任何第三方库的情况下,在应用中加入加密功能。

一个开源的加密加载器是Go shellcode LoaDer。它用AES对有效载荷进行加密。它对有效载荷进行解密,并在执行之前使用ZwProtectVirtualMemory将解密缓冲区标记为读取/执行。

我们还观察到威胁行为者编写自己的加密器和加载器。例如,我们看到一个名为gocrypter的加载器被用于加密商品恶意软件;大多数是RAT(Remote Access Trojans,远程访问木马)和键盘记录器。有效载荷已经用AES加密,并作为base64编码的blob存储在二进制内部。加密器将其解码成字节,并在写入磁盘和执行之前进行解密。

在2020年仍有一些活动的勒索软件,比如:RobbinHood。RobbinHood在2019年春季被发现,当巴尔的摩市被发现受到该勒索软件攻击时,得到了很多媒体的关注。Sophos在2月份发布了一份报告,详细介绍了该威胁行为者的一些演变过程。通过利用技嘉公司的一个脆弱的驱动程序,威胁行为者开始加载一个未签名的驱动程序。一旦驱动程序被加载,它将杀死进程和篡改保护软件,以确保勒索软件可以在不被中断的情况下加密硬盘驱动器的其余部分。但在2020年11月,仍有新的样本被发现,但勒索说明没有改变。11月的一个样本的PDB字符串为C:/Users/User/go/src/Robbinhood7,这表明根据恶意软件作者的说法,它可能是第7个版本的勒索软件。

另一个用Go编写的、仍然活跃的老牌勒索软件是Snatch。Snatch是在2018年12月被发现的,到现在似乎还在使用。该勒索软件由Snatch Team使用,他们通过远程访问服务(例如RDP)瞄准企业环境。一旦进入网络,该组织就会尝试在所有机器上部署勒索软件, 并对文件进行加密。该勒索软件在加密文件时有一个有趣的技术,该技术在2019年10月被引入到勒索软件中。该勒索软件将自己安装为一项服务,即使Windows启动到安全模式,也可以启动。在此之后,勒索软件将Windows重新启动到安全模式,允许它加密硬盘上的所有文件,而不会被安装的任何潜在的安全保护软件阻止。

Nefilim是一款勒索软件,最早出现在2020年3月。它是另一款名为Nemty的勒索软件的前身。最初的版本是用C++编写的,但在7月,该恶意软件用Go重新编写。除了加密受害者机器上的文件外,Nefilim背后的威胁行为者还窃取受害者的数据,并用于勒索。

由于Go提供了一种针对不同架构和操作系统交叉编译二进do制文件的简单方法,因此它被用于RaaS(Ransomware as a Service)勒索软件并不奇怪。它允许威胁行为者使用单一的代码库,以极低的工作量制作针对不同操作系统的二进制文件。Go已经被用于RaaS。在2020年的春天,一个新的RaaS被宣布,名为Smaug。Smaug是一个相对简单的勒索软件,但它为Windows、Linux和macOS提供”用户”的勒索软件服务。它可以在”企业”模式下运行,即所有机器使用一个密钥,或者每台机器模式下使用一个密钥。

Go可以为其他操作系统和架构制作二进制文件,这使得威胁行为者可以轻松地针对不同类型的设备,例如,嵌入式系统。在2019年夏天,我们发现了QNAPCrypt,也就是eCh0raix,这是一款针对QNAP NAS设备的勒索软件。后来,它还被用来针对Synology NAS设备。2020年,又发现了一款针对QNAP设备的新勒索软件。新的勒索软件被称为AgeLocker,因为它使用了开源的加密工具和库age

在2020年期间发现的其他用Go编写的勒索软件包括。1月发现的Betasup,2月发现的Sorena也就是HackForLife和Vash,3月发现的GoGoogle。

4. 使用Go优秀的网络协议栈实现开发RAT(远程访问木马)、恶意偷窃程序、恶意机器人和僵尸网络

Go的网络协议栈写得非常好,易于操作。Go已经成为云计算的编程语言之一,很多云原生应用都是用它编写的。例如,Docker、Kubernetes、InfluxDB、Traefik、Terraform、CockroachDB、Prometheus和Consul都是用Go编写的。这是有道理的,因为创建Go背后的原因之一正是要发明一种更好的语言,可以用来取代Google内部使用的C++网络服务。因此远程访问木马(RAT)是用Go编写的,这并不奇怪。毕竟,它们非常需要优良的网络服务功能。

在这一年中,既有新的RAT出现,也有老的RAT不断被使用。早在2020年8月,我们发现了一个Linux版本的Carbanak威胁行为体使用的后门。该样本使用2017年2月发布的Go 1.8版本编译器进行编译。同样的编译器版本和构建环境被用于2017年RSA报告的一部分的初始Windows样本。

Glupteba是一个自2011年以来一直存在的恶意软件,但在2019年9月,发现了一个用Go改写的新版本。在整个2020年,这个新版本出现的更为频繁。该恶意软件在感染机器时,会尝试安装一个root-kit。为了绕过Windows中防止安装内核驱动程序的保护措施,恶意软件利用了一个脆弱的VirtualBox驱动程序。恶意软件会安装该驱动程序,由于该驱动程序是经过签名的,所以Windows会允许安装,并使用它在Ring-0中执行代码,以禁用Kernel Patch Protection(KPP)。这种技术并不新鲜,它最早被APT组织Turla使用。除此之外,该恶意软件还试图通过利用EternalBlue在本地网络内进行传播。

Windows并不是唯一一个被用Go编写的RAT攻击的操作系统。2020年10月,Bitdefender发布了一个针对Linux的新RAT的发现。Bitdefender的研究人员认为,它可能与2019年的PowerGhost活动有关。该威胁行为体针对的是易受CVE-2019-2725影响的WebLogic服务器。该RAT似乎被作者命名为NiuB。该恶意软件由两个二进制文件组成,即主恶意软件和一个防护恶意软件。该恶意软件收集受感染机器的信息,并将其发送到C2服务器。它可以执行shell命令,下载并执行其他二进制文件。

2020年1月,FireEye发布了一份针对NetScaler设备的攻击报告。攻击是利用CVE-2019-19781漏洞。作为攻击的一部分,威胁行为者使用了一种新的恶意软件,以前从未见过。FireEye将该恶意软件命名为NOTROBIN。它是用Go编写的,并被编译成在*BSD上运行,这是NetScaler使用的底层操作系统。一个有趣的功能是,该恶意软件通过扫描新的NetScaler模板文件并将其删除来阻止其他恶意软件利用相同的漏洞,这些文件可能是作为利用尝试的一部分添加的。它在18634端口上打开一个UDP监听器,但忽略发送到它的数据。它基本上充当了一个mutex,以确保受感染的机器上只运行一个恶意软件的副本。

已经有一些用Go编写的窃取器。在2019年,Malwarebytes报告了一个名为CryptoStealer.Go的窃取器。它旨在窃取加密货币钱包和 存储在浏览器中的数据,如信用卡信息。

同样在2020年期间,发现了一个用Go编写的剪贴板窃取器。它似乎自2019年以来一直活跃。根据上传到VirusTotal的样本的文件名 ,该窃取器被伪装成黑客工具,表明它被用来针对其他威胁行为者。该恶意软件的设计很简单。它将自己安装在App/DataLocal/Support下,并隐藏文件或文件夹。它读取剪贴板并检查它是否看起来像加密货币地址。如果是,恶意软件就会用攻击者自己的比特币、莱特币、Monero或Ethereum钱包替换剪贴板内容。

该恶意软件中的比特币钱包地址自2018年秋季以来一直处于活跃状态。截至本文撰写时,它已经收到了534笔交易,价值近11BTC。

随着Go作为标准库的一部分支持许多网络协议,以及为不同架构编译二进制文件的便利性,越来越多的机器人用Go编写也就不足为奇了。另外,二进制文件包含了正常运行所需的一切,这也为代码作者提供了更多的保证,例如,它可以在不同的Linux发行版上运行。它不用担心机器上是否已经安装了库。因为它需要什么,就自带什么。还有很多第三方库,提供了访问其他服务的功能。

比如这里列出了一些机器人库,可以用来开发不同服务的机器人。

  • https://github.com/go-joe/joe
  • https://github.com/bot-api/telegram
  • https://github.com/shomali11/slacker
  • https://github.com/go-chat-bot/bot
  • https://github.com/frodsan/fbot
  • https://github.com/go-telegram-bot-api/telegram-bot-api
  • https://github.com/tucnak/telebot

随着开源机器人库的出现,它们被恶意软件作者滥用的情况并不少见。IRCFlu就是一个例子。IRCFlu是一个托管在GitHub上的IRC机器人。该机器人提供了在托管机器人的机器上执行任意代码的功能,这使得威胁行为者可以利用这个机器人远程控制多台受感染的机器。

除了开源项目被滥用外,2020年还出现了老牌知名僵尸网络的攻击行为。被称为ddg的僵尸网络是由Netlab在360首次报道的。他们在2017年10月检测到该僵尸网络对托管OrientDB的服务器的攻击。该僵尸网络的目标是安装Monero矿机。2020年,该僵尸网络进行了更新,通过增加一个p2p网络支持的C2基础设施,使其更有弹性地抵御击杀。混合的p2p网络基础设施允许威胁行为者在正常的C2服务器瘫痪时保持对机器人的控制。

另一个仍然活跃的老僵尸网络是StealthWorker,也被称为GoBrut。StealthWorker是Malwarebytes在2019年2月首次报道的。它是一个以Stealth Bomber为名在暗网论坛上销售的僵尸,用于通过凭证式蛮力攻击获得网络服务的访问权限。

僵尸网络r2r2是另一个通过蛮横强迫凭证传播的僵尸。它最早是在2018年被发现的。它随机生成IP地址,并试图通过弱凭证访问运行SSH的服务。一旦它获得了一个立足点,它就会在机器上安装一个密码器。该僵尸的功能非常有限,它由不到200百行的代码组成。

其他僵尸网络也在不断进化,以增加其潜在的目标。在2020年,Orthrus,也被称为Golang,演变为也针对Windows服务器。该僵尸是Antiy在2019年6月首次报道的。它主要针对未受保护或凭证薄弱的Redis服务器。一旦它获得远程代码执行,它就会安装一套二进制文件。一个是针对其他易受攻击服务的扫描器,一个看门狗服务和一个密码器。扫描器试图破坏其他有已知漏洞的网络服务。例如,Weblogic,Elasticsearch和Drupal是目标。在2020年,该恶意软件还增加了针对微软SQL服务器的目标。它试图通过强行获取凭证来获得访问权。该恶意软件包括一个近3000个密码的列表,它只针对SQL服务器使用。

12月,我们发现了另一个跨操作系统的挖掘机器人,我们称之为XMRig Miner Dropper。它的目标是运行MySQL、Tomcat和Jenkins的服务器以及凭证较弱或脆弱的WebLogic。根据底层操作系统的不同,该机器人提供了一个用于执行shell脚本或PowerShell脚本的有效载荷。一旦它入侵机器,它就会安装一个密码器,并试图利用其他服务器。

2016年9月,Mirai的源代码被发布。这导致许多新的僵尸网络从Mirai源代码中衍生出来。虽然该僵尸代码是用C++编写的,但该代码的发布为其他恶意软件作者用不同语言编写类似的僵尸提供了蓝本。2020年1月,Bitdefender发布了一份报告,介绍了一个用Go编写的受Mirai启发的新僵尸网络,他们将其命名为LiquorBot。该僵尸网络本质上是Mirai在Go中的重新实现,目标是运行在ARM(32位和64位)、x86(32位和64位)和MIPS上的Linux设备。该僵尸通过强行获取SSH证书和利用路由器的已知漏洞进行传播。一旦它获得了设备的访问权限,它就会试图感染其他人,并且还安装了一个Monero密码器。

LiquorBot并不是唯一受Mirai启发的僵尸网络。4月,我们发现了Kaiji,这是一个通过SSH蛮横强迫来针对Linux服务器和物联网设备的僵尸网络。除了强行插入薄弱的凭证外,该僵尸还试图使用在受感染机器上发现的本地SSH密钥来传播到企业内的其他机器。与Mirai类似,Kaiji允许僵尸管理员对他们选择的任何基础设施发起DDoS攻击。攻击包括两个TCPFlood实现(一个带有原始套接字)、两个UDPFlood实现(一个带有原始套接字)、IPSpoof攻击、SYNACK攻击、SYN攻击和ACK攻击。

2020年6月,Kaiji将其目标方法扩大到包括暴露API套接字的服务器。该恶意软件开始在互联网上扫描端口2375暴露的主机。如果它找到了一个,它会尝试部署一个流氓Docker容器,并在容器中执行Kaiji。

Kaiji不是唯一一个针对暴露的Docker API的僵尸网络。2020年11月,NetLab 360报告发现了一种名为Blackrota的新恶意软件。Kinsing,也被称为h2Miner,已经被称为针对Docker API。2020年1月,阿里巴巴云的研究人员首次报道了Kinsing。该僵尸网络正在使用masscan寻找暴露Hadoop Yarn、Redis和Docker的机器。当它发现一台运行这些服务的服务器时,它会试图利用服务中的已知漏洞来进一步传播自己。5月,我们观察到Kinsing利用SaltStack的两个漏洞CVE-2020-11651和CVE-2020-11652进行传播。该恶意软件还开始使用LD-PRELOAD用户地rootkit来隐藏其进程。

SSH brute-force已经成为用Go编写的僵尸网络采用的主要攻击方式之一。我们发现了IPStorm的一个新的Linux变种,其中包括这种攻击向量。IPStorm是一个点对点(p2p)僵尸网络,于2019年5月首次被发现。它使用开源项目IPFS作为其网络骨干。除了原始的Windows变体,我们还发现了作为Linux变体的一部分,针对Android和物联网设备的变体。与本报告中的其他僵尸网络不同,IPStorm的目标不是安装矿机。相反,该僵尸网络似乎提供了一个代理网络。这个代理网络是作为互联网上的匿名代理网络出售的。

IPStorm不是唯一一个在2020年活跃的Go编写的p2p网络。2020年8月,Guardicore发布了一份关于他们从同年1月开始追踪的一个新的p2p僵尸网络的报告。该僵尸网络被命名为FritzFrog,通过强行使用弱小的凭证来感染机器。Guardicore称,该僵尸网络已经成功入侵了超过500台服务器,其中包括 “美国和欧洲的知名高教机构,以及一家铁路公司”。

5. 未来预测与结论

虽然与用其他语言编写的恶意软件相比,用Go编写的恶意软件数量相对较少,但同比增长幅度很大。这种增长速度很可能会继续下去,这意味着用Go编写的恶意软件将变得更加频繁。对于针对Linux环境的恶意软件来说,用Go编写的部分比针对Windows的恶意软件要大。这很可能导致,在根据针对特定系统的恶意软件总量统计中,针对Linux系统的恶意软件的比例将可能变得最大。

在目前用Go编写的Linux恶意软件中,有很大一部分是用于DDoS或安装密码器的机器人。这种趋势可能会持续下去。其他类型也可能会变得更加频繁。我们已经看到了针对Linux系统的Go勒索软件,而且有可能会出现更多的以窃取和加密有价值数据为目标的勒索软件。这与Proofpoint对2021年的预测一致,即勒索软件威胁行为者将开始更加关注攻击云端。这意味着企业应该采用专注于云的检测和预防产品,以确保他们的云环境受到保护。许多传统的防病毒和保护解决方案都是为了保护Windows环境而设计的,而Linux环境则更多地成为了”二等公民”。

根据CrowdStrike从2020年开始的事件报告,在40%的事件中,恶意软件没有被反病毒产品检测到。除此之外,Go恶意软件一直很难被反病毒产品检测到,所以这种趋势很可能会继续下去。我们已经看到威胁行为者以相同的恶意软件代码库为中心,针对不同的操作系统进行攻击,导致恶意软件样本较少或未被检测到。由于恶意软件来自相同的代码库,因此使用代码基因的检测方法非常有效。未来我们很可能会看到更多针对多个操作系统的恶意软件,因为像Go这样的编程语言为恶意软件作者提供了一种简单的交叉编译恶意软件的方法。

在Windows方面,许多威胁行为者已经使用Go来制作勒索软件。未来这种趋势很可能会继续下去。随着更多RaaS产品的出现,用Go编写勒索软件也不是不可能。由于能够轻松地进行交叉编译,RaaS运营商可以为他们的”客户”提供更广泛的目标。

Go是一种开源的编程语言,它是在Google内部开发的,目的是利用过去几十年在硬件上取得的进步。它的设计是为了让开发者能够轻松地制作快速、安全、以网络为中心的代码,并在当今的多核CPU上获益。这使得该语言得到了极大的应用,尤其是在云环境中。开发者并不是唯一采用Go的人。Go强大的跨平台交叉编译、优秀的网络实现和加密库以及原生的文件嵌入功能让其颇受恶意软件开发者的青睐! 在过去几年中,在市面上发现的用Go编写的新恶意软件几乎增加了2000%。这些恶意软件中有许多是针对Linux和物联网设备的僵尸网络,以安装加密矿机或将受感染的机器注册到DDoS僵尸网络中。此外,用Go编写的勒索软件似乎也变得更加普遍。一些用Go编写的著名勒索软件是Nefilim、EKANS和RobbinHood,这些勒索软件用于所谓的大型猎物攻击。

传统的反病毒解决方案似乎仍然难以检测到用Go编写的恶意软件。较新的技术不仅可以根据代码重用来判断恶意,还可以对威胁进行分类,已经取得了较大的成功,因为它们甚至可以处理Linux和Windows二进制文件之间的相似性。虽然用Go编写的恶意软件可能仍处于初级阶段,但它可能很快就会进入青春期,从而导致大量增加。


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

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!目前该技术专栏正在新春促销!关注我的个人公众号“iamtonybai”,发送“go专栏活动”即可获取专栏专属优惠码,可在订阅专栏时抵扣20元哦(2021.2月末前有效)。

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

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.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 1.16中值得关注的几个变化

img{512x368}

辛丑牛年初七开工大吉的日子(2021.2.18),Go核心开发团队为中国Gopher们献上了大礼 – Go 1.16版本正式发布了!国内Gopher可以在Go中国官网上下载到Go 1.16在各个平台的安装包:

img{512x368}

2020年双12,Go 1.16进入freeze状态,即不再接受新feature,仅fix bug、编写文档和接受安全更新等,那时我曾写过一篇名为《Go 1.16新功能特性不完全前瞻》的文章。当时Go 1.16的发布说明尚处于早期草稿阶段,要了解Go 1.16功能特性都有哪些变化,只能结合当时的release note以及从Go 1.16里程碑中的issue列表中挖掘。

如今Go 1.16版本正式发布了,和当时相比,Go 1.16又有哪些变化呢?在这篇文章中,我们就来一起详细分析一下Go 1.16中那些值得关注的重要变化!

一. 语言规范

如果你是Go语言新手,想必你一定很期待一个大版本的发布会带来许多让人激动人心的语言特性。但是Go语言在这方面肯定会让你“失望”的。伴随着Go 1.0版本一起发布的Go1兼容性承诺给Go语言的规范加了一个“框框”,从Go 1.0到Go 1.15版本,Go语言对语言规范的变更屈指可数,因此资深Gopher在阅读Go版本的release notes时总是很自然的略过这一章节,因为这一章节通常都是如下面这样的描述:

img{512x368}

这就是Go的设计哲学:简单!绝不轻易向语言中添加新语法元素增加语言的复杂性。除非是那些社区呼声很高并且是Go核心团队认可的。我们也可以将Go从1.0到Go 1.16这段时间称为“Go憋大招”的阶段,因为就在Go团队发布1.16版本之前不久,Go泛型提案正式被Go核心团队接受(Accepted):

img{512x368}

这意味着什么呢?这意味着在2022年2月份(Go 1.18),Gopher们将迎来Go有史以来最大一次语言语法变更并且这种变更依然是符合Go1兼容性承诺的,这将避免Go社区出现Python3给Python社区带去的那种“割裂”。不过就像《“能力越大,责任越大” – Go语言之父详解将于Go 1.18发布的Go泛型》一文中Go语言之父Robert Griesemer所说的那样:泛型引入了抽象,但滥用抽象而没有解决实际问题将带来不必要的复杂性,请三思而后行! 离泛型的落地还有一年时间,就让我们耐心等待吧!

二. Go对各平台/OS支持的变更

Go语言具有良好的可移植性,对各主流平台和OS的支持十分全面和及时,Go官博曾发布过一篇文章,简要列出了自Go1以来对各主流平台和OS的支持情况:

  • Go1(2012年3月)支持原始系统(译注:上面提到的两种操作系统和三种架构)以及64位和32位x86上的FreeBSD、NetBSD和OpenBSD,以及32位x86上的Plan9。
  • Go 1.3(2014年6月)增加了对64位x86上Solaris的支持。
  • Go 1.4(2014年12月)增加了对32位ARM上Android和64位x86上Plan9的支持。
  • Go 1.5(2015年8月)增加了对64位ARM和64位PowerPC上的Linux以及32位和64位ARM上的iOS的支持。
  • Go 1.6(2016年2月)增加了对64位MIPS上的Linux,以及32位x86上的Android的支持。它还增加了32位ARM上的Linux官方二进制下载,主要用于RaspberryPi系统。
  • Go 1.7(2016年8月)增加了对的z系统(S390x)上Linux和32位x86上Plan9的支持。
  • Go 1.8(2017年2月)增加了对32位MIPS上Linux的支持,并且它增加了64位PowerPC和z系统上Linux的官方二进制下载。
  • Go 1.9(2017年8月)增加了对64位ARM上Linux的官方二进制下载。
  • Go 1.12(2018年2月)增加了对32位ARM上Windows10 IoT Core的支持,如RaspberryPi3。它还增加了对64位PowerPC上AIX的支持。
  • Go 1.14(2019年2月)增加了对64位RISC-V上Linux的支持。

Go 1.7版本中新增的go tool dist list命令还可以帮助我们快速了解各个版本究竟支持哪些平台以及OS的组合。下面是Go 1.16版本该命令的输出:

$go tool dist list
aix/ppc64
android/386
android/amd64
android/arm
android/arm64
darwin/amd64
darwin/arm64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
freebsd/arm64
illumos/amd64
ios/amd64
ios/arm64
js/wasm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/mips
linux/mips64
linux/mips64le
linux/mipsle
linux/ppc64
linux/ppc64le
linux/riscv64
linux/s390x
netbsd/386
netbsd/amd64
netbsd/arm
netbsd/arm64
openbsd/386
openbsd/amd64
openbsd/arm
openbsd/arm64
openbsd/mips64
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64
windows/arm

通常我不太会过多关注每次Go版本发布时关于可移植性方面的内容,这次将可移植性单独作为章节主要是因为Go 1.16发布之前的Apple M1芯片事件

img{512x368}

苹果公司再次放弃Intel x86芯片而改用自造的基于Arm64的M1芯片引发业界激烈争论。但现实是搭载Arm64 M1芯片的苹果笔记本已经大量上市,对于编程语言开发团队来说,能做的只有尽快支持这一平台。因此,Go团队给出了在Go 1.16版本中增加对Mac M1的原生支持。

在Go 1.16版本之前,Go也支持darwin/arm64的组合,但那更多是为了构建在iOS上运行的Go应用(利用gomobile)。

Go 1.16做了进一步的细分:将darwin/arm64组合改为apple M1专用;而构建在iOS上运行的Go应用则使用ios/arm64。同时,Go 1.16还增加了ios/amd64组合用于支持在MacOS(amd64)上运行的iOS模拟器中运行Go应用

另外还值得一提的是在OpenBSD上,Go应用的系统调用需要通过libc发起,而不能再绕过libc而直接使用汇编指令了,这是出于对未来OpenBSD的一些兼容性要求考虑才做出的决定。

三. Go module-aware模式成为默认!

在泛型落地前,Go module依旧是这些年Go语言改进的重点(虽不是语言规范特性)。在Go 1.16版本中,Go module-aware模式成为了默认模式(另一种则是传统的gopath模式)。module-aware模式成为默认意味着什么呢?意味着GO111MODULE的值默认为on了。

自从Go 1.11加入go module,不同go版本在GO111MODULE为不同值的情况下开启的构建模式几经变化,上一次go module-aware模式的行为有较大变更还是在Go 1.13版本中。这里将Go 1.13版本之前、Go 1.13版本以及Go 1.16版本在GO111MODULE为不同值的情况下的行为做一下对比,这样我们可以更好的理解go 1.16中module-aware模式下的行为特性,下面我们就来做一下比对:

GO111MODULE < Go 1.13 Go 1.13 Go 1.16
on 任何路径下都开启module-aware模式 任何路径下都开启module-aware模式 【默认值】:任何路径下都开启module-aware模式
auto 【默认值】:使用GOPATH mode还是module-aware mode,取决于要构建的源码目录所在位置以及是否包含go.mod文件。如果要构建的源码目录不在以GOPATH/src为根的目录体系下,且包含go.mod文件(两个条件缺一不可),那么使用module-aware mode;否则使用传统的GOPATH mode。 【默认值】:只要当前目录或父目录下有go.mod文件时,就开启module-aware模式,无论源码目录是否在GOPATH外面 只有当前目录或父目录下有go.mod文件时,就开启module-aware模式,无论源码目录是否在GOPATH外面
off gopath模式 gopath模式 gopath模式

我们看到在Go 1.16模式下,依然可以回归到gopath模式。但Go核心团队已经决定拒绝“继续保留GOPATH mode”的提案,并计划在Go 1.17版本中彻底取消gopath mode,仅保留go module-aware mode:

img{512x368}

虽然目前仍有项目没有转换到go module下,但根据调查,大多数项目已经选择拥抱go module并完成了转换工作,因此笔者认为即便Go 1.17真的取消了GOPATH mode,对整个Go社区的影响也不会太大了。

Go 1.16中,go module机制还有其他几个变化,这里逐一来看一下:

1. go build/run命令不再自动更新go.mod和go.sum了

为了能更清晰看出Go 1.16与之前版本的差异,我们准备了一个小程序:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld/go.mod
module github.com/bigwhite/helloworld

go 1.16

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld/helloworld.go
package main

import "github.com/sirupsen/logrus"

func main() {
    logrus.Println("Hello, World")
}

我们使用go 1.15版本构建一下该程序:

$go build
go: finding module for package github.com/sirupsen/logrus
go: downloading github.com/sirupsen/logrus v1.8.0
go: found github.com/sirupsen/logrus in github.com/sirupsen/logrus v1.8.0

$cat go.mod
module github.com/bigwhite/helloworld

go 1.16

require github.com/sirupsen/logrus v1.8.0

$cat go.sum
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/magefile/mage v1.10.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
github.com/sirupsen/logrus v1.8.0 h1:nfhvjKcUMhBMVqbKHJlk5RPrrfYr/NMo3692g0dwfWU=
github.com/sirupsen/logrus v1.8.0/go.mod h1:4GuYW9TZmE769R5STWrRakJc4UqQ3+QQ95fyz7ENv1A=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 h1:YyJpGZS1sBuBCzLAR1VEpK193GlqGZbnPFnPV/5Rsb4=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

在Go 1.15版本中,go build会自动分析源码中的依赖,如果go.mod中没有对该依赖的require,则会自动添加require,同时会将go.sum中将相关包(特定版本)的校验信息写入。

我们将上述helloworld恢复到初始状态,再用go 1.16来build一次:

$go build
helloworld.go:3:8: no required module provides package github.com/sirupsen/logrus; to add it:
    go get github.com/sirupsen/logrus

我们看到go build没有成功,而是给出错误:go.mod中没有对logrus的require,并给出添加对logrus的require的方法(go get github.com/sirupsen/logrus)。

我们就按照go build给出的提示执行go get:

$go get github.com/sirupsen/logrus
go: downloading github.com/magefile/mage v1.10.0
go get: added github.com/sirupsen/logrus v1.8.0

$cat go.mod
module github.com/bigwhite/helloworld

go 1.16

require github.com/sirupsen/logrus v1.8.0 // indirect

$cat go.sum
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/magefile/mage v1.10.0 h1:3HiXzCUY12kh9bIuyXShaVe529fJfyqoVM42o/uom2g=
github.com/magefile/mage v1.10.0/go.mod h1:z5UZb/iS3GoOSn0JgWuiw7dxlurVYTu+/jHXqQg881A=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
github.com/sirupsen/logrus v1.8.0 h1:nfhvjKcUMhBMVqbKHJlk5RPrrfYr/NMo3692g0dwfWU=
github.com/sirupsen/logrus v1.8.0/go.mod h1:4GuYW9TZmE769R5STWrRakJc4UqQ3+QQ95fyz7ENv1A=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 h1:YyJpGZS1sBuBCzLAR1VEpK193GlqGZbnPFnPV/5Rsb4=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

$go build
//ok

我们看到go build并不会向go 1.15及之前版本那样做出有“副作用”的动作:自动修改go.mod和go.sum,而是提示开发人员显式通过go get来添加缺少的包/module,即便是依赖包major版本升级亦是如此。

从自动更新go.mod,到通过提供-mod=readonly选项来避免自动更新go.mod,再到Go 1.16的禁止自动更新go.mod,笔者认为这个变化是Go不喜“隐式转型”的一种延续,即尽量不支持任何可能让开发者产生疑惑或surprise的隐式行为(就像隐式转型),取而代之的是要用一种显式的方式去完成(就像必须显式转型那样)。

我们也看到在go 1.16中,添加或更新go.mod中的依赖,只有显式使用go get。go mod tidy依旧会执行对go.mod的清理,即也可以修改go.mod。

2. 推荐使用go install安装Go可执行文件

在gopath mode下,go install基本“隐身”了,它能做的事情基本都被go get“越俎代庖”了。在go module时代初期,go install更是没有了地位。但Go团队现在想逐步恢复go install的角色:安装Go可执行文件!在Go 1.16中,当go install后面的包携带特定版本号时,go install将忽略当前go.mod中的依赖信息而直接编译安装可执行文件:

// go install回将gopls v0.6.5安装到GOBIN下
$go install golang.org/x/tools/gopls@v0.6.5

并且后续,Go团队会让go get将专注于分析依赖,并获取go包/module,更新go.mod/go.sum,而不再具有安装可执行Go程序的行为能力,这样go get和go install就会各司其职,Gopher们也不会再被两者的重叠行为所迷惑了。现在如果不想go get编译安装,可使用go get -d。

3. 作废module的特定版本

《如何作废一个已发布的Go module版本,我来告诉你!》一文中,我曾详细探讨了Go引入module后如何作废一个已发布的go module版本。当时已经知晓Go 1.16会在go.mod中增加retract指示符,因此也给出了在Go 1.16下retract一个module版本的原理和例子(基于当时的go tip)。

Go 1.16正式版在工具的输出提示方面做了进一步的优化,让开发人员体验更为友好。我们还是以一个简单的例子来看看在Go 1.16中作废一个module版本的过程吧。

在我的bitbucket账户下有一个名为m2的Go module(https://bitbucket.org/bigwhite/m2/),当前它的版本为v1.0.0:

// bitbucket.org/bigwhite/m2
$cat go.mod
module bitbucket.org/bigwhite/m2

go 1.15

$cat m2.go
package m2

import "fmt"

func M2() {
    fmt.Println("This is m2.M2 - v1.0.0")
}

我们在本地建立一个m2的消费者:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/retract

$cat go.mod
module github.com/bigwhite/retractdemo

go 1.16

$cat main.go
package main

import "bitbucket.org/bigwhite/m2"

func main() {
    m2.M2()
}

运行这个消费者:

$go run main.go
main.go:3:8: no required module provides package bitbucket.org/bigwhite/m2; to add it:
    go get bitbucket.org/bigwhite/m2

由于上面提到的原因,go run不会隐式修改go.mod,因此我们需要手工go get m2:

$go get bitbucket.org/bigwhite/m2
go: downloading bitbucket.org/bigwhite/m2 v1.0.0
go get: added bitbucket.org/bigwhite/m2 v1.0.0

再来运行消费者,我们将看到以下运行成功的结果:

$go run main.go
This is m2.M2 - v1.0.0

现在m2的作者对m2打了小补丁,版本升级到了v1.0.1。这时消费者通过go list命令可以看到m2的最新版本(前提:go proxy server上已经cache了最新的v1.0.1):

$go list -m -u all
github.com/bigwhite/retractdemo
bitbucket.org/bigwhite/m2 v1.0.0 [v1.0.1]

消费者可以通过go get将对m2的依赖升级到最新的v1.0.1:

$go get bitbucket.org/bigwhite/m2@v1.0.1

go get: upgraded bitbucket.org/bigwhite/m2 v1.0.0 => v1.0.1
$go run main.go
This is m2.M2 - v1.0.1

m2作者收到issue,有人指出v1.0.1版本有安全漏洞,m2作者确认了该漏洞,但此时v1.0.1版已经发布并被缓存到各大go proxy server上,已经无法撤回。m2作者便想到了Go 1.16中引入的retract指示符,于是它在m2的go.mod用retract指示符做了如下更新:

$cat go.mod
module bitbucket.org/bigwhite/m2

// 存在安全漏洞
retract v1.0.1

go 1.15

并将此次更新作为v1.0.2发布了出去!

之后,当消费者使用go list查看m2是否有最新更新时,便会看到retract提示:(前提:go proxy server上已经cache了最新的v1.0.2)

$go list -m -u all
github.com/bigwhite/retractdemo
bitbucket.org/bigwhite/m2 v1.0.1 (retracted) [v1.0.2]

执行go get会收到带有更详尽信息的retract提示和问题解决建议:

$go get .
go: warning: bitbucket.org/bigwhite/m2@v1.0.1: retracted by module author: 存在安全漏洞
go: to switch to the latest unretracted version, run:
    go get bitbucket.org/bigwhite/m2@latest

于是消费者按照提示执行go get bitbucket.org/bigwhite/m2@latest:

$go get bitbucket.org/bigwhite/m2@latest
go get: upgraded bitbucket.org/bigwhite/m2 v1.0.1 => v1.0.2

$cat go.mod
module github.com/bigwhite/retractdemo

go 1.16

require bitbucket.org/bigwhite/m2 v1.0.2

$go run main.go
This is m2.M2 - v1.0.2

到此,retract的使命终于完成了!

4. 引入GOVCS环境变量,控制module源码获取所使用的版本控制工具

出于安全考虑,Go 1.16引入GOVCS环境变量,用于在go命令直接从代码托管站点获取源码时对所使用的版本控制工具进行约束,如果是从go proxy server获取源码,那么GOVCS将不起作用,因为go工具与go proxy server之间使用的是GOPROXY协议

GOVCS的默认值为public:git|hg,private:all,即对所有公共module允许采用git或hg获取源码,而对私有module则不限制版本控制工具的使用。

如果要允许使用所有工具,可像下面这样设置GOVCS:

GOVCS=*:all

如果要禁止使用任何版本控制工具去直接获取源码(不通过go proxy),那么可以像下面这样设置GOVCS:

GOVCS=*:off

5. 有关go module的文档更新

自打Go 1.14版本宣布go module生产可用后,Go核心团队在说服和帮助Go社区全面拥抱go module的方面不可谓不努力。在文档方面亦是如此,最初有关go module的文档仅局限于go build命令相关以及有关go module的wiki。随着go module日益成熟,go.mod格式的日益稳定,Go团队在1.16版本中还将go module相关文档升级到go reference的层次,与go language ref等并列:

img{512x368}

我们看到有关go module的ref文档包括:

官方还编写了详细的Go module日常开发时的使用方法,包括:开发与发布module、module发布与版本管理工作流、升级major号等。

img{512x368}

建议每个gopher都要将这些文档仔细阅读一遍,以更为深入了解和使用go module

四. 编译器与运行时

1. runtime/metrics包

《Go 1.16新功能特性不完全前瞻》一文中,我们提到过:Go 1.16 新增了runtime/metrics包,以替代runtime.ReadMemStats和debug.ReadGCStats输出runtime的各种度量数据,这个包更通用稳定,性能也更好。限于篇幅这里不展开,后续可能会以单独的文章讲解这个新包。

2. GODEBUG环境变量支持跟踪包init函数的消耗

GODEBUG=inittrace=1这个特性也保留在了Go 1.16正式版当中了。当GODEBUG环境变量包含inittrace=1时,Go运行时将会报告各个源代码文件中的init函数的执行时间和内存开辟消耗情况。我们用上面的helloworld示例(github.com/bigwhite/experiments/blob/master/go1.16-examples/go-modules/helloworld)来看看该特性的效果:

$go build
$GODEBUG=inittrace=1 ./helloworld
init internal/bytealg @0.006 ms, 0 ms clock, 0 bytes, 0 allocs
init runtime @0.037 ms, 0.031 ms clock, 0 bytes, 0 allocs
init errors @0.29 ms, 0.005 ms clock, 0 bytes, 0 allocs
init math @0.31 ms, 0 ms clock, 0 bytes, 0 allocs
init strconv @0.33 ms, 0.002 ms clock, 32 bytes, 2 allocs
init sync @0.35 ms, 0.003 ms clock, 16 bytes, 1 allocs
init unicode @0.37 ms, 0.10 ms clock, 24568 bytes, 30 allocs
init reflect @0.49 ms, 0.002 ms clock, 0 bytes, 0 allocs
init io @0.51 ms, 0.003 ms clock, 144 bytes, 9 allocs
init internal/oserror @0.53 ms, 0 ms clock, 80 bytes, 5 allocs
init syscall @0.55 ms, 0.010 ms clock, 752 bytes, 2 allocs
init time @0.58 ms, 0.010 ms clock, 384 bytes, 8 allocs
init path @0.60 ms, 0 ms clock, 16 bytes, 1 allocs
init io/fs @0.62 ms, 0.002 ms clock, 16 bytes, 1 allocs
init internal/poll @0.63 ms, 0.001 ms clock, 64 bytes, 4 allocs
init os @0.65 ms, 0.089 ms clock, 4472 bytes, 20 allocs
init fmt @0.77 ms, 0.006 ms clock, 32 bytes, 2 allocs
init bytes @0.84 ms, 0.004 ms clock, 48 bytes, 3 allocs
init context @0.87 ms, 0 ms clock, 128 bytes, 4 allocs
init encoding/binary @0.89 ms, 0.002 ms clock, 16 bytes, 1 allocs
init encoding/base64 @0.90 ms, 0.015 ms clock, 1408 bytes, 4 allocs
init encoding/json @0.93 ms, 0.002 ms clock, 32 bytes, 2 allocs
init log @0.95 ms, 0 ms clock, 80 bytes, 1 allocs
init golang.org/x/sys/unix @0.96 ms, 0.002 ms clock, 48 bytes, 1 allocs
init bufio @0.98 ms, 0 ms clock, 176 bytes, 11 allocs
init github.com/sirupsen/logrus @0.99 ms, 0.009 ms clock, 312 bytes, 5 allocs
INFO[0000] Hello, World

以下面这行为例:

init fmt @0.77 ms, 0.006 ms clock, 32 bytes, 2 allocs
  • 0.77ms表示的是自从程序启动后到fmt包init执行所过去的时间(以ms为单位)
  • 0.006 ms clock表示fmt包init函数执行的时间(以ms为单位)
  • 312 bytes表示fmt包init函数在heap上分配的内存大小;
  • 5 allocs表示的是fmt包init函数在heap上执行内存分配操作的次数。

3. Go runtime默认使用MADV_DONTNEED

Go 1.15版本时,我们可以通过GODEBUG=madvdontneed=1让Go runtime使用MADV_DONTNEED替代MADV_FREE达到更积极的将不用的内存释放给OS的效果(如果使用MADV_FREE,只有OS内存压力很大时,才会真正回收内存),这将使得通过top查看到的常驻系统内存(RSS或RES)指标更实时也更真实反映当前Go进程对os内存的实际占用情况(仅使用linux)。

在Go 1.16版本中,Go runtime将MADV_DONTNEED作为默认值了,我们可以用一个小例子来对比一下这种变化:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/runtime/memalloc.go
package main

import "time"

func allocMem() []byte {
    b := make([]byte, 1024*1024*1) //1M
    return b
}

func main() {
    for i := 0; i < 100000; i++ {
        _ = allocMem()
        time.Sleep(500 * time.Millisecond)
    }
}

我们在linux上使用go 1.16版本编译该程序,考虑到优化和inline的作用,我们在编译时关闭优化和内联:

$go build -gcflags "-l -N" memalloc.go

接下来,我们分两次运行该程序,并使用top监控其RES指标值:

$./memalloc
$ top -p 9273
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 9273 root      20   0  704264   5840    856 S  0.0  0.3   0:00.03 memalloc
 9273 root      20   0  704264   3728    856 S  0.0  0.2   0:00.05 memalloc
 ... ...

$GODEBUG=madvdontneed=0 ./memalloc
$ top -p 9415

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 9415 root      20   0  704264   5624    856 S  0.0  0.3   0:00.03 memalloc
 9415 root      20   0  704264   5624    856 S  0.0  0.3   0:00.05 memalloc

我们看到默认运行的memalloc(开启MADV_DONTNEED),RES很积极的变化,当上一次显示5840,下一秒内存就被归还给OS,RES变为3728。而关闭MADV_DONTNEED(GODEBUG=madvdontneed=0)的memalloc,OS就会很lazy的回收内存,RES一直显示5624这个值。

4. Go链接器的进一步进行现代化改造

新一代Go链接器的更新计划从Go 1.15版本开始,在Go 1.15版本链接器的性能、资源占用、最终二进制文件大小等方面都有了一定幅度的优化提升。Go 1.16版本延续了这一势头:相比于Go 1.15,官方宣称(在linux上)性能有20%-25%的提升,资源占用下降5%-15%。更为直观的是编译出的二进制文件的size,我实测了一下文件大小下降10%以上:

-rwxr-xr-x   1 tonybai  staff    22M  2 21 23:03 my-large-app-demo*
-rwxr-xr-x   1 tonybai  staff    25M  2 21 23:02 my-large-app-demo-go1.15*

并且和Go 1.15的链接器优化仅针对amd64平台和基于ELF格式的OS不同,这次的链接器优化已经扩展到所有平台和os组合上

五. 标准库

1. io/fs包

Go 1.16标准库新增io/fs包,并定义了一个fs.File接口用于表示一个只读文件树(tree of file)的抽象。之所以要加入io/fs包并新增fs.File接口源于对嵌入静态资源文件(embed static asset)的实现需求。虽说实现embed功能特性是直接原因,但io/fs的加入也不是“临时起意”,早在很多年前的godoc实现时,对一个抽象的文件系统接口的需求就已经被提了出来并给出了实现:

最终这份实现以godoc工具的vfs包的形式一直长期存在着。虽然它的实现有些复杂,抽象程度不够,但却对io/fs包的设计有着重要的参考价值。同时也部分弥补了Rob Pike老爷子当年没有将os.File设计为interface的遗憾Ian Lance Taylor 2013年提出的增加VFS层的想法也一并得以实现。

io/fs包的两个最重要的接口如下:

// $GOROOT/src/io/fs/fs.go

// An FS provides access to a hierarchical file system.
//
// The FS interface is the minimum implementation required of the file system.
// A file system may implement additional interfaces,
// such as ReadFileFS, to provide additional or optimized functionality.
type FS interface {
        // Open opens the named file.
        //
        // When Open returns an error, it should be of type *PathError
        // with the Op field set to "open", the Path field set to name,
        // and the Err field describing the problem.
        //
        // Open should reject attempts to open names that do not satisfy
        // ValidPath(name), returning a *PathError with Err set to
        // ErrInvalid or ErrNotExist.
        Open(name string) (File, error)
}

// A File provides access to a single file.
// The File interface is the minimum implementation required of the file.
// A file may implement additional interfaces, such as
// ReadDirFile, ReaderAt, or Seeker, to provide additional or optimized functionality.
type File interface {
        Stat() (FileInfo, error)
        Read([]byte) (int, error)
        Close() error
}

FS接口代表虚拟文件系统的最小抽象,File接口则是虚拟文件的最小抽象,我们可以基于这两个接口进行扩展以及对接现有的一些实现。io/fs包也给出了一些扩展FS的“样例”:

这两个接口的设计也是“Go秉持定义小接口惯例”的延续(更多关于这方面的内容,可以参考我的专栏文章《定义小接口是Go惯例》)。

io/fs包的加入也契合了Go社区对vfs的需求,在Go团队决定加入io/fs并提交实现后,社区做出了积极的反应,在github上我们能看到好多为各类对象提供针对io/fs.FS接口实现的项目:

io/fs.FS和File接口在后续Go演进过程中会像io.Writer和io.Reader一样成为Gopher们在操作类文件树时最爱的接口。

2. embed包

《Go 1.16新功能特性不完全前瞻》一文中我们曾重点说了Go 1.16将支持在Go二进制文件中嵌入静态文件并给出了一个在webserver中嵌入文本文件的例子:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/webserver/hello.txt
hello, go 1.16

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/webserver/main.go
package main

import (
         _  "embed"
    "net/http"
)

//go:embed hello.txt
var s string

func main() {
    http.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(s))
    }))
    http.ListenAndServe(":8080", nil)
}

我们看到在这个例子,通过//go:embed hello.txt,我们可以轻易地将hello.txt的内容存储在包级变量s中,而s将作为每个http request的应答返回给客户端。

在Go二进制文件中嵌入静态资源文件是Go核心团队对社区广泛需求的积极回应。在go 1.16以前,Go社区开源的类嵌入静态文件的项目不下十多个,在Russ Cox关于embed的设计草案中,他就列了十多个:

  • github.com/jteeuwen/go-bindata(主流实现)
  • github.com/alecthomas/gobundle
  • github.com/GeertJohan/go.rice
  • github.com/go-playground/statics
  • github.com/gobuffalo/packr
  • github.com/knadh/stuffbin
  • github.com/mjibson/esc
  • github.com/omeid/go-resources
  • github.com/phogolabs/parcello
  • github.com/pyros2097/go-embed
  • github.com/rakyll/statik
  • github.com/shurcooL/vfsgen
  • github.com/UnnoTed/fileb0x
  • github.com/wlbr/templify
  • perkeep.org/pkg/fileembed

Go1.16原生支持嵌入并且给出一种开发者体验良好的实现方案,这对Go社区是一种极大的鼓励,也是Go团队重视社区声音的重要表现。

笔者认为embed机制是Go 1.16中玩法最多的一种机制,也是极具新玩法挖掘潜力的机制。在embed加入Go tip不久,很多Gopher就已经“脑洞大开”:

有通过embed嵌入版本号的:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/version/main.go
package main

import (
    _ "embed"
    "fmt"
    "strings"
)

var (
    Version string = strings.TrimSpace(version)
    //go:embed version.txt
    version string
)

func main() {
    fmt.Printf("Version %q\n", Version)
}

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/version/version.txt
v1.0.1

有通过embed打印自身源码的:

// github.com/bigwhite/experiments/blob/master/go1.16-examples/stdlib/embed/printself/main.go
package main

import (
        _ "embed"
        "fmt"
)

//go:embed main.go
var src string

func main() {
        fmt.Print(src)
}

更是有将一个完整的、复杂的带有js支持的web站点直接嵌入到go二进制文件中的示例,鉴于篇幅,这里就不一一列举了。

Go擅长于Web服务,而embed机制的引入粗略来看,可以大大简化web服务中资源文件的部署,估计这也是之前社区青睐各种静态资源文件嵌入项目的原因。embed估计也会成为Go 1.16中最被gopher们喜爱的功能特性。

不过embed机制的实现目前有如下一些局限:

  • 仅支持在包级变量前使用//go:embed指示符,还不支持在函数/方法内的局部变量上应用embed指示符(当然我们可以通过将包级变量赋值给局部变量来过渡一下);
  • 使用//go:embed指示符的包必须以空导入的方式导入embed包,二者是成对出现的,缺一不可;

3. net包的变化

在Go 1.16之前,我们检测在一个已关闭的网络上进行I/O操作或在I/O完成前网络被关闭的情况,只能通过匹配字符串”use of closed network connection”的方式来进行。之前的版本没有针对这个错误定义“哨兵错误变量”(更多关于哨兵错误变量的内容,可以参考我的专栏文章《别笑!这就是 Go 的错误处理哲学》),Go 1.16增加了ErrClosed这个“哨兵错误变量”,我们可以通过errors.Is(err, net.ErrClosed)来检测是否是上述错误情况。

六. 小结

从Go 1.16版本变更的功能特性中,我看到了Go团队更加重视社区的声音,这也是Go团队一直持续努力的目标。在最新的Go proposal review meeting的结论中,我们还看到了这样的一个proposal被accept:

要知道这个proposal的提议是将在Go 1.18才会落地的泛型实现分支merge到Go项目master分支,也就是说在Go 1.17中就会包含“不会发布的”泛型部分实现,这在之前是不可能实现的(之前,新proposal必须有原型实现的分支,实现并经过社区测试与Go核心委员会评估后才会在特定版本merge到master分支)。虽说泛型的开发有其特殊情况,但能被accept,这恰证明了Go社区的声音在Go核心团队日益受到重视。

如果你还没有升级到Go 1.16,那么现在正是时候

本文中涉及的代码可以在这里下载。https://github.com/bigwhite/experiments/tree/master/go1.16-examples


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

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

考虑到部落尚处于推广期,这里仍然为大家准备了新人优惠券,虽然优惠幅度有所下降,但依然物超所值,早到早享哦!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订阅!目前该技术专栏正在新春促销!关注我的个人公众号“iamtonybai”,发送“go专栏活动”即可获取专栏专属优惠码,可在订阅专栏时抵扣20元哦(2021.2月末前有效)。

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

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.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}

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

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

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats