2020-06-30 晚上 22:40左右出现大量的dubbo接口超时。
原因是NTP服务出现时间差，与真实的北京时间差了正好8小时，开始出问题的时间段，NTP服务由VM虚拟机切换到PVE虚拟机，但是切换机器之后没有调整好时间，导致所有机器节点的时间全部出现问题。
2020-06-30 22:45左右，将PVE虚拟机NTP服务回切至VM虚拟机，NTP服务正常；
NTP异常后，应用服务器同步时间出错，容器应用调用异常、超时，重启应用，生成新节点，但因新节点未同步到正确时间，ZK又注册到原来旧节点，即ZK中同时存在新旧不同节点，导致提供服务异常。
此时此刻，所有进行了时间同步的机器节点全部出现DUBBO接口调用失败，zk的时间偏差会导致节点数据无法被正确的删除，很多旧的节点也出现了类似的问题。
可以参考类似问题的文章： https://blog.csdn.net/liujunzxcv/article/details/91670951
这种情况要解决有两个办法。
方案一： 手动去ZooKeeper删除旧节点的数据，这个非常繁琐。
方案二： 搭建一套新的ZooKeeper，把dubbo注册中心的ZooKeeper的地址的域名映射到这个新集群ip，然后重启所有应用，这种方法简单粗暴。
先是采用的方案一，发现要删除的节点太多了，操作极其麻烦，最后转而使用方案二。
2020-06-30 23:35 ，搭建新ZK；
2020-06-30 23:40 ，重启所有应用，问题恢复。
总结：
NTP服务所代表的所有机器节点的时间一致性看起来是一个非常简单但是很容易忽略的东西，重要性可想而知。面对NTP服务异常导致的RPC调用异常，以为服务、消费者节点的万能重启大法可以解决，这反而加大了问题的严重性。
（第二天在查询应用日志的时候更麻烦，因为时间的不一致，相差了八个小时，日志的时间已经是错乱了，在一个时空混乱的情况下处理问题真的是很容易跑偏）
题外话：
以前搭建CockroachDB数据库集群的时候也遇到过类似的问题，参考我的博客： https://my.oschina.net/110NotFound/blog/3042036