Goroutine是如何工作的

No Comments

golangweekly的第36期Go Newsletter中我发现一篇短文"How Goroutines Work" ,其作者在参考了诸多资料后,简短概要地总结了一下 Goroutine的工作原理,感觉十分适合刚入门的Gophers(深入理解Goroutine调度的话,可以参考Daniel Morsing的" The Go scheduler" )。这里粗译如下。

一、Go语言简介

如果你是Go语言新手,或如果你对"并发(Concurrency)不是并行(parallelism)"这句话毫无赶脚,那么请看一下Rob Pike大神关于这个主题的演讲吧,演讲共30分 钟,我敢保证你在这个演讲上花费30分钟是绝对值得的。

总结一下两者(Concurrency和Parallelism)的不同:"当人们听到并发(Concurrency)这个词时,总是会想起并行 (Parallelism),它们之间有相关性,但却是两个明显不同的概念。在编程领域,并发(Concurrency)是独立的执行过程 (Process)的组合,而并行(Parallelism)则是计算(可能是相关联的)的同时执行。并发(Concurrency)是关于同时 应对很多事情(deal with lots of things),而并行(Parallelism)则是同时做许多事情(do lots of things)"。(Rob Pike的“Concurrency is not parallelism")

Go语言支持我们编写并发(Concurrent)的程序。它提供了Goroutine以及更重要的在Goroutines之间通信的能力。这里 我们将聚焦在前者(译注:指并发)。

二、Goroutines和Threads

Goroutine是一个简单的模型:它是一个函数,与其他Goroutines并发执行且共享相同地址空间。Goroutines的通常用法是根据需要创建尽可 能的Groutines,成百上千甚至上万的。这种用法对于那些习惯了使用C++或Java的程序员来讲可能会有些奇怪。创建这么多 goroutines势必要付出不菲的代价?一个操作系统线程使用固定大小的内存作为它的执行栈,当线程数增多时,线程间切换的代价也是相当的 高。这也是每处理一个request就创建一个新线程的服务程序方案被诟病的原因。

不过Goroutine完全不同。它们由Go运行时初始化并调度,操作系统根本看不到Goroutine的存在。所有的goroutines都是 活着的,并且以多路复用的形式运行于操作系统为应用程序分配的少数几个线程上。创建一个Goroutine并不需要太多内存,只需要8K的栈空间 (在Go 1.3中这个Size发生了变化)。它们根据需要在堆上分配和释放内存以实现自身的增长。

Go运行时负责调度Goroutines。Goroutines的调度是协作式的,而线程不是。这意味着每次一个线程发生切换,你都需要保存/恢 复所有寄存器,包括16个通用寄存器、PC(程序计数器)、SP(栈指针)、段寄存器(segment register)、16个XMM寄存器、FP协处理器状态、X AVX寄存器以及所有MSR等。而当另一个Goroutine被调度时,只需要保存/恢复三个寄存器,分别是PC、SP和DX。Go调度器和任何现代操作 系统的调度器都是O(1)复杂度的,这意味着增加线程/goroutines的数量不会增加切换时间,但改变寄存器的代价是不可忽视的。

由于Goroutines的调度是协作式的,一个持续循环的goroutine会导致运行于同一线程上的其他goroutines“饿死”。在 Go 1.2中,这个问题或多或少可以通过在进入函数前间或地调用Go调度器来缓解一些,因此一个包含非内联函数调用的循环是可以被调度器抢占的。

三、Goroutine阻塞

只要阻塞存在,它在OS线程中就是不受欢迎的,因为你拥有的线程数量很少。如果你发现大量线程阻塞在网络操作或是Sleep操作上,那就是问题, 需要修正。正如前面提到的那样,Goroutine是廉价的。更关键地是,如果它们在网络输入操作、Sleep操作、Channel操作或 sync包的原语操作上阻塞了,也不会导致承载其多路复用的线程阻塞。如果一个goroutine在上述某个操作上阻塞,Go运行时会调度另外一 个goroutine。即使成千上万的Goroutine被创建了出来,如果它们阻塞在上述的某个操作上,也不会浪费系统资源。从操作系统的视角来看,你的程序的行为就像是一个事件驱动的C程序似的。

四、最后的想法

就是这样,Goroutines可以并发的运行。不过和其他语言一样,组织两个或更多goroutine同时访问共享资源是很重要的。最好采用Channel在不同Goroutine间传递数据。

最后,虽然你无法直接控制Go运行时创建的线程的数量,但可以通过调用runtime.GOMAXPROCS(n)方法设置变量GOMAXPROCS来设 定使用的处理器核的数量。提高使用的处理器核数未必能提升你的程序的性能,这取决于程序的设计。程序剖析诊断工具(profiling tool)可以用来检查你的程序使用处理器核数的真实情况。

Go语言的有效错误处理

No Comments

中午闲暇翻看Daniel Morsing的“The Go scheduler”时,发现其另外一篇短文“Effective error handling in Go”,文章不长,但感觉对Go中错误处理方法总结的还是比较到位的,这里译之供大家参考。

一、简介

Go语言受到诟病最多的一项就是其错误处理机制。如果显式地检查和处理每个error,这恐怕的确会让人望而却步。你可以试试这里列出的几个方法,以避免你走入错误处理方法的误区当中去。

二、在缩进区处理错误

当使用Go语言编写代码时,首选下面这样的错误处理方法:

f, err := os.Open(path)
if err != nil {
    // handle error
}
// do stuff

而不是下面这样的:

f, err := os.Open(path)
if err == nil {
    // do stuff
}
// handle error

按照上面的方法处理错误,处理正常情况的代码读起来就显得通篇连贯了。

三、定义你自己的errors

做好如何正确进行错误处理的第一步就是要了解error是什么。如果你设计实现的包会因某种原因发生某种错误,你的包用户将会对错误的原因很感兴趣。为了满足用户的需求,你需要实现error接口,简单做起来就像这样:

type Error string
func (e Error) Error() string { return string(e) }

现在,你的包用户通过执行一个type assertion就可以知道是否是你的包导致了这个错误:

result, err := yourpackage.Foo()
if ype, ok := err.(yourpackage.Error); ok {
    // use ype to handle error
}

通过这个方法,你还可以向你的包用户暴露更多地结构化错误信息:

type ParseError struct {
    File  *File
    Error string
}

func (oe *ParseError) Error() string {//译注:原文中这里是OpenError
    // format error string here
}

func ParseFiles(files []*File) error {
    for _, f := range files {
        err := f.parse()
        if err != nil {
            return &ParseError{ //译注:原文中这里是OpenError
                File:  f,
                Error: err.Error(),
            }
        }
    }
}

通过这种方法,你的用户就可以明确地知道到底哪个文件出现解析错误了。(译注:从这里看到的go语言error设计之内涵,让我想起了Rob Pike大神的一篇Blog:"少即是级数级的多")

不过包装error时要小心,当你将一个error包装起来后,你可能会丢失一些信息:

var c net.Conn
f, err := DownloadFile(c, path)
switch e := err.(type) {
default:
    // this will get executed if err == nil
case net.Error:
    // close connection, not valid anymore
    c.Close()
    return e
case error:
    // if err is non-nil
    return err
}
// do other things.

如果你包装了net.Error,上面这段代码将无法知道是由于网络问题导致的失败,会继续使用这条无效的链接。

有一条经验规则:如果你的包中使用了一个外部interface,那么不要对这个接口中方法返回的任何错误,使用你的包的用户可能更关心这些错误,而不是你包装后的错误。

四、将错误作为状态

有时,当遇到一个错误时,你可能会停下来等等。这或是因为你将延迟报告错误,又或是因为你知道如果这次报告后,后续你会再报告同样的错误。

第一种情况的一个例子就是bufio包。当一个bufio.Reader遇到一个错误时,它将停下来保持这个状态,直到buffer已经被清空。只有在那时它才会报告错误。

第二种情况的一个例子是go/loader。当你通过某些参数调用它导致错误时,它会停下来保持这个状态,因为它知道你很可能会使用同样地参数再次调用它。

五、使用函数以避免重复代码

如果你有两段重复的错误处理代码,你可以将它们放到一个函数中去:

func handleError(c net.Conn, err error) {
    // repeated error handling
}

func DoStuff(c net.Conn) error {
    f, err := downloadFile(c, path)
    if err != nil {
        handleError(c, err)
        return err
    }

    f, err := doOtherThing(c)
    if err != nil {
        handleError(c, err)
        return err
    }
}

优化后的实现方法如下:

func handleError(c net.Conn, err error) {
    if err == nil {
        return
    }
    // repeated error handling
}

func DoStuff(c net.Conn) error {
    defer func() { handleError(c, err) }()
    f, err := downloadFile(c, path)
    if err != nil {
        return err
    }

    f, err := doOtherThing(c)
    if err != nil {
        return err
    }
}

这就是全部了。就Go语言错误处理而言,我知道的就这么多了。

Go,5周年

5 Comments

2014年11月10日(美国当地时间),Golang官方博客 放出了Andrew Gerrand的一篇博文《Half a decade with Go》来纪念Go语言发布五周年。文章按时间顺序简要描述了Golang这五年来发展的 点点滴滴,并让全世界Gopher看到了Go可期的光明未来。考虑到这篇文章在墙外,不便于国内Gopher阅读,这里给出中文翻译版,希望能给中国大陆 的Gophers带来些帮助!

五年前,我们启动了Go语言项目。我们准备发布第一版时的一幕仿佛就发生在昨天似的:我们的官方站点用的是一种可爱的黄色色调,我们将Go语言称为一门 “系统编程语言”,你需要使用分号作为语句结束标志,使用Makefile来构建你的代码。我们不知道Go语言是否能被大家接受。人们会分享我们的目标和 愿景吗?人们会发现Go语言有用吗?

起初,我们的发布引起了一阵关注。Google发布了一门新的编程语言,每个人都渴望探究它一番。一些程序员因为Go相对保守的功能特性集合而选择了放 弃,Go给他们的第一印象就是:没有什么新鲜玩意儿!但另外一小群程序员则看到了这个为软件工程师量身定做的生态系统的开端。这少数人将组成Go语言社区 的核心。

第一版发布后,我们花了些时间向社区传达Go语言背后的目标和设计理念。Rob Pike在官方的《Go at Google: Language Design in the Service of Software Engineering》一文中对此进行了生动地表达,并 在其个人博客文章《Less is exponentially more》中做了进一步的阐述。Andrew Gerrand的《Code that grows with grace》(Slides在这里)和《Go for Gophers》(Slides在这里)对Go的设计哲学又给出了更有深度和技术性的说明。

随着时间的推移,积少成多。这个项目的转折点出现在2012年3月Go 1发布时。Go 1为程序员们提供了可以信赖的稳定的语言和标准库。到2014年,Go项目拥有了上百的核心贡献者,其生态圈中拥有了数不尽的第三方库和工具 ,并由成千上万的开发者维护着。正在发展壮大的社区拥有许多极具热情的成员(或者就如我们所称呼 的:Gophers)。今天,就我们目前的统计分析,Go社区的成长速度远远超出了我们的预期。

Gophers们在哪里可以得到这些呢?全世界目前有很多有关Go语言的“大事”发生。今年我们看到了几个专门的Go技术大会:在丹佛和巴黎举行的首次 GopherCondotGo大 会。FOSDEM的Go DevRoom以及在东京举行的一年两次的GoCon。每次会上来自全球各地的Gophers们都踊跃地展示他们开发的Go项目。对于Go语言开发组来 说,我们很高兴能满足这些分享我们愿景和兴奋的程序员的需求。

在世界各地,还有数十个社区驱动运行的“Go用户组”。如果你还没有造访过你当地的用户组,可以考虑去尝试一下。如果你当地尚没有这类用户组,也许你可以考虑发起一个

今天,Go在云端找到了用武之地。Go出现在了工业向云计算转型的时刻。并且我们兴奋地看到Go正在快速成为这个运动的一个重要组成部分。简单、高效、内 置并发原语和现代的标准库让Go语言尤其适合云端软件开发(毕竟它就是为此而设计的)。一些重量级的开源云项目,诸如Docker和Kubernetes 都是用Go语言实现的,一些运作基础设置的公司,诸如Google、CloudFlare、Canonical、Digital Ocean、Github、Heroku以及微软也都在使用Go语言开发一些重量级的项目。

那么将来会怎样呢?我们认为2015年将是Go语言大爆发的一年。

Go 1.4,除了其新增的特性和bug修正外,它为实现一个新的低延迟垃圾收集器以及支 持在移动终端上运行Go奠定了基础。 预计Go1.4将在2014年12月1日正式发布。我们期望在Go 1.5中能出现新GC的身影,Go 1.5预计在2015年6月1日发布,它将使Go适合更加广泛的应用开发。我们迫不及待的想看到哪些领域的开发者会接受它。

接下来会有更多的Go大事发生。11月15日,GothamGo将在纽约如期举行。2014年1月31日到 2月1日,布鲁塞尔将举行另一次Go DevRoot at FOSDEM。2015年2月19日到21日,在印度班加罗尔将举行GopherCon India大会。最初的GopherCon将在2015年7月份回到丹佛。2015年11月 dotGo大会将再次来到巴黎。

Go团队将向届时到场的所有gophers表示衷心的感谢。为Go语言的下一个五年!

为了庆祝Go诞生5周年,在未来的一个月里,Gopher Academy将会发布一系列由知名Go users撰写的文章,务必要去看看哦。

Golang开发环境搭建-Vim篇

评论关闭

虽说sublimetext3+gosublime+gocode是目前较为 流行的Golang开发环境组合,但作为一名VIMer,没有一套得心应手的Vim for Golang dev心里总是过不去的。Golang虽然年轻,但即便是从Go 1版本发布(2012年3月28日)算起,掐指算来也有小三年了。全世界的开发者已经为Golang贡献了较为成熟的Vim插件了。有了这些插件,搭建出 一套高效的Golang开发环境还是不难的,网上也有大量的资料可以参考,其中就有vim-go作者自己发表的一篇文章《Go development environment for Vim》。不过看别人 写的与自己搭建体验的还是有大不同的,于是想来想去还是把整个过程记录下来。

一、一个干净的环境

找个干净的基础环境,方便确认每个搭建步骤后的效果:

Ubuntu 14.04 x86_64
vim version 7.4.52
go version go1.4beta1 linux/amd64

再准备一个编辑Go源码的测试源文件:

//hellogolang.go

package main

import "fmt"

func main() {
        fmt.Println("Hello Golang!")
}

用于验证每个搭建步骤后的变化。

二、严格按照vim-go的官方说明逐一搭建

Vim-go是当前使用最为广泛的用于搭建Golang开发环境的vim插件,这里我同样使用vim-go作为核心和基础进行环境搭建的。vim-go利 用开源Vim插件管理器安装,gmarik/Vundle.vim是目前被推荐次数更多的Vim插件管理器,超过了pathogen。这里我们 就用vundle来作为Vim的插件管理工具。

1、安装Vundle.vim

Vundle.vim的安装步骤如下:

mkdir ~/.vim/bundle
git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim   
                                                                  

创建~/.vimrc文件(如果你没有这个文件的话),在文件顶部添加有关Vundle.vim的配置:

set nocompatible              " be iMproved, required
filetype off                  " required

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required

此时Vim仅安装了Vundle.vim这一个插件。编辑hellogolang.go时与编辑普通文本文件无异,一切都还是Vim的默认属性。

2、安装Vim-go

编辑~/.vimrc,在vundle#beginvundle#end间增加一行:

Plugin 'fatih/vim-go'

在Vim内执行 :P luginInstall

Vundle.vim会在左侧打开一个Vundle Installer Preview子窗口,窗口下方会提示:“Processing 'fatih/vim-go'”,待安装完毕后,提示信息变 成“Done!”。

这时,我们可以看到.vim/bundle下多了一个vim-go文件夹:

$ ls .vim/bundle/
vim-go/  Vundle.vim/

此时,再次编辑hellogolang.go,语法高亮有了, 保存时自动format(利用$GOBIN/gofmt)也有了,但其他高级功能,比如自动import缺失的 package、自动补齐仍然没有,我们还要继续安装一些东东。

3、安装go.tools Binaries

vim-go安装说明中提到所有必要的binary需要先安装好,比如gocode、godef、goimports等。

通过:GoInstallBinaries,这些vim-go依赖的二进制工具将会自动被下载,并被安装到$GOBIN下或$GOPATH/bin下。(这个工具需要依赖git或hg,需要提前安装到你的OS中。)

:GoInstallBinaries的执行是交互式的,你需要回车确认:

vim-go: gocode not found. Installing github.com/nsf/gocode to folder /home/tonybai/go/bin
vim-go: goimports not found. Installing code.google.com/p/go.tools/cmd/goimports to folder /home/tonybai/go/bin/
vim-go: godef not found. Installing code.google.com/p/rog-go/exp/cmd/godef to folder /home/tonybai/go/bin/
vim-go: oracle not found. Installing code.google.com/p/go.tools/cmd/oracle to folder /home/tonybai/go/bin/
vim-go: gorename not found. Installing code.google.com/p/go.tools/cmd/gorename to folder /home/tonybai/go/bin/
vim-go: golint not found. Installing github.com/golang/lint/golint to folder /home/tonybai/go/bin/

vim-go: errcheck not found. Installing github.com/kisielk/errcheck to folder /home/tonybai/go/bin/

不过这些代码多在code.google.com上托管,因此由于众所周知的原因,vim-go的自动安装很可能以失败告终,这样就需要你根据上 面日志中提到的各个工具的源码地址逐一去下载并本地安装。无法搭梯子的,可以通过http://gopm.io 下载相关包。

安装后,$GOBIN下的新增Binaries如下:
-rwxr-xr-x  1 tonybai tonybai  5735552 11??  7 11:03 errcheck*
-rwxr-xr-x  1 tonybai tonybai  9951008 11??  7 10:33 gocode*
-rwxr-xr-x  1 tonybai tonybai  5742800 11??  7 11:07 godef*
-rwxr-xr-x  1 tonybai tonybai  4994120 11??  7 11:00 goimports*
-rwxr-xr-x  1 tonybai tonybai  5750152 11??  7 11:03 golint*
-rwxr-xr-x  1 tonybai tonybai  6381832 11??  7 11:01 gorename*
-rwxr-xr-x  1 tonybai tonybai  2954392 11??  7 10:38 gotags*
-rwxr-xr-x  1 tonybai tonybai  9222856 11??  7 11:01 oracle*

安装好这些Binaries后,我们来看看哪些特性被支持了。

再次编辑hellogolang.go

         - 新起一行输入fmt.,然后ctrl+x, ctrl+o,Vim 会弹出补齐提示下拉框,不过并非实时跟随的那种补齐,这个补齐是由gocode提供的。
    – 输入一行代码:time.Sleep(time.Second),执行:GoImports,Vim会自动导入time包。
    – 将光标移到Sleep函数上,执行:GoDef或命令模式下敲入gd,Vim会打开$GOROOT/src/time/sleep.go中 的Sleep函数的定义。执行:b 1返回到hellogolang.go。
    – 执行:GoLint,运行golint在当前Go源文件上。
    – 执行:GoDoc,打开当前光标对应符号的Go文档。
    – 执行:GoVet,在当前目录下运行go vet在当前Go源文件上。
    – 执行:GoRun,编译运行当前main package。
    – 执行:GoBuild,编译当前包,这取决于你的源文件,GoBuild不产生结果文件。
    – 执行:GoInstall,安装当前包。
    – 执行:GoTest,测试你当前路径下地_test.go文件。
    – 执行:GoCoverage,创建一个测试覆盖结果文件,并打开浏览器展示当前包的情况。
    – 执行:GoErrCheck,检查当前包种可能的未捕获的errors。
    – 执行:GoFiles,显示当前包对应的源文件列表。
    – 执行:GoDeps,显示当前包的依赖包列表。
    – 执行:GoImplements,显示当前类型实现的interface列表。
    – 执行:GoRename [to],将当前光标下的符号替换为[to]。

三、其他插件

到目前为止,我们还有若干特性没能实现,重点是:

    – 实时跟随的代码补齐
    – Code Snippet support

1、安装YCM(Your Complete Me)

在~/.vimrc中添加一行:

Plugin 'Valloric/YouCompleteMe'

保存退出后,再打开~/.vimrc并执行 :P luginInstall

安装完后,下面的提示栏提示:

ycm_client_support.[so|pyd|dll] and ycm_core.[so|pyd|dll] not detected; you need to compile YCM before using it. Read the docs!

似乎YCM是用了C++编写的模块对性能进行优化了,于是需要手工编译YCM的support库。步骤如下:

sudo apt-get install build-essential cmake python-dev
cd ~/.vim/bundle/YouCompleteMe
./install.sh

构建(编译C++很慢,需要耐心的等一会)ok后,再打开hellogolang.go,逐字的实时补全功能就具备了!Cool!

2、安装 UltiSnips

Vim-go默认是用ultisnips引擎插件,但这个插件需要单独安装。

同样,我们利用vundle来安装它,在~/.vimrc中添加一行:

Plugin 'SirVer/ultisnips'

snippet和snippet引擎是分开的。ultisnips是引擎,vim-go的go snippet定义在这里

https://github.com/fatih/vim-go/blob/master/gosnippets/snippets/go.snip

编辑hellogolang.go,按照go.snip中的说明,我们输入func后敲击tab键,我们发现期待的:

func name(params) type {
       
}

并没有出现。反倒是YCM的下拉提示显示在那里让你选择。似乎是ultisnips和YCM的键组合冲突了。ultisnips官方说明也的确如 此。ultisnips默认是用Tab展开snippet的,而YCM中的Tab用来选择补齐项,我们可以通过设置来避免这些。

我们在.vimrc中添加如下setting:

" YCM settings
let g:ycm_key_list_select_completion = ['', '']
let g:ycm_key_list_previous_completion = ['']
let g:ycm_key_invoke_completion = '<C-Space>'

" UltiSnips setting
let g:UltiSnipsExpandTrigger="<tab>"
let g:UltiSnipsJumpForwardTrigger="<c-b>"
let g:UltiSnipsJumpBackwardTrigger="<c-z>"

这样让YCM通过回车和向下的箭头来做list item正向选择,通过向上箭头做反向选择。通过ctrl+space来原地触发补齐提示。

而ultisnips则是用tab做snippet展开,ctrl+b正向切换占位符,ctrl+z反向切换占位符。

3、安装molokai theme

Molokai theme是TextMate的theme的vim port,看着截图挺不错的,于是也安装了一下。

    mkdir ~/.vim/colors
    下载或copy https://github.com /fatih/molokai/blob/master/colors/molokai.vim到~/.vim /colors目录下
    在.vimrc添加一行:colorscheme molokai

四、.vimrc

前面讲到了vim-go有许多命令,在:xx模式下执行多显不便,于是你可以定义一些Mappings,比如:

" set mapleader
let mapleader = ","

" vim-go custom mappings
au FileType go nmap <Leader>s <Plug>(go-implements)
au FileType go nmap <Leader>i <Plug>(go-info)
au FileType go nmap <Leader>gd <Plug>(go-doc)
au FileType go nmap <Leader>gv <Plug>(go-doc-vertical)
au FileType go nmap <leader>r <Plug>(go-run)
au FileType go nmap <leader>b <Plug>(go-build)
au FileType go nmap <leader>t <Plug>(go-test)
au FileType go nmap <leader>c <Plug>(go-coverage)
au FileType go nmap <Leader>ds <Plug>(go-def-split)
au FileType go nmap <Leader>dv <Plug>(go-def-vertical)
au FileType go nmap <Leader>dt <Plug>(go-def-tab)
au FileType go nmap <Leader>e <Plug>(go-rename)

这样我们在命令模式下,输入<,>+<r>就是运行 当前main包,以此类推。

另外下面这个配置使得我们在save file时既可以格式化代码,又可以自动插入包导入语句(或删除不用的包导入语句)。

" vim-go settings
let g:go_fmt_command = "goimports"

到这里,我们的Vim Golang开发环境就基本搭建好了。snippet+实时补齐让你Coding如飞!

五、附录:.vimrc文件

下面是截至目前为止全量.vimrc文件的内容:

set nocompatible              " be iMproved, required
filetype off                  " required
colorscheme molokai

" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()

" let Vundle manage Vundle, required
Plugin 'gmarik/Vundle.vim'
Plugin 'fatih/vim-go'
Plugin 'Valloric/YouCompleteMe'

Plugin 'SirVer/ultisnips'

" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required

" set mapleader
let mapleader = ","

" vim-go custom mappings
au FileType go nmap <Leader>s <Plug>(go-implements)
au FileType go nmap <Leader>i <Plug>(go-info)
au FileType go nmap <Leader>gd <Plug>(go-doc)
au FileType go nmap <Leader>gv <Plug>(go-doc-vertical)
au FileType go nmap <leader>r <Plug>(go-run)
au FileType go nmap <leader>b <Plug>(go-build)
au FileType go nmap <leader>t <Plug>(go-test)
au FileType go nmap <leader>c <Plug>(go-coverage)
au FileType go nmap <Leader>ds <Plug>(go-def-split)
au FileType go nmap <Leader>dv <Plug>(go-def-vertical)
au FileType go nmap <Leader>dt <Plug>(go-def-tab)
au FileType go nmap <Leader>e <Plug>(go-rename)

" vim-go settings
let g:go_fmt_command = "goimports"

" YCM settings
let g:ycm_key_list_select_completion = ['', '']
let g:ycm_key_list_previous_completion = ['', '']
let g:ycm_key_invoke_completion = '<C-Space>'

" UltiSnips settings
let g:UltiSnipsExpandTrigger="<tab>"
let g:UltiSnipsJumpForwardTrigger="<c-b>"
let g:UltiSnipsJumpBackwardTrigger="<c-z>"

六、Mac OS X下Vim配置

1、MacVim替换

Mac OS X下的配置方法稍有不同,因为Mac下系统自带的Vim是7.3版本,YCM要求Vim 7.3.584+版本,因此我们需要安装MacVim以替代自带的Vim,目前MacVim最新版本是version 7.4.258,完全满足要求。在这里https://github.com/b4winckler/macvim/releases可以下载到最新的MacVim,下载后的MacVim可以通过如下步骤替换原Vim。

原Vim安装到/usr/bin/vim下。

MacVim解压后如下:

[tony@tonydeair ~/Downloads/MacVim-snapshot-73]$ls
MacVim.app/    README.txt    mvim*

我们执行以下步骤即可完成vim替换工作:

sudo mv /usr/bin/vim /usr/bin/vim.bak //备份一下原vim
cp mvim /usr/local/bin/
sudo ln -s /usr/local/bin/mvim /usr/bin/vim

2、插件安装和配置

按照上面Linux Vim的插件安装步骤和配置方法我们来配置MacVim,配置后,我们发现除了molokai的colorscheme没有生效外,其余插件工作均正常。而所有.go文件打开,均无molokai方案的颜色高亮,甚至连一般的颜色高亮都没有了。经过不断调试,发现了一个解决方法,在~/.vimrc中添加几行代码即可:

syntax on
au BufRead,BufNewFile *.go set filetype=go
colorscheme molokai

但这几行配置代码如果放在~/.vimrc的前面,则UltiSnips会无法工作,我将其移到~/.vimrc文件的末尾,这样就不存在冲突了(看来.vimrc的插件配置的先后顺序会对插件功能的正常使用有影响)。漂亮的molokai colorscheme也会展现出来!

Go语言是如何处理栈的

3 Comments

Go 1.4Beta1刚刚发布,在Go 1.4Beta1中,Go语言的stack处理方式由之前的"segmented stacks"改为了"continuous stacks"。关于Go语言对stack的处理机制、发展历史、存在问题等,CloudFlare的一篇官方blog进行了系统的阐述,这里的内容就是 翻译自CloudFlare的那篇blog:《How Stacks are Handled in Go》。

在CloudFlare,我们使用Go语言实现各种服务和应用。在这篇博文中,我们将带领大家深入挖掘一些Go的某些纷繁复杂的技术细节。

Go语言的重要特性之一是goroutines。它们是代价低廉、协同调度的执行线程,被用于实现各种操作,诸如timeout、生成器、相互竞 争的后端程序。为了使goroutines可以适应更多地任务,我们不仅需要保证每个goroutines的内存最小占用量,还要保证人们可以使 用最低配置将它们启动起来。

为了实现这个目标,Go语言采用了栈管理,这一与其他编程语言类似的方案,但在具体实现层面,又与其他语言有着较大的不同。

一、线程栈(thread stacks)介绍

在我们研究Go的栈处理方式之前,我们先来看看传统语言,比如C是如何进行栈管理的。

当你启动一个C实现的thread时,C标准库会负责分配一块内存作为这个线程的栈。标准库分配这块内存,告诉内核它的位置并让内核处理这个线程 的执行。不过当这块内存不够用时,问题就来了,我们来看一下下面这个函数:

int a(int m, int n) {
    if (m == 0) {
        return n + 1;
    } else if (m > 0 && n == 0) {
        return a(m – 1, 1);
    } else {
        return a(m – 1, a(m, n – 1));
    }
}

这个函数大量使用递归,执行a(4, 5)就会降所有栈内存耗尽。要解决这个问题,你可以调整标准库给线程栈分配的内存块的大小。但是全线提高栈大小意味着每个线程都会提高栈的内存使用量,即 便它们不是大量采用递归方式的。这样一来,你将用光所有内存,即便你的程序还尚未使用栈上的内存。

另外一种可选的解决方法则是为每个线程单独确定栈大小。这样一来你就不得不完成这样的任务:根据每个线程的需要,估算它们的栈内存的大小。这将是 创建线程的难度超出我们的期望。想搞清楚一般情况下一个线程栈需要多少内存是不可行的,即便是通常情况也是非常困难的。

二、Go是如何应对这个问题的

Go运行时会试图按需为goroutine提供它们所需要的栈空间,而不是为每个goroutine分配一个固定大小的栈空间。这样可以把程序员 们从决定栈空间大小的烦心事中解脱了出来。不过Go核心团队正在尝试切换到另外一种方案,这里我将尝试阐述旧方案以及它的缺点,新方案以及为何要 做出如此改变。

三、分段栈(Segmented Stacks)

分段栈(segmented stacks)是Go语言最初用来处理栈的方案。当创建一个goroutine时,Go运行时会分配一段8K字节的内存用于栈供goroutine运行使 用,我们让goroutine在这个栈上完成其任务处理。

当我们用光这8K字节的栈空间后,问题随之而来。为了解决这个问题,每个go函数在函数入口处都会有一小段代码(called prologue),这段代码会检查是否用光了已分配的栈空间,如果用光了,这段代码会调用morestack函数。

morestack函数会分配一段新内存用作栈空间,接下来它会将有关栈的各种数据信息写入栈底的一个struct中(译注:下图中Stack info),包括上一段栈的地址。有点我们拥有了一个新的栈段(stack segment),我们将重启goroutine,从导致栈空间用光的那个函数(译注:下图中的Foobar)开始执行。这就是所谓的“栈分裂 (stack split)”。

下面的栈示意图刚好是我们进行栈分裂后的情形:

在新栈的底部,我们插入了一个栈入口函数lessstack。我们不会调用该函数,设置这个函数就是用于我们从那个导致我们用光栈空间的函数(译 注:Foobar)返回时用的。当那个函数(译注:Foobar)返回时,我们回到lessstack(这个栈帧),lessstack会查找 stack底部的那个struct,并调整栈指针(stack pointer),使得我们返回到前一段栈空间。这样做之后,我们就可以将这个新栈段(stack segment)释放掉,并继续执行我们的程序了。

四、分段栈(Segmented stacks)的问题

分段栈给了我们具备按需伸缩能力的栈。程序员们无需担心计算栈的大小了,启动一个新的goroutine代价低廉并且程序员不会知道栈将增长多 大。

这就是直到目前Go语言处理stack增长的方法,但是这个方法有个瑕疵。那就是栈缩小会是一个相对代价高昂的操作。如果你在一个循环遇到栈分裂 (stack split),你会最有感触。一个函数会增加栈空间,做栈分裂,返回并释放栈段(stack segment)。如果你在一个循环中进行这些,你会付出很大的代价(性能方面)。

这就是所谓的“hot split”问题。它也是Go核心开发组更换到一个新的栈管理方案-栈拷贝(stack copying)的主要原因。

五、栈拷贝(stack copying)

栈拷贝初始阶段与分段栈类似。goroutine在栈上运行着,当用光栈空间,它遇到与旧方案中相同的栈溢出检查。但是与旧方案采用的保留一个返 回前一段栈的link不同,新方案创建一个两倍于原stack大小的新stack,并将旧栈拷贝到其中。这意味着当栈实际使用的空间缩小为原先的 大小时,go运行时不用做任何事情。栈缩小是一个无任何代价的操作。此外,当栈再次增长时,运行时也无需做任何事情,我们只需要重用之前分配的空 闲空间即可。

六、栈是怎么拷贝的

拷贝栈听起来简单,但实际上它是一件有难度的事情。因为Go中栈上的变量都有自己的地址,一旦你拥有指向栈上变量的指针,这种情况下你就无法如你 所愿。当你移动栈时,指向原栈的指针都将变为无效指针。

幸运的是,只有在栈上分配的指针才能指向栈上的地址。这点对于内存安全是极其必要的,否则,程序可能会访问到已不再使用了的栈上的地址。

由于我们需要知道那些需要被垃圾收集器回收的指针的位置,因此我们知道栈上哪些部分是指针。当我们移动栈时,我们可以更新栈里地指针使其指向新的 目标地址,并且所有相关的指针都要被照顾到。

由于我们使用垃圾回收的信息来协助完成栈拷贝,因此所有出现在栈上的函数都必须具备这些信息。但事情不总是这样的。因为Go运行时的大部分代码是 用C编写的,大量的运行时调用没有指针信息可用,这样就无法进行拷贝。一旦这种情况发生,我们又不得不退回到分段栈方案,并接受为其付出的高昂代 价。

这就是当前Go运行时开发者大规模重写Go runtime的原因。那些无法用Go重写的代码,比如调度器和垃圾收集器的内核,将在一个特殊的栈上执行,这个特殊栈的size由runtime开发者 单独计算确定。

除了让栈拷贝成为可能之外,这个方法还会使得我们在未来能够实现出并发垃圾回收等特性。

七、关于虚拟内存

另外一种不同的栈处理方式就是在虚拟内存中分配大内存段。由于物理内存只是在真正使用时才会被分配,因此看起来好似你可以分配一个大内存段并让操 作系统处理它。下面是这种方法的一些问题

首先,32位系统只能支持4G字节虚拟内存,并且应用只能用到其中的3G空间。由于同时运行百万goroutines的情况并不少见,因此你很可 能用光虚拟内存,即便我们假设每个goroutine的stack只有8K。

第二,然而我们可以在64位系统中分配大内存,它依赖于过量内存使用。所谓过量使用是指当你分配的内存大小超出物理内存大小时,依赖操作系统保证 在需要时能够分配出物理内存。然而,允许过量使用可能会导致一些风险。由于一些进程分配了超出机器物理内存大小的内存,如果这些进程使用更多内存 时,操作系统将不得不为它们补充分配内存。这会导致操作系统将一些内存段放入磁盘缓存,这常常会增加不可预测的处理延迟。正是考虑到这个原因,一 些新系统关闭了对过量使用的支持。

八、结论

为了使goroutine使用代价更加低廉,更快速,适合更多task情况,Go开发组做出了很多努力。栈管理只是其中一小部分。如果你想了解更 多关于栈拷贝的细节,可以参考其设计文档。此外,如果你想了解更多有关Go运行 时重写的细节,这里有一个mail list

Go 1.4中值得关注的几个变化

1 Comment

在Go 1.3发布半年过去后,Go核心项目组于本月初发布了Go 1.4 Beta1版本。这个版本的几个变化点虽然不是革命性的,但对后续Go语言的发展来说,打下了基础,定下了基调。这里就几个值得关注的变化点结合Go 1.4代码进行一些简单描述,希望大家能对Go 1.4有个感性的认知和了解。

Go 1.4依旧保持了Go 1兼容性的承诺,你的已有代码几乎无需任何改动就可以通过Go 1.4的编译并运行。(以下是我的测试环境:go version go1.3 darwin/amd64 vs. go version go1.4beta1 linux/amd64

一、语言变化

1、For-range循环

在Go 1.3及以前,for-range循环具有两种形式:

for k, v := range x {
    …
}

for k := range x {
    …
}

问题:如果我们不关心循环中的值,我们只关心循环本身,我们仍然要提供一个变量,或用_占位。

for _ = range x {
    …
}

下面这样的语法在Go 1.3及以前是无法编译通过的:

for range x {
    …
}

不过Go 1.4支持这种形式的语法,它使得代码更加clean,虽然它可能很少会被使用到。

例子:

//testforrange.go

package main

import "fmt"

func main() {
        var a [5]int = [5]int{2, 3, 4, 5, 6}
        for k, v := range a {
                fmt.Println(k, v)
        }

        for k := range a {
                fmt.Println(k)
        }

        for _ = range a {
                fmt.Println("print without care about the key and value")
        }

        for range a {
                fmt.Println("new syntax – print without care about the key and value")
        }
}

Go 1.3编译出错:

$go run testforrange.go
# command-line-arguments
./testforrange.go:19: syntax error: unexpected range, expecting {
./testforrange.go:22: syntax error: unexpected }

Go 1.4编译成功并输出正确结果:

0 2
1 3
2 4
3 5
4 6
0
1
2
3
4
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value

2、通过**T调用方法

下面这个例子:

package main

import "fmt"

type T int

func (T) M() {
        fmt.Println("Call M")
}

var x **T

func main() {
        x.M()
}

按照Go 1.4官方release note的说法,1.3版本及以前的gc和gccgo都会正常接受这种调用方式。但Go 1规范只允许自动在x前面加一个解引用,而不是两个,因此这个是有悖于定义的。Go 1.4强制禁止这种调用。

不过根据我实际的测试,Go 1.3和Go 1.4针对上面代码都会出现同样地编译错误。

$go run testdoubledeferpointer.go
# command-line-arguments
./testdoubledeferpointer.go:14: calling method M with receiver x (type **T) requires explicit dereference

二、支持的操作系统以及处理器体系架构的变化

这个无法演示。不过一个主要的变化就是Go 1.4可以构建出运行于ARM处理器Android操作系统上的二进制程序了。使用go.mobile库中的支持包,Go 1.4也可以构建出可以被Android应用加载的.so库。

三、兼容性变化

人们通过unsafe包并利用Go的内部实现细节和数据的机器表示形式来绕过Go语言类型系统的约束。Go的设计者们认为这是对Go兼容性规范的 不尊重,在Go 1.4中,Go核心组正式宣布unsafe code不再保证其兼容性。这次Go 1.4并没有针对此做任何代码变动,只是一个clarification而已。

四、实现和工具的变化

1、运行时(runtime)的变化

Go 1.3及以前版本,Go语言的runtime(垃圾收集、并发支持、interface管理、maps、slices、strings等)主要由C语言和 少量汇编语言实现的。在1.4版本中,很多代码被替换成了用Go自身实现,这样垃圾回收器可以扫描程序运行时栈,获取活跃变量的精确信息。这个变 化很大,但对程序应该没有语义上的影响。

这次重写使得垃圾回收器变得更加精确,这意味着它知道所有程序中活跃指针的位置。这些相关改变将减小heap的大小,总体上大约减少 10%~30%。

这样做的结果是栈也不再需要是分段的(segmented)了,消除了“hot split”的问题。如果一个stack到达了使用上限,Go将分配一个新的更大的stack,相应goroutine中的所有活跃的栈帧将被复制到新 stack上,所有指向栈的指针将被更新。在某些场景下,其性能将会变得显著提升,并且这样修改后,其性能更具可预测性。

连续栈(contiguous stacks)的使用使得栈的初始Size可以更小,在Go 1.4中goroutine的初始栈大小从8192字节缩小为2048字节。(正式发布时也许会改为4096)。

interface值类型的实现也做了调整。在之前的发布版中,interface值内部用一个字(word)来承载,要么是一个指针,要么是一 个单字(one-word)大小的纯量值,这取决于interface值变量中具体存储的是什么对象。这个实现会给垃圾收集器带来诸多困难,因此 在Go 1.4版本中interface值内部就用指针表示。在运行的程序中,绝大多数interface值都是指针,因此这个影响很小。不过那些在 interface值类型变量中存储整型值的程序将会有更多的内存分配。

2、gccgo的状态

Gcc和Go两个项目的发布计划不是同步的,GCC 4.9版本包含了实现了1.2规范的gccgo,下一个发布版gcc 5.0将可能包含实现了1.4规范的gccgo。

3、internal包(内部包)

Go以package为基本逻辑单元组织代码。Go 1.3及之前版本的Go语言实际上只支持两种形式Package内符号的可见性:本地的(unexported)和全局的(exported)。有些时候 我们希望一些包并非能被所有外部包所导入,但却能被其“临近”的包所导入和访问。但之前的Go语言不具备这种特性。Go 1.4引入了"internal"包的概念,导入这种internal包的规则约束如下:

如果导入代码本身不在以"internal"目录的父目录为root的目录树中,那么 不允许其导入路径(import path)中包含internal元素。

例如:
    – a/b/c/internal/d/e/f只可以被以a/b/c为根的目录树下的代码导入,不能被a/b/g下的代码导入。
    – $GOROOT/src/pkg/internal/xxx只能被标准库($GOROOT/src)中的代码所导入。(注:Go 1.4 取消了$GOROOT/src/pkg,标准库都移到$GOROOT/src下了)。
    – $GOROOT/src/pkg/net/http/internal只能被net/http和net/http/*的包所导入
    – $GOPATH/src/mypkg/internal/foo只能被$GOPATH/src/mypkg包的代码所导入

对于Go 1.4该规则首先强制应用于$GOROOT下。Go 1.5将扩展应用到$GOPATH下。

4、权威导入路径(import paths)

我们经常使用托管在公共代码托管服务中的代码,诸如github.com,这意味着包导入路径包含托管服务名,比如github.com/rsc /pdf。一些场景下为了不破坏用户代码,我们用rsc.io/pdf,屏蔽底层具体哪家托管服务,比如rso.io/pdf的背后可能是 github.com也可能是bitbucket。但这样会引入一个问题,那就是不经意间我们为一个包生成了两个合法的导入路径。如果一个程序中 使用了这两个合法路径,一旦某个路径没有被识别出有更新,或者将包迁移到另外一个不同的托管公共服务下去时,使用旧导入路径包的程序就会报错。

Go 1.4引入一个包字句的注释,用于标识这个包的权威导入路径。如果使用的导入的路径不是权威路径,go命令会拒绝编译。语法很简单:

package pdf // import "rsc.io/pdf"

如果pdf包使用了权威导入路径注释,那么那些尝试使用github.com/rsc/pdf导入路径的程序将会被go编译器拒绝编译。

这个权威导入路径检查是在编译期进行的,而不是下载阶段。

我们举个例子:

我们的包foo以前是放在github.com/bigwhite/foo下面的,后来主托管站换成了tonybai.com/foo,最新的 foo包的代码:

package foo // import "tonybai.com/foo"

import "fmt"

func Echo(a string) {
        fmt.Println("Foo:, a)
}

某个应用通过旧路径github.com/bigwhite/foo导入了该包:

//testcanonicalimportpath.go
package main

import "github.com/bigwhite/foo"

func main() {
        foo.Echo("Hello!")
}

我们编译该go文件,得到以下结果:

code in directory /home/tonybai/Test/Go/src/github.com/bigwhite/foo expects import "tonybai.com/foo"

5、go generate子命令

go 1.4中go工具集合新引入一个子命令:go generate,用于在编译前自动化生成某类代码。例如在.y上运行yacc编译器生成实现该语法的.go源文件。或是使用stringer工 具自动为常量生成String方法。这个命令并非由go tools(build, get等)自动执行,而必须显式执行。

不过我简单测试了一下,似乎这个命令设计文档中的:

// +build generate

并不好用啊。即便将其作为generate directive放入go源文件,该文件依旧会被go编译器当做正常go文件编译。Go 1.4标准库中使用go generate directive的有三个地方:

strconv/quote.go://go:generate go run makeisprint.go -output isprint.go
time/zoneinfo_windows.go://go:generate go run genzabbrs.go -output zoneinfo_abbrs_windows.go
unicode/letter.go://go:generate go run maketables.go -tables=all -output tables.go

通过go generate来实现泛型(generics)似乎不那么优雅啊。虽然设计者并非将其作为Go泛型的实现^_^。

6、源码布局变化

在Go自身源码库($GOROOT下)中,包的源码放在src/pkg中,这样做与其他库不同,包括Go自己的子库,比如go.tools。因此在Go 1.4中,pkg这一层目录树将被去除,比如fmt包的源码曾经放在src/pkg/fmt下,现在则放在src/fmt下。

五、性能

绝大多数程序使用1.4编译后的运行速度会与1.3的一致或略有提升,有些可能也会变得慢些。这次修改的较多,很难准确预测。

这次许多runtime的代码由C变为Go,这将导致一些heap大小有所缩减。另外这样做后有利于Go编译器的优化,诸如内联,会带来性能上的小幅提升。

垃圾回收器一方面得到了加速,使得重度依赖垃圾收集的程序得到可衡量的提升。但另外一方面,新的write barrier又引起了性能下降。提升和下降的量的多少取决于程序的行为。

WordPress迁移到Docker容器

No Comments

目前的Blog托管在同事的一个共享主机上,由于种种原因,这个主机即将无法使用,我只能再次迁移我的WordPress,不得不感叹:铁打的Wordpress,流水的主机啊!

这次迁移前,我仔细考量了一番,如何能让以后可能出现的Wordpress迁移最简化呢?虽然现在的迁移也不是特别复杂。我想到了近期研究的 Docker。目前很多国外的VPS都已经支持了Docker,我只需要在本地制作好Docker容器导出,再导入目标VPS的Docker中即可完成迁 移。在真正做迁移前,我打算在实验环境下测试一下。以下是将Wordpress迁移到Docker容器的测试过程。

一、容器准备

1、下载镜像

WordPress主要就是两个部分组成:wordpress程序 + mysql数据库。Docker官方registery提供了Wordpress和MySQL的image,我们可以直接pull使用。考虑到外站速度较 慢,这里我使用了国内镜像站点dockerpool.com提供的镜像了。

sudo docker pull dl.dockerpool.com:5000/wordpress:4.0.0
sudo docker pull dl.dockerpool.com:5000/mysql:5.6.20

考虑到使用phpmyadmin操作mysql数据的方便性,我又找了一个phpmyadmin的image:

sudo docker pull corbinu/docker-phpmyadmin

2、启动容器

mysql作为数据库数据存储镜像,在启动是会被wordpress和phpmyadmin link的,这样后两者在各自容器内才能顺利访问mysql服务和数据库。

按顺序启动容器(mysql为最先启动):
sudo docker run –name blogmysql -e MYSQL_ROOT_PASSWORD=root -d dl.dockerpool.com:5000/mysql:5.6.20
sudo docker run –name blogwordpress –link blogmysql:mysql -p 80:80 -d dl.dockerpool.com:5000/wordpress:4.0.0
sudo docker run –name blogphpmyadmin -e MYSQL_USERNAME=root –link blogmysql:mysql -p 8000:80 -d corbinu/docker-phpmyadmin

三个容器均可以顺利启动。mysql数据库的访问方式是root/root。wordpress默认为80端口,phpmyadmin用8000端口访问,你可以试试http://localhost:80和http://localhost:8000。

$ sudo docker ps
CONTAINER ID        IMAGE                                 COMMAND                CREATED             STATUS              PORTS                  NAMES
a30540120b5d        corbinu/docker-phpmyadmin:latest      "/bin/sh -c phpmyadm   5 seconds ago       Up 3 seconds        0.0.0.0:8000->80/tcp   blogphpmyadmin     
a88c456bf840        dl.dockerpool.com:5000/wordpress:4    "/entrypoint.sh apac   37 seconds ago      Up 35 seconds       0.0.0.0:80->80/tcp     blogwordpress      
1b6f84f428e3        dl.dockerpool.com:5000/mysql:5.6.20   "/entrypoint.sh mysq   45 seconds ago      Up 44 seconds       3306/tcp               blogmysql  

访问phpmyadmin,使用root/root登录后,我们可以看到主页上得数据库信息:

Database server

Server: 172.17.0.2 via TCP/IP
Server type: MySQL
Server version: 5.6.20 – MySQL Community Server (GPL)
Protocol version: 10
User: root@172.17.0.4
Server charset: UTF-8 Unicode (utf8)
Web server

nginx/1.7.1
Database client version: libmysql – 5.6.20
PHP extension: mysqli Documentation
phpMyAdmin

Version information: 4.2.7.1, latest stable version: 4.2.10.1

3、install wordpress

第一次通过http://locahost:80访问wordpress,便进入了wordpress安装流程,这个镜像中携带的版本是wordpress 4.0.0。

step1:
    选择安装语言:简体中文

step2:
    填写站点名称、用户名、密码、邮件等。

安装ok后,你就进入到了Wordpress 4.0.0的管理后台。
 

二、迁移

1、导出备份

目前的Blog使用的是DirectAdmin管理面板。通过DirectAdmin我们可以将当前的Wordpress站点整个下载,下载包中包含:

$ls
backup/        domains/

domains/tonybai.com/public_html下就是你的wordpress程序以及相关配置、插件等数据。
backup/xxx.sql就是数据库导出文件。

我们需要将这两部分恢复到Docker中。

2、数据表导入

我曾经试过通过WP-DB-Backup导出sql文件,再通过phpmyadmin导入的方法,但WP-DB-Backup导出的sql文件较大(>2M),无法满足phpmyadmin对导入文件的要求(<=2m),于是总是失败。之后决定通过mysql直接执行sql脚本导入。

首先通过phpmyadmin在mysql中建立数据库xx_db,编码:utf8_general_ci。

然后将上面的backup/xxx.sql拷贝到blogmysql容器中,比如就放在/root/下。然后通过nscenter进入到blogmysql容器中,切换到/usr/local/mysql/bin下,执行如下命令:

$ ./mysql -u root -p
输入root,进入mysql

在mysql下执行:
mysql > use xx_db
mysql > source /root/xxx.sql

如无意外,数据将顺利导入mysql的xx_db下。

3、wordpress导入

通过docker nsenter工具进入blogwordpress容器,进入/var/www目录下:

$ cp -r html html.bak
$ rm -fr html/*

再将上面提到的public_html下面的文件悉数copy到html下。

打开浏览器,输入http://localhost:80,会出现错误提示:"您在 wp-config.php 文件中提供的数据库用户名和密码可能不正确,或者无法连接到 localhost 上的数据库服务器"。

我们需要修改wp-config.php中的数据库连接信息。

define('DB_NAME', 'bigwhite_db');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'mysql');

再次刷新浏览器,依旧无法正确打开。重启blogwordpress容器后,wordpress终于可以打开了,但打开的wordpress管理页面连接 的数据库不对,我的文章并没有出现在文章列表中,这是一个新库。于是通过docker logs查看blogwordpress日志,进入blogwordpress查看wp-config.php的内容,我惊奇的发现:wp- config.php中的DB_NAME被改回'wordpress'了,而没有使用导入的"bigwhite_db"。

多次修改回bigwhite_db并重启容器后,这个值均被改为wordpress。无奈只好通过phpmyadmin删除wordpress库,重新创 建wordpress库并采用同样方法导入xx.sql,使得wordpress这个db与bigwhite_db拥有同样地内容。这回再打开 wordpress,一切尽在眼前。

迁移实验成功!这样我们将迁移后的容器导出,再导入你的支持docker的VPS中,无需任何其余操作即可完成真正的迁移。目前Digital Ocean已经支持了Docker,Aliyun据说也拥抱了Docker。

Older Entries