本文由騰訊技術(shù)團隊peter分享，原題“騰訊網(wǎng)關(guān)TGW架構(gòu)演進之路”，下文進行了排版和內(nèi)容優(yōu)化等。
1、引言
TGW全稱Tencent Gateway，是一套實現(xiàn)多網(wǎng)統(tǒng)一接入，支持自動負(fù)載均衡的系統(tǒng)， 是公司有10+年歷史的網(wǎng)關(guān)，因此TGW也被稱為公司公網(wǎng)的橋頭堡。
本文從騰訊公網(wǎng)TGW網(wǎng)關(guān)系統(tǒng)的應(yīng)用場景、背景需求講起，重點解析了從山海1.0架構(gòu)到山海2.0架構(gòu)需要解決的問題和架構(gòu)規(guī)劃與設(shè)計實現(xiàn)，以及對于未來TGW山海網(wǎng)關(guān)的發(fā)展和演進方向。
技術(shù)交流：
2、專題目錄
本文是專題系列文章的第11篇，總目錄如下：
- 《長連接網(wǎng)關(guān)技術(shù)專題(一)：京東京麥的生產(chǎn)級TCP網(wǎng)關(guān)技術(shù)實踐總結(jié)》
- 《長連接網(wǎng)關(guān)技術(shù)專題(二)：知乎千萬級并發(fā)的高性能長連接網(wǎng)關(guān)技術(shù)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(三)：手淘億級移動端接入層網(wǎng)關(guān)的技術(shù)演進之路》
- 《長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實時推送網(wǎng)關(guān)技術(shù)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(五)：喜馬拉雅自研億級API網(wǎng)關(guān)技術(shù)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(六)：石墨文檔單機50萬WebSocket長連接架構(gòu)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(七)：小米小愛單機120萬長連接接入層的架構(gòu)演進》
- 《長連接網(wǎng)關(guān)技術(shù)專題(八)：B站基于微服務(wù)的API網(wǎng)關(guān)從0到1的演進之路》
- 《長連接網(wǎng)關(guān)技術(shù)專題(九)：去哪兒網(wǎng)酒店高性能業(yè)務(wù)網(wǎng)關(guān)技術(shù)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(十)：百度基于Go的千萬級統(tǒng)一長連接服務(wù)架構(gòu)實踐》
- 《長連接網(wǎng)關(guān)技術(shù)專題(十一)：揭秘騰訊公網(wǎng)TGW網(wǎng)關(guān)系統(tǒng)的技術(shù)架構(gòu)演進》（* 本文）
3、TGW網(wǎng)關(guān)系統(tǒng)的重要性
TGW全稱Tencent Gateway，是一套實現(xiàn)多網(wǎng)統(tǒng)一接入、支持自動負(fù)載均衡的系統(tǒng)， 是公司有10+年歷史的網(wǎng)關(guān)，因此TGW也被稱為公司公網(wǎng)的橋頭堡。它對外連接了各大運營商并支撐公有云上EIP、CLB等產(chǎn)品功能，對內(nèi)提供了公網(wǎng)網(wǎng)絡(luò)的接入功能，如為游戲、微信等業(yè)務(wù)提供公網(wǎng)接入服務(wù)。
TGW主要有兩大產(chǎn)品：
- 1）彈性EIP（比如購買一臺虛擬機CVM或是一個NAT實例后，通過EIP連通外網(wǎng)）；
- 2）四層CLB。
四層CLB一般分為內(nèi)網(wǎng)CLB和外網(wǎng)CLB：
- 1）內(nèi)網(wǎng)CLB是在vpc內(nèi)創(chuàng)建一個CLB實例，把多個CVM服務(wù)掛在了內(nèi)網(wǎng)CLB上，為后端RS提供負(fù)載均衡的能力；
- 2）外網(wǎng)CLB面對的是公網(wǎng)側(cè)負(fù)載均衡的需求。
當(dāng)在內(nèi)部部署CLB集群時，可分為IPV4或者IPV6兩大類，根據(jù)物理網(wǎng)絡(luò)類型又細(xì)分為BGP和三網(wǎng)兩類。三網(wǎng)指這些IP地址是靜態(tài)的，不像BGP一樣能夠在多個運營商之間同時進行廣播。
以上就是四層TGW產(chǎn)品及功能，山海網(wǎng)關(guān)在原有產(chǎn)品基礎(chǔ)上做了網(wǎng)絡(luò)架構(gòu)方面的演進。
4、Region EIP的引入
具體介紹下EIP和CLB兩個產(chǎn)品。
過去CLB和EIP使用不同的IP地址池，導(dǎo)致資源池上的隔離問題。使得我們無法把EIP地址綁定到公有云CLB實例上。
例如：一個創(chuàng)業(yè)公司最初只購買一臺虛擬機并掛載一個公網(wǎng)EIP來提供服務(wù)。隨著用戶量的增長，如果想將這個EIP地址遷移到一個公網(wǎng)CLB實例上，在原有架構(gòu)下是無法實現(xiàn)這種遷移的。
此外：EIP和CLB部署在每個機房，因此在每個機房都需要建立EIP出口。但是各個機房的公網(wǎng)出口之間缺無法相互容災(zāi)。
所以這種情形下，我們確定了產(chǎn)品的目標(biāo)：
- 1）希望將所有公網(wǎng)出口整合到一到兩個機房之內(nèi)，以避免重復(fù)建設(shè)，節(jié)省成本；
- 2）通過將出口集中，我們可以將對應(yīng)的網(wǎng)關(guān)服務(wù)器也進行集中，進而提高設(shè)備的利用率；
- 3）通過這樣的布局可實現(xiàn)跨機房的容災(zāi)方案。
因此：最早的Region EIP（REIP）計劃應(yīng)運而生。
以北京這類大型region為例的：我們將EIP專區(qū)建設(shè)到位于兩個城市的超核機房。這兩個機房通常會放置物理網(wǎng)絡(luò)的交換設(shè)備，并為各自設(shè)立了一個REIP專區(qū)。在REIP專區(qū)內(nèi)部署Region EIP集群。為了實現(xiàn)跨AZ容災(zāi)，兩個機房的集群之間借助大小網(wǎng)段實現(xiàn)互相備份容災(zāi)的能力。一旦其中一個機房的集群發(fā)生故障或出現(xiàn)網(wǎng)絡(luò)問題，另一個機房的集群可以立即承擔(dān)起容災(zāi)任務(wù)。
同時：因為新的Region EIP的網(wǎng)絡(luò)架構(gòu)跟原來的網(wǎng)絡(luò)架構(gòu)不一樣，通過網(wǎng)絡(luò)架構(gòu)升級以及機型升級，我們能夠把單臺Region EIP的性能做到原有單臺EIP性能的5倍。這樣我們通過容量的提升進一步提升了設(shè)備利用率，在完成全量Region EIP后，設(shè)備數(shù)量會從3000+臺縮減至700+臺。同時原有的CLB集群還保留在各個機房不變，這些CLB集群的外網(wǎng)接入能力由Region EIP承擔(dān)。
5、公網(wǎng)CLB的演進
5.1概述
公網(wǎng)CLB最早是有公網(wǎng)接入能力的。引入到Region EIP之后，當(dāng)初設(shè)想是公網(wǎng)CLB不再演進，盡量讓存量用戶遷移到另外一種形式，上層是Region EIP，下層是內(nèi)網(wǎng)CLB。用戶先買一個內(nèi)網(wǎng)CLB，如果需要對公網(wǎng)提供服務(wù)就再買一個彈性EIP，把EIP跟內(nèi)網(wǎng)CLB綁定在一起，提供CLB公網(wǎng)的能力，替代原有的公網(wǎng)CLB，這是最早公網(wǎng)CLB的替代方案。
兩個方案的區(qū)別是：原有公網(wǎng)CLB，用戶僅看到一個CLB實例。新的模式下，用戶看到的是兩個實例：一個EIP+一個內(nèi)網(wǎng)CLB，兩個實例都可以獨立運營管理。這就是我們最早的兩層架構(gòu)設(shè)想，想把公網(wǎng)CLB跟外網(wǎng)解耦。
但是，真正去跟用戶或產(chǎn)品交流時，這個想法遇到了比較大的挑戰(zhàn)：
1）用戶體驗的改變：以前公網(wǎng)CLB用戶看到是一個實例，但是現(xiàn)在用戶看到兩個實例，必然會給用戶帶來一些適配工作。比如用戶進行創(chuàng)建、管理實例時，API不一樣了。以前使用通過自動化腳本創(chuàng)建公網(wǎng)CLB實例的，現(xiàn)在腳本還要改變?nèi)ミm配新的API。
2）用戶習(xí)慣改變：以前用戶習(xí)慣在一個實例下，點擊頁面，就能夠查看流量、鏈接數(shù)等監(jiān)控信息。現(xiàn)在EIP流量需要到REIP查看，而鏈接數(shù)還需在CLB產(chǎn)品上看。
3）存量客戶無法遷移：原來客戶買的公網(wǎng)CLB實例，是無法直接無感知遷移到內(nèi)網(wǎng)CLB+REIP這種新形式的。
在這些挑戰(zhàn)下，這個替代方案沒能真正落地。結(jié)合用戶的要求，我們最終跟產(chǎn)品定下的策略是：公網(wǎng)CLB保持不變。原有的公網(wǎng)CLB繼續(xù)保留，同時如果用戶新增的公網(wǎng)CLB需求，也要繼續(xù)支持。
5.2公網(wǎng)CLB模型
那么，公網(wǎng)CLB到底怎么演變？
我們的初衷并不是把公網(wǎng)CLB這個產(chǎn)品摒棄掉，而是要收斂公網(wǎng)入口。所以我們針對這個初始需求，提出了上面這個兩級架構(gòu)模型。
首先：用REIP將公網(wǎng)流量先引進來，再將這個流量通過隧道報文的形式轉(zhuǎn)發(fā)給原有的公網(wǎng)CLB集群，這樣公網(wǎng)CLB不需要原有外網(wǎng)接入的能力，不需要再跟外網(wǎng)打交道，可以演變成只在機房內(nèi)部的集群；同時因為公網(wǎng)CLB的流量都會經(jīng)過REIP，REIP自然也就是公網(wǎng)CLB的流量入口。從而達(dá)到我們最初收斂公網(wǎng)入口的目的。這樣的架構(gòu)升級，可實現(xiàn)用戶無感知。架構(gòu)升級切換過程中，用戶在訪問公網(wǎng)CLB，不會出現(xiàn)卡頓或者重連的現(xiàn)象。
這個架構(gòu)模型也有一定的局限性的。公網(wǎng)CLB實例只能承載公網(wǎng)的流量，無法像上文提到的兩層RERP+CLB那樣，內(nèi)外網(wǎng)隨時進行轉(zhuǎn)化。REIP+CLB實例中的CLB既承載內(nèi)網(wǎng)側(cè)CLB的流量，又承載公網(wǎng)側(cè)CLB的流量。
6、山海架構(gòu) 1.0
借助這個兩級架構(gòu)模型，我們能夠把公網(wǎng)CLB保留下來，并且通過REIP把公網(wǎng)入口收斂。
進一步思考并完善，我們提出了下面的想法：跟產(chǎn)品進行解耦。
以前我們一個地區(qū)上線公網(wǎng)CLB產(chǎn)品，底層就要搭建有一個公網(wǎng)CLB的集群去支持。用戶需要內(nèi)網(wǎng)CLB服務(wù)，就要對應(yīng)搭建個內(nèi)網(wǎng)CLB的集群。底層集群類型跟產(chǎn)品是強耦合，有IPv4/IPv6， 公網(wǎng)/內(nèi)網(wǎng)、BGP/三網(wǎng)組合出的多個產(chǎn)品形態(tài)。
這種模式在小地域部署，因為產(chǎn)品業(yè)務(wù)的流量小，集群利用率低，就會造成很大的成本壓力。
為了應(yīng)對這種小帶寬低成本的訴求，我們將CLB+REIP的模型進一步抽象，引入山海架構(gòu)：我們只建設(shè)CLB和REIP兩類集群。通過這兩類集群上的不同實例組合，滿足多個產(chǎn)品形態(tài)的要求。從而實現(xiàn)產(chǎn)品形態(tài)和底層物理網(wǎng)絡(luò)集群類型解耦。
解耦合的方式是：CLB和REIP通過不同的實例類型，組合出不同的產(chǎn)品形態(tài)。
山海架構(gòu)在TGW內(nèi)部做閉環(huán)，不涉及到產(chǎn)品側(cè)和用戶側(cè)的改動。整個過程升級，對產(chǎn)品側(cè)不做任何接口上的更新。因為產(chǎn)品側(cè)的API接口保持不變，對用戶側(cè)就可以做到完全無感知。在產(chǎn)品側(cè)保持不變，就需要我們在內(nèi)部管控，識別接入用戶實例是哪種形態(tài)的產(chǎn)品，拆分成不同形式的CLB和REIP的實例。其他的相關(guān)功能的比如流量統(tǒng)計、限速等模塊也都要適配不同的產(chǎn)品形態(tài)，通過模塊的適配，做到山海架構(gòu)對上層產(chǎn)品側(cè)應(yīng)用的透明。
山海架構(gòu)1.0歸納起來有兩個重點：收斂公網(wǎng)入口和集群類型歸一。
1）REIP：部署在城核機房，同時承載的是CLB和REIP兩類產(chǎn)品的公網(wǎng)流量。之前EIP，在物理網(wǎng)絡(luò)上有BGP+三網(wǎng)、v4/v6等多種集群類型。REIP借助vlan的隔離支持，把所有的網(wǎng)絡(luò)類型都集中到一種REIP集群上來，我們稱之為全通集群。在物理網(wǎng)絡(luò)層面實現(xiàn)網(wǎng)絡(luò)類型的歸一， 然后再通過軟件層的適配，實現(xiàn)REIP支持多通類型的網(wǎng)絡(luò)接入能力。
2）CLB：在山海兩級架構(gòu)下，REIP集群處理公網(wǎng)側(cè)的各種場景組合，CLB集群通過隧道與REIP處理公網(wǎng)流量。之前一個機房如果要把所有的產(chǎn)品能力支持起來，大概有7種集群類型。現(xiàn)在CLB集群可以用一種集群類型來支持所有的產(chǎn)品的公網(wǎng)CLB產(chǎn)品，以及內(nèi)網(wǎng)CLB產(chǎn)品的能力。我們把三網(wǎng)+BGP以及內(nèi)外網(wǎng)還有V4V6等集群類型都用一種類型來支持，山海架構(gòu)完全落地后，開區(qū)的最小服務(wù)器數(shù)量可以降低到8臺服務(wù)器，來承載所有的EIP和CLB產(chǎn)品需求。
歸納起來一句話：對于用戶來說，產(chǎn)品形態(tài)沒有改變，用戶使用習(xí)慣也沒有改變。而在底層，我們把集群類型收斂到一個CLB集群和一個REIP集群上。
7、山海架構(gòu)1.0限速技術(shù)
在山海架構(gòu)演進中，有許多技術(shù)點，本文選取限速技術(shù)進行分享。
首先Region EIP支持三網(wǎng)。以前BGP跟三網(wǎng)分開獨立支持，山海網(wǎng)關(guān)統(tǒng)一用Region EIP支持。Region EIP本身的網(wǎng)絡(luò)架構(gòu)分成兩個機房，每個機房放4臺TGW設(shè)備，每個EIP只會走左邊或者右邊。一個EIP進來的流量經(jīng)過上面這層交換機時，經(jīng)過了ECMP分流，然后分到了4臺設(shè)備上。這樣對每個EIP其實是采用了分布式限速。
限速有兩個要求：
- 1）精確性，限速上下浮動要小，要限得準(zhǔn)；
- 2）要有容災(zāi)能力。
限速最極端的精準(zhǔn)就是把它放到單點上去做限速，但是單點限速就會面臨單點故障和容災(zāi)的問題。在X86服務(wù)器上，使用的是分布式限速，一個EIP均分到4臺服務(wù)器上，每五秒鐘做一次流量的的匯總統(tǒng)計，通過流量比例計算將這個EIP的帶寬配額，重新分配并分發(fā)到4臺設(shè)備上，以此來實現(xiàn)集群上的限速。在單臺設(shè)備上，也是沒隔一段時間，就重新計算配額并分配到每個CPU核上，我們目前用的是300毫秒周期。
需要說明的是：在限速的實現(xiàn)上，業(yè)務(wù)有多重實現(xiàn)方式，我們了解到有的實現(xiàn)的是靜態(tài)分配，比如120兆的帶寬，4臺設(shè)備，我們每臺設(shè)備分40M(三分之一)的帶寬。1/3而不是1/4的帶寬，目的是防止某一臺設(shè)備斷了之后，用戶總帶寬不達(dá)標(biāo)，影響用戶體驗。在單臺設(shè)備上限速，也有另外一種實現(xiàn)方式，大小桶。比如限速1M的帶寬，那么每個核第一次取回100K或者200K配額。后續(xù)報文處理時候，先消耗上次取回的配額，如果帶寬配額消耗光了，再重新取。周期調(diào)整跟大小桶這兩種實現(xiàn)方式各有優(yōu)缺點。從資源消耗來說，300毫秒周期的資源消耗相對會更少一些，兩者大概有10%左右的性能偏差。
限速上另一訴求：小帶寬的限速的精準(zhǔn)限速。
大帶寬比如100兆，分到每個核上相對富裕。小帶寬如一M帶寬，一秒鐘100k字節(jié)等，分到四臺機器再分到幾十個核上，每個核都可能不到一個大報，這時候再去做精準(zhǔn)限速就會非常困難，因為既然要提前分配資源，資源那么少，分配到單核上，可能一個包都過不去，但凡有一個報文過去了，又可能超了。所以在小帶寬限速時，我們把它退化成類似于單點限速的模式。由于入方向帶寬最小也是100兆，因此保持原有的分布式限速不變。只對出方向小帶寬，使用單點限速。方案是這樣的：
每臺REIP有自己一個獨享的內(nèi)網(wǎng)地址，只有這臺服務(wù)器故障時候，這個地址的流量才被分發(fā)到其他三臺服務(wù)器。
入方向流量被分到四臺REIP服務(wù)器后，REIP處理完通過tunnel轉(zhuǎn)發(fā)給母機。隧道的外層源地址，只使用其中一臺REIP服務(wù)器的獨享的IP地址。每個外網(wǎng)IP地址在掛載到集群下管理時候，就確定下來了。
母機在接受到網(wǎng)關(guān)發(fā)過去的流量，解析外層報文地址，并記錄在本地會話表里，我們稱之為母機的自學(xué)習(xí)能力。當(dāng)母機側(cè)轉(zhuǎn)發(fā)出方向報文時，就只會使用本地學(xué)習(xí)并記錄的外層地址去封裝隧道。這樣出方向的流量，就回到單臺TGW設(shè)備上，實現(xiàn)了單點限速。
獨享的內(nèi)網(wǎng)地址本身是有容災(zāi)能力：
- 1）當(dāng)其服務(wù)器故障了，流量就被分散到集群其他服務(wù)器，放棄單點限速；
- 2）當(dāng)服務(wù)器被修復(fù)上線后，又可以重新變成精準(zhǔn)的單點限速。
這樣保證小帶寬精準(zhǔn)限速的同時，又避免了單點故障。
在限速過程中，還有一個問題，因為CLB集群原來的限速是在CLB集群上自己做的，引入山海之后，REIP上有限速能力，那么公網(wǎng)CLB的限速要不要挪到REIP上？
我們經(jīng)過多次討論， 最終還是維持**這個限速在公網(wǎng)CLB上不變。
這里有幾種場景考量：
1）內(nèi)外網(wǎng)攻擊：如果我們把它放到REIP上，這里可以扛住外網(wǎng)的攻擊，但同時內(nèi)網(wǎng)的攻擊我們是防不住的，因為公網(wǎng)CLB上沒有限速后，流量內(nèi)網(wǎng)的攻擊就會先把CLB上壓過載，導(dǎo)致丟包，影響業(yè)務(wù)的穩(wěn)定性。
2）有效流量的準(zhǔn)確統(tǒng)計：原有架構(gòu)下，從公網(wǎng)流量首先到達(dá)CLB，我們需要檢查公網(wǎng)CLB上與port對應(yīng)的服務(wù)是否已配置規(guī)則并啟用。如果沒有啟用，則將報文直接丟棄且不記錄為公網(wǎng)CLB的帶寬使用量。山海架構(gòu)下，如果先經(jīng)過Region EIP限速，這類無服務(wù)訪問流量（如惡意攻擊和垃圾流量）也將占用限速資源。盡管這部分限速流量會送達(dá)至CLB集群，但由于缺乏相應(yīng)服務(wù)支持，它們最終還是將被丟棄。結(jié)果導(dǎo)致用戶帶寬不及預(yù)期。比如用戶購買10M帶寬，實際有效運行的僅有8M流量，而其余2M被無服務(wù)流量占用了。
3）多重限速的影響：還有一個這個場景中，當(dāng)Region EIP實施帶寬限速后，這些流量最終可能進入公網(wǎng)CLB。然而，由于CLB的規(guī)格限制，例如新建連接數(shù)或并發(fā)連接數(shù)已達(dá)到上限，部分?jǐn)?shù)據(jù)包可能會被丟棄。這些丟失的數(shù)據(jù)包已經(jīng)消耗了購買的公網(wǎng)帶寬，從而導(dǎo)致用戶觀察到的公網(wǎng)CLB流量帶寬未達(dá)到預(yù)期。因此，我們保留公網(wǎng)CLB限速功能不變，僅進行引流調(diào)整。
8、山海架構(gòu)1.0的優(yōu)勢
CLB產(chǎn)品及REIP產(chǎn)品，在使用山海1.0之后的幾點優(yōu)勢。
1）CLB產(chǎn)品本身支持熱遷移，擴容到山海熱遷移，不會引起用戶的斷流，有助于運維做用戶產(chǎn)品升級迭代。這方面有個典型案例，比如某臺設(shè)備壞了或者發(fā)現(xiàn)某臺設(shè)備上有問題，需要把流量遷走的時候，我們可以不用中斷用戶的流量的。我們了解到，以前有的競品，因為熱遷移做的不是特別完善，在設(shè)備出現(xiàn)問題或者是需要升級版本的時候，常選擇低峰期做升級。
2）EIP在做限速的時候，在出方向時是小帶寬，可以做到比較精準(zhǔn)的限速。好處是用戶做壓測或測試的時，帶寬不會抖動影響自己的業(yè)務(wù)的穩(wěn)定性。
3）高低優(yōu)先級限速。用戶買一些比較小的比如10M帶寬或者5M帶寬，用來服務(wù)本身業(yè)務(wù)，同時也會ssh或者遠(yuǎn)程桌面登錄EIP；因為一起我們是做無差別的限速丟包的話，這樣會造成它本身的控制流量，如遠(yuǎn)程桌面的流量也會被丟包，造成登錄的卡頓。用戶需要在不超限速的前提下，優(yōu)先保證遠(yuǎn)程桌面不卡，然后再提供其他的下載服務(wù)。我們把流量根據(jù)端口進行區(qū)分，比如22端口或者是遠(yuǎn)程桌面的3389端口的流量，標(biāo)記為高優(yōu)先級。在做限速時，只要高優(yōu)先流量不超限速，就全部放行。當(dāng)高優(yōu)先級流量再疊加上低優(yōu)先級的流量超限速時，把低優(yōu)先級的流量丟掉，這樣ssh訪問服務(wù)器的時候能夠非常順暢。
4）山海架構(gòu)上線后，基于vip粒度的調(diào)度，可以讓調(diào)度更加靈活。比如原來一個集群為了節(jié)省路由條目，我們按照一個網(wǎng)段發(fā)路由，不是每個VIP都發(fā)路由的。山海兩級架構(gòu)之后，沒有了這個限制，就可以按照VIP，把CLB實例調(diào)度到不同CLB集群。這樣如果用戶需要一個特別大規(guī)格的VIP的時候，我們可用一個集群的能力去扛用戶一個VIP，從而滿足超大規(guī)格實例的訴求。當(dāng)然真實使用產(chǎn)品時，很少有客戶把上百G的流量用一個VIP來承載。用戶出于容災(zāi)考慮，通常不會把所有的雞蛋放到一個籃子里。
9、山海架構(gòu) 2.0
9.1概述
如前所述：山海 1.0 主要目標(biāo)是整合公共網(wǎng)絡(luò)并將所有公網(wǎng)出口集中在城市核心機房內(nèi)。至于剩余的 CLB 群集，我們會繼續(xù)將其保存在原有各機房的專區(qū)里。這是因為網(wǎng)關(guān)設(shè)備有其與服務(wù)器不同的網(wǎng)絡(luò)訴求，例如普通服務(wù)器不能提供發(fā)布動態(tài)路由，并通過動態(tài)路由引流處理業(yè)務(wù)流量。
再比如：網(wǎng)關(guān)專區(qū)的收斂比1:1，而服務(wù)器雖然帶寬也是100G， 但其收斂比率往往小于1：1。
在這種情況下，我們不能簡單地將 CLB 網(wǎng)關(guān)群集群平移放置到服務(wù)器區(qū)。因此，CLB 網(wǎng)關(guān)群集通常在構(gòu)建每個機房時，預(yù)先規(guī)劃并預(yù)留相應(yīng)的網(wǎng)關(guān)專區(qū)。機房建設(shè)起來后，如業(yè)務(wù)量小，又會因預(yù)留資源空置造成浪費。目前專區(qū)閑置機位也是一筆較大的費用。
同時，還有一種臨時擴容的需求場景，例如VIP大客戶，臨時會有大流量的轉(zhuǎn)發(fā)需求，這時常態(tài)運營水位沒法滿足需要，需要調(diào)配設(shè)備做集群擴容。如果本機房的設(shè)備不夠還需要跨機房搬遷，搬遷周期比較長，對我們運營壓力會很大。
所以，我們希望通過山海2.0能把專區(qū)建設(shè)的空置率降下來，同時提升彈性，能夠低成本的快速擴縮容。
9.2引流交換機
在山海 2.0里，我們采用了“引流交換機”。在每個機房的建設(shè)時，我們可以放置兩組共四臺引流交換機。
考慮到單個交換機的容量可以達(dá)到 1 T 以上，有四臺交換機工作，一個機房能夠承受大約 4T~ 6T 的流量峰值。這意味著后續(xù)無需再額外擴容，一次性的建設(shè)和布局就可以滿足長期的需求。相比于 CLB 群集占用的機位空間，四臺交換機所需的機位顯著減少。
我們把原來CLB集群對外聲明路由的能力放到了引流交換機上，把CLB服務(wù)器用用通用服務(wù)器區(qū)的設(shè)備來代替。考慮收斂比和容災(zāi)，不會把一個集群放到一兩個機架上，會相對分散些，更不會把整個機架全部再用成CLB集群。這樣CLB集群不再單獨建設(shè)網(wǎng)關(guān)專區(qū)，引流交換機把路由聲明發(fā)出去，通過隧道跟CLB設(shè)備轉(zhuǎn)發(fā)流量。
9.3山海2.0的變化
我們以內(nèi)網(wǎng)CLB為例，原來一臺虛擬機訪問CLB集群，CLB集群把它的流量轉(zhuǎn)到對應(yīng)的RS。
引入交換機之后，其進出兩個方向都會有變化：入方向（訪問LB方向），虛擬機的流量先被引流到了引流交換機，交換機把報文做一次封裝，然后發(fā)送給對應(yīng)的服務(wù)器，進行負(fù)載均衡轉(zhuǎn)換。最后處理后的結(jié)果，被轉(zhuǎn)發(fā)給真正的RS。原來的兩跳訪問變成了現(xiàn)在的三跳。同樣反方向流量返回時，RS的流量先回到引流交換機，然后被分發(fā)到對應(yīng)的LD設(shè)備上。LD處理完之后，再把報文直接轉(zhuǎn)到client虛擬機上。借助引流交換機的中轉(zhuǎn)，我們就能夠讓負(fù)載均衡的專區(qū)設(shè)備的放到普通的服務(wù)器區(qū)里。
另外：這里的CLB服務(wù)器，可以跟其他的網(wǎng)關(guān)包括母機復(fù)用一些相同機型的服務(wù)器，當(dāng)需要擴容時，就可以使用通用服務(wù)器。而不像以前CLB既有自己獨立的機型，又對服務(wù)器的物理位置有要求。有了引流交換機跟LD之間是做隧道傳輸，LD具體的物理位置就沒有像原來一樣有硬性的要求。這樣CLB可以通過通用服務(wù)器區(qū)域，調(diào)配服務(wù)器。
最后一項是：原有跟REIP類似的，CLB設(shè)備做路由通告時，也是按照網(wǎng)段通告，有引流交換機之后，我們可以在引流交換機上去做細(xì)粒度的調(diào)度，一個VIP或是幾個vip放到一個集群。還可以在引流交換機上做更細(xì)粒度的調(diào)度，如IP+port這樣的五元組的粒度的調(diào)度。
10、未來展望
目前網(wǎng)關(guān)設(shè)備最重要也是最大的一個方向就是做高性能、硬件卸載。依賴硬件來實現(xiàn)高性能的轉(zhuǎn)發(fā)。
網(wǎng)關(guān)設(shè)備分為有狀態(tài)和無狀態(tài)兩種：
- 1）無狀態(tài)設(shè)備就像IP轉(zhuǎn)換一樣，只要依據(jù)規(guī)則，任何時刻來了報文，轉(zhuǎn)換出來的形式都是固定的；
- 2）有狀態(tài)設(shè)備是需要記錄TCP、 UDP狀態(tài)，記錄轉(zhuǎn)發(fā)到后端設(shè)備，當(dāng)不同的時間轉(zhuǎn)發(fā)即使相同的類型的流量，它轉(zhuǎn)發(fā)的目的地也不一樣，轉(zhuǎn)換的格式也可能不一樣。
硬件卸載在有狀態(tài)和無狀態(tài)時，基本上用到的設(shè)備都是DPU和交換機，用到的介質(zhì)幾乎都是FPGA。
FPGA和ASIC本質(zhì)上是一個東西，無論友商還是我們自己內(nèi)部研發(fā)，更多的是FPGA上做功能，并小規(guī)模的灰度上線驗證，一旦穩(wěn)定下來，就轉(zhuǎn)化成批量的ASIC，以此來降低成本。
DPU和交換機在無狀態(tài)設(shè)備上，交換機相對更有優(yōu)勢，因為無狀態(tài)設(shè)備對容量的要求相對小些，像EIP網(wǎng)關(guān)以及內(nèi)部無狀態(tài)的網(wǎng)關(guān)大多用交換機形態(tài)實現(xiàn)。DPU目前更多的用在母機側(cè)，做有狀態(tài)類的網(wǎng)絡(luò)處理。當(dāng)然， 采用DPU不僅僅局限網(wǎng)絡(luò)訴求，還有存儲安全等其他需求。去年英特爾宣布已不再進行交換機tf芯片的演進迭代，大家對交換機的質(zhì)疑會增大。
所以，也衍化了另一種方案：在一臺額外的服務(wù)器中插入 DPU 網(wǎng)卡以實現(xiàn)卸載功能。
但不同方案有不同的優(yōu)缺點：
1）使用交換機的最大優(yōu)勢在于其強大的交換性能（可達(dá) 1T或幾個T及更高），可支持很大的接入容量。但是，交換機僅能是一個底座，若要擴展容量仍需依賴 FPGA 技術(shù)。
2） DPU 的優(yōu)點則包括成熟的產(chǎn)業(yè)鏈、龐大的產(chǎn)量以及穩(wěn)定的供應(yīng)保障；此外，由于 DPU 在母機側(cè)已被廣泛驗證和采用，許多功能的實現(xiàn)都相對固定。
這是兩種方案各自的優(yōu)缺點。
在兩個產(chǎn)品運用負(fù)載均衡狀態(tài)的交換上，業(yè)內(nèi)不同的廠家也有不同的玩法，有的是交換機，有的是DPU。當(dāng)前，無論是交換機還是 DPU，都依賴FPGA(ASIC)來做大容量的會話管理，同時越來越多的設(shè)備或多或少的支持P4。在 X86 上進行編程時，通常選擇 DPDK。
相較之下：使用 P4 進行編程的門檻較低。P4 編寫一般功能需求的代碼非常簡單快捷，只需一兩周時間即可完成，甚至對于熟練者來說，可以在幾個小時就開發(fā)出一個小功能。雖然充分發(fā)揮硬件的性能，P4類芯片還需要進行很深入細(xì)節(jié)的研究，但P4還是大大降低了數(shù)據(jù)面編程的門檻，特別是在高性能轉(zhuǎn)發(fā)的需求方面。
另一個特點是：小型化。大家過去比較關(guān)注數(shù)據(jù)中心和海量數(shù)據(jù)的優(yōu)化問題，隨著業(yè)務(wù)發(fā)展，逐步轉(zhuǎn)向降低運營成本和提高效率的場景，開設(shè)小型站點。這類小型站點，是典型的“麻雀雖小，五臟俱全”，希望用盡量少的設(shè)備成本來滿足各種功能需求。所以我們將設(shè)備設(shè)計為具有較小規(guī)格的產(chǎn)品系列，并在易用性上進行改進，通過集群合并、虛擬機等承擔(dān)更多的任務(wù)負(fù)載。這樣在業(yè)務(wù)規(guī)模和流量不大，也能以較少的資源應(yīng)對較高的功能性需求。一旦業(yè)務(wù)規(guī)模擴大，我們可將這些小型站點升級為傳統(tǒng)的數(shù)據(jù)中心級物理設(shè)備。
以上未來網(wǎng)關(guān)兩個主要的方向。
11、相關(guān)資料
[1] IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（上篇）
[2] 網(wǎng)絡(luò)編程入門從未如此簡單(三)：什么是IPv6？漫畫式圖文，一篇即懂！
[3] 網(wǎng)絡(luò)編程懶人入門(十五)：外行也能讀懂的網(wǎng)絡(luò)硬件設(shè)備功能原理速成
[4] 腦殘式網(wǎng)絡(luò)編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？
[5] 腦殘式網(wǎng)絡(luò)編程入門(七)：面視必備，史上最通俗計算機網(wǎng)絡(luò)分層詳解
[6] 以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計為例，理解實時通信的技術(shù)挑戰(zhàn)
[7] 百度統(tǒng)一socket長連接組件從0到1的技術(shù)實踐
[8] 淘寶移動端統(tǒng)一網(wǎng)絡(luò)庫的架構(gòu)演進和弱網(wǎng)優(yōu)化技術(shù)實踐
[9] 百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇
[10] 新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進歷史、技術(shù)原理、最佳實踐
[11] 一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐
（本文已同步發(fā)布于：http://www.52im.net/thread-4641-1-1.html）