F5硬件負載均衡的優點是，負載均衡能直接通過智能交換機實現,處理能力更強，與操作系統無關，負載性能強，適用于一大堆設備、大量，其缺點也是很明顯的，那就是成本高，設備的配置冗余，有些用不上的都給默認配置了。另外，由于設備只有單個，所以單個負載均衡配置無法有效掌握所有服務器及應用狀態。軟件模式的話，比較常用的軟件的有LVS、Nginx、HALVSNginx這種負載均衡工具是七層負載均衡。而HA同時支持四層、七層負載均衡，還可以根據報文內容選擇內部服因此，LVS分發路徑優于Nginx和HA，性能上也要高些。但Nginx和HA很久以前，游戲服務器只是簡單的對應客戶端的服務，就像使用編程語言寫了一個多線程的程序，每個線程接收一個客戶端，然后把該的數據放到數據庫去保存。到了后期，大量的網游開始興起，玩的人越來越多，所以一些老式游戲服務器框架已經更大更現代化的的需求了。到了2005年左右，這種情況愈演愈烈，不改變現狀。于是，程序員和游戲開發廠商設計出了新的一種服務器的框架模型。這種模型幾乎是延用到今天，這種模型甚至延伸到各行各業的服務框架。我們甚至可以說Nginx反向的想法也是類似這種模型的一種表現形式。盡管我們不能說Nginx學的就是這種模型，但是與這種反向的模型的做法實在太類似了。這種服務器模型的最大改變，就是加了一個aeway，可以稱作網關。這當然不是傳統意義上的網關路由器，只是在服務器的應用層面，做的事情類似網關路由器，所以我們仍然把它稱為網關。Web會話（Session），也可以稱它為LinkServer，總之道理是一通過網關服務器，用該服務器作為中轉。也就是說，假設有A客戶端到B服務器，網關為G的話，就是A到G到B，然后B服務器完成邏輯計算后，返回給G網關，網關再一次返回給A、B到G到A。這樣做的好處是，網關可以隨時詢問它的真實邏輯服務器到底哪一臺趨于飽和，可以將玩家移動到不飽和的游戲服務器，但是缺點也是很明顯的，那就是玩家和服務器之間隔了一層網關，需要消耗更長的時間，傳輸速率相對低。網關服務器作為查詢網關，也就是說，網關服務器會和所有服務器做一個長連接，或者隨時詢問的連接，這個連接所詢問的內容，可以放到一個緩存里面，所查詢的內容就是它底下所有服務器哪一臺有空，在這種功能模式下，網關服務器只做了負載均衡的工作。AG，模型看起來會是A-詢問G，G通過查詢緩存表，告知A客戶端，C服務器有空，于是通知A，你去連C服務器，IP地址和端是多少多少，于是A從網關G關閉連接，去連接C服務器。如這個模型，網關服務器只做了負載均衡的動作，客戶端和網關之間不會保持一個長連接，在這個基礎上，一臺網關服務器支撐同時七以上都不是什么太大的問題。但是它的缺點也很明顯，那就是一臺游戲邏輯服務器只能負責一個游戲世界，不能進行分塊。如果要進行分塊，則需要其他模型的服務器模塊，這個我一會兒會說。Ninx的反向也是類似這種負載均衡的網關模型，這種模型大量運用在很多應用服務器、HTTP連接的網絡服務器上。但是，這項技術到了上升時期開始遇到了瓶頸，人們發現就算加上網關，也無法負擔體量更大的游戲地圖。于是，我們需要對這樣的模型進行修改。首先，需要將網關服務器增加為幾個網關服務器。每個網關服務器都做相同的工作，也就是管理它所下屬的所有邏輯服務器。客戶端在啟動的時候，隨機抽取某一個網關服務器，進行詢問，使用網關服務器做進行中轉。個邏輯服務器中，網關做中轉服務，比如服務器A負責浙江省，服務器B負責省等客戶端在連接到網關服務器后，隨著游戲進度的，網關服務器可以選擇連接負責哪一塊地圖的邏輯服務器，這樣在玩家看來就像是連接了一臺服務器，而客戶端并不用考慮切換服務器的工作。當然為了減輕服務器的壓力，增加的人流量，后期這樣的模型被逐步細分。比如可以將聊天服務放到一立的服務器進行存放，把用戶數據獨立到一臺數據服務器存放，把商品放到另一個獨立的服務器，或者把私信等等這些和主游戲邏輯無關的內容都放到一個獨立的服務器上。這樣一來，主游戲邏輯的服務器的負載就會減輕，然而客戶端就不得不多連接幾臺服務器，這樣的游戲邏輯服務器的模型一直沿用到現在。某一些稍微輕量級的，只是使用網關當成負載均衡使用，有一些重量級的，加上地圖分割，就會增加網關服務器，但是付出的代價就是，如果要加一臺新的游戲邏輯服務器的話，勢必會增加部署難度。不僅網關服務器的配置文件要重新部署，每個游戲節點服務器和被分割的諸如聊天等服務都需要進行重新配置，這樣付出的代價也是巨大的，當然很多游戲公司靠著這樣的服務器框架使用了好多年，其思想也被延伸到各個行業領域的服務器架構中。網關服務器有中轉功能和負載功能。Nginx的反向用的是負載均衡的網關模型，但是這種模型無法負擔更大體量的內容。為了減輕服務器的壓力，也為了增加的人流量，可以通過增加網關