覺得很多人都對這個選擇存在疑惑，就簡單寫寫。
LVS主要是DR,TUN,NAT和淘寶的FULLNAT模式，對於絕大部分人而言只能選擇原版內核支持的前三種。
1.DR模式
DR模式是效率最高的一種，對於每個請求LVS把目的mac改成從RS中選擇的機器的mac，再將修改後的數據幀在與服務器組的局域網上發送。但是侷限性是LVS機器需要和RS至少能有一個網卡同在一個VLAN下面，這樣限制了DR模式只能在比較單一的網絡拓撲下使用。
2.TUN模式
TUN模式其實性能與DR模式相比差別不大的，TUN模式下會動態地從RS列表選擇一臺服務器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；RS服務器收到報文後，先將報文解封獲得原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。TUN模式可以解決DR模式下不能垮網段的問題，甚至可以垮公網進行。但是需要RS能支持ipip模塊。
3.NAT模式
NAT模式對RS沒有其他要求，唯一的要求是得把RS的網關設置爲LVS機器。因爲進出的流量都要通過LVS機器，所以性能相對會差很多，而且部署的規模很難做大。
以上DR模式和TUN模式在部署的時候都需要在本機綁定VIP，非常麻煩，比如我們之前有的老應用因爲一些歷史問題單個應用的VIP有40來個，如果用LVS做負載均衡基本就崩潰了，每次新增/刪除一個VIP，估計得線下測試好多次ip addr add/del的用法。NAT模式在部署的時候也是太麻煩了。而且還有一個很關鍵很關鍵的是，使用了LVS後萬一被人ddos怎麼辦？syn-cookie在抵擋***的時候效果一般不是太好，這樣***透過lvs直擊後端應用就杯具了。所以在很多大公司都不敢直接把lvs放公網，前面得加個防火牆啥的。所以淘寶單獨搞了一個fullnat模式，一方面可以解決部署綁VIP、或者把RS的網關設置爲LVS機器IP帶來的部署複雜問題，另外一方面是加了一個syn-proxy等等，可以抵擋下一般的網絡層***。但是使用FULLNAT模式後確實有個麻煩的是後端機器看不到用戶的IP了，所以RS上還得用裝上打過補丁的內核，對取IP的操作就劫持才能獲取到用戶IP。
對於大規模網站，其實無聊單獨使用哪種LVS都是不能替換商業設備的，所以還是得配合nginx or haproxy做負載均衡。這個時候最簡單的就是lvs(fullnat)+nginx/haproxy（nginx官方版本現在沒有4層代理功能，haproxy對後端又不支持keepalive）,當然使用DR模式或者TUN模式也還可以的。總之基本都得用2層才能搞得定，滿足大部分應用上的需求。其實對於很多小公司，我覺得直接用nginx/haproxy就OK了。搞的那麼複雜維護成本會非常高的，自動化運維沒有跟上的時候只會把自己給玩死。
在使用LVS之前，建議大家一定仔細看看文檔，沒有好好看文檔就別瞎折騰了。