本文由騰訊技術(shù)團(tuán)隊(duì)peter分享，原題“騰訊網(wǎng)關(guān)TGW架構(gòu)演進(jìn)之路”，下文進(jìn)行了排版和內(nèi)容優(yōu)化等。

1、引言

TGW全稱Tencent Gateway，是一套實(shí)現(xiàn)多網(wǎng)統(tǒng)一接入，支持自動(dòng)負(fù)載均衡的系統(tǒng)， 是公司有10+年歷史的網(wǎng)關(guān)，因此TGW也被稱為公司公網(wǎng)的橋頭堡。

本文從騰訊公網(wǎng)TGW網(wǎng)關(guān)系統(tǒng)的應(yīng)用場(chǎng)景、背景需求講起，重點(diǎn)解析了從山海1.0架構(gòu)到山海2.0架構(gòu)需要解決的問(wèn)題和架構(gòu)規(guī)劃與設(shè)計(jì)實(shí)現(xiàn)，以及對(duì)于未來(lái)TGW山海網(wǎng)關(guān)的發(fā)展和演進(jìn)方向。

 

技術(shù)交流：

- 移動(dòng)端IM開(kāi)發(fā)入門文章：《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》

- 開(kāi)源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4641-1-1.html）

2、專題目錄

本文是專題系列文章的第11篇，總目錄如下：

1. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(一)：京東京麥的生產(chǎn)級(jí)TCP網(wǎng)關(guān)技術(shù)實(shí)踐總結(jié)》
2. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(二)：知乎千萬(wàn)級(jí)并發(fā)的高性能長(zhǎng)連接網(wǎng)關(guān)技術(shù)實(shí)踐》
3. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(三)：手淘億級(jí)移動(dòng)端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路》
4. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(四)：愛(ài)奇藝WebSocket實(shí)時(shí)推送網(wǎng)關(guān)技術(shù)實(shí)踐》
5. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(五)：喜馬拉雅自研億級(jí)API網(wǎng)關(guān)技術(shù)實(shí)踐》
6. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(六)：石墨文檔單機(jī)50萬(wàn)WebSocket長(zhǎng)連接架構(gòu)實(shí)踐》
7. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(七)：小米小愛(ài)單機(jī)120萬(wàn)長(zhǎng)連接接入層的架構(gòu)演進(jìn)》
8. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(八)：B站基于微服務(wù)的API網(wǎng)關(guān)從0到1的演進(jìn)之路》
9. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(九)：去哪兒網(wǎng)酒店高性能業(yè)務(wù)網(wǎng)關(guān)技術(shù)實(shí)踐》
10. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(十)：百度基于Go的千萬(wàn)級(jí)統(tǒng)一長(zhǎng)連接服務(wù)架構(gòu)實(shí)踐》
11. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(十一)：揭秘騰訊公網(wǎng)TGW網(wǎng)關(guān)系統(tǒng)的技術(shù)架構(gòu)演進(jìn)》（* 本文）

3、TGW網(wǎng)關(guān)系統(tǒng)的重要性

TGW全稱Tencent Gateway，是一套實(shí)現(xiàn)多網(wǎng)統(tǒng)一接入、支持自動(dòng)負(fù)載均衡的系統(tǒng)， 是公司有10+年歷史的網(wǎng)關(guān)，因此TGW也被稱為公司公網(wǎng)的橋頭堡。它對(duì)外連接了各大運(yùn)營(yíng)商并支撐公有云上EIP、CLB等產(chǎn)品功能，對(duì)內(nèi)提供了公網(wǎng)網(wǎng)絡(luò)的接入功能，如為游戲、微信等業(yè)務(wù)提供公網(wǎng)接入服務(wù)。

TGW主要有兩大產(chǎn)品：

• 1）彈性EIP（比如購(gòu)買一臺(tái)虛擬機(jī)CVM或是一個(gè)NAT實(shí)例后，通過(guò)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)建一個(gè)CLB實(shí)例，把多個(gè)CVM服務(wù)掛在了內(nèi)網(wǎng)CLB上，為后端RS提供負(fù)載均衡的能力；
• 2）外網(wǎng)CLB面對(duì)的是公網(wǎng)側(cè)負(fù)載均衡的需求。

當(dāng)在內(nèi)部部署CLB集群時(shí)，可分為IPV4或者IPV6兩大類，根據(jù)物理網(wǎng)絡(luò)類型又細(xì)分為BGP和三網(wǎng)兩類。三網(wǎng)指這些IP地址是靜態(tài)的，不像BGP一樣能夠在多個(gè)運(yùn)營(yíng)商之間同時(shí)進(jìn)行廣播。

以上就是四層TGW產(chǎn)品及功能，山海網(wǎng)關(guān)在原有產(chǎn)品基礎(chǔ)上做了網(wǎng)絡(luò)架構(gòu)方面的演進(jìn)。

4、Region EIP的引入

具體介紹下EIP和CLB兩個(gè)產(chǎn)品。

過(guò)去CLB和EIP使用不同的IP地址池，導(dǎo)致資源池上的隔離問(wèn)題。使得我們無(wú)法把EIP地址綁定到公有云CLB實(shí)例上。

例如：一個(gè)創(chuàng)業(yè)公司最初只購(gòu)買一臺(tái)虛擬機(jī)并掛載一個(gè)公網(wǎng)EIP來(lái)提供服務(wù)。隨著用戶量的增長(zhǎng)，如果想將這個(gè)EIP地址遷移到一個(gè)公網(wǎng)CLB實(shí)例上，在原有架構(gòu)下是無(wú)法實(shí)現(xiàn)這種遷移的。

此外：EIP和CLB部署在每個(gè)機(jī)房，因此在每個(gè)機(jī)房都需要建立EIP出口。但是各個(gè)機(jī)房的公網(wǎng)出口之間缺無(wú)法相互容災(zāi)。

所以這種情形下，我們確定了產(chǎn)品的目標(biāo)：

• 1）希望將所有公網(wǎng)出口整合到一到兩個(gè)機(jī)房之內(nèi)，以避免重復(fù)建設(shè)，節(jié)省成本；
• 2）通過(guò)將出口集中，我們可以將對(duì)應(yīng)的網(wǎng)關(guān)服務(wù)器也進(jìn)行集中，進(jìn)而提高設(shè)備的利用率；
• 3）通過(guò)這樣的布局可實(shí)現(xiàn)跨機(jī)房的容災(zāi)方案。

因此：最早的Region EIP（REIP）計(jì)劃應(yīng)運(yùn)而生。

以北京這類大型region為例的：我們將EIP專區(qū)建設(shè)到位于兩個(gè)城市的超核機(jī)房。這兩個(gè)機(jī)房通常會(huì)放置物理網(wǎng)絡(luò)的交換設(shè)備，并為各自設(shè)立了一個(gè)REIP專區(qū)。在REIP專區(qū)內(nèi)部署Region EIP集群。為了實(shí)現(xiàn)跨AZ容災(zāi)，兩個(gè)機(jī)房的集群之間借助大小網(wǎng)段實(shí)現(xiàn)互相備份容災(zāi)的能力。一旦其中一個(gè)機(jī)房的集群發(fā)生故障或出現(xiàn)網(wǎng)絡(luò)問(wèn)題，另一個(gè)機(jī)房的集群可以立即承擔(dān)起容災(zāi)任務(wù)。

同時(shí)：因?yàn)樾碌腞egion EIP的網(wǎng)絡(luò)架構(gòu)跟原來(lái)的網(wǎng)絡(luò)架構(gòu)不一樣，通過(guò)網(wǎng)絡(luò)架構(gòu)升級(jí)以及機(jī)型升級(jí)，我們能夠把單臺(tái)Region EIP的性能做到原有單臺(tái)EIP性能的5倍。這樣我們通過(guò)容量的提升進(jìn)一步提升了設(shè)備利用率，在完成全量Region EIP后，設(shè)備數(shù)量會(huì)從3000+臺(tái)縮減至700+臺(tái)。同時(shí)原有的CLB集群還保留在各個(gè)機(jī)房不變，這些CLB集群的外網(wǎng)接入能力由Region EIP承擔(dān)。

5、公網(wǎng)CLB的演進(jìn)

5.1概述

公網(wǎng)CLB最早是有公網(wǎng)接入能力的。引入到Region EIP之后，當(dāng)初設(shè)想是公網(wǎng)CLB不再演進(jìn)，盡量讓存量用戶遷移到另外一種形式，上層是Region EIP，下層是內(nèi)網(wǎng)CLB。用戶先買一個(gè)內(nèi)網(wǎng)CLB，如果需要對(duì)公網(wǎng)提供服務(wù)就再買一個(gè)彈性EIP，把EIP跟內(nèi)網(wǎng)CLB綁定在一起，提供CLB公網(wǎng)的能力，替代原有的公網(wǎng)CLB，這是最早公網(wǎng)CLB的替代方案。

兩個(gè)方案的區(qū)別是：原有公網(wǎng)CLB，用戶僅看到一個(gè)CLB實(shí)例。新的模式下，用戶看到的是兩個(gè)實(shí)例：一個(gè)EIP+一個(gè)內(nèi)網(wǎng)CLB，兩個(gè)實(shí)例都可以獨(dú)立運(yùn)營(yíng)管理。這就是我們最早的兩層架構(gòu)設(shè)想，想把公網(wǎng)CLB跟外網(wǎng)解耦。

但是，真正去跟用戶或產(chǎn)品交流時(shí)，這個(gè)想法遇到了比較大的挑戰(zhàn)：

1）用戶體驗(yàn)的改變：以前公網(wǎng)CLB用戶看到是一個(gè)實(shí)例，但是現(xiàn)在用戶看到兩個(gè)實(shí)例，必然會(huì)給用戶帶來(lái)一些適配工作。比如用戶進(jìn)行創(chuàng)建、管理實(shí)例時(shí)，API不一樣了。以前使用通過(guò)自動(dòng)化腳本創(chuàng)建公網(wǎng)CLB實(shí)例的，現(xiàn)在腳本還要改變?nèi)ミm配新的API。

2）用戶習(xí)慣改變：以前用戶習(xí)慣在一個(gè)實(shí)例下，點(diǎn)擊頁(yè)面，就能夠查看流量、鏈接數(shù)等監(jiān)控信息。現(xiàn)在EIP流量需要到REIP查看，而鏈接數(shù)還需在CLB產(chǎn)品上看。

3）存量客戶無(wú)法遷移：原來(lái)客戶買的公網(wǎng)CLB實(shí)例，是無(wú)法直接無(wú)感知遷移到內(nèi)網(wǎng)CLB+REIP這種新形式的。

在這些挑戰(zhàn)下，這個(gè)替代方案沒(méi)能真正落地。結(jié)合用戶的要求，我們最終跟產(chǎn)品定下的策略是：公網(wǎng)CLB保持不變。原有的公網(wǎng)CLB繼續(xù)保留，同時(shí)如果用戶新增的公網(wǎng)CLB需求，也要繼續(xù)支持。

5.2公網(wǎng)CLB模型

那么，公網(wǎng)CLB到底怎么演變？

我們的初衷并不是把公網(wǎng)CLB這個(gè)產(chǎn)品摒棄掉，而是要收斂公網(wǎng)入口。所以我們針對(duì)這個(gè)初始需求，提出了上面這個(gè)兩級(jí)架構(gòu)模型。

首先：用REIP將公網(wǎng)流量先引進(jìn)來(lái)，再將這個(gè)流量通過(guò)隧道報(bào)文的形式轉(zhuǎn)發(fā)給原有的公網(wǎng)CLB集群，這樣公網(wǎng)CLB不需要原有外網(wǎng)接入的能力，不需要再跟外網(wǎng)打交道，可以演變成只在機(jī)房?jī)?nèi)部的集群；同時(shí)因?yàn)楣W(wǎng)CLB的流量都會(huì)經(jīng)過(guò)REIP，REIP自然也就是公網(wǎng)CLB的流量入口。從而達(dá)到我們最初收斂公網(wǎng)入口的目的。這樣的架構(gòu)升級(jí)，可實(shí)現(xiàn)用戶無(wú)感知。架構(gòu)升級(jí)切換過(guò)程中，用戶在訪問(wèn)公網(wǎng)CLB，不會(huì)出現(xiàn)卡頓或者重連的現(xiàn)象。

這個(gè)架構(gòu)模型也有一定的局限性的。公網(wǎng)CLB實(shí)例只能承載公網(wǎng)的流量，無(wú)法像上文提到的兩層RERP+CLB那樣，內(nèi)外網(wǎng)隨時(shí)進(jìn)行轉(zhuǎn)化。REIP+CLB實(shí)例中的CLB既承載內(nèi)網(wǎng)側(cè)CLB的流量，又承載公網(wǎng)側(cè)CLB的流量。

6、山海架構(gòu) 1.0

借助這個(gè)兩級(jí)架構(gòu)模型，我們能夠把公網(wǎng)CLB保留下來(lái)，并且通過(guò)REIP把公網(wǎng)入口收斂。

進(jìn)一步思考并完善，我們提出了下面的想法：跟產(chǎn)品進(jìn)行解耦。

以前我們一個(gè)地區(qū)上線公網(wǎng)CLB產(chǎn)品，底層就要搭建有一個(gè)公網(wǎng)CLB的集群去支持。用戶需要內(nèi)網(wǎng)CLB服務(wù)，就要對(duì)應(yīng)搭建個(gè)內(nèi)網(wǎng)CLB的集群。底層集群類型跟產(chǎn)品是強(qiáng)耦合，有IPv4/IPv6， 公網(wǎng)/內(nèi)網(wǎng)、BGP/三網(wǎng)組合出的多個(gè)產(chǎn)品形態(tài)。

這種模式在小地域部署，因?yàn)楫a(chǎn)品業(yè)務(wù)的流量小，集群利用率低，就會(huì)造成很大的成本壓力。

為了應(yīng)對(duì)這種小帶寬低成本的訴求，我們將CLB+REIP的模型進(jìn)一步抽象，引入山海架構(gòu)：我們只建設(shè)CLB和REIP兩類集群。通過(guò)這兩類集群上的不同實(shí)例組合，滿足多個(gè)產(chǎn)品形態(tài)的要求。從而實(shí)現(xiàn)產(chǎn)品形態(tài)和底層物理網(wǎng)絡(luò)集群類型解耦。

解耦合的方式是：CLB和REIP通過(guò)不同的實(shí)例類型，組合出不同的產(chǎn)品形態(tài)。

山海架構(gòu)在TGW內(nèi)部做閉環(huán)，不涉及到產(chǎn)品側(cè)和用戶側(cè)的改動(dòng)。整個(gè)過(guò)程升級(jí)，對(duì)產(chǎn)品側(cè)不做任何接口上的更新。因?yàn)楫a(chǎn)品側(cè)的API接口保持不變，對(duì)用戶側(cè)就可以做到完全無(wú)感知。在產(chǎn)品側(cè)保持不變，就需要我們?cè)趦?nèi)部管控，識(shí)別接入用戶實(shí)例是哪種形態(tài)的產(chǎn)品，拆分成不同形式的CLB和REIP的實(shí)例。其他的相關(guān)功能的比如流量統(tǒng)計(jì)、限速等模塊也都要適配不同的產(chǎn)品形態(tài)，通過(guò)模塊的適配，做到山海架構(gòu)對(duì)上層產(chǎn)品側(cè)應(yīng)用的透明。

山海架構(gòu)1.0歸納起來(lái)有兩個(gè)重點(diǎn)：收斂公網(wǎng)入口和集群類型歸一。

1）REIP：部署在城核機(jī)房，同時(shí)承載的是CLB和REIP兩類產(chǎn)品的公網(wǎng)流量。之前EIP，在物理網(wǎng)絡(luò)上有BGP+三網(wǎng)、v4/v6等多種集群類型。REIP借助vlan的隔離支持，把所有的網(wǎng)絡(luò)類型都集中到一種REIP集群上來(lái)，我們稱之為全通集群。在物理網(wǎng)絡(luò)層面實(shí)現(xiàn)網(wǎng)絡(luò)類型的歸一， 然后再通過(guò)軟件層的適配，實(shí)現(xiàn)REIP支持多通類型的網(wǎng)絡(luò)接入能力。

2）CLB：在山海兩級(jí)架構(gòu)下，REIP集群處理公網(wǎng)側(cè)的各種場(chǎng)景組合，CLB集群通過(guò)隧道與REIP處理公網(wǎng)流量。之前一個(gè)機(jī)房如果要把所有的產(chǎn)品能力支持起來(lái)，大概有7種集群類型。現(xiàn)在CLB集群可以用一種集群類型來(lái)支持所有的產(chǎn)品的公網(wǎng)CLB產(chǎn)品，以及內(nèi)網(wǎng)CLB產(chǎn)品的能力。我們把三網(wǎng)+BGP以及內(nèi)外網(wǎng)還有V4V6等集群類型都用一種類型來(lái)支持，山海架構(gòu)完全落地后，開(kāi)區(qū)的最小服務(wù)器數(shù)量可以降低到8臺(tái)服務(wù)器，來(lái)承載所有的EIP和CLB產(chǎn)品需求。

歸納起來(lái)一句話：對(duì)于用戶來(lái)說(shuō)，產(chǎn)品形態(tài)沒(méi)有改變，用戶使用習(xí)慣也沒(méi)有改變。而在底層，我們把集群類型收斂到一個(gè)CLB集群和一個(gè)REIP集群上。

7、山海架構(gòu)1.0限速技術(shù)

在山海架構(gòu)演進(jìn)中，有許多技術(shù)點(diǎn)，本文選取限速技術(shù)進(jìn)行分享。

首先Region EIP支持三網(wǎng)。以前BGP跟三網(wǎng)分開(kāi)獨(dú)立支持，山海網(wǎng)關(guān)統(tǒng)一用Region EIP支持。Region EIP本身的網(wǎng)絡(luò)架構(gòu)分成兩個(gè)機(jī)房，每個(gè)機(jī)房放4臺(tái)TGW設(shè)備，每個(gè)EIP只會(huì)走左邊或者右邊。一個(gè)EIP進(jìn)來(lái)的流量經(jīng)過(guò)上面這層交換機(jī)時(shí)，經(jīng)過(guò)了ECMP分流，然后分到了4臺(tái)設(shè)備上。這樣對(duì)每個(gè)EIP其實(shí)是采用了分布式限速。

限速有兩個(gè)要求：

• 1）精確性，限速上下浮動(dòng)要小，要限得準(zhǔn)；
• 2）要有容災(zāi)能力。

限速最極端的精準(zhǔn)就是把它放到單點(diǎn)上去做限速，但是單點(diǎn)限速就會(huì)面臨單點(diǎn)故障和容災(zāi)的問(wèn)題。在X86服務(wù)器上，使用的是分布式限速，一個(gè)EIP均分到4臺(tái)服務(wù)器上，每五秒鐘做一次流量的的匯總統(tǒng)計(jì)，通過(guò)流量比例計(jì)算將這個(gè)EIP的帶寬配額，重新分配并分發(fā)到4臺(tái)設(shè)備上，以此來(lái)實(shí)現(xiàn)集群上的限速。在單臺(tái)設(shè)備上，也是沒(méi)隔一段時(shí)間，就重新計(jì)算配額并分配到每個(gè)CPU核上，我們目前用的是300毫秒周期。

需要說(shuō)明的是：在限速的實(shí)現(xiàn)上，業(yè)務(wù)有多重實(shí)現(xiàn)方式，我們了解到有的實(shí)現(xiàn)的是靜態(tài)分配，比如120兆的帶寬，4臺(tái)設(shè)備，我們每臺(tái)設(shè)備分40M(三分之一)的帶寬。1/3而不是1/4的帶寬，目的是防止某一臺(tái)設(shè)備斷了之后，用戶總帶寬不達(dá)標(biāo)，影響用戶體驗(yàn)。在單臺(tái)設(shè)備上限速，也有另外一種實(shí)現(xiàn)方式，大小桶。比如限速1M的帶寬，那么每個(gè)核第一次取回100K或者200K配額。后續(xù)報(bào)文處理時(shí)候，先消耗上次取回的配額，如果帶寬配額消耗光了，再重新取。周期調(diào)整跟大小桶這兩種實(shí)現(xiàn)方式各有優(yōu)缺點(diǎn)。從資源消耗來(lái)說(shuō)，300毫秒周期的資源消耗相對(duì)會(huì)更少一些，兩者大概有10%左右的性能偏差。

限速上另一訴求：小帶寬的限速的精準(zhǔn)限速。

大帶寬比如100兆，分到每個(gè)核上相對(duì)富裕。小帶寬如一M帶寬，一秒鐘100k字節(jié)等，分到四臺(tái)機(jī)器再分到幾十個(gè)核上，每個(gè)核都可能不到一個(gè)大報(bào)，這時(shí)候再去做精準(zhǔn)限速就會(huì)非常困難，因?yàn)榧热灰崆胺峙滟Y源，資源那么少，分配到單核上，可能一個(gè)包都過(guò)不去，但凡有一個(gè)報(bào)文過(guò)去了，又可能超了。所以在小帶寬限速時(shí)，我們把它退化成類似于單點(diǎn)限速的模式。由于入方向帶寬最小也是100兆，因此保持原有的分布式限速不變。只對(duì)出方向小帶寬，使用單點(diǎn)限速。方案是這樣的：

每臺(tái)REIP有自己一個(gè)獨(dú)享的內(nèi)網(wǎng)地址，只有這臺(tái)服務(wù)器故障時(shí)候，這個(gè)地址的流量才被分發(fā)到其他三臺(tái)服務(wù)器。

入方向流量被分到四臺(tái)REIP服務(wù)器后，REIP處理完通過(guò)tunnel轉(zhuǎn)發(fā)給母機(jī)。隧道的外層源地址，只使用其中一臺(tái)REIP服務(wù)器的獨(dú)享的IP地址。每個(gè)外網(wǎng)IP地址在掛載到集群下管理時(shí)候，就確定下來(lái)了。

母機(jī)在接受到網(wǎng)關(guān)發(fā)過(guò)去的流量，解析外層報(bào)文地址，并記錄在本地會(huì)話表里，我們稱之為母機(jī)的自學(xué)習(xí)能力。當(dāng)母機(jī)側(cè)轉(zhuǎn)發(fā)出方向報(bào)文時(shí)，就只會(huì)使用本地學(xué)習(xí)并記錄的外層地址去封裝隧道。這樣出方向的流量，就回到單臺(tái)TGW設(shè)備上，實(shí)現(xiàn)了單點(diǎn)限速。

獨(dú)享的內(nèi)網(wǎng)地址本身是有容災(zāi)能力：

• 1）當(dāng)其服務(wù)器故障了，流量就被分散到集群其他服務(wù)器，放棄單點(diǎn)限速；
• 2）當(dāng)服務(wù)器被修復(fù)上線后，又可以重新變成精準(zhǔn)的單點(diǎn)限速。

這樣保證小帶寬精準(zhǔn)限速的同時(shí)，又避免了單點(diǎn)故障。

在限速過(guò)程中，還有一個(gè)問(wèn)題，因?yàn)镃LB集群原來(lái)的限速是在CLB集群上自己做的，引入山海之后，REIP上有限速能力，那么公網(wǎng)CLB的限速要不要挪到REIP上？

我們經(jīng)過(guò)多次討論， 最終還是維持**這個(gè)限速在公網(wǎng)CLB上不變。

這里有幾種場(chǎng)景考量：

1）內(nèi)外網(wǎng)攻擊：如果我們把它放到REIP上，這里可以扛住外網(wǎng)的攻擊，但同時(shí)內(nèi)網(wǎng)的攻擊我們是防不住的，因?yàn)楣W(wǎng)CLB上沒(méi)有限速后，流量?jī)?nèi)網(wǎng)的攻擊就會(huì)先把CLB上壓過(guò)載，導(dǎo)致丟包，影響業(yè)務(wù)的穩(wěn)定性。

2）有效流量的準(zhǔn)確統(tǒng)計(jì)：原有架構(gòu)下，從公網(wǎng)流量首先到達(dá)CLB，我們需要檢查公網(wǎng)CLB上與port對(duì)應(yīng)的服務(wù)是否已配置規(guī)則并啟用。如果沒(méi)有啟用，則將報(bào)文直接丟棄且不記錄為公網(wǎng)CLB的帶寬使用量。山海架構(gòu)下，如果先經(jīng)過(guò)Region EIP限速，這類無(wú)服務(wù)訪問(wèn)流量（如惡意攻擊和垃圾流量）也將占用限速資源。盡管這部分限速流量會(huì)送達(dá)至CLB集群，但由于缺乏相應(yīng)服務(wù)支持，它們最終還是將被丟棄。結(jié)果導(dǎo)致用戶帶寬不及預(yù)期。比如用戶購(gòu)買10M帶寬，實(shí)際有效運(yùn)行的僅有8M流量，而其余2M被無(wú)服務(wù)流量占用了。

3）多重限速的影響：還有一個(gè)這個(gè)場(chǎng)景中，當(dāng)Region EIP實(shí)施帶寬限速后，這些流量最終可能進(jìn)入公網(wǎng)CLB。然而，由于CLB的規(guī)格限制，例如新建連接數(shù)或并發(fā)連接數(shù)已達(dá)到上限，部分?jǐn)?shù)據(jù)包可能會(huì)被丟棄。這些丟失的數(shù)據(jù)包已經(jīng)消耗了購(gòu)買的公網(wǎng)帶寬，從而導(dǎo)致用戶觀察到的公網(wǎng)CLB流量帶寬未達(dá)到預(yù)期。因此，我們保留公網(wǎng)CLB限速功能不變，僅進(jìn)行引流調(diào)整。

8、山海架構(gòu)1.0的優(yōu)勢(shì)

CLB產(chǎn)品及REIP產(chǎn)品，在使用山海1.0之后的幾點(diǎn)優(yōu)勢(shì)。

1）CLB產(chǎn)品本身支持熱遷移，擴(kuò)容到山海熱遷移，不會(huì)引起用戶的斷流，有助于運(yùn)維做用戶產(chǎn)品升級(jí)迭代。這方面有個(gè)典型案例，比如某臺(tái)設(shè)備壞了或者發(fā)現(xiàn)某臺(tái)設(shè)備上有問(wèn)題，需要把流量遷走的時(shí)候，我們可以不用中斷用戶的流量的。我們了解到，以前有的競(jìng)品，因?yàn)闊徇w移做的不是特別完善，在設(shè)備出現(xiàn)問(wèn)題或者是需要升級(jí)版本的時(shí)候，常選擇低峰期做升級(jí)。

2）EIP在做限速的時(shí)候，在出方向時(shí)是小帶寬，可以做到比較精準(zhǔn)的限速。好處是用戶做壓測(cè)或測(cè)試的時(shí)，帶寬不會(huì)抖動(dòng)影響自己的業(yè)務(wù)的穩(wěn)定性。

3）高低優(yōu)先級(jí)限速。用戶買一些比較小的比如10M帶寬或者5M帶寬，用來(lái)服務(wù)本身業(yè)務(wù)，同時(shí)也會(huì)ssh或者遠(yuǎn)程桌面登錄EIP；因?yàn)橐黄鹞覀兪亲鰺o(wú)差別的限速丟包的話，這樣會(huì)造成它本身的控制流量，如遠(yuǎn)程桌面的流量也會(huì)被丟包，造成登錄的卡頓。用戶需要在不超限速的前提下，優(yōu)先保證遠(yuǎn)程桌面不卡，然后再提供其他的下載服務(wù)。我們把流量根據(jù)端口進(jìn)行區(qū)分，比如22端口或者是遠(yuǎn)程桌面的3389端口的流量，標(biāo)記為高優(yōu)先級(jí)。在做限速時(shí)，只要高優(yōu)先流量不超限速，就全部放行。當(dāng)高優(yōu)先級(jí)流量再疊加上低優(yōu)先級(jí)的流量超限速時(shí)，把低優(yōu)先級(jí)的流量丟掉，這樣ssh訪問(wèn)服務(wù)器的時(shí)候能夠非常順暢。

4）山海架構(gòu)上線后，基于vip粒度的調(diào)度，可以讓調(diào)度更加靈活。比如原來(lái)一個(gè)集群為了節(jié)省路由條目，我們按照一個(gè)網(wǎng)段發(fā)路由，不是每個(gè)VIP都發(fā)路由的。山海兩級(jí)架構(gòu)之后，沒(méi)有了這個(gè)限制，就可以按照VIP，把CLB實(shí)例調(diào)度到不同CLB集群。這樣如果用戶需要一個(gè)特別大規(guī)格的VIP的時(shí)候，我們可用一個(gè)集群的能力去扛用戶一個(gè)VIP，從而滿足超大規(guī)格實(shí)例的訴求。當(dāng)然真實(shí)使用產(chǎn)品時(shí)，很少有客戶把上百G的流量用一個(gè)VIP來(lái)承載。用戶出于容災(zāi)考慮，通常不會(huì)把所有的雞蛋放到一個(gè)籃子里。

9、山海架構(gòu) 2.0

9.1概述

如前所述：山海 1.0 主要目標(biāo)是整合公共網(wǎng)絡(luò)并將所有公網(wǎng)出口集中在城市核心機(jī)房?jī)?nèi)。至于剩余的 CLB 群集，我們會(huì)繼續(xù)將其保存在原有各機(jī)房的專區(qū)里。這是因?yàn)榫W(wǎng)關(guān)設(shè)備有其與服務(wù)器不同的網(wǎng)絡(luò)訴求，例如普通服務(wù)器不能提供發(fā)布動(dòng)態(tài)路由，并通過(guò)動(dòng)態(tài)路由引流處理業(yè)務(wù)流量。

再比如：網(wǎng)關(guān)專區(qū)的收斂比1:1，而服務(wù)器雖然帶寬也是100G， 但其收斂比率往往小于1：1。

在這種情況下，我們不能簡(jiǎn)單地將 CLB 網(wǎng)關(guān)群集群平移放置到服務(wù)器區(qū)。因此，CLB 網(wǎng)關(guān)群集通常在構(gòu)建每個(gè)機(jī)房時(shí)，預(yù)先規(guī)劃并預(yù)留相應(yīng)的網(wǎng)關(guān)專區(qū)。機(jī)房建設(shè)起來(lái)后，如業(yè)務(wù)量小，又會(huì)因預(yù)留資源空置造成浪費(fèi)。目前專區(qū)閑置機(jī)位也是一筆較大的費(fèi)用。

同時(shí)，還有一種臨時(shí)擴(kuò)容的需求場(chǎng)景，例如VIP大客戶，臨時(shí)會(huì)有大流量的轉(zhuǎn)發(fā)需求，這時(shí)常態(tài)運(yùn)營(yíng)水位沒(méi)法滿足需要，需要調(diào)配設(shè)備做集群擴(kuò)容。如果本機(jī)房的設(shè)備不夠還需要跨機(jī)房搬遷，搬遷周期比較長(zhǎng)，對(duì)我們運(yùn)營(yíng)壓力會(huì)很大。

所以，我們希望通過(guò)山海2.0能把專區(qū)建設(shè)的空置率降下來(lái)，同時(shí)提升彈性，能夠低成本的快速擴(kuò)縮容。

9.2引流交換機(jī)

在山海 2.0里，我們采用了“引流交換機(jī)”。在每個(gè)機(jī)房的建設(shè)時(shí)，我們可以放置兩組共四臺(tái)引流交換機(jī)。

考慮到單個(gè)交換機(jī)的容量可以達(dá)到 1 T 以上，有四臺(tái)交換機(jī)工作，一個(gè)機(jī)房能夠承受大約 4T~ 6T 的流量峰值。這意味著后續(xù)無(wú)需再額外擴(kuò)容，一次性的建設(shè)和布局就可以滿足長(zhǎng)期的需求。相比于 CLB 群集占用的機(jī)位空間，四臺(tái)交換機(jī)所需的機(jī)位顯著減少。

我們把原來(lái)CLB集群對(duì)外聲明路由的能力放到了引流交換機(jī)上，把CLB服務(wù)器用用通用服務(wù)器區(qū)的設(shè)備來(lái)代替。考慮收斂比和容災(zāi)，不會(huì)把一個(gè)集群放到一兩個(gè)機(jī)架上，會(huì)相對(duì)分散些，更不會(huì)把整個(gè)機(jī)架全部再用成CLB集群。這樣CLB集群不再單獨(dú)建設(shè)網(wǎng)關(guān)專區(qū)，引流交換機(jī)把路由聲明發(fā)出去，通過(guò)隧道跟CLB設(shè)備轉(zhuǎn)發(fā)流量。

9.3山海2.0的變化

我們以內(nèi)網(wǎng)CLB為例，原來(lái)一臺(tái)虛擬機(jī)訪問(wèn)CLB集群，CLB集群把它的流量轉(zhuǎn)到對(duì)應(yīng)的RS。

引入交換機(jī)之后，其進(jìn)出兩個(gè)方向都會(huì)有變化：入方向（訪問(wèn)LB方向），虛擬機(jī)的流量先被引流到了引流交換機(jī)，交換機(jī)把報(bào)文做一次封裝，然后發(fā)送給對(duì)應(yīng)的服務(wù)器，進(jìn)行負(fù)載均衡轉(zhuǎn)換。最后處理后的結(jié)果，被轉(zhuǎn)發(fā)給真正的RS。原來(lái)的兩跳訪問(wèn)變成了現(xiàn)在的三跳。同樣反方向流量返回時(shí)，RS的流量先回到引流交換機(jī)，然后被分發(fā)到對(duì)應(yīng)的LD設(shè)備上。LD處理完之后，再把報(bào)文直接轉(zhuǎn)到client虛擬機(jī)上。借助引流交換機(jī)的中轉(zhuǎn)，我們就能夠讓負(fù)載均衡的專區(qū)設(shè)備的放到普通的服務(wù)器區(qū)里。

另外：這里的CLB服務(wù)器，可以跟其他的網(wǎng)關(guān)包括母機(jī)復(fù)用一些相同機(jī)型的服務(wù)器，當(dāng)需要擴(kuò)容時(shí)，就可以使用通用服務(wù)器。而不像以前CLB既有自己獨(dú)立的機(jī)型，又對(duì)服務(wù)器的物理位置有要求。有了引流交換機(jī)跟LD之間是做隧道傳輸，LD具體的物理位置就沒(méi)有像原來(lái)一樣有硬性的要求。這樣CLB可以通過(guò)通用服務(wù)器區(qū)域，調(diào)配服務(wù)器。

最后一項(xiàng)是：原有跟REIP類似的，CLB設(shè)備做路由通告時(shí)，也是按照網(wǎng)段通告，有引流交換機(jī)之后，我們可以在引流交換機(jī)上去做細(xì)粒度的調(diào)度，一個(gè)VIP或是幾個(gè)vip放到一個(gè)集群。還可以在引流交換機(jī)上做更細(xì)粒度的調(diào)度，如IP+port這樣的五元組的粒度的調(diào)度。

10、未來(lái)展望

目前網(wǎng)關(guān)設(shè)備最重要也是最大的一個(gè)方向就是做高性能、硬件卸載。依賴硬件來(lái)實(shí)現(xiàn)高性能的轉(zhuǎn)發(fā)。

網(wǎng)關(guān)設(shè)備分為有狀態(tài)和無(wú)狀態(tài)兩種：

• 1）無(wú)狀態(tài)設(shè)備就像IP轉(zhuǎn)換一樣，只要依據(jù)規(guī)則，任何時(shí)刻來(lái)了報(bào)文，轉(zhuǎn)換出來(lái)的形式都是固定的；
• 2）有狀態(tài)設(shè)備是需要記錄TCP、 UDP狀態(tài)，記錄轉(zhuǎn)發(fā)到后端設(shè)備，當(dāng)不同的時(shí)間轉(zhuǎn)發(fā)即使相同的類型的流量，它轉(zhuǎn)發(fā)的目的地也不一樣，轉(zhuǎn)換的格式也可能不一樣。

硬件卸載在有狀態(tài)和無(wú)狀態(tài)時(shí)，基本上用到的設(shè)備都是DPU和交換機(jī)，用到的介質(zhì)幾乎都是FPGA。

FPGA和ASIC本質(zhì)上是一個(gè)東西，無(wú)論友商還是我們自己內(nèi)部研發(fā)，更多的是FPGA上做功能，并小規(guī)模的灰度上線驗(yàn)證，一旦穩(wěn)定下來(lái)，就轉(zhuǎn)化成批量的ASIC，以此來(lái)降低成本。

DPU和交換機(jī)在無(wú)狀態(tài)設(shè)備上，交換機(jī)相對(duì)更有優(yōu)勢(shì)，因?yàn)闊o(wú)狀態(tài)設(shè)備對(duì)容量的要求相對(duì)小些，像EIP網(wǎng)關(guān)以及內(nèi)部無(wú)狀態(tài)的網(wǎng)關(guān)大多用交換機(jī)形態(tài)實(shí)現(xiàn)。DPU目前更多的用在母機(jī)側(cè)，做有狀態(tài)類的網(wǎng)絡(luò)處理。當(dāng)然， 采用DPU不僅僅局限網(wǎng)絡(luò)訴求，還有存儲(chǔ)安全等其他需求。去年英特爾宣布已不再進(jìn)行交換機(jī)tf芯片的演進(jìn)迭代，大家對(duì)交換機(jī)的質(zhì)疑會(huì)增大。

所以，也衍化了另一種方案：在一臺(tái)額外的服務(wù)器中插入 DPU 網(wǎng)卡以實(shí)現(xiàn)卸載功能。

但不同方案有不同的優(yōu)缺點(diǎn)：

1）使用交換機(jī)的最大優(yōu)勢(shì)在于其強(qiáng)大的交換性能（可達(dá) 1T或幾個(gè)T及更高），可支持很大的接入容量。但是，交換機(jī)僅能是一個(gè)底座，若要擴(kuò)展容量仍需依賴 FPGA 技術(shù)。

2） DPU 的優(yōu)點(diǎn)則包括成熟的產(chǎn)業(yè)鏈、龐大的產(chǎn)量以及穩(wěn)定的供應(yīng)保障；此外，由于 DPU 在母機(jī)側(cè)已被廣泛驗(yàn)證和采用，許多功能的實(shí)現(xiàn)都相對(duì)固定。

這是兩種方案各自的優(yōu)缺點(diǎn)。

在兩個(gè)產(chǎn)品運(yùn)用負(fù)載均衡狀態(tài)的交換上，業(yè)內(nèi)不同的廠家也有不同的玩法，有的是交換機(jī)，有的是DPU。當(dāng)前，無(wú)論是交換機(jī)還是 DPU，都依賴FPGA(ASIC)來(lái)做大容量的會(huì)話管理，同時(shí)越來(lái)越多的設(shè)備或多或少的支持P4。在 X86 上進(jìn)行編程時(shí)，通常選擇 DPDK。

相較之下：使用 P4 進(jìn)行編程的門檻較低。P4 編寫一般功能需求的代碼非常簡(jiǎn)單快捷，只需一兩周時(shí)間即可完成，甚至對(duì)于熟練者來(lái)說(shuō)，可以在幾個(gè)小時(shí)就開(kāi)發(fā)出一個(gè)小功能。雖然充分發(fā)揮硬件的性能，P4類芯片還需要進(jìn)行很深入細(xì)節(jié)的研究，但P4還是大大降低了數(shù)據(jù)面編程的門檻，特別是在高性能轉(zhuǎn)發(fā)的需求方面。

另一個(gè)特點(diǎn)是：小型化。大家過(guò)去比較關(guān)注數(shù)據(jù)中心和海量數(shù)據(jù)的優(yōu)化問(wèn)題，隨著業(yè)務(wù)發(fā)展，逐步轉(zhuǎn)向降低運(yùn)營(yíng)成本和提高效率的場(chǎng)景，開(kāi)設(shè)小型站點(diǎn)。這類小型站點(diǎn)，是典型的“麻雀雖小，五臟俱全”，希望用盡量少的設(shè)備成本來(lái)滿足各種功能需求。所以我們將設(shè)備設(shè)計(jì)為具有較小規(guī)格的產(chǎn)品系列，并在易用性上進(jìn)行改進(jìn)，通過(guò)集群合并、虛擬機(jī)等承擔(dān)更多的任務(wù)負(fù)載。這樣在業(yè)務(wù)規(guī)模和流量不大，也能以較少的資源應(yīng)對(duì)較高的功能性需求。一旦業(yè)務(wù)規(guī)模擴(kuò)大，我們可將這些小型站點(diǎn)升級(jí)為傳統(tǒng)的數(shù)據(jù)中心級(jí)物理設(shè)備。

以上未來(lái)網(wǎng)關(guān)兩個(gè)主要的方向。

11、相關(guān)資料

[1] IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）

[2] 網(wǎng)絡(luò)編程入門從未如此簡(jiǎn)單(三)：什么是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ò)編程入門(七)：面視必備，史上最通俗計(jì)算機(jī)網(wǎng)絡(luò)分層詳解

[6] 以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)

[7] 百度統(tǒng)一socket長(zhǎng)連接組件從0到1的技術(shù)實(shí)踐

[8] 淘寶移動(dòng)端統(tǒng)一網(wǎng)絡(luò)庫(kù)的架構(gòu)演進(jìn)和弱網(wǎng)優(yōu)化技術(shù)實(shí)踐

[9] 百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇

[10] 新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐

[11] 一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐

（本文已同步發(fā)布于：http://www.52im.net/thread-4641-1-1.html）