建站
咨詢
售后
建站咨詢
新聞中心
本篇介紹微服務(wù)的高并發(fā)設(shè)計(jì)，先從最外層的接入層入手，看都有什么樣的策略保證高并發(fā)。
創(chuàng)新互聯(lián)建站10多年企業(yè)網(wǎng)站制作服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及高端網(wǎng)站定制服務(wù),企業(yè)網(wǎng)站制作及推廣,對墻體彩繪等多個(gè)行業(yè)擁有多年的網(wǎng)站營銷經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。
接入層的架構(gòu)，如下圖：
接下來我們依次解析各個(gè)部分以及可以做的優(yōu)化。
數(shù)據(jù)中心之外：DNS、HttpDNS、GSLB
當(dāng)我們要訪問一個(gè)網(wǎng)站的服務(wù)的時(shí)候，首先訪問的肯定是一個(gè)域名，然后由 DNS，將域名解析為 IP 地址。
我們通過 DNS 訪問數(shù)據(jù)中心中的對象存儲(chǔ)上的靜態(tài)資源為例子，看一看整個(gè)過程。
我們建議將例如文件、圖片、視頻、音頻等靜態(tài)資源放在對象存儲(chǔ)中，直接通過 CDN 下發(fā)，而非放在服務(wù)器上，和動(dòng)態(tài)資源綁定在一起。
假設(shè)全國有多個(gè)數(shù)據(jù)中心，托管在多個(gè)運(yùn)營商，每個(gè)數(shù)據(jù)中心三個(gè)可用區(qū) Available Zone，對象存儲(chǔ)通過跨可用區(qū)部署，實(shí)現(xiàn)高可用性。
在每個(gè)數(shù)據(jù)中心中，都至少部署兩個(gè)內(nèi)部負(fù)載均衡器，內(nèi)部負(fù)載均衡器后面對接多個(gè)對象存儲(chǔ)的前置服務(wù) proxy-server。
1、當(dāng)一個(gè)客戶端要訪問 object.yourcompany.com 的時(shí)候，需要將域名轉(zhuǎn)換為 IP 地址進(jìn)行訪問，所以他要請求本地的 resolver 幫忙。
2、本地的 resolver 看本地的緩存是否有這個(gè)記錄呢？如果有則直接使用。
3、如果本地?zé)o緩存，則需要請求本地的 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 地址。
對于不需要做全局負(fù)載均衡的簡單應(yīng)用來講，yourcompany.com 的 Name Server 可以直接將 object.yourcompany.com 這個(gè)域名解析為一個(gè)或者多個(gè) IP 地址，然后客戶端可以通過多個(gè) IP 地址，進(jìn)行簡單的輪詢，實(shí)現(xiàn)簡單的負(fù)載均衡即可。
但是對于復(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，讓他去請求 GSLB 去解析這個(gè)域名，則 GSLB 就可以在解析這個(gè)域名的過程中，通過自己的策略實(shí)現(xiàn)負(fù)載均衡。
圖中畫了兩層的 GSLB，是因?yàn)榉诌\(yùn)營商和分地域，我們希望將屬于不同運(yùn)營商的客戶，訪問相同運(yùn)營商機(jī)房中的資源，這樣不用跨運(yùn)營商訪問，有利于提高吞吐量，減少時(shí)延。
8、***層 GSLB 通過查看請求他的本地 Name Server 所在的運(yùn)營商，就知道了用戶所在的運(yùn)營商。
假設(shè)是移動(dòng)，然后通過 CNAME 的方式，通過另一個(gè)別名 object.yd.yourcompany.com，告訴本地 Name Server 去請求第二層的 GSLB。
9、第二層的 GSLB 通過查看請求他的本地 Name Server 所在的地址，就知道了用戶所在的地理位置，然后將距離用戶位置比較近的 Region 里面的內(nèi)部負(fù)載均衡 SLB 的地址共六個(gè)返回給本地 Name Server。
10、本地 Name Server 將結(jié)果返回給 resolver。
11、resolver 將結(jié)果緩存后，返回給客戶端。
12、客戶端開始訪問屬于相同運(yùn)營商的距離較近的 Region1 中的對象存儲(chǔ)，當(dāng)然客戶端得到了六個(gè) IP 地址。
它可以通過負(fù)載均衡的方式，隨機(jī)或者輪詢選擇一個(gè)可用區(qū)進(jìn)行訪問，對象存儲(chǔ)一般會(huì)有三份備份，從而可以實(shí)現(xiàn)對存儲(chǔ)讀寫的負(fù)載均衡。
從上面的過程可以看出，基于 DNS 域名的 GSLB 實(shí)現(xiàn)全局的負(fù)載均衡，可是現(xiàn)在跨運(yùn)營商和跨地域的流量調(diào)度，由于不同運(yùn)營商的 DNS 緩存策略不同，會(huì)造成 GSLB 的工作失效。
有的用戶的 DNS 會(huì)將域名解析的請求轉(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
對于靜態(tài)資源來講，其實(shí)在真實(shí)的訪問機(jī)房內(nèi)的對象存儲(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)用戶從 6 個(gè) IP 里面選擇了 1 個(gè) IP 地址進(jìn)行訪問的時(shí)候，可以通過公網(wǎng)上面的路由，找到機(jī)房的邊界路由器。
邊界路由器知道當(dāng)時(shí)這個(gè)路由是從哪個(gè) AZ 里面給它的，于是就通過核心交換一層，將請求轉(zhuǎn)發(fā)給某一個(gè) AZ，這個(gè) AZ 的匯聚交換機(jī)會(huì)將請求轉(zhuǎn)發(fā)給這個(gè) SLB。
如果一個(gè) AZ 出現(xiàn)了問題，是否可以讓對某個(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ú)享單獨(dú)的 HAProxy，但是所有的租戶共享 LVS 集群。
如果有云環(huán)境，則 HAProxy 可以部署在虛擬機(jī)里面，可以根據(jù)流量的情況和租戶的請求進(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 請求，最終聚合成為一個(gè)頁面。
如果是 App 的話，其實(shí)也沒有問題，但是會(huì)有大量的工作要在客戶端做，這樣會(huì)非常的耗電，用戶體驗(yàn)非常不好，因而***有一個(gè)地方可以將請求聚合，這就是 API 網(wǎng)關(guān)的職責(zé)之一。
這樣對于前端 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ù)載均衡。
對于微服務(wù)來講，服務(wù)之間也是需要做服務(wù)發(fā)現(xiàn)的，常見的框架是 Dubbo 和 Spring Cloud，服務(wù)的注冊中心可以是 ZooKeeper、Consul、etcd、Eureka 等。
我們以 Consul 為例子，既然服務(wù)之間的調(diào)用已經(jīng)注冊到 Consul 上，則 Nginx 自然也可以通過 Consul 來獲取后端服務(wù)的狀態(tài)，實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡。
Nginx 可以集成 consul-template，可監(jiān)聽 Consul 的事件, 當(dāng)已注冊 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 模式配置相對復(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，相對 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 的本地緩存或者單獨(dú)的緩存層如 Varnish 或者 Squid，將動(dòng)態(tài)的資源訪問后端的應(yīng)用或者動(dòng)態(tài)資源的緩存。
在 Nginx 中，可以通過配置 expires、cache-control、if-modified-since 來控制瀏覽器端的緩存控制。使得瀏覽器端在一段時(shí)間內(nèi)，對于靜態(tài)資源，不會(huì)重復(fù)請求服務(wù)端。這一層稱為瀏覽器端的緩存。
當(dāng)有的請求的確到達(dá)了接入層 Nginx 的時(shí)候，也不用總是去應(yīng)用層獲取頁面，可以在接入層 Nginx 先攔截一部分熱點(diǎn)的請求。
在這里可以有兩層緩存。一是 Nginx 本身的緩存 proxy_cache，二是緩存層的 Varnish 或者 Squid。
在使用接入層緩存的時(shí)候，需要注意的是緩存 key 的選擇，不應(yīng)該包含于用戶相關(guān)的信息，如用戶名、地理信息、cookie、deviceid 等，這樣相當(dāng)于每個(gè)用戶單獨(dú)的一份緩存，使得緩存的***率比較低。
在分離了靜態(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)是更新的速度有些慢，對于大促場景下的并發(fā)訪問高的頁面，可以進(jìn)行如此的處理。
動(dòng)態(tài)資源緩存
在動(dòng)靜分離之后，靜態(tài)頁面可以很好的緩存，而動(dòng)態(tài)的數(shù)據(jù)還是會(huì)向后端請求。
動(dòng)態(tài)頁面靜態(tài)化延時(shí)相對比較高，而且頁面數(shù)目多的時(shí)候，靜態(tài)化的工作量也比較大，因而在接入層還可以通過 Redis 或者 Memcached，對動(dòng)態(tài)資源進(jìn)行緩存。
資源隔離
接入層的 Nginx 集群不是一個(gè)，而是不同的請求可以有獨(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 接收到登陸請求的時(shí)候，去認(rèn)證中心請求認(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)的限流。
對于 Nginx 來講，限流有多種方式，可以進(jìn)行連接數(shù)限制 limit_conn，可以進(jìn)行訪問頻率限制 limit_req，可以啟用過載保護(hù) sysgurad 模塊。
對請求的目標(biāo) URL 進(jìn)行限流（例如：某個(gè) URL 每分鐘只允許調(diào)用多少次）。
對客戶端的訪問 IP 進(jìn)行限流（例如：某個(gè) IP 每分鐘只允許請求多少次）。
對于被限流的用戶，可以進(jìn)行相對友好的返回，不同的頁面的策略可以不同。
對于首頁和活動(dòng)頁，是讀取比較多的，可以返回緩存中的老的頁面，或者 App 定時(shí)刷新。
對于加入購物車、下單、支付等寫入請求被限流的，可以返回等待頁面，或者返回一個(gè)圈圈轉(zhuǎn)啊轉(zhuǎn)，如果過了一段時(shí)間還轉(zhuǎn)不出來，就可以返回?cái)D爆了。
對于支付結(jié)果返回，如果被限流，需要馬上返回錯(cuò)誤頁面。
灰度發(fā)布與 AB 測試
在接入層，由于可以配置訪問路由，以及訪問權(quán)重，可以實(shí)現(xiàn)灰度發(fā)布，或者 AB 測試，同時(shí)上線兩套系統(tǒng)，通過切入部分流量的方式，測試新上系統(tǒng)的穩(wěn)定性或者是否更受歡迎。
當(dāng)前名稱：從接入層入手，設(shè)計(jì)高并發(fā)的微服務(wù)架構(gòu)？
當(dāng)前網(wǎng)址：http://fisionsoft.com.cn/article/djcdiip.html
