摘要：接入層作用一的聚合。接入層作用二服務(wù)發(fā)現(xiàn)與動(dòng)態(tài)負(fù)載均衡既然統(tǒng)一的入口變?yōu)榱私尤雽?，則接入層就有責(zé)任自動(dòng)的發(fā)現(xiàn)后端拆分，聚合，擴(kuò)容，縮容的服務(wù)集群，當(dāng)后端服務(wù)有所變化的時(shí)候，能夠?qū)崿F(xiàn)健康檢查和動(dòng)態(tài)的負(fù)載均衡。

此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營經(jīng)驗(yàn)。

這個(gè)系列是微服務(wù)高并發(fā)設(shè)計(jì)，所以我們先從最外層的接入層入手，看都有什么樣的策略保證高并發(fā)。

接入層的架構(gòu)畫一個(gè)簡圖來講包括下面的部分

接下來我們依次解析各個(gè)部分以及可以做的優(yōu)化。

一、數(shù)據(jù)中心之外：DNS，HttpDNS，GSLB

當(dāng)我們要訪問一個(gè)網(wǎng)站的服務(wù)的時(shí)候，首先訪問的肯定是一個(gè)域名，然后由DNS，將域名解析為IP地址。

我們首先先通過DNS訪問數(shù)據(jù)中心中的對(duì)象存儲(chǔ)上的靜態(tài)資源為例子，看一看整個(gè)過程。

我們建議將例如文件，圖片，視頻，音頻等靜態(tài)資源放在對(duì)象存儲(chǔ)中，直接通過CDN下發(fā)，而非放在服務(wù)器上，和動(dòng)態(tài)資源綁定在一起。

假設(shè)全國有多個(gè)數(shù)據(jù)中心，托管在多個(gè)運(yùn)營商，每個(gè)數(shù)據(jù)中心三個(gè)可用區(qū)Available Zone，對(duì)象存儲(chǔ)通過跨可用區(qū)部署，實(shí)現(xiàn)高可用性，在每個(gè)數(shù)據(jù)中心中，都至少部署兩個(gè)內(nèi)部負(fù)載均衡器，內(nèi)部負(fù)載均衡器后面對(duì)接多個(gè)對(duì)象存儲(chǔ)的前置服務(wù)proxy-server。

(1) 當(dāng)一個(gè)客戶端要訪問object.yourcompany.com的時(shí)候，需要將域名轉(zhuǎn)換為IP地址進(jìn)行訪問，所以他要請(qǐng)求本地的resolver幫忙

(2) 本地的resolver看本地的緩存是否有這個(gè)記錄呢？如果有則直接使用

(3) 如果本地?zé)o緩存，則需要請(qǐng)求本地的Name Server

(4) 本地的Name Server一般部署在客戶的數(shù)據(jù)中心或者客戶所在的運(yùn)營商的網(wǎng)絡(luò)中，本地Name Server看本地是否有緩存，如果有則返回

(5) 如果本地沒有，本地Name Server需要從Root Name Server開始查起，Root Name Server會(huì)將.com Name Server的地址返回給本地Name Server

(6) 本地的Name Server接著訪問.com的Name Server，他會(huì)將你們公司的yourcompany.com的Name Server給本地Name Server

(7) 本地的Name Server接著訪問yourcompany.com的Name Server，按說這一步就應(yīng)該返回真實(shí)要訪問的IP地址。

對(duì)于不需要做全局負(fù)載均衡的簡單應(yīng)用來講，yourcompany.com的Name Server可以直接將object.yourcompany.com這個(gè)域名解析為一個(gè)或者多個(gè)IP地址，然后客戶端可以通過多個(gè)IP地址，進(jìn)行簡單的輪詢，實(shí)現(xiàn)簡單的負(fù)載均衡即可。

但是對(duì)于復(fù)雜的應(yīng)用，尤其是跨地域跨運(yùn)營商的大型應(yīng)用，則需要更加復(fù)雜的全局負(fù)載均衡機(jī)制，因而需要專門的設(shè)備或者服務(wù)器來做這件事情，這就是GSLB，全局負(fù)載均衡器

從yourcompany.com的Name Server中，一般是通過配置CNAME的方式，給object.yourcompany.com起一個(gè)別名，例如object.vip.yourcomany.com，然后告訴本地Name Server，讓他去請(qǐng)求GSLB去解析這個(gè)域名，則GSLB就可以在解析這個(gè)域名的過程中，通過自己的策略實(shí)現(xiàn)負(fù)載均衡。

圖中畫了兩層的GSLB，是因?yàn)榉诌\(yùn)營商和分地域，我們希望將屬于不同運(yùn)營商的客戶，訪問相同運(yùn)營商機(jī)房中的資源，這樣不用跨運(yùn)營商訪問，有利于提高吞吐量，減少時(shí)延。

(8) 第一層GSLB通過查看請(qǐng)求他的本地Name Server所在的運(yùn)營商，就知道了用戶所在的運(yùn)營商，假設(shè)是移動(dòng)，然后通過CNAME的方式，通過另一個(gè)別名object.yd.yourcompany.com，告訴本地Name Server去請(qǐng)求第二層的GSLB

(9) 第二層的GSLB通過查看請(qǐng)求他的本地Name Server所在的地址，就知道了用戶所在的地理位置，然后將距離用戶位置比較近的Region的里面的內(nèi)部負(fù)載均衡SLB的地址共六個(gè)返回給本地Name Server

(10) 本地Name Server將結(jié)果返回給resolver

(11) resolver將結(jié)果緩存后，返回給客戶端

(12) 客戶端開始訪問屬于相同運(yùn)營商的距離較近的Region1中的對(duì)象存儲(chǔ)，當(dāng)然客戶端得到了六個(gè)IP地址，他可以通過負(fù)載均衡的方式，隨機(jī)或者輪詢選擇一個(gè)可用區(qū)進(jìn)行訪問，對(duì)象存儲(chǔ)一般會(huì)有三份備份，從而可以實(shí)現(xiàn)對(duì)存儲(chǔ)讀寫的負(fù)載均衡。

從上面的過程可以看出，基于DNS域名的GSLB實(shí)現(xiàn)全局的負(fù)載均衡，可是現(xiàn)在跨運(yùn)營商和跨地域的流量調(diào)度，但是由于不同運(yùn)營商的DNS緩存策略不同，會(huì)造成GSLB的工作實(shí)效。

有的用戶的DNS會(huì)將域名解析的請(qǐng)求轉(zhuǎn)發(fā)給其他的運(yùn)營商的DNS進(jìn)行解析，導(dǎo)致到GSLB的時(shí)候，錯(cuò)誤的判斷了用戶所在的運(yùn)營商。

有的運(yùn)營商的DNS出口會(huì)做NAT，導(dǎo)致GSLB判斷錯(cuò)誤用戶所在的運(yùn)營商。

所以不同于傳統(tǒng)的DNS，有另一種機(jī)制稱為httpDNS，可以在用戶的手機(jī)App里面嵌入SDK，通過http的方式訪問一個(gè)httpDNS服務(wù)器，由于手機(jī)App可以精確的獲得自己的IP地址，可以將IP地址傳給httpDNS服務(wù)器，httpDNS服務(wù)器完全由應(yīng)用的服務(wù)商提供，可以實(shí)現(xiàn)完全自主的全網(wǎng)流量調(diào)度。

二、數(shù)據(jù)中心之外：CDN

對(duì)于靜態(tài)資源來講，其實(shí)在真實(shí)的訪問機(jī)房內(nèi)的對(duì)象存儲(chǔ)之前，在最最接近用戶的地方，可以先通過CDN進(jìn)行緩存，這也是高并發(fā)應(yīng)用的一個(gè)總體的思路，能接近客戶，盡量接近客戶。

CDN廠商的覆蓋范圍往往更廣，在每個(gè)運(yùn)營商，每個(gè)地區(qū)都有自己的POP點(diǎn)，所以總有更加靠近用戶的相同運(yùn)營商和相近地點(diǎn)的CDN節(jié)點(diǎn)就近獲取靜態(tài)數(shù)據(jù)，避免了跨運(yùn)營商和跨地域的訪問。

在使用了CDN之后，用戶訪問資源的時(shí)候，和上面的過程類似，但是不同的是，DNS解析的時(shí)候，會(huì)將域名的解析權(quán)交給CDN廠商的DNS服務(wù)器，而CDN廠商的DNS服務(wù)器可以通過CDN廠商的GSLB，找到最最接近客戶的POP點(diǎn)，將數(shù)據(jù)返回給用戶。

當(dāng)CDN中沒有找到緩存數(shù)據(jù)的時(shí)候，則需要到真正的服務(wù)器中去拿，這個(gè)稱為回源，僅僅非常少數(shù)的流量需要回源，大大減少了服務(wù)器的壓力。

三、數(shù)據(jù)中心邊界與核心：邊界路由，核心交換，等價(jià)路由

如果真的需要回源，或者訪問的壓根就不是靜態(tài)資源，而是動(dòng)態(tài)資源，則需要進(jìn)入數(shù)據(jù)中心了。

剛才第一節(jié)中說到，最終GSLB返回了6個(gè)IP地址，都是內(nèi)部負(fù)載均衡SLB的IP地址，說明這6個(gè)IP地址都是公網(wǎng)可以訪問的，那么公網(wǎng)如何知道這些IP地址的呢？

這就要看機(jī)房的結(jié)構(gòu)了

一個(gè)機(jī)房一般會(huì)有邊界路由器，核心交換機(jī)，每個(gè)AZ有匯聚交換機(jī)，6個(gè)SLB是在AZ里面的，所以他們的IP地址是通過iBGP協(xié)議告知邊界路由器的。

當(dāng)用戶從六個(gè)IP里面選擇了一個(gè)IP地址進(jìn)行訪問的時(shí)候，可以通過公網(wǎng)上面的路由，找到機(jī)房的邊界路由器，邊界路由器知道當(dāng)時(shí)這個(gè)路由是從哪個(gè)AZ里面給他的，于是就通過核心交換一層，將請(qǐng)求轉(zhuǎn)發(fā)給某一個(gè)AZ，這個(gè)AZ的匯聚交換機(jī)會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給這個(gè)SLB。

如果一個(gè)AZ出現(xiàn)了問題，是否可以讓對(duì)某個(gè)公網(wǎng)IP的訪問給另一個(gè)AZ呢？當(dāng)然是可以的，在核心路由和核心交換之間，可以做ECMP等價(jià)路由。當(dāng)然也可以在邊界路由上將外部地址NAT稱為內(nèi)部的一個(gè)VIP地址，通過等價(jià)路由實(shí)現(xiàn)跨AZ的流量分擔(dān)。

四、數(shù)據(jù)中心可用區(qū)中：負(fù)載均衡SLB，LVS，Haproxy

進(jìn)入一個(gè)可用區(qū)AZ之后，首先到達(dá)的是負(fù)載均衡SLB，可以購買商用的SLB，也可以自己搭建，例如通過LVS實(shí)現(xiàn)基本的負(fù)載均衡功能。

LVS的性能比較好，很多工作通過內(nèi)核模塊ipvs完成。

LVS可使用keepalived實(shí)現(xiàn)雙機(jī)熱備，也可以通過OSPF使用等價(jià)路由的方式，在多個(gè)LVS之間進(jìn)行流量分擔(dān)，往往作為統(tǒng)一的負(fù)載均衡入口，承載大的流量。

有時(shí)候需要更加復(fù)雜的4層和7層負(fù)載均衡，則會(huì)在LVS后面加上haproxy集群，也即將LVS導(dǎo)入的流量，分發(fā)到一大批haproxy上，這些haproxy可以根據(jù)不同的應(yīng)用或者租戶進(jìn)行隔離，每個(gè)租戶獨(dú)享多帶帶的haproxy，但是所有的租戶共享LVS集群。

如果有云環(huán)境，則haproxy可以部署在虛擬機(jī)里面，可以根據(jù)流量的情況和租戶的請(qǐng)求進(jìn)行動(dòng)態(tài)的創(chuàng)建和刪除。

五、數(shù)據(jù)中心可用區(qū)中：接入層nginx，接入層緩存

在負(fù)載均衡之后，是接入網(wǎng)關(guān)，或者API網(wǎng)關(guān)，往往需要實(shí)現(xiàn)很多靈活的轉(zhuǎn)發(fā)策略，這里會(huì)選擇使用nginx+lua或者openresty做這一層。

由于nginx本身也有負(fù)載均衡機(jī)制，有的時(shí)候會(huì)將haproxy這一層和nginx這一層合并，LVS后面直接跟nginx集群。

接入層作用一：API的聚合。

使用微服務(wù)之后，后端的服務(wù)會(huì)拆分的非常的細(xì)，因而前端應(yīng)用如果要獲取整個(gè)頁面的顯示，往往需要從多個(gè)服務(wù)獲取數(shù)據(jù)，將數(shù)據(jù)做一定的聚合后，方能夠顯示出來。

如果是網(wǎng)頁其實(shí)還好，如果你用chrome的debug模式下，打開一個(gè)復(fù)雜的電商主頁的時(shí)候，你會(huì)發(fā)現(xiàn)這個(gè)頁面同時(shí)會(huì)發(fā)出很多的http的請(qǐng)求，最終聚合稱為一個(gè)頁面。

如果是APP的話，其實(shí)也沒有問題，但是會(huì)有大量的工作要在客戶端做，這樣會(huì)非常的耗電，用戶體驗(yàn)非常不好，因而最好有一個(gè)地方可以將請(qǐng)求聚合，這就是API網(wǎng)關(guān)的職責(zé)之一。這樣對(duì)于前端APP來講，后端接是似乎是一個(gè)統(tǒng)一的入口，則后端的服務(wù)的拆分和聚合，灰度發(fā)布，緩存策略等全部被屏蔽了。

接入層作用二：服務(wù)發(fā)現(xiàn)與動(dòng)態(tài)負(fù)載均衡

既然統(tǒng)一的入口變?yōu)榱私尤雽?，則接入層就有責(zé)任自動(dòng)的發(fā)現(xiàn)后端拆分，聚合，擴(kuò)容，縮容的服務(wù)集群，當(dāng)后端服務(wù)有所變化的時(shí)候，能夠?qū)崿F(xiàn)健康檢查和動(dòng)態(tài)的負(fù)載均衡。

對(duì)于微服務(wù)來講，服務(wù)之間也是需要做服務(wù)發(fā)現(xiàn)的，常見的框架是dubbo和springcloud，服務(wù)的注冊(cè)中心可以是zookeeper, consul, etcd, eureka等。

我們以consul為例子，既然服務(wù)之間的調(diào)用已經(jīng)注冊(cè)到consul上，則nginx自然也可以通過consul來獲取后端服務(wù)的狀態(tài)，實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡。

nginx可以集成consul-template，可監(jiān)聽consul的事件, 當(dāng)已注冊(cè)service列表或key/value 發(fā)生變化時(shí), consul-template會(huì)修改配置文件同時(shí)可執(zhí)行一段shell, 如 nginx reload

consul-template -template "/tmp/nginx.hcl:/var/nginx/nginx.conf:service nginx reload"

consul-template模式配置相對(duì)復(fù)雜，需要reload nginx。

另一種集成consul的方式是nginx-upsync-module，可以同步consul的服務(wù)列表或key/value存儲(chǔ)，需要重新編譯nginx，不需要reload nginx。

upstream test {

    server 127.0.0.1:11111;
    # 所有的后端服務(wù)列表會(huì)從consul拉取, 并刪除上面的占位server
    upsync 127.0.0.1:8500/v1/catelog/service/test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
    # 備份的地址, 保證nginx不強(qiáng)依賴consul
    upsync_dump_path /usr/local/nginx/conf/servers/servers_test.conf;

}
還有一種方式是openresty+lua，相對(duì)nginx-upsync-module, 可以加入更多自己的邏輯, init_*_by_lua 階段通過http api 獲取服務(wù)列表載入Nginx 內(nèi)存, 并設(shè)置timer輪訓(xùn)更新列表，balancer_by_lua 階段 讀取內(nèi)存的列表, 設(shè)置后端服務(wù)器。

Lua實(shí)現(xiàn) 同樣可以不reload nginx, 相比nginx-upsync-module 來說更加可擴(kuò)展。

接入層作用三：動(dòng)靜資源隔離，靜態(tài)頁面緩存，頁面靜態(tài)化

為什么靜態(tài)資源需要隔離呢，靜態(tài)資源往往變化較少，但是卻往往比較大，如果每次都加載，則影響性能，浪費(fèi)帶寬。其實(shí)靜態(tài)資源可以預(yù)加載，并且可以進(jìn)行緩存，甚至可以推送到CDN。

所以應(yīng)該在接入層nginx中配置動(dòng)態(tài)資源和靜態(tài)資源的分離，將靜態(tài)資源的url導(dǎo)入到nginx的本地緩存或者多帶帶的緩存層如varnish或者squid，將動(dòng)態(tài)的資源訪問后端的應(yīng)用或者動(dòng)態(tài)資源的緩存。

在nginx中，可以通過配置expires，cache-control，if-modified-since來控制瀏覽器端的緩存控制。使得瀏覽器端在一段時(shí)間內(nèi)，對(duì)于靜態(tài)資源，不會(huì)重復(fù)請(qǐng)求服務(wù)端。這一層稱為瀏覽器端的緩存。

當(dāng)有的請(qǐng)求的確到達(dá)了接入層nginx的時(shí)候，也不用總是去應(yīng)用層獲取頁面，可以在接入層nginx先攔截一部分熱點(diǎn)的請(qǐng)求。在這里可以有兩層緩存。一是nginx本身的緩存proxy_cache，二是緩存層的varnish或者squid。

在使用接入層緩存的時(shí)候，需要注意的是緩存key的選擇，不應(yīng)該包含于用戶相關(guān)的信息，如用戶名，地理信息，cookie，deviceid等，這樣相當(dāng)于每個(gè)用戶多帶帶的一份緩存，使得緩存的命中率比較低。

在分離了靜態(tài)和動(dòng)態(tài)資源之后，就存在組合的問題，可以通過ajax訪問動(dòng)態(tài)資源，在瀏覽器端進(jìn)行組合，也可以在接入層進(jìn)行組合。

如果在接入層聚合，或者varnish進(jìn)行聚合，則可以讓接入層緩存定時(shí)輪詢后端的應(yīng)用，當(dāng)有數(shù)據(jù)修改的時(shí)候，進(jìn)行動(dòng)態(tài)頁面靜態(tài)化，這樣用戶訪問的數(shù)據(jù)到接入層就會(huì)被攔截，缺點(diǎn)是更新的速度有些慢，對(duì)于大促場景下的并發(fā)訪問高的頁面，可以進(jìn)行如此的處理。

接入層作用四：動(dòng)態(tài)資源緩存

在動(dòng)靜分離之后，靜態(tài)頁面可以很好的緩存，而動(dòng)態(tài)的數(shù)據(jù)還是會(huì)向后端請(qǐng)求，而動(dòng)態(tài)頁面靜態(tài)化延時(shí)相對(duì)比較高，而且頁面數(shù)目多的時(shí)候，靜態(tài)化的工作量也比較大，因而在接入層還可以通過redis或者memcached，對(duì)動(dòng)態(tài)資源進(jìn)行緩存。

接入層作用五：資源隔離

接入層的nginx集群不是一個(gè)，而是不同的請(qǐng)求可以有獨(dú)立的nginx集群。

例如搶券或者秒殺系統(tǒng)，會(huì)成為熱點(diǎn)中的熱點(diǎn)，因而應(yīng)該有獨(dú)立的nginx集群。

接入層作用六：統(tǒng)一鑒權(quán)，認(rèn)證，過濾

API Gateway的另一個(gè)作用是統(tǒng)一的認(rèn)證和鑒權(quán)。

一種是基于session的，當(dāng)客戶端輸入用戶名密碼之后，API Gateway會(huì)向后端服務(wù)提交認(rèn)證和鑒權(quán)，成功后生成session，session統(tǒng)一放在redis里面，則接下來的訪問全部都帶著session進(jìn)行。

另一種方式是通過統(tǒng)一的認(rèn)證鑒權(quán)中心，分配token的方式進(jìn)行。

這是一個(gè)三角形的結(jié)構(gòu)，當(dāng)API Gateway接收到登陸請(qǐng)求的時(shí)候，去認(rèn)證中心請(qǐng)求認(rèn)證和授權(quán)，如果成功則返回token，token是一個(gè)加密過的字符串，里面包含很多的認(rèn)證信息，接下來的訪問中，API Gateway可以驗(yàn)證這個(gè)token是否有效來認(rèn)證，而真正的服務(wù)可以根據(jù)token來鑒權(quán)。

接入層作用七：限流

在大促過程中，常常會(huì)遇到真實(shí)的流量遠(yuǎn)遠(yuǎn)大于系統(tǒng)測試下來的可承載流量，如果這些流量都進(jìn)來，則整個(gè)系統(tǒng)一定垮掉，最后誰也別玩。所以長做的方式是限流。

限流是從上到下貫穿整個(gè)應(yīng)用的，當(dāng)然接入層作為最外面的屏障，需要做好整個(gè)系統(tǒng)的限流。

對(duì)于nginx來講，限流有多種方式，可以進(jìn)行連接數(shù)限制limit_conn，可以進(jìn)行訪問頻率限制limit_req，可以啟用過載保護(hù)sysgurad模塊。

對(duì)請(qǐng)求的目標(biāo)URL進(jìn)行限流（例如：某個(gè)URL每分鐘只允許調(diào)用多少次）

對(duì)客戶端的訪問IP進(jìn)行限流（例如：某個(gè)IP每分鐘只允許請(qǐng)求多少次）

對(duì)于被限流的用戶，可以進(jìn)行相對(duì)友好的返回，不同的頁面的策略可以不同。

對(duì)于首頁和活動(dòng)頁，是讀取比較多的，可以返回緩存中的老的頁面，或者APP定時(shí)刷新。

對(duì)于加入購物車，下單，支付等寫入請(qǐng)求被限流的，可以返回等待頁面，或者返回一個(gè)圈圈轉(zhuǎn)啊轉(zhuǎn)，如果過了一段時(shí)間還轉(zhuǎn)不出來，就可以返回?cái)D爆了。

對(duì)于支付結(jié)果返回，如果被限流，需要馬上返回錯(cuò)誤頁面。

接入層作用八：灰度發(fā)布與AB測試

在接入層，由于可以配置訪問路由，以及訪問權(quán)重，可以實(shí)現(xiàn)灰度發(fā)布，或者AB測試，同時(shí)上線兩套系統(tǒng)，通過切入部分流量的方式，測試新上系統(tǒng)的穩(wěn)定性或者是否更受歡迎。

網(wǎng)易云計(jì)算基礎(chǔ)服務(wù)深度整合了 IaaS、PaaS 及容器技術(shù)，提供彈性計(jì)算、DevOps 工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決 IT、架構(gòu)及運(yùn)維等問題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計(jì)算平臺(tái)，點(diǎn)擊可免費(fèi)試用。

免費(fèi)體驗(yàn)云安全(易盾)內(nèi)容安全、驗(yàn)證碼等服務(wù)

更多網(wǎng)易技術(shù)、產(chǎn)品、運(yùn)營經(jīng)驗(yàn)分享請(qǐng)點(diǎn)擊。

文章來源： 網(wǎng)易云社區(qū)