整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
碼/視頻評論后加前端學習群470593776
知識點：原生js動畫效果 ,重力系統+元素彈跳算法, 遞歸在特效中的應用,
兩種定時器配合使用,編程思想與解決方案思維
由于現在面試中，對于原生JS的要求越來越高，所以本次分享，都是使用的原生js來實現效果！
源碼/視頻評論后加前端學習群470593776
源碼/視頻評論后加前端學習群470593776
TML 5雖然只是一個技術標準，但是眼下更多承載著顛覆蘋果與谷歌移動生態的理想。我并不想單純從技術角度談論HTML5的現實處境，因為技術從來不會成為發展的絕對瓶頸，尤其是HTML 5本身就不存在任何重大的技術難題。反而“商業”成了HTML 5發展無法逾越的鴻溝。只可惜“商業”從來都摻雜大量的投機成分，當然也有商業政治的成分。
HTML5所謂的“標準定稿”在我看來只是一場公眾秀。HTML 5標準自始至終就不是W3C組織一家的自留地，更不是唯一的代言人。原本W3C組織對外宣傳“要到2022年才會完成HTML 5正式標準的頒布”，現在為何又如此匆忙的定稿？這種定稿真的會對移動開發產生多大影響？
最糾結的10%
真正一直關心HTML 5的人會記得2012年7月的一個重大新聞，HTML5的兩個標準組織W3C和WHATWG因為“理念不合”決定分道揚鑣，這被看成一場IT界的商業政治事件。二者的根本理念差異是WHATWG認為HTML 5應該成為一個動態的標準既Living Standard，而W3C則認為應該形成一個固定的標準。導致這場事件升級的真正原因并不是“理念”這么簡單，而是二者各自代表的利益集團背后的推手。WHATWG向W3C叫板的底氣，正是來自Mozilla、蘋果和Opera的支持。W3C則選擇了微軟。
HTML5標準本身涉及的技術并無任何障礙，但是之前遲遲無法定案的原因則是錯綜復雜，緩慢的進度除了再一次證明這些組織是超級低效機構之外，所謂的利益和政治博弈才是直接導致了進度緩慢的真正原因。實際上截止2013年90%以上的HTML 5的標準早已完成，剩下的部分恰恰是各大利益集團博弈的重點，此次W3C代為發聲，明顯生米煮成熟飯的意味，這真的會奏效么？答案是完全否定的！因為各大金主不會因為一場PR活動就放棄自己的利益。
那么對開發者和技術用戶而言，W3C所謂的標準定案到底意味著什么？是否可以從中獲益？到底該如何看待這一“進步”？
這一切還要從W3C與WHATWG的分歧開始，動態標準還是固定的標準更適合開發者？我想，答案或許是WHATWG的Living Standard！因為沒有動態的標準，就不會有HTML 5的未來。未來HTML5想得到真正的發展，核心問題并不是標準哪天定稿亦或是瀏覽器性能不足，關鍵在于兩點，一是持續改進，二是生態。
龜速迭代
如果沒有一個持續改進的標準和為此而不斷努力的組織，HTML 5就只能把顛覆App生態當成一句口號，永遠充當配角。因為生態革新速度要遠大于開發者的行動速度。
IT world已經完全不是10年前的樣子，Cloud/Client“云與端”快速蠶食著傳統B/S架構（瀏覽器到服務器）的空間。端不特指“手機端”而是更廣泛的包含“pad端”“PC端”甚至“手表端”“汽車端”“家電端”等等。而相比PC時代，更多端的出現，代表著更多的硬件組合以及更多業務場景和功能。我們一直詬病W3C等標準組織行動緩慢，這次標準的公布很明顯沒有解決任何“云與端”復雜性的解決方案。我們設想一下：
場景A：以iphone的touchID為代筆的生物識別功能在各種端上興起，繼而產生了大量新的API，甚至可能今后帶有硬解的虹膜識別、聲紋識別等終端能力，在一個固定的HTML5標準下如何解決？HTML5附帶的device API甚至只涵蓋了feature phone時代的基礎通訊錄、攝像頭等功能，今天出現的touchID均無法有效調動，更何況2、3年后我們無法認知的新功能的標準配套實現。這種情況下不發展的HTML 5標準代表著“弱功能”
場景B：智能硬件的發展對藍牙和wifi使用以及驅動的需求迅猛增長，而HTML 5配套的對藍牙3.0驅動的支持標準何在？可以遵照標準的HTML 5亦或是配套的標準以及協議在瀏覽器內連接大部分的智能硬件么？答案當然也是全然否定的。這種未來最常見的常見之一都無法實現，那些大談HTML 5將會取代APP的人恐怕又會說“這些不是HTML 5擅長的，這種舉例毫無疑義”。那請問HTML 5擅長的只是排版布局和閱讀類亦或者一些低價游戲的APP么？更不要說對于NFC等很快可能成為終端標配的系統新能力，所以定稿后不發展的HTML 5標準代表著“弱擴展”
其實，這一切基于HTML 5的論點并非沒有明確的解決方案，簡單來說所謂的HTML 5定稿只是鬧劇和PR，如果真正期盼HTML 5挑戰App生態，一定要出現一個不停發展的動態標準，才能夠具備上場參賽的基礎。只是這倚重的是標準背后的“推手”和“金主”，那些想打造自己生態王國的大玩家。作為WHATWG的重要支柱，蘋果公司一直在低調中快速發展著自身的Web App技術，到今天為止，在iOS中已經有比Android和其他操作系統更成熟和完美的圍繞HTML 5和Web App的支持，只是遺憾的是蘋果公司只是把HTML 5當成技術，而沒有為打造HTML 5的生態做出任何其他的努力。
推不動的生態
2013年是HTML 5最低調的一年，因為在此前一年，眾多打擊接踵而至，除了用戶對HTML 5普遍負面的反饋之外，最嚴重的一次事件就是Facebook的徹底反水！
扎克伯格：我們過去最大的錯誤就是在HTML 5上面賭太大！
曾幾何時，面對HTML5扎克伯格野心勃勃的推動著“復制Facebook在PC端生態和霸權計劃”。眾所周知，蘋果的生態系統是相當封閉的，Android雖然開放但是也全面復制著蘋果的玩法iOS－>Developer－>APP－>Appstore－>User。所以Facebook全面推進HTML 5，妄圖跳開移動操作系統的掌控，擁抱HTML5和www的開放流量體系。
但是即便是Facebook如此重量級的玩家，最后也認栽了。無獨有偶，Linkedin作為又一風向標，在2013年也同樣放棄了HTML 5重新擁抱APP。到今天，難道短短的一年多，世界就發生了徹底的改變，HTML 5又重新具備了王者的氣質？當然是不可能的，世界上各個IT王國都沒有改變，改變的只是時間。
根據Flurry的報告，相比去年，2014年用戶在移動端的使用APP的份額進一步上升突破80%，而手機網站的使用情況進一步被擠壓。這說明用戶市場沒有將APP升級和下載當成多大的困難（至少沒你想像的那么困難），并且隨著App store更加人性和智能化的幫助用戶在wifi環境下自動升級等機制的普及，APP在使用上對用戶來說門檻越來越低，反而基于HTML5的Web App的使用和獲取倒是成了用戶的障礙。手機瀏覽器的用戶留存和使用情況越來越不樂觀，這個最重要的HTML 5的載體正在失去活力，反而大家寄望于超級APP，微信在中國眼下成了一根救命稻草。
當然想基于超級APP的形式打造自身閉環生態的廠商不止Facebook一家，反觀國內試水的大公司也很多，但均以鳴金收兵結尾。從UC的web app商店到百度的輕應用，構建基于移動web流量的生態系統無一成功。目前造成這種局面原因眾多，例如瀏覽器性能不足、HTML 5標準未定稿、無有效的web app發行渠道等等，但是正如我3年前說的，最核心的問題是移動開放流量體系和原生生態系統的對抗。
目前用戶從App store去搜索和下載app，在桌面存留app入口點擊使用，這已經成了iOS與Android生態系統下的固定模式。反而讓用戶進入超級APP，再通過搜索或連接的方式進入一個第三方web app，無論是從操作流程還是用戶最終體驗都無法和操作系統層級的體驗抗衡。而HTML 5標準定稿沒有為這種生態的困難帶來任何一點的改變，所以說HTML 5在W3C操縱下的所謂標準定稿，只是一場PR的鬧劇，雖然攪動了市場，但是也刺激了一批從業者充當炮灰。
期待新玩家
打造移動開放平臺和生態系統，微信是佼佼者，并且成功將部分App的流量轉化成了Web app的流量。微信也一路創新了導流手段，沒有選擇用戶網址輸入、也沒有選擇用戶搜索進入web app，而是把賬號變成網址并且直接收藏的方式，形成了一個特殊的“web app瀏覽器”。在打通了流量后又恰當的加入了支付手段，不但盤活了流量也讓流量變得更加有價值。
這給HTML 5開發者帶來了希望，不過很快又很失望，因為開發者發現微信對流量的管控超乎預期。這讓我想到了SNS時代開放平臺玩死眾多social game廠商的過去。中國有大的互聯網開放平臺，曾經的騰訊、人人甚至淘寶。但是總結規則無一不是“貔貅原則”流量只進不出，所謂的盤活流量只是為自身生態服務，雖然這樣無可厚非，只是對于開發者來說把自己的夢想嫁接在“中國版的開放平臺上”無異于“與虎謀皮”。因此HTML 5生態的建立或許可以借助開放平臺，但是真正可以對抗原生生態的HTML 5需要的是類似于WebOS這種更徹底的變革。
開發者對于HTML5的定稿，心態大可保持平和，短期內不會帶來任何的實質性改變。瀏覽器特別是操作系統廠商也不會因為W3C標準的定稿而放棄一直維護的自身利益，該支持的早已經支持，不該支持的也不會遵照標準去支持。只是HTML 5作為進步的一代標準，拋開利益和政治的博弈，還是會給開發者帶來更多的價值。只要不盲從，以學習的心態積極對待，仍會從中獲益。
HTML 5和配套的web開發技術具有跨平臺、低門檻的特性，目前大量的APP中廣泛使用了HTML5配合native development原生開發，極大的降低了APP整體的開發成本，更有一些移動應用引擎使用Javascript和HTML 5開發跨平臺native app，在不觸碰iOS與Android生態利益的前提下，發揮實用的價值。因此只要回歸到技術本身，把HTML 5技術應用到可以使用的場景中充分發揮價值，就可以逐步迎接更光明的未來。
2年前，移動開發領域掀起過一次行業大辯論“web app和native app誰死誰活”的問題。今天這個問題依然是一個有價值的問題。所以下一篇是，HTML 5盛宴（二）：再論Web app和Native app的未來。
本文作者劉鑫，移動云服務APICloud創始人兼CEO，從SP夢網時代就開始持續關注移動Web開發，個人郵箱hi.seanliu@yahoo.com
除非注明，本站文章均為原創或編譯，轉載請注明： 文章來自 36氪
36氪官方iOS應用正式上線，支持『一鍵下載36氪報道的移動App』和『離線閱讀』立即下載！
今，在各種互聯網應用中，隨著站點對硬件性能、響應速度、服務穩定性、數據可靠性等要求也越來越高，單臺服務器也將難以無法承擔所有的訪問需求。
圖片來自 Pexels
當然了，除了使用性價比高的設備和專用負載分流設備外，還有一些其他選擇來幫你解決此問題，就是搭建集群服務器通過整合多臺普通的服務器設備并以同一個地址對外提供相同的服務。
今天就帶大家學習企業中常用的一種群集技術 LVS：
什么是 LVS?
LVS 是 Linux Virtual Server 的簡寫，也就是 Linux 虛擬服務器，是一個虛擬的服務器集群系統，本項目在 1998 年 5 月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。
官方網站：http://www.linuxvirtualserver.org，LVS 實際上相當于基于 IP 地址的虛擬化應用，為基于 IP 地址和內容請求分發的負載均衡提出了高效的解決方法，現在 LVS 已經是 Linux 內核標準的一部分。
使用 LVS 可以達到的技術目標是：通過 LVS 達到的負載均衡技術和 Linux 操作系統實現一個高性能高可用的 Linux 服務器集群，具有良好的可靠性、可擴展性和可操作性，從而以低廉的成本實現最優的性能。
LVS 是一個實現負載均衡集群的開源軟件項目，LVS 架構從邏輯上可分為調度層、Server 集群層和共享存儲層。
為什么要用 LVS?
那為什么還需要用 LVS 呢?隨著 Internet 的爆炸性增長以及日常生活中的日益重要的作用，Internet 上的流量速度增長，以每年 100% 以上的速度增長。
服務器上的工作負載壓力也迅速增加，因此服務器在短時間內將會過載，尤其是對于受歡迎的網站而言。
為了克服服務器的過載壓力問題，有兩種解決方案：
構建服務器集群的方法如下：
基于 DNS 的負載均衡集群：DNS 負載均衡可能是構建網絡服務群集的最簡單方法。
使用域名系統通過將域名解析為服務器的不同 IP 地址來將請求分發到不同的服務器。
當 DNS 請求到達 DNS 服務器以解析域名時，DNS 服務器將基于調度策略發出服務器 IP 地址之一，然后來自客戶端的請求使用相同的本地緩存名稱服務器將在指定的名稱解析生存時間(TTL)中發送到同一服務器。
但是，由于客戶端和分層 DNS 系統的緩存特性，很容易導致服務器之間的動態負載不平衡，因此服務器很難處理其峰值負載。在 DNS 服務器上不能很好地選擇名稱映射的 TTL 值。
如果值較小，DNS 流量很高，而 DNS 服務器將成為瓶頸;如果值較大，則動態負載不平衡將變得更糟。
即使 TTL 值設置為零，調度粒度也是針對每個主機的，不同用戶的訪問模式可能會導致動態負載不平衡，因為有些人可能從站點中拉出很多頁面，而另一些人可能只瀏覽了幾頁然后轉到遠。
而且，它不是那么可靠，當服務器節點發生故障時，將名稱映射到 IP 地址的客戶端會發現服務器已關閉。
基于分派器的負載平衡集群：分派器，也稱為負載平衡器，可用于在群集中的服務器之間分配負載，以便服務器的并行服務可以在單個 IP 地址上顯示為虛擬服務，并且最終用戶可以像單個服務器一樣進行交互不知道群集中的所有服務器。
與基于 DNS 的負載平衡相比，調度程序可以按精細的粒度(例如每個連接)調度請求，以實現服務器之間的更好負載平衡。一臺或多臺服務器發生故障時，可以掩蓋故障。
服務器管理變得越來越容易，管理員可以隨時使一臺或多臺服務器投入使用或退出服務，而這不會中斷最終用戶的服務。
負載均衡可以分為兩個級別，即應用程序級別和 IP 級別。例如，反向代理和 pWEB是用于構建可伸縮 Web 服務器的應用程序級負載平衡方法。
他們將 HTTP 請求轉發到群集中的其他 Web 服務器，獲取結果，然后將其返回給客戶端。
由于在應用程序級別處理 HTTP 請求和答復的開銷很高，我相信當服務器節點數增加到 5 個或更多時，應用程序級別的負載均衡器將成為新的瓶頸，這取決于每個服務器的吞吐量服務器。
LVS 與 Nginx 功能對比如下：
LVS 的組成及作用
LVS 由兩部分程序組成：
作用如下：
負載均衡的由來及所帶來的好處
在業務剛起步時，一般先使用單臺服務器對外進行提供服務。隨著后期的業務增長，流量也越來越大。
當這單臺服務器的訪問量越大時，服務器所承受的壓力也就越大，性能也將無法滿足業務需求，超出自身所指定的訪問壓力就會崩掉，避免發生此類事情的發生。
我們將采取其他方案，將多臺服務器組成集群系統從而來提高整體服務器的處理性能，使用統一入口(流量調度器)的方式通過均衡的算法進行對外提供服務，將用戶大量的請求均衡地分發到后端集群不同的服務器上。
因此也就有了負載均衡來分擔服務器的壓力。使用負載均衡給我們所帶來的好處：提高系統的整體性能、提高系統的擴展性、提高系統的高可用性。
LVS 負載均衡集群的類型
負載均衡群集：Load Balance Cluster，以提高應用系統的響應能力，盡可能處理更多的訪問請求、減少延遲為目標，從而獲得高并發、高負載的整體性能。
高可用群集：High Availability Cluster，以提高應用系統的可靠性，盡可能的減少終端時間為目標、確保服務的連續性，達到高可用的容錯效果。
高性能運算群集：High Performance Computer Cluster，以提高應用系統的 CPU 運算速度、擴展硬件資源和分析能力為目標、從而獲得相當于大型、超級計算機的高性能計算能力。
DNS/軟硬件負載均衡的類型
①DNS 實現負載均衡
一個域名通過 DNS 解析到多個 IP，每個 IP 對應不同的服務器實例，就完成了流量的調度，這也是 DNS 實現負載均衡是最簡單的方式。
使用該方式最大的優點：實現簡單，成本低，無需自己開發或維護負載均衡設備。
不過存在一些缺點：服務器故障切換延遲大，升級不方便、流量調度不均衡，粒度大、流量分配策略較簡單，支持的算法較少、DNS 所支持的 IP 列表有限制要求。
②硬件負載均衡
硬件負載均衡是通過專門的硬件設備從而來實現負載均衡功能，比如：交換機、路由器就是一個負載均衡專用的網絡設備。
目前典型的硬件負載均衡設備有兩款：F5 和 A10。不過話說，能用上這種硬件負載均衡設備的企業都不是一般的公司，反而普通業務量級小的其他企業基本用不到。
硬件負載均衡的優點：
硬件負載均衡的缺點：
③軟件負載均衡
軟件負載均衡有如下幾種：
軟件負載均衡的優點：簡單、靈活、便宜(直接在 Linux 操作系統上安裝上述所使用的軟件負載均衡，部署及維護較簡單，4 層 和 7 層負載均衡可根據業務進行選擇也可根據業務特點，比較方便進行擴展及定制功能)。
LVS 集群的通用體系結構
第一層：負載調度器：Load Balancer，它是訪問整個群集系統的唯一入口，對外使用所有服務器共有的虛擬 IP 地址，也成為群集 IP 地址。
負載均衡器：是服務器群集系統的單個入口點，可運行 IPVS，該 IPVS 在 Linux 內核或 KTCPVS 內部實現 IP 負載均衡技術，在 Linux 內核中實現應用程序級負載平衡。
使用 IPVS 時，要求所有服務器提供相同的服務和內容，負載均衡器根據指定的調度算法和每個服務器的負載將新的客戶端請求轉發到服務器。無論選擇哪個服務器，客戶端都應獲得相同的結果。
使用 KTCPVS 時，服務器可以具有不同的內容，負載均衡器可以根據請求的內容將請求轉發到其他服務器。
由于 KTCPVS 是在 Linux 內核內部實現的，因此中繼數據的開銷很小，因此仍可以具有較高的吞吐量。
第二層：服務器池 Server Pool，群集所提供的應用服務，比如：HTTP、FTP 服務器池來承擔，每個節點具有獨立的真實 IP 地址，只處理調度器分發過來的客戶機請求。
服務器群集的節點可根據系統所承受的負載進行分擔。當所有服務器過載時，可添加多臺服務器來處理不斷增加的工作負載。
對于大多數 Internet 服務(例如Web)，請求通常沒有高度關聯，并且可以在不同服務器上并行運行。因此，隨著服務器群集的節點數增加，整體性能幾乎可以線性擴展。
第三層：共享存儲 Shared Storage，為服務器池中的所有節點提供穩定、一致的文件存儲服務，確保整個群集的統一性，可使用 NAS 設備或提供 NFS (Network File System)網絡文件系統共享服務的專用服務器。
共享存儲：可以是數據庫系統，網絡文件系統或分布式文件系統。服務器節點需要動態更新的數據應存儲在基于數據的系統中，當服務器節點并行在數據庫系統中讀寫數據時，數據庫系統可以保證并發數據訪問的一致性。
靜態數據通常保存在網絡文件系統(例如 NFS 和 CIFS)中，以便可以由所有服務器節點共享數據。
但是，單個網絡文件系統的可伸縮性受到限制，例如，單個 NFS / CIFS 只能支持 4 到 8 個服務器的數據訪問。
對于大型集群系統，分布式/集群文件系統可以用于共享存儲，例如 GPFS，Coda 和 GFS，然后共享存儲也可以根據系統需求進行擴展。
LVS 負載均衡的基本原理
Netfilter 的基本原理
在介紹 LVS 負載均衡基本原理之前，先說一下 Netfilter 的基本原理。因為 LVS 是基于 Linux 內核中 Netfilter 框架實現的負載均衡系統。
Netfilter 其實很復雜也很重要，平時說的 Linux 防火墻就是 Netfilter，不過我們操作的還是 iptables，iptables 和 Netfilter 是 Linux 防火墻組合工具，是一起來完成系統防護工作的。
iptables 是位于用戶空間，而 Netfilter 是位于內核空間。iptables 只是用戶空間編寫和傳遞規則的工具而已，真正工作的還是 Netfilter。
兩者間的區別：Netfilter 是內核態的 Linux 防火墻機制，它作為一個通用、抽象的框架，提供了一整套的 hook 函數管理機制，提供數據包過濾、網絡地址轉換、基于協議類型的連接跟蹤的功能，可在數據包流經過程中，根據規則設置若干個關卡(hook 函數)來執行相關操作。
它共設置了 5 個點，包括：
iptable 是用戶層的工具，提供命令行接口，能夠向 Netfilter 中添加規則策略，從而實現報文過濾，修改等功能。
通過下圖我們可以來了解下 Netfilter 的工作機制：
當數據包通過網絡接口進入時，經過鏈路層之后進入網絡層到達PREROUTING，然后根據目標 IP 地址進行查找路由。
如目標 IP 是本機，數據包會傳到 INPUT 上，經過協議棧后根據端口將數據送到相應的應用程序;應用程序將請求處理后把響應數據包發送至 OUTPUT 里，最終通過 POSTROUTING 后發送出網絡接口。
如目標 IP 不是本機，并且服務器開啟了 FORWARD 參數，這時會將數據包遞送給 FORWARD，最后通過 POSTROUTING 后發送出網絡接口。
LVS 的基本原理
LVS 基于 Netfilter 框架，工作在 INPUT 鏈上，在 INPUT 鏈上注冊 ip_vs_in HOOK 函數，進行 IPVS 相關主流程。
詳細原理概述如下：
①當客戶端用戶訪問 www.baidu.com 網站時，用戶訪問請求通過層層網絡，最終通過交換機進入 LVS 服務器網卡進入內核空間層。
②進入 PREROUTING 后通過查找路由，確定訪問目的 VIP 是本機 IP 地址的話，數據包將進入 INPUT 鏈中。
③因為 IPVS 工作在 INPUT 鏈上，會根據訪問的 VIP 和端口判斷請求是否為 IPVS 服務，是的情況下，則調用注冊的 IPVS HOOK 函數，進行 IPVS 相關流程，并強制修改數據包的相關數據，并將數據包發往 POSTROUTING 鏈中。
④POSTROUTING 鏈收到數據包后，將根據目標 IP 地址服務器，通過路由選路，將數據包最終發送至后端真實服務器中。
上面就是我們所介紹的 LVS 的工作原理，那么 LVS 負載均衡還包括三種工作模式，且每種模式工作原理都有所不同，適用于不同應用場景，其最終目的都是能實現均衡的流量調度和良好的擴展性。
LVS 負載均衡的三種工作模式
群集的負載調度技術，可基于 IP、端口、內容等進行分發，其中基于 IP 的負載均衡是效率最高的。
基于 IP 的負載均衡模式，常見的有地址轉換(NAT)、IP 隧道(TUN)和直接路由(DR)三種工作模式。
NAT 模式
地址轉換：Network Address Translation，簡稱：NAT 模式，類似于防火墻的私有網絡結構，負載調度器作為所有服務器節點的網關，作為客戶機的訪問入口，也是各節點回應客戶機的訪問出口，服務器節點使用私有 IP 地址，與負載調度器位于同一個物理網絡，安全性要優于其他兩種方式。
NAT 實現原理過程如下：
①客戶端發出的請求數據包經過網絡到達 LVS 網卡，數據包源 IP 為 CIP，目的 IP 為 VIP。
②然后進入 PREROUTING 鏈中，根據目的 IP 查找路由，確定是否為本機 IP 地址，隨后將數據包轉發至 INPUT 鏈中，源 IP 和 目的 IP 不變。
③到達 LVS 后，通過目的 IP 和目的 PORT 查找是否為 IPVS 服務，如是 IPVS 服務，將會選擇一個 RS 來作為后端服務器，數據包的目的 IP 地址將會修改為 RIP，這時并以 RIP 為目的 IP 去查找路由，確定下一跳及 PORT 信息后，數據包將會轉發至 OUTPUT 鏈中。
④被修改過的數據包經過 POSTROUTING 鏈后，到達 RS 服務器，數據包源 IP 為 CIP，目的 IP 為 RIP。
⑤RS 服務器經過處理后，將會把數據包發送至用戶空間的應用程序，待處理完成后，發送響應數據包，RS 服務器的默認網關為 LVS 的 IP，應用程序將會把數據包轉發至下一跳 LVS 服務器，數據包源 IP 為 RIP，目的 IP 為 CIP。
⑥LVS 服務器收到 RS 服務器響應的數據包后，查找路由，目的 IP 不是本機 IP并且 LVS 服務器開啟了 FORWARD 模式，會將數據包轉發給它，數據包不變。
⑦LVS 服務器收到響應數據包后，根據目的 IP 和 目的 PORT 查找相應的服務，這時，源 IP 為 VIP，通過查找路由，確定下一跳信息并將數據包發送至網關，最終回應給客戶端用戶。
NAT 模式的優點：
NAT 模式的缺點：
NAT 模式的使用場景：對 Windows 操作系統的用戶比較友好，使用 LVS ，必須選擇 NAT 模式。
TUN 模式
IP 隧道：IP Tunnel，簡稱：TUN 模式，采用開放式的網絡結構，負載調度器作為客戶機的訪問入口，各節點通過各自的 Internet 連接直接回應給客戶機，而不經過負載調度器，服務器節點分散在互聯網中的不同位置，有獨立的公網 IP 地址，通過專用 IP 隧道與負載調度器相互通信。
TUN 實現原理過程如下：
①客戶端發送數據包經過網絡后到 LVS 網卡，數據包源 IP 為 CIP，目的 IP 為 VIP。
②進入 PREROUTING 鏈后，會根據目的 IP 去查找路由，確定是否為本機 IP，數據包將轉發至 INPUT 鏈中，到 LVS，源 IP 和 目的 IP 不變。
③到 LVS 后，通過目的 IP 和目的 PORT 查找是否為 IPVS 服務，如是 IPVS 服務，將會選擇一個 RS 后端服務器， 源 IP 為 DIP，目標 IP 為 RIP，數據包將會轉發至 OUTPUT 鏈中。
④數據包根據路由信息到達 LVS 網卡，發送至路由器網關，最終到達后端服務器。
⑤后端服務器收到數據包后，會拆掉最外層的 IP 地址后，會發現還有一層 IP 首部，源 IP 為 CIP，目的 IP 為 VIP，TUNL0 上配置 VIP，查找路由后判斷為本機 IP 地址，將會發給用戶空間層的應用程序響應后 VIP 為源 IP，CIP 為目的 IP 數據包發送至網卡，最終返回至客戶端用戶。
TUN 模式的優點：
TUN 模式的缺點：
TUN 模式的使用場景：如對轉發性要求較高且具有跨機房需求的，可選擇 TUN 模式。
DR 模式
直接路由：Direct Routing，簡稱 DR 模式，采用半開放式的網絡結構，與 TUN 模式的結構類似，但各節點并不是分散在各個地方，而是與調度器位于同一個物理網絡，負載調度器與各節點服務器通過本地網絡連接，不需要建立專用的 IP 隧道。它是最常用的工作模式，因為它的功能性強大。
DR 實現原理過程如下：
①當客戶端用戶發送請求給 www.baidu.com 網站時，首先經過 DNS 解析到 IP 后并向百度服務器發送請求，數據包經過網絡到百度 LVS 負載均衡服務器。
這時到達 LVS 網卡時的數據包包括：源 IP 地址(客戶端地址)、目的 IP 地址(百度對外服務器 IP 地址，也就是 VIP)、源 MAC 地址(CMAC / LVS 連接路由器的 MAC 地址)、目標 MAC 地址(VMAC / VIP 對應的 MAC 地址)。
②數據包到達網卡后，經過鏈路層到達 PREROUTING 鏈，進行查找路由，發現目的 IP 是 LVS 的 VIP，這時就會發送至 INPUT 鏈中并且數據包的 IP 地址、MAC 地址、Port 都未經過修改。
③數據包到達 INPUT 鏈中，LVS 會根據目的 IP 和 Port(端口)確認是否為 LVS 定義的服務。
如是定義過的 VIP 服務，會根據配置的服務信息，從 RealServer 中選擇一個后端服務器 RS1，然后 RS1 作為目標出方向的路由，確定下一跳信息及數據包通過具體的哪個網卡發出，最好將數據包通過 INET_HOOK 到 OUTPUT 鏈中。
④數據包通過 POSTROUTING 鏈后，目的 MAC 地址將會修改為 RealServer 服務器 MAC 地址(RMAC)源 MAC 地址修改為 LVS 與 RS 同網段的 IP 地址的 MAC 地址(DMAC)此時，數據包將會發至 RealServer 服務器。
⑤數據包到達 RealServer 服務器后，發現請求報文的 MAC 地址是自己的網卡 MAC 地址，將會接受此報文，待處理完成之后，將響應報文通過 lo 接口傳送給 eth0 網卡然后向外發出。
此時的源 IP 地址為 VIP，目標 IP 為 CIP，源 MAC 地址為 RS1 的 RMAC，目的 MAC 地址為下一跳路由器的 MAC 地址(CMAC)，最終數據包通過 RS 相連的路由器轉發給客戶端。
DS 模式的優點：
DS 模式的缺點：
DS 模式的使用場景：對性能要求高的，可首選 DR 模式，還可透傳客戶端源 IP 地址。
NAT 模式：只需一個公網 IP 地址，是最易用的一種負載均衡模式，安全性較好。
TUN 模式 和 DR 模式：負載能力強大、適用范圍廣、節點安全性較差。
LVS 的十種負載調度算法
LVS 的十種負載調度算法如下：
①輪詢：Round Robin，將收到的訪問請求按順序輪流分配給群集中的各節點真實服務器中，不管服務器實際的連接數和系統負載。
②加權輪詢：Weighted Round Robin，根據真實服務器的處理能力輪流分配收到的訪問請求，調度器可自動查詢各節點的負載情況，并動態跳轉其權重，保證處理能力強的服務器承擔更多的訪問量。
③最少連接：Least Connections，根據真實服務器已建立的連接數進行分配，將收到的訪問請求優先分配給連接數少的節點，如所有服務器節點性能都均衡，可采用這種方式更好的均衡負載。
④加權最少連接：Weighted Least Connections，服務器節點的性能差異較大的情況下，可以為真實服務器自動調整權重，權重較高的節點將承擔更大的活動連接負載。
⑤基于局部性的最少連接：LBLC，基于局部性的最少連接調度算法用于目標 IP 負載平衡，通常在高速緩存群集中使用。
如服務器處于活動狀態且處于負載狀態，此算法通常會將發往 IP 地址的數據包定向到其服務器;如果服務器超載(其活動連接數大于其權重)，并且服務器處于半負載狀態，則將加權最少連接服務器分配給該 IP 地址。
⑥復雜的基于局部性的最少連接：LBLCR，具有復雜調度算法的基于位置的最少連接也用于目標 IP 負載平衡，通常在高速緩存群集中使用。
與 LBLC 調度有以下不同：負載平衡器維護從目標到可以為目標提供服務的一組服務器節點的映射。對目標的請求將分配給目標服務器集中的最少連接節點。
如果服務器集中的所有節點都超載，則它將拾取群集中的最少連接節點，并將其添加到目標服務器群中;如果在指定時間內未修改服務器集群，則從服務器集群中刪除負載最大的節點，以避免高度負載。
⑦目標地址散列調度算法：DH，該算法是根據目標 IP 地址通過散列函數將目標 IP 與服務器建立映射關系，出現服務器不可用或負載過高的情況下，發往該目標 IP 的請求會固定發給該服務器。
⑧源地址散列調度算法：SH，與目標地址散列調度算法類似，但它是根據源地址散列算法進行靜態分配固定的服務器資源。
⑨最短延遲調度：SED，最短的預期延遲調度算法將網絡連接分配給具有最短的預期延遲的服務器。
如果將請求發送到第 i 個服務器，則預期的延遲時間為(Ci +1)/Ui，其中 Ci 是第 i 個服務器上的連接數，而 Ui 是第 i 個服務器的固定服務速率(權重) 。
⑩永不排隊調度：NQ，從不隊列調度算法采用兩速模型。當有空閑服務器可用時，請求會發送到空閑服務器，而不是等待快速響應的服務器。
如果沒有可用的空閑服務器，則請求將被發送到服務器，以使其預期延遲最小化(最短預期延遲調度算法)。
LVS 涉及相關的術語及說明
上述內容中涉及到很多術語或縮寫，這里簡單解釋下具體的含義，便于理解：
總結
回顧下，通過本文你可學習到什么是 LVS、為什么要用 LVS、LVS 的組成及工作原理等。
參考文獻：
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
