摘要:在访问依赖的服务过程中，我们通常会通过在程序或者配置文件中写死ip列表的形式来发现下游服务，但在下游服务集群出现ip迁移的时候，会导致所有依赖该服务的上游应用重新配置ip列表并重新发布或者重启才能生效。本文介绍了如何使用阿里云配置管理产品ACM，并以zookeeper集群服务为例，如何方便的在数据中心里实现透明的替换zookeeper坏掉的机器节点。
在一个数据中心里，一个zookeeper集群常常会服务多条业务线或者业务系统，每个业务线或者业务系统有自己的开发团队，而zookeeper这类公共服务则会有专门的运维或者团队负责保障其服务可用性和连续性。
业务应用通过Apache Curator客户端或者原生的zookeeper客户端访问zookeeper服务，在这个过程中，必须在应用程序里指定connectString,即zookeeper服务所在的机器的ip列表, 代码示例如下：
但在zookeeper的生产运行过程中，zookeeper服务集群可能会遇到机器故障，机器迁移等情况，这个过程则需要zookeeper运维人员替换节点，将服务迁移到新的ip节点，整个流程，如下图所示，
该方案如图所示:
在这个方案中，可以将zk服务ip挂在一个dns域名或者vip上.
这样在zookeeper替换节点时，应用无感知，这个方案即服务发现方案。
优点
缺点
我们将zookeeper集群的服务ip列表，连接超时，session超时参数，chroot，当前的用户名，密码等放在一个ACM配置里。
然后通过ACM SDK监听这个配置的变更，这里我们可以使用curator client提供的EnsembleProvider功能来结合ACM达到动态监听配置服务ip列表变更的效果。
示例代码如下
当zookeeper集群的节点挂掉，需要更换ip列表或者修改超时参数，应用的znode配额quota时，zookeeper运维人员只需要在ACM上修改相关的配置项，ACM将自动分发变更到所有的应用系统。
在上例中，我们可以看到，应用系统开发人员(Dev)和运维人员(Ops)之间省去了沟通成本，应用系统也省去了因连接相关的配置变更导致的应用重新启动或者发布应用的变更成本。
在本文中我们介绍了，如何利用ACM解决服务发现场景中的下游依赖服务透明替换节点，调整服务连接超时参数等问题。
通过该例，我们可以看到，在将应用的静态配置文件方式迁移到ACM之后，通过应用主动动态监听配置变更，可以在应用和运维层面获得诸多好处，这包括省去了应用配置变更时，应用往往需要重新发布或者重启的成本，同时使Dev和Ops在配置变更场景下2者之间的沟通成本降到最低。