前段时间，由于工作上的原因，与Docker的联系发生了几个月的中断^_^，从10月份开始，工作中又与Docker建立了广泛密切的联系。不过这次，Docker却给我泼了一盆冷水:(。事情的经过请允许多慢慢道来。

经过几年的开发，Docker已经成为轻量级容器领域不二的事实标准，应用范围以及社区都在快速发展和壮大。今年的年中，Docker发布了其里程碑的版本Docker 1.12，该版本最大的变动就在于其引擎自带了swarmkit ，一款Docker开发的容器集群管理工具，可以让用户无需安装第三方公司提供的工具或Docker公司提供的引擎之外的工具，就能搭建并管理好一个容器集群，并兼有负载均衡、服务发现和服务编排管理等功能。这对于容器生态圈内的企业，尤其是那些做容器集群管理和服务编排平台的公司来说，不亚于当年微软在Windows操作系统中集成Internet Explorer。对此，网上和社区对Docker口诛笔伐之声不绝于耳，认为Docker在亲手打击社区，葬送大好前程。关于商业上的是是非非，我们这里暂且不提。不可否认的是，对于容器的普通用户而言，Docker引擎内置集群管理功能带来的更多是便利。

9月末启动的一款新产品的开发中，决定使用容器技术，需要用到容器的集群管理以及服务伸缩、服务发现、负载均衡等特性。鉴于团队的能力和开发时间约束，初期我们确定直接利用Docker 1.12版本提供的这些内置特性，而不是利用第三方，诸如k8s或Rancher这样的第三方容器集群管理工具或是手工利用各种开源组件“拼凑”出一套满足需求的集群管理系统，如利用consul做服务注册和发现等。于是Docker 1.12的集群模式之旅就开始了。

一、环境准备

这次我们直接使用的是阿里的公有云虚拟主机服务，这里使用两台aliyun ECS：

manager: 10.46.181.146/21(内网)
worker: 10.47.136.60/22 (内网）

系统版本为：

Ubuntu 14.04.4:
Linux iZ25cn4xxnvZ 3.13.0-86-generic #130-Ubuntu SMP Mon Apr 18 18:27:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Docker版本：

# docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

在Ubuntu上Docker的安装日益方便了，我个人习惯于采用daocloud推荐的方式，在这里可以看到。当然你也可以参考Docker官方的doc。

如果你的Ubuntu上已经安装了old版的Docker，也可以在docker的github上下载相应平台的二进制包，覆盖本地版本即可（注意1.10.0版本前后的Docker组件有所不同）。

二、Swarm集群搭建

Docker 1.12内置swarm mode，即docker原生支持的docker容器集群管理模式，只要是执行了docker swarm init或docker swarm join到一个swarm cluster中，执行了这些命令的host上的docker engine daemon就进入了swarm mode。

swarm mode中，Docker进行了诸多抽象概念（这些概念与k8s、rancher中的概念大同小异，也不知是谁参考了谁^_^）：

- node: 部署了docker engine的host实例，既可以是物理主机，也可以是虚拟主机。
- service: 由一系列运行于集群容器上的tasks组成的。
- task: 在具体某个docker container中执行的具体命令。
- manager: 负责维护docker cluster的docker engine，通常有多个manager在集群中，manager之间通过raft协议进行状态同步，当然manager角色engine所在host也参与负载调度。
- worker: 参与容器集群负载调度，仅用于承载tasks。

swarm mode下，一个Docker原生集群至少要有一个manager，因此第一步我们就要初始化一个swarm cluster：

# docker swarm init --advertise-addr 10.46.181.146
Swarm initialized: current node (c7vo4qtb2m41796b4ji46n9uw) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
    10.46.181.146:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

通过一行swarm init命令，我们就创建了一个swarm集群。同时，Docker daemon给出了清晰提示，如果要向swarm集群添加worker node，执行上述提示中的语句。如果其他node要以manager身份加入集群，则需要执行：docker swarm join-token manager以获得下一个“通关密语”^_^。

# docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-8wh5gp043i1cqz4at76wvx29m \
    10.46.181.146:2377

对比两个“通关密语”，我们发现仅是token串的后半部分有所不同(2mg011xh7vso9hu7x542uizpt vs. 8wh5gp043i1cqz4at76wvx29m)。

在未添加新node之前，我们可以通过docker node ls查看当前集群内的node状态：

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

可以看出当前swarm仅有一个node，且该node是manager，状态是manager中的leader。

我们现在将另外一个node以worker身份加入到该swarm：

# docker swarm join \
     --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
     10.46.181.146:2377
This node joined a swarm as a worker.

在manager上查看node情况：

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
8asff8ta70j91myh734os6ihg    iZ25cn4xxnvZ  Ready   Active
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

Swarm集群中已经有了两个active node：一个manager和一个worker。这样我们的集群环境初建ok。

三、Service启动

Docker 1.12版本宣称提供服务的Scaling、health check、滚动升级等功能，并提供了内置的dns、vip机制，实现service的服务发现和负载均衡能力。接下来，我们来测试一下docker的“服务能力”：

我们先来创建一个用户承载服务的自定义内部overlay网络：

root@iZ25mjza4msZ:~# docker network create -d overlay mynet1
avjvpxkfg6u8xt0qd5xynoc28
root@iZ25mjza4msZ:~# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
dba1faa24c0d        bridge              bridge              local
a2807d0ec7ed        docker_gwbridge     bridge              local
2b6eb8b95c00        host                host                local
55v43pasf7p9        ingress             overlay             swarm
avjvpxkfg6u8        mynet1              overlay             swarm
6f2d47678226        none                null                local

我们看到在network list中，我们的overlay网络mynet1出现在列表中。这时，在worker node上你还看不到mynet1的存在，因为按照目前docker的机制，只有将归属于mynet1的task调度到worker node上时，mynet1的信息才会同步到worker node上。

接下来就是在mynet1上启动service的时候了，我们先来测试一下：

在manager节点上，用docker service命令启动服务mytest：

# docker service create --replicas 2 --name mytest --network mynet1 alpine:3.3 ping baidu.com
0401ri7rm1bdwfbvhgyuwroqn

似乎启动成功了，我们来查看一下服务状态：

root@iZ25mjza4msZ:~# docker service ps mytest
ID                         NAME          IMAGE       NODE          DESIRED STATE  CURRENT STATE                     ERROR
73hyxfhafguivtrbi8dyosufh  mytest.1      alpine:3.3  iZ25mjza4msZ  Ready          Preparing 1 seconds ago
c5konzyaeq4myzswthm8ax77w   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 1 seconds ago              "starting container failed: co…"
6umn2qlj34okagb4mldpl6yga   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 6 seconds ago              "starting container failed: co…"
5y7c1uoi73272uxjp2uscynwi   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 11 seconds ago             "starting container failed: co…"
4belae8b8mhd054ibhpzbx63q   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 16 seconds ago             "starting container failed: co…"

似乎服务并没有起来，service ps的结果告诉我：出错了！

但从ps的输出来看，ERROR那行的日志太过简略：“starting container failed: co…” ，无法从这里面分析出失败原因，通过docker logs查看失败容器的日志（实际上日志是空的）以及通过syslog查看docker engine的日志都没有特殊的发现。调查了许久，无意中尝试手动重启一下失败的Service task：

# docker start 4709dbb40a7b
Error response from daemon: could not add veth pair inside the network sandbox: could not find an appropriate master "ov-000101-46gc3" for "vethf72fc59"
Error: failed to start containers: 4709dbb40a7b

从这个Daemon返回的Response Error来看似乎与overlay vxlan的网络驱动有关。又经过搜索引擎的确认，大致确定可能是因为host的kernel version太low导致的，当前kernel是3.13.0-86-generic，记得之前在docker 1.9.1时玩vxlan overlay我是将kernel version升级到3.19以上了。于是决定升级kernel version。

升级到15.04 ubuntu版本的内核：

命令：

    apt-get install linux-generic-lts-vivid

升级后：

# uname -a
Linux iZ25cn4xxnvZ 3.19.0-70-generic #78~14.04.1-Ubuntu SMP Fri Sep 23 17:39:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

reboot虚拟机后，重新启动mytest service，这回服务正常启动了。看来升级内核版本这味药是对了症了。

这里issue第一个吐槽：Docker强依赖linux kernel提供的诸多feature，但docker似乎在kernel版本依赖这块并未给出十分明确的对应关系，导致使用者莫名其妙的不断遇坑填坑，浪费了好多时间。

顺便这里把service的基本管理方式也一并提一下：

scale mytest服务的task数量从2到4：

docker service scale mytest=4

删除mytest服务：

docker service rm mytest

服务删除执行后，需要一些时间让docker engine stop and remove container instance。

四、vip机制测试

Docker 1.12通过集群内置的DNS服务实现服务发现，通过vip实现自动负载均衡。单独使用DNS RR机制也可以实现负载均衡，但这种由client端配合实现的机制，无法避免因dns update latency导致的服务短暂不可用的情况。vip机制才是相对理想的方式。

所谓Vip机制，就是docker swarm为每一个启动的service分配一个vip，并在DNS中将service name解析为该vip，发往该vip的请求将被自动分发到service下面的诸多active task上（down掉的task将被自动从vip均衡列表中删除）。

我们用nginx作为backend service来测试这个vip机制，首先在集群内启动mynginx service，内置2个task，一般来说，docker swarm会在manager和worker node上各启动一个container来承载一个task：

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true  nginx:1.10.1
3n7dlr8km9v2xd66bf0mumh1h

一切如预期，swarm在manager和worker上各自启动了一个nginx container:

# docker service ps mynginx
ID                         NAME       IMAGE         NODE          DESIRED STATE  CURRENT STATE               ERROR
bcyffgo1q3i5x0qia26fs703o  mynginx.1  nginx:1.10.1  iZ25mjza4msZ  Running        Running about a minute ago
arkol2l7gpvq42f0qytqf0u85  mynginx.2  nginx:1.10.1  iZ25cn4xxnvZ  Running        Running about a minute ago

接下来，我们尝试在mynet1中启动一个client container，并在client container中使用ping、curl对mynginx service进行vip机制的验证测试。client container的image是基于ubuntu:14.04 commit的本地image，只是在官方image中添加了curl, dig, traceroute等网络探索工具，读者朋友可自行完成。

我们在manager node上尝试启动client container:

# docker run -it --network mynet1 ubuntu:14.04 /bin/bash
docker: Error response from daemon: swarm-scoped network (mynet1) is not compatible with `docker create` or `docker run`. This network can only be used by a docker service.
See 'docker run --help'.

可以看到：直接通过docker run的方式在mynet1网络里启动container的方法失败了，docker提示：docker run与swarm范围的网络不兼容。看来我们还得用docker service create的方式来做。

# docker service create --replicas 1 --name myclient --network mynet1 test/client tail -f /var/log/bootstrap.log
0eippvade7j5e0zdyr5nkkzyo

# docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS                    NAMES
4da6700cdf4d        test/client:latest   "tail -f /var/log/boo"   33 seconds ago      Up 32 seconds                                myclient.1.3cew8x46i5b28e2q3kd1zz3mq

我们使用exec命令attach到client container中：

root@iZ25mjza4msZ:~# docker exec -it 4da6700cdf4d /bin/bash
root@4da6700cdf4d:/#

在client container中，我们可以通过dig命令查看mynginx service的vip：

root@4da6700cdf4d:/# dig mynginx

; <<>> DiG 9.9.5-3ubuntu0.9-Ubuntu <<>> mynginx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34806
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mynginx.            IN    A

;; ANSWER SECTION:
mynginx.        600    IN    A    10.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Tue Oct 11 08:58:58 UTC 2016
;; MSG SIZE  rcvd: 48

可以看到为mynginx service分配的vip是10.0.0.2。

接下来就是见证奇迹的时候了，我们尝试通过curl访问mynginx这个service，预期结果是：请求被轮询转发到不同的nginx container中，返回结果输出不同内容。实际情况如何呢？

root@4da6700cdf4d:/# curl mynginx
^C
root@4da6700cdf4d:/# curl mynginx
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am manager</p>
</body>
</html>
root@4da6700cdf4d:/# curl mynginx
curl: (7) Failed to connect to mynginx port 80: Connection timed out

第一次执行curl mynginx，curl就hang住了。ctrl+c后，再次执行curl mynginx，顺利返回manager节点上的nginx container的response结果：”hello world, i am manager“。

第三次执行curl mynginx，又hang住了，一段时间后显示timed out，这也从侧面说明了，swarm下的docker engine的确按照rr规则将request均衡转发到不同nginx container，但实际看来，从manager node上的client container到worker node上的nginx container的网络似乎不通。我们来验证一下这两个container间的网络是否ok。

我们在两个node上分别用docker inspect获得client container和nginx container的ip地址：

    manager node:
        client container: 10.0.0.6
        nginx container: 10.0.0.4
    worker node:
        nginx container: 10.0.0.3

理论上，位于同一overlay网络中的三个container之间应该是互通的。但实际上通过docker exec -it container_id /bin/bash进入每个docker container内部进行互ping来看，manager node上的两个container可以互相ping通，但无法ping通 worker node上的nginx container，同样，位于worker node上的nginx container也无法ping通位于manager node上的任何container。

通过docker swarm leave将worker节点从swarm cluster中摘出，docker swarm会在manager上再启动一个nginx container，这时如果再再client container测试vip机制，那么测试是ok的。

也就是说我遇到的问题是跨node的swarm network不好用，导致vip机制无法按预期执行。

后续我又试过双swarm manager等方式，vip机制在跨node时均不可用。在docker github的issue中，很多人遇到了同样的问题，涉及的环境也是多种多样（不同内核版本、不同linux发行版，不同公有云提供商或本地虚拟机管理软件），似乎这个问题是随机出现的。 按照docker developer的提示检查了swarm必要端口的开放情况、防火墙、swarm init的传递参数，都是无误的。也尝试过重建swarm，在init和join时全部显式带上–listen-addr和–advertise-addr选项，问题依旧没能解决。

最后，又将docker版本从1.12.1升级到最新发布的docker 1.12.2rc3版本，重建集群，问题依旧没有解决。

自此确定，docker 1.12的vip机制尚不稳定，并且没有临时解决方案能绕过这一问题。

五、Routing mesh机制测试

内部网络的vip机制的测试失败，让我在测试Docker 1.12的另外一个机制：Routing mesh之前心里蒙上了一丝阴影，一个念头油然而生：Routing mesh可能也不好用。

对于外部网络和内部网络的边界，docker 1.12提供了ingress（入口） overlay网络应对，通过routing mesh机制，保证外部的请求可以被任意集群node转发到启动了相应服务container的node中，并保证高
可用。如果有多个container，还可以实现负载均衡的转发。

与vip不同，Routing mesh在启动服务前强调暴露一个node port的概念。既然叫node port，说明这个暴露的port是docker engine listen的，并由docker engine将发到port上的流量转到相应启动了service container的节点上去（如果本node也启动了service task，那么也会负载分担留给自己node上的service task container去处理）。

我们先清除上面的service，还是利用nginx来作为网络入口服务：

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true --publish 8091:80/tcp nginx:1.10.1
cns4gcsrs50n2hbi2o4gpa1tp

看看node上的8091端口状态：

root@iZ25mjza4msZ:~# lsof -i tcp:8091
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dockerd 13909 root   37u  IPv6 121343      0t0  TCP *:8091 (LISTEN)

dockerd负责监听该端口。

接下来，我们在manager node上通过curl来访问10.46.181.146:8091。

# curl 10.46.181.146:8091
^C
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am master</p>
</body>
</html>
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091

在vip测试中的一幕又出现了，docker swarm似乎再将请求负载分担到两个node上，当分担到worker node上时，curl又hang住了。routing mesh机制失效。

理论上再向swarm cluster添加一个worker node，该node上并未启动nginx service，当访问这个新node的8091端口时，流量也会被转到manager node或之前的那个worker node，但实际情况是，跨node流量互转失效，和vip机制测试似乎是一个问题。

六、小结

Docker 1.12的routing mesh和vip均因swarm network的问题而不可用，这一点出乎我的预料。

翻看Docker在github上的issues，发现类似问题从Docker 1.12发布起就出现很多，近期也有不少：

https://github.com/docker/docker/issues/27237

https://github.com/docker/docker/issues/27218

https://github.com/docker/docker/issues/25266

https://github.com/docker/docker/issues/26946

*https://github.com/docker/docker/issues/27016

这里除了27016的issue发起者在issue最后似乎顿悟到了什么（也没了下文）：Good news. I believe I discovered the root cause of our issue. Remember above I noted our Swarm spanned across L3 networks? I appears there is some network policy that is blocking VxLAN traffic (4789/udp) across the two L3 networks. I redeployed our same configuration to a single L3 network and can reliably access the published port on all worker nodes (based on a few minutes of testing)。其余的几个issue均未有solution。

不知道我在阿里云的两个node之间是否有阻隔vxlan traffic的什么policy，不过使用nc探测4789 udp端口均是可用的：

nc -vuz 10.47.136.60 4789

无论是配置原因还是代码bug导致的随机问题，Docker日益庞大的身躯和背后日益复杂的网络机制，让开发者（包括docker自己的开发人员）查找问题的难度都变得越来越高。Docker代码的整体质量似乎也呈现出一定下滑的不良趋势。

针对上述问题，尚未找到很好的解决方案。如果哪位读者能发现其中玄机，请不吝赐教。

闲暇时翻阅了近期下载到的电子书《Go in Practice》 ，看到1.2.4 Package Management一节中的代码Demo，感觉作者对Go package导入的说法似乎不够精确：“Packages are imported by their name”(后续的说明将解释不精确的原因)。联想到前几天遇到的一个Java包导入的问题，让我隐约地感觉Java程序员很容易将两种语言的Package import机制搞混淆，于是打算在这里将Golang和Java的Package import机制做一个对比，对于Java转型到Golang的程序员将大有裨益:)。这里的重点在于与Java的对比，关于Golang的Package Import的细节可以参考我之前写过的一篇文章《理解Golang包导入》。

我们先来看两个功能等价的代码。

//TestDate.java
import java.util.*;
import java.text.DateFormat;

public class TestDate {
        public static void main(String []args){
                Date d = new Date();
                String s = DateFormat.getDateInstance().format(d);
                System.out.println(s);
        }
}

和

//testdate.go
package main

import (
    "fmt"
    "time"
)

func main() {
    t := time.Now()
    fmt.Println(t.Format("2006-01-02"))
}

两个程序在Run时，都输出下面内容：

2016-9-13

我们看到Golang和Java都是用import关键字来进行包导入的：

import java.util.Date;

Date d = new Date();

vs.

import "time"

t := time.Now()

咋看起来，Java在package import后似乎使用起来更Easy，使用包内的类和方法时，前面无需再附着Package name，即Date d，而不是java.util.Date d。而Go在导入”time”后，引用包中方法时依然要附着着包名，比如time.Now()。但实质上两种语言在import package的机制上是有很大不同的。

1、机制

虽然都使用import，但import关键字后面的字符串所代表的含义有不同。

Java import导入的是类而不是包，import后面的字符串表示的是按需导入Java Package下面的类，比如import java.util.*； 或导入Package下某个类，比如import java.util.Date。而Go import关键字后面的字符串是包名吗？很多初学者会认为这个就是Go包名，实则不然，Go import后面的字符串实际上是一个包导入路径，这也是Java用”xxx.yyy.zzz”形式而Golang使用”xxx/yyy/zzz”形式的原因。我们用个简单的例子就能证明这一点。我们知道Golang会在\$GOROOT/src + \$GOPATH/src下面导入xxx/yyy/zzz路径下的包，我们在import “fmt”时，实际上导入的是\$GOROOT/src/fmt目录下的包，只是恰好这个下面的包的名字是fmt罢了。如果我们将\$GOROOT/src/fmt目录改名为fmt1，结果会是如何呢？

$go build helloworld.go
helloworld.go:3:8: cannot find package "fmt" in any of:
           /Users/tony/.bin/go17/src/fmt (from $GOROOT)
           /Users/tony/Test/GoToolsProjects/src/fmt (from $GOPATH)

helloworld.go是一个helloworld go源码。

之所以出错是因为在\$GOROOT/src下已经没有fmt这个目录了，所以下面代码中的两个fmt含义是不同的（这也解释了Go in practice中关于包导入的说法的不精确的原因）：

package main

import "fmt"  ---- 这里的fmt指的是$GOROOT/src下的名为"fmt"的目录名

func main() {
    fmt.Println("Hello, World") --- 这里的fmt是真正的包名"fmt"
}

从上面我们可以看出Go的包名和包的源文件所在的路径的名字并没有必须一致的要求，这也是为什么在Go源码使用包时一定是用packagename.XX形式，而不是packagename.subpackagename.XX的形式了。比如导入”net/http”后，我们在源码中使用的是http.xxx，而不是net.http.xxx，因为net/http只是一个路径，并不是一个嵌套的包名。

之所以看起来导入路径的终段目录名与包名一致，只是因为这是Go官方的建议：Go的导入路径的最后一段目录名(xxx/yyy/zzz中的zzz)与该目录（zzz）下面源文件中的Go Package名字相同。

下面是一个非标准库的包名与导入路径终段名完全不一致的例子：

//github.com/pkgtest/pkg1/foo.go
package foo

import "fmt"

func Foo() {
    fmt.Println("Foo in pkg1")
}

//testfoo.go
package main

import (
    "github.com/pkgtest/pkg1"
)

func main() {
    foo.Foo() //输出：Foo in pkg1
}

可以看出testfoo.go导入的是”github.com/pkgtest/pkg1″这个路径，但这个路径下的包名却是foo。

Java语言中的包实际以.jar为单位，.jar内部实际上也是以路径组织.class文件的，比如：foo.jar这个jar包中有一个package名为：com.tonybai.foo，foo包中包含类Foo、Bar，那实际上foo.jar内部的目录格式将是：

foo.jar
    - com/
        - tonybai/
            - foo/
                - Foo.class
                - Bar.class

但对于Java包的使用者，这些都是透明的。

2、重名

Java中关于包导入(实则是类导入)唯一的约束就是不能有两个类导入后的full name相同，如果存在两个导入类的full name完全相同，Javac在resolve时，要以ClassPath路径的先后顺序为准了，选择最先遇到的那个类。但是在Go中，如果导入的两个路径下的包名相同，那么Go compiler显然是不能允许这种情况的存在的，会给出Error信息。

比如我们在GOPATH下的github.com/pkgtest/pkg1和github.com/pkgtest/pkg2下放置了同名包foo，下面代码将会报错：

package main

import (
    "github.com/pkgtest/pkg1"
    "github.com/pkgtest/pkg2"
)

func main() {
    foo.Foo()
}

错误信息如下：

$go run testfoo.go
# command-line-arguments
./testdate.go:8: foo redeclared as imported package name
           previous declaration at ./testfoo.go:7

解决这一问题的方法就是采用package alias：

package main

import (
    a "github.com/pkgtest/pkg1"
    b "github.com/pkgtest/pkg2"
)

func main() {
    a.Foo()
    b.Foo()
}

编译执行上面程序将得到下面结果，而不是Error：

Foo of foo package in pkg1
Foo in foo package in pkg2