公司现有项目中使用zk作为配置中心，内部维护着各种系统的配置信息，每次启动时都会连接zk后，覆盖本地默认配置，公司zk作为公用的组件有专门的团队负责维护，连接的应用也有上千个，所以一直没出现过问题。
问题过程：
在一次上线过程中，核心接口所在的系统上了一半集群后，测试机器的核心接口时发现提示错误，换了几个IP都是错误的，然后打开日志搜发现没有日志信息，因为近期带上去了其他模块改动的功能，怀疑是代码改动导致的问题。
首先回滚了镜像，回滚之后的机器访问核心接口还是有报错，依旧没有日志信息，此时系统只有一半的集群可用，在预发布环境部署了线上包，用远程断点的方式验证是哪个环节出错了，发现是在入口处，以前做的新版流程编排接口的ZK开关控制有问题，正常会获取ZK里配置的城市ID列表，然后匹配对应城市，因为连接不上ZK，所以没有获取到城市白名单，导致走了以前的旧接口，旧接口已经很多没有更新，有些逻辑出现问题，所以一直报错，即使回滚也不行，而且日志打印级别也依赖于zk配置，所以有问题的机器都没有打印出来日志，默认都是ERROR级别。
问题解决：
快速联系zk集群负责团队，他们处理了下访问域名，又重启了机器终于连上ZK，接口连接到ZK获取了城市白名单信息，才恢复正常访问。
问题回顾：
zk团队回复的问题原因：前几天ZK系统进行了迁移，系统配置的zk域名链接，其实是访问到另一个管理端服务获取真实的zk地址，然后再转发访问zk集群。而他们在做ZK迁移的时候这个域名映射没有配置，所以导致一些系统访问不到zk集群。
深入探究：
为什么旧接口一直没有更新，现在访问却报错了，于是怀疑是不是也和zk有关系，在观察了日志打印的错误信息后，发现在查询商品信息时，每页查询的数量也是依赖于zk配置的，正常zk配置都是10，而系统的默认配置却是0，这就导致每次都没有查询到商品，在最上层进行判空时直接抛出了异常。
问题总结：
- 类似于每页请求数量的参数，可以设置一个合理的默认值，保证配置中心失效之后也能够完成请求
- 有类似于白名单配置的新旧接口，在灰度发布没有问题后之后就尽快全量新接口，避免旧接口太久不维护，意外切到旧接口时造成访问失败
- 上线过程中一定要全面验证系统内部的核心接口，这次只是系统中某一个核心接口有问题，但该系统上其他接口都没有问题，如果当时只看了其他接口，没验证这个接口就可能造成事故，把异常抛给用户侧。
- 可以考虑给单独的ZK配置设置默认值，而不用完全依赖线上ZK环境
