今天闲的蛋疼把腾讯云服务器重启了，发现登陆不了，由于没有禁止防火墙开机启动，重启后导致防火墙重启启动，导致 SSH 端口变成了过滤状态。
随着万众瞩目的 JDK11 的发布，ZGC 也随着 JDK11 面世了，这是一个处于实验阶段的，可扩展的低延迟垃圾回收器，为什么说他令人惊叹，我们都知道 发生 GC 时，会发生 stop the world，也就是全部线程停止运行，官方承诺 ZGC 将 GC 时长控制在10ms以内，而且还不会随着堆的大小发生变化，这是什么概念，你要知道上一代的 G1，通常都会在100ms以上，你就知道 ZGC 有多牛了。
go test是go语言的程序测试工具，在目录中，它是以*_test.go的文件形式存在，且go build并不会将其编译，成为构建的一部分。
在 Java 的项目中，有 Maven 和 Gradle 这些很好用的依赖版本管理工具，简直不要太方便了，但是在 Golang 的项目中，之前的 Golang 官方并没有提供版本管理工具，我们以前用 go get 获取依赖其实是有潜在危险的，因为我们不确定最新版依赖是否会破坏掉我们项目对依赖包的使用方式，即当前项目可能会出现不兼容最新依赖包的问题。之后官方出了一个 vendor 机制，将项目依赖的包都放在该目录中，但这也并没有很好地管理依赖的版本。之后官方出了一个准官方版本管理工具 go dep，这也算是 go modules 的前身了吧。随着 Go1.11 的发布，Golang 给我们带来了 module 全新特性，这是 Golang 新的一套依赖管理系统。现在 Go1.12 已经发布了，go modules 进一步稳定，但官方还是没有将其设为默认机制，所以踩坑之路是必须的，本篇文章除了详细说明 go modules 的特性以及使用之外，还总结了我在这个过程中遇到的一些“坑”。
之前 swarm 集群中docker service create一次只能部署一个微服务，我们可以使用 docker stack + compose 一次启动多个服务。
swarm 集群的内部会为容器的各个节点之间负责负载均衡的管理，现在我们来验证一下 swarm 的负载均衡特性。
单机容器内的通信是通过 docker 自带的网桥连接互通的，如果是集群，那么做这些单机网络模型就行不通了，因为集群必然会将一个服务的多个任务需要分布到不同的机器上进行部署，因为如果把所有的任务都分配到一台机器部署了，这台服务器有故障，就会导致这个服务不能正常运行了，而且一个集群内，不同主机之间的容器是怎么进行通信的呢，这里我们就涉及到 docker 网络模型。
之前一直在玩单个 docker 节点，但是如果一家公司需要部署大量 docker 节点，这是远远不够的，我们需要一个集群部署的调用平台，swarm 相比 k8s 、mesos 等等容器集群调度系统，是最容易学的，而且没那么多陌生的概念，简单上手，而且与 docker 无缝链接，毕竟是亲生的嘛。
Maven 是一个版本依赖工具，它有一个官方的中央仓库，很多开源项目的 jar 包版本都能够在上面找到，但是将项目发布 jar 到中央仓库是在太麻烦了，因此我想到了用自己的 Github 作为仓库，从 Github 仓库中拉取依赖包。
上一篇讲到了 Mapper 如何注册到 Configuration 类中与 MapperProxyFactory 绑定的过程，我们平时的使用场景一般都配合着 Spring，使用 Spring 意味着需要注册 Bean，也就是说需要将 Mapper 的代理实现类注册到 Spring 容器中，成为 Spring 容器中的一个 Bean。