zookeeper迁移方案

采用版本： 3.4.14
2 April, 2019: release 3.4.14 available

集群规模： 5+N，5个选举节点，N个观察者节点

硬件要求： 16核CPU + 32G内存+ 2块物理硬盘，1个SSD，另一个不做要求
用虚机的话，避免分在同一个宿主机上，避免一挂全挂

存在的困难：
很多应用采用的是ip连接方式，ip变更的话需要显式切换（写在代码里面的需要重新编译；写在配置里面需要重新发版），
要让这么多应用都切换的话，需要一个较长的周期，所以在升级迁移服务的过程中一定有一个新老并存时期。

针对以上问题：
每个Id申请一个内部域名，对外公布域名，以后如有类似的操作，通过切换ip就可以完成。
思考： 是否需要针对每个团队一个域名，这样zk后续变化的话，更灵活，带来的问题是需要更多的域名，增加了管理上的复杂度

升级方案：
1、先用起来。
先部署观察者节点，让部分应用可以提前迁移到新环境，减少迁移周期；

2、迁移
大方向滚动式升级，对上面的应用的影响尽量平滑
注意：在每轮变更前是否需要提前修改现有观察者节点？观察者节点的观察对象如果有非选举对象是否有问题？
提前设成旧的在本轮变更中角色不变的阶段最为稳妥。

2.1 缩减选举节点规模，超过5个的，减少到5个，减少选举周期；
2.2 滚动升级。小步迭代，每次更新（N-1）/2 个节点
以5个举例，原来集群1A 2A 3A 4A 5A，假定1A是leader
第1轮：变更后的选举集群节点为：1/2/3A 1/2B，观察者节点为 4/5A
第一步：新建集群1/2/3A 1/2B.
1/2/3A不动， 挨个启动1/2B;
第二步：修改2/3 A的配置为新集群配置，并挨个重启；
由于变动的是少数服务，对新旧集群无影响；
第三步：修改4/5A为新集群观察者节点
修改集群1A配置为新集群配置，此时触发集群重新选组，选组完成，新集群对外提供服务。

第2轮A： 旧的节点当选为leader，仍假定为1A，变更后的集群节点为：1A 1/2/3/4B, 新添观察者节点2/3A
第一步：新建集群1A 1/2/3/4B
依次加入3/4B节点
第二步：更新1/2B节点的配置，并挨个重启；
第三步：修改2/3A为新集群观察者节点
修改集群1A配置为新集群配置，此时触发集群重新选组，选组完成，新集群对外提供服务。

第三轮A-A：新节点为leader，假定1B，变更后的集群节点为：1/2/3/4/5B,新添观察者节点1A
第一步：停掉1A，更新2/3/4B节点配置并依次重启
第二步：更新1B配置，并重启，触发选举并对外服务；
第三步：加入5B节点，修改1A节点为观察者节点，并重启
第三轮A-B：旧节点1A为leader，先停掉1A，触发选举，新节点当选为leader，后续操作同第三轮A-A

总结
      替换非leader节点的逻辑： 加入新节点；逐个修改要保留的节点；要下掉的旧节点改成观察者节点；最后更新leader节点
      替换leader节点的逻辑：节点少的情况下先加后减。先加入新的节点，后停掉要替换的节点，挨个修改配置并重启；
      节点多的情况下，先停后加

以上做法的前提：是否选组由leader控制，各节点对自己的状态负责，实际上也是这样的。
比较粗犷的操作先扩容，再缩容，扩容和缩容的操作都修改配置触发一次选主，这样做的优点，方法简单，好操作。