Startup fails because of Logger timeout on a busy machine

I have change the configuration file in kafka-manager-1.3.3.6/target/universal/kafka-manager-1.3.3.6/conf/application.conf from

akka {
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  loglevel = "INFO"
}

to

akka {
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  loglevel = "INFO"
  logger-startup-timeout = 30s
}

docker部署devops

使用docker部署devops;

  • 基础环境搭建
    • rabbitmq 集群 –> 完成
    • zookeeper 集群 –> 完成
    • jenkins 集群  –> 完成
    • redis 集群(3主3从)  –> 完成
    • nginx+keepalive –> 完成
    • github 版本管理
    • 配置中心 集群
    • nexus 私服
    • 注册管理中心搭建
    • 任务管理器
  • 数据层环境搭建
    • mysql 数据库 集群
    • fastdfs 数据存储层 集群
  • 监控环境搭建
    • elk 搭建
    • pinpoint 搭建
    • portainer 监控
    • zabbix 搭建
    • zikpin 监控
  • 基础服务搭建
    • 用户服务 集群
    • 日志服务 集群
    • 内容服务 集群
    • CAS 认证 集群
    • 微信服务 集群
    • 管理平台 集群
    • 通知服务 集群
  • 业务服务搭建
    • 业务服务集群
  • 前端服务搭建
    • 前端服务集群

使用 Docker搭建 ZooKeeper 集群

镜像下载

hub.docker.com 上有不少 ZK 镜像, 不过为了稳定起见, 我们就使用官方的 ZK 镜像吧.
首先执行如下命令:

docker pull zookeeper

当出现如下结果时, 表示镜像已经下载完成了:

>>> docker pull zookeeper
Using default tag: latest
latest: Pulling from library/zookeeper

e110a4a17941: Pull complete
a696cba1f6e8: Pull complete
bc427bd93e95: Pull complete
c72391ae24f6: Pull complete
40ab409b6b34: Pull complete
d4bb8183b85d: Pull complete
0600755f1470: Pull complete
Digest: sha256:12458234bb9f01336df718b7470cabaf5c357052cbcb91f8e80be07635994464
Status: Downloaded newer image for zookeeper:latest

ZK 镜像的基本使用

启动 ZK 镜像

>>> docker run --name my_zookeeper -d zookeeper:latest

这个命令会在后台运行一个 zookeeper 容器, 名字是 my_zookeeper, 并且它默认会导出 2181 端口.
接着我们使用:

docker logs -f my_zookeeper

这个命令查看 ZK 的运行情况, 输出类似如下内容时, 表示 ZK 已经成功启动了:

>>> docker logs -f my_zookeeper
ZooKeeper JMX enabled by default
Using config: /conf/zoo.cfg
...
2016-09-14 06:40:03,445 [myid:] - INFO  [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181

使用 ZK 命令行客户端连接 ZK

因为刚才我们启动的那个 ZK 容器并没有绑定宿主机的端口, 因此我们不能直接访问它. 但是我们可以通过 Docker 的 link 机制来对这个 ZK 容器进行访问. 执行如下命令:

docker run -it --rm --link my_zookeeper:zookeeper zookeeper zkCli.sh -server zookeeper

如果对 Docker 有过了解的话, 那么对上面的命令一定不会陌生了.
这个命令的含义是:

  1. 启动一个 zookeeper 镜像, 并运行这个镜像内的 zkCli.sh 命令, 命令参数是 “-server zookeeper”
  2. 将我们先前启动的名为 my_zookeeper 的容器连接(link) 到我们新建的这个容器上, 并将其主机名命名为 zookeeper

当我们执行了这个命令后, 就可以像正常使用 ZK 命令行客户端一样操作 ZK 服务了.

ZK 集群的搭建

因为一个一个地启动 ZK 太麻烦了, 所以为了方便起见, 我直接使用 docker-compose 来启动 ZK 集群.
首先创建一个名为 docker-compose.yml 的文件, 其内容如下:

version: '2'
services:
    zoo1:
        image: zookeeper
        restart: always
        container_name: zoo1
        ports:
            - "2181:2181"
        environment:
            ZOO_MY_ID: 1
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

    zoo2:
        image: zookeeper
        restart: always
        container_name: zoo2
        ports:
            - "2182:2181"
        environment:
            ZOO_MY_ID: 2
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

    zoo3:
        image: zookeeper
        restart: always
        container_name: zoo3
        ports:
            - "2183:2181"
        environment:
            ZOO_MY_ID: 3
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

这个配置文件会告诉 Docker 分别运行三个 zookeeper 镜像, 并分别将本地的 2181, 2182, 2183 端口绑定到对应的容器的2181端口上.
ZOO_MY_ID 和 ZOO_SERVERS 是搭建 ZK 集群需要设置的两个环境变量, 其中 ZOO_MY_ID 表示 ZK 服务的 id, 它是1-255 之间的整数, 必须在集群中唯一. ZOO_SERVERS 是ZK 集群的主机列表.

接着我们在 docker-compose.yml 当前目录下运行:

COMPOSE_PROJECT_NAME=zk_test docker-compose up

即可启动 ZK 集群了.
执行上述命令成功后, 接着在另一个终端中运行 docker-compose ps 命令可以查看启动的 ZK 容器:

>>> COMPOSE_PROJECT_NAME=zk_test docker-compose ps
Name              Command               State           Ports
----------------------------------------------------------------------
zoo1   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2181->2181/tcp
zoo2   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2182->2181/tcp
zoo3   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2183->2181/tcp

注意, 我们在 “docker-compose up” 和 “docker-compose ps” 前都添加了 COMPOSE_PROJECT_NAME=zk_test 这个环境变量, 这是为我们的 compose 工程起一个名字, 以免与其他的 compose 混淆.

使用 Docker 命令行客户端连接 ZK 集群

通过 docker-compose ps 命令, 我们知道启动的 ZK 集群的三个主机名分别是 zoo1, zoo2, zoo3, 因此我们分别 link 它们即可:

docker run -it --rm \
        --link zoo1:zk1 \
        --link zoo2:zk2 \
        --link zoo3:zk3 \
        --net zktest_default \
        zookeeper zkCli.sh -server zk1:2181,zk2:2181,zk3:2181

通过本地主机连接 ZK 集群

因为我们分别将 zoo1, zoo2, zoo3 的 2181 端口映射到了 本地主机的2181, 2182, 2183 端口上, 因此我们使用如下命令即可连接 ZK 集群了:

zkCli.sh -server localhost:2181,localhost:2182,localhost:2183

查看集群

我们可以通过 nc 命令连接到指定的 ZK 服务器, 然后发送 stat 可以查看 ZK 服务的状态, 例如:

>>> echo stat | nc 127.0.0.1 2181
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:49810[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 5/39/74
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: follower
Node count: 4
>>> echo stat | nc 127.0.0.1 2182
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:50870[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: follower
Node count: 4
>>> echo stat | nc 127.0.0.1 2183
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:51820[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: leader
Node count: 4

通过上面的输出, 我们可以看到, zoo1, zoo2 都是 follower, 而 zoo3 是 leader, 因此证明了我们的 ZK 集群确实是搭建起来了.

因为docker-compose.yml的格式比较蛋疼，如果你按照上述文件手写起不来，报错.yml文件报错。那就复制粘贴然后启动。亲自试用，绝对可行。

svn分支管理的使用与经验

最近项目用上了svn分支管理，因为项目太过庞杂，版本迭代也过于频繁，致使多个版本的代码交杂在一起，难以维护，无法保证其中某个版本的稳定性。当然，我们也用过很土的办法，代码复制一份出来，但是，这个副本也需要加上新开发的功能。

所以，我们决定使用svn分支管理。当然，这有代价，svn版本管理对二进制文件不友好，可能文件分支合并时二进制文件会难以处理。（这里说的二进制文件，泛指所有非文本文件，比如说美术资源，策划文档）

svn分支简述

使用分支最主要的目的是，多个分支可以并行，相互不干扰，而且任何时候都可以合并。其次，容易保证主干的稳定性。

没有分支的时候，你的svn可能是这样的：

就一份代码存在主干（trunk），当然也不会有主干这个说法。开发完1.0，继续开发2.0，版本一个一个迭代。

有了分支后，你的svn可能就是这样的了：

主干用来存放稳定的代码，每个版本都会开一个分支，等版本完成后再合并到主干。版本一个一个迭代，但可以并行开发。

svn分支管理

接下来，简单讲解下 如何使用svn做分支管理。

第一步，建立主干分支目录结构

第二步，创建分支

在主干目录 trunk 右键，在svn菜单选择 Branch/tag…

步骤①是分支地址，这里直接以 /branches/1

步骤②是取trunk版本，HEAD revision表示最新版本，其他可通过 show log选择

执行 OK 后，到 branches 目录 svn update 就可以看到最新的分支了。

第三步，合并分支到主干

分支就是开发目录了，现在分支提交一个文件做测试。

然后，合并这个文件分支到主干。

现在到主干目录，右键svn菜单选 Merge…

这个是将分支或主干的修改合并到当前工作目录，继续如下。

接下来点完成，如果没冲突的话，分支文件就合到主干了。

但这里还要一个操作，就是在主干提交分支合过来的文件。

题外话，之所以要有这一步，除了对分支内容进一步修改，还可以同时合并多个分支。选择权交给用户。

另外，主干内容合到分支，也是使用 Merge 命令。

svn分支应用

根据项目的不同，实际上的分支架构也会不同。以我们项目为例，我们是做游戏的，项目过于庞杂，版本迭代非常频繁。在版本1.1还没完成时，我们可能就要开发2.0版本，这样，版本1.1和版本2.0就要并行开发。而且，我们对稳定性有非常高的要求。

为此，我们设计了这样的svn架构。

测试分支

为了保证主干稳定，我们加了测试分支（如 rel_1.1的测试分支为 rel1.1_test ）。测试分支1.1是在分支1.1开发结束后开的，等待测试修复bug完成后，就会把测试分支1.1合入主干及分支1.1。合并完成后，这个测试分支将会关闭。

多分支并行

因为项目需求较多，版本迭代繁杂，所以在版本1.1还没结束时，就开了版本2.0的分支。当分支2.0需要测试合并到主干时，就会从主干合并最新的文件到2.0测试分支，测试通过后，再合并到主干。

分支合并的时机

对我们而言，不同分支的最大区别是功能上线的时间点。我们根据上线周期划分功能，拆分到不同分支。因为开发需求多，迭代过于频繁，所以靠后的分支对比之前的分支通常只是多了某些新功能。这样，分支的出现，避免了未开发完成的功能影响了已开发完的功能，导致当前版本的不稳定。所以，合并分支的时机就是这个分支的功能要不要上线。

这样，主干永远是稳定的，也只有经过测试的内容，才会合入主干。同时，多个版本也可以并行。