Zookeeper，你可把我坑惨了！

内容简介：前些日子，我们被自己部署的 Zookeeper 集群 DDOS 攻击了，惊不惊喜，意不意外？

1 说多了都是泪

前些日子，我们被自己部署的 Zookeeper 集群 DDOS 攻击了，惊不惊喜，意不意外？肯定有很多朋友会问，怎么会呢？

一般来说确实不可能，但在一系列条件的配合下，可以把不可能变为可能（感觉好励志有木有！），下面就让我给大家一一道来。

2 交代下前提

在讲故事前，有几个前提先跟大家说明下：

前提一

我们公司服务治理框架用的是 Dubbo，注册中心使用的是 Zookeeper 集群。但是早期规划的时候，为了运维和开发维护简单，将 Zookeeper 的 IP 放到了 F5 的一个 VS Pool 里，后续增加或修改节点直接修改 VS Pool ，应用中注册中心配置的就是这个 VS 地址。

我们年前已经发现这种连接方式存在弊端（应用通过 F5 与 Zookeeper 之间的心跳检测经常中断），并发布了邮件让大家改为直连 Zookeeper 集群，但没有重视，也没有强制要求。

前提二

我们有两个数据中心，且关键业务应用都实现了双活。但因为一些应用没有部署双活，所以存在跨机房服务调用与治理。因此，早期规划的时候 Zookeeper 也是在一个机房部署了集群，但这种模式在 Zookeeper 进行消息广播时，会占用较多的专线带宽。

经监控系统报警后，我们决定在下周进行 Zookeeper 部署改造，一个机房部署普通 Zookeeper 节点，另一个机房部署 Oberserver 节点，同时修改 DNS，让应用连接本机房的 Zookeeper 节点，这样可以有效降低跨机房带宽占用。

3 吃一堑

那是一个周五的下午，大家本应该轻松下班，然后享受周末。突然监控系统报警 F5 流量过高，导致请求被阻塞。紧急来到案发现场，得到的信息是 Zookeeper 集群是流量大户。按照应急处理原则，我们将所有可能的上线都进行了回滚，但问题没有得到改善。于是，我们怀疑是不是某些应用连接 Zookeeper 做了坏事。

通过网络抓包，看了下基本全是 Dubbo 的注册和订阅事件。当时我也非常奇怪，Dubbo 与 Zookeeper 之间只有在心跳检测失败时才会有大量的广播事件，导致流量上升。但我们的 F5 硬件、网络、 Zookeeper 服务都非常正常，一时之间想不到问题的原因，线索又中断了。

所以当时的第一决定是启动紧急上线，即按照前提 1 中提到的，直接修改公司所有应用的配置文件，让大家直连 Zookeeper 集群，而不通过 F5 做代理。这一过程很坎坷，因为涉及的应用太多，但是完成改造后，F5 的流量终于降下来了。

正当我们以为终于解决问题时，灾难再次发生，跨机房专线流量过高，导致电信机房业务受到影响，还是 Zookeeper 在疯狂的广播。当时的第一想法，是不是同时注册引起的，再加上本身专线带宽就不富裕。我们提议将前提 2 中的方案也实施，看一下效果。

经过一番折腾后，专线流量也下来了，同时看业务也恢复了正常，加上人困马乏，我们决定后续再研究下之前抓取的网络包，先让大家回去休息下，以免明天没人支持。

周六的一天，就这样在偶尔的报警中度过了。至于分析网络包，看了几个内容后，发现都是正常的服务注册和订阅事件，也是一头雾水。

然后从周日 5 点开始，部分业务突然报警，网络 Ping 不通。经排查发现，受影响的业务，都是和 Zookeeper 部署在同一宿主机的应用。Zookeeper 吃掉了宿主机 600M 的带宽。由于还是没查询出“内鬼”是谁，我们只能定下临时方案：迁移 Zookeeper ，部署到与业务系统无关的宿主机上。

正当我们赶赴公司，准备完成迁移 Zookeeper 时，突然某个同事发现一个非常大的网络报文。当他把数据包给我看后，真的是柳暗花明的感觉，“内鬼”终于找到了。原来是一个基础服务，配置了很多路由规则，导致一个包的大小有几百 k ，而我们的机房里有将近两千台机器， Zookeeper 的性能又是变态的强，于是一切的巧合安排在一起，一瞬间，流量打死了物理机，打死了专线，打死了 F5……于是，事情就这样发生了。当我们把一堆无用规则删除后，整个世界安静了，所有报警都消失了。

4 长一智

故事讲到这里似乎就结束了，可是等等，我们在这件事故中到底犯了哪些错误，我们来复盘一下：

在前提 1、2 中，我们发现了异常，却没有刨根问底，只是凭感觉认为做个简单处理方案即可。魔鬼在细节，一切的灾难在发生前都是有征兆的，如果再多一丝细心，多一丝警惕，结果也许会全然不同。

同样在前提 1、2 中，整个事件的追踪与跟进完全没有，问题没有闭环，没有协作推进。

监控不完善，不论是内网的流量监控还是 Zookeeper 方面的监控都缺失，完全是靠运气找到了有问题的数据包。

SOA 技术运营缺失，由于功能权限的随意下放，导致造成了灾难的后果。

技术架构选型与搭建时不够谨慎，不管是 Zookeeper 集群的搭建还是 Dubbo 在服务治理那些坑不能踩等等，都没有去仔细讨论与思考。

技术没有好坏之分，关键是看人如何运用。一定避免人云亦云，适合自己公司技术体系的就是最好的。选好自己公司的技术体系后，最重要的就是做好运维与监控工作。监控的每一次报警，就像先兆一样，万万不可掉以轻心。运维的事情，永远是最辛苦最复杂的，但不能因为这些，就将权限随意下放，一定要确保自己可以掌控全局。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• Zookeeper，你可把我坑惨了！

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。