dcos marathon 部署3节点zk（一个入口）的一个死结

在目前的公司，zk的使用是一共三台高可用，然后前边加上一个haproxy做负载，这种用法还是第一次看到。现在，我们打算用dcos + marathon的方案去替代过去的swarm的方案，让我们看看有啥问题。

首先，我们部署zk不成问题，三个节点白，然后本地有存储（暂时这样）。部署完成后，如果我们想利用marathon-lb-internal，service port该如何写，如果只写一个，那么可以，但是没有负载的特性；如果三个都写成2181，那是不可能的？ 难道要在marathon内部搭建一个haproxy不成？

内部搭建haproxy和swarm方案中内部搭建haproxy一个样，但是有个问题，就是如果zk一个挂掉重新启动后，ip地址是会变的哦，即使haproxy里面固化的是zk节点的name，除非reboot haproxy，让配置重新生效并且去找zk节点名字对应的ip地址。看来过去swarm方案里面有bug。

这个方案还有就是说，如果我们部署一批tomcat app，那么 service port是固定的，因为marathon-lb会通过service port来标识服务，而且每个服务对应于一个applicance。

那么解决方案是啥来？

方案1：
如果研发可以直接在marathon内部采用 代码中指定三个节点的方式就好了。但是这样也会有问题，就是如果节点挂掉，除非程序重启否则拿到的ip地址还是错误的。

方案2：
只是部署一台zk，lb只有前端一台。

另外，marathon-lb有个啥好处来，一旦有风吹草动，比如docker挂了，ip地址会重新分配，marathon-lb也会重新生成到后端的映射。

这个地方还有个该死的问题，假如我们有两个marathon-lb，app已经固化了lb的地址，如果lb全挂了重启了，那么地址也就变了，所以这个地方我们应该使用vip+port的方式。即使ip地址再变，vip地址不变呀。

这是个大bug呀。

简称，marathon-lb全挂，全玩儿完；name 》 ip的变化不是那么及时的。

而vip地址就不同了。

所以最重要的是， 用户在使用zk的时候，采用 vip1:2181,vip2:2181,vip3:2181的方式。