之前做運維，有一些印象很深的事故，今天來講其中一個，為了大家能理解，先說一些背景。現在因為流量巨大，單臺機器肯定不足以為所有使用者提供服務，所以大公司幾乎任何一個服務的背後都是一套叢集，然而任意一臺機器不是100%可靠，如果你想讓你服務儘可能接近100%可靠，你的叢集就得具備檢測和剔除壞點的能力。
　　之前在阿里廣泛使用的是LVS負載均衡，LVS叢集就支援壞點檢測和剔除，使用者訪問大概架構如下。

　　起始網路請求經過的路徑遠比這個複雜，我這裡只是個示意圖。lvs叢集必須能檢測到10.11.100.4這臺機器的異常。你說啥？lvs是做啥的？我們在訪問淘寶的時候，拿到的ip地址並不是真正提供服務的伺服器ip地址，不行你用dig

1. 節省公網ip，像淘寶這麼大的網站，如果伺服器全部掛域名下面，這就得需要成千上萬公網ip，如果每個公司都這麼做，ipv4資源早就耗盡了。
2. 更高的可用性，dns是用快取的，幾分鐘到十幾分鐘不等，如果有ip變化，可能意味著大批使用者在十幾分鍾內都拿到的是錯誤的ip。但lvs下面的ip可用很快切換。
3. 更方便的運維。如果流量變化，可用快速在lvs下增刪機器，出現壞點，lvs也可以快速把壞的機器流量切走。

今天要說的這個事故，就和lvs第三個優點有關，就是有個vip下有一批機器服務有問題，但其實lvs機器並沒有將其下線。這裡並不是說lvs本身出現了問題，根本原因其實是運維在配置lvs Health Check方式不合理導致的。
　　阿里lvs叢集其實提供了兩種對web服務Health Check的方式。1.檢測服務埠是否開啟，只要伺服器埠支援開著就認為是正常。 2.發出一個http請求，看狀態碼是否正常。
　　事故那次都是用的第一種health check方式，問題的本質在於，埠開著服務並不一定正常，所以lvs把大量請求轉發到這些埠開著但服務異常的機器上，這些請求便得不到正常的響應。 　　第一種health check起始只是在OSI網路分層的第4層傳輸層做檢測，它起始只能檢測資料能否被正常的傳送到。 而第二種health check方式是在第7層應用層做的，它不僅能保證資料能否被傳送到，而且還檢測能否被正常處理。