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 在服務治理那些坑不能踩等等，都沒有去仔細討論與思考。
技術沒有好壞之分，關鍵是看人如何運用。一定避免人云亦云，適合自己公司技術體系的就是最好的。選好自己公司的技術體系後，最重要的就是做好運維與監控工作。監控的每一次報警，就像先兆一樣，萬萬不可掉以輕心。運維的事情，永遠是最辛苦最複雜的，但不能因為這些，就將許可權隨意下放，一定要確保自己可以掌控全域性。