屬於一個線上的問題，就大概介紹下處理
背景
一個需要需要進行內外網流量的切分（基於dns）外部dns 解析到一個公網ip，然后公網ip 映射到內網的lvs vip
為了部署簡單，內網流量以及外網流量使用了一套keepalived（dr 模式，夠用了），不同業務流量的請求到vip
然后vip 轉發到實際提供服務的服務器節點
現象
在進行測試階段，配置好keepavlied 之后，測試lb 都是正常的（包括內網網的處理，但是外網的是基於內部vip的）
在基本的測試都沒問題之后，添加了外網ip到內網的映射（基於F5），同時修改了dns A記錄（以前外網的ip還可用，這樣業務影響很小）
dns 切換完成之后，觀測外網服務節點的流量很比較正常（基於prometheus+node exporter），然后晚上突然收到報警服務
有異常，因為在路上，只能手機測試下（沒有問題，應該不是100%問題），后邊過了20分鍾，收到短信通知服務恢
復（實際上系統負載小了，系統自動恢復可用了）
排查
到家之后，查看系統配置(通過vpn)，以及lvs 狀態，發現一個很怪異的問題，lvs 外網流量只有一個節點可處理請求，其他節點基本就是空閑狀態
自然懷疑lvs 是不是故障了，但是內網流量很正常，lvs real server 的配置也沒問題，一句話系統的負載均衡有問題，因為排查很晚了，還沒解決
就休息了（臨時調整了一些服務器參數，保障業務處理會好點）
找到問題原因
第二天到公司，查看服務的請求日志發現了一個比較怪異的問題，理論上我是要內外網流量切換的，但是提供服務的機器，獲取到的一直是同一個ip
（F5入口的），這個就比較怪異了，而且也不應該的，因為我們系統需要回話的處理，keepalived 配置了回話保持，基於lvs的策略，負載當然就不均
衡了（之前還嘗試過修改lvs 的負載均衡算法，按照實際的請求都是一個ip，修改也沒用），之后聯系開通外網ip的同事，調整f5提供ip 的模式，讓
用戶端ip可以透傳到lvs 的vip 請求數據包中，通過ipvsadmn -ln 觀測master 的鏈接請求，負載均衡立馬正常，各real server 都可以提供服務了，系統
響應以及狀態也都慢慢正常了
說明
以上是一個關於lvs的問題，很多時候我們可能只關注了一點，同時只測試了系統的部分鏈路，這樣可能就會有風險，同時我們在搞方案設計的時候
應該對於整個請求的鏈路以及環節都應該清楚點，至少解決問題會快很多，不會那么盲目，還有就是多看看源碼，了解系統的工作原理也是很重要的