本篇介紹微服務的高并發設計，先從最外層的接入層入手，看都有什么樣的策略保證高并發。

[[222015]]

接入層的架構，如下圖：

接下來我們依次解析各個部分以及可以做的優化。

數據中心之外：DNS、HttpDNS、GSLB

當我們要訪問一個網站的服務的時候，首先訪問的肯定是一個域名，然后由 DNS，將域名解析為 IP 地址。

我們通過 DNS 訪問數據中心中的對象存儲上的靜態資源為例子，看一看整個過程。

我們建議將例如文件、圖片、視頻、音頻等靜態資源放在對象存儲中，直接通過 CDN 下發，而非放在服務器上，和動態資源綁定在一起。

假設全國有多個數據中心，托管在多個運營商，每個數據中心三個可用區 Available Zone，對象存儲通過跨可用區部署，實現高可用性。

在每個數據中心中，都至少部署兩個內部負載均衡器，內部負載均衡器后面對接多個對象存儲的前置服務 proxy-server。

1、當一個客戶端要訪問 object.yourcompany.com 的時候，需要將域名轉換為 IP 地址進行訪問，所以他要請求本地的 resolver 幫忙。

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

3、如果本地無緩存，則需要請求本地的 Name Server。

4、本地的 Name Server 一般部署在客戶的數據中心或者客戶所在運營商的網絡中，本地 Name Server 看本地是否有緩存，如果有則返回。

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

6、本地的 Name Server 接著訪問 .com 的 Name Server，他會將你們公司的 yourcompany.com 的 Name Server 給本地 Name Server。

7、本地的 Name Server 接著訪問 yourcompany.com 的 Name Server，到這一步就應該返回真實要訪問的 IP 地址。

對于不需要做全局負載均衡的簡單應用來講，yourcompany.com 的 Name Server 可以直接將 object.yourcompany.com 這個域名解析為一個或者多個 IP 地址，然后客戶端可以通過多個 IP 地址，進行簡單的輪詢，實現簡單的負載均衡即可。

但是對于復雜的應用，尤其是跨地域跨運營商的大型應用，則需要更加復雜的全局負載均衡機制，因而需要專門的設備或者服務器來做這件事情，這就是 GSLB，全局負載均衡器。

從 yourcompany.com 的 Name Server 中，一般是通過配置 CNAME 的方式，給 object.yourcompany.com 起一個別名。

例如 object.vip.yourcomany.com，然后告訴本地 Name Server，讓他去請求 GSLB 去解析這個域名，則 GSLB 就可以在解析這個域名的過程中，通過自己的策略實現負載均衡。

圖中畫了兩層的 GSLB，是因為分運營商和分地域，我們希望將屬于不同運營商的客戶，訪問相同運營商機房中的資源，這樣不用跨運營商訪問，有利于提高吞吐量，減少時延。

8、***層 GSLB 通過查看請求他的本地 Name Server 所在的運營商，就知道了用戶所在的運營商。

假設是移動，然后通過 CNAME 的方式，通過另一個別名 object.yd.yourcompany.com，告訴本地 Name Server 去請求第二層的 GSLB。

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

10、本地 Name Server 將結果返回給 resolver。

11、resolver 將結果緩存后，返回給客戶端。

12、客戶端開始訪問屬于相同運營商的距離較近的 Region1 中的對象存儲，當然客戶端得到了六個 IP 地址。

它可以通過負載均衡的方式，隨機或者輪詢選擇一個可用區進行訪問，對象存儲一般會有三份備份，從而可以實現對存儲讀寫的負載均衡。

從上面的過程可以看出，基于 DNS 域名的 GSLB 實現全局的負載均衡，可是現在跨運營商和跨地域的流量調度，由于不同運營商的 DNS 緩存策略不同，會造成 GSLB 的工作失效。

有的用戶的 DNS 會將域名解析的請求轉發給其他運營商的 DNS 進行解析，導致到 GSLB 的時候，錯誤的判斷了用戶所在的運營商。

有的運營商的 DNS 出口會做 NAT，導致 GSLB 判斷錯誤用戶所在的運營商。

所以不同于傳統的 DNS，有另一種機制稱為 httpDNS，可以在用戶的手機 App 里面嵌入 SDK，通過 http 的方式訪問一個 httpDNS 服務器。

由于手機 App 可以精確的獲得自己的 IP 地址，可以將 IP 地址傳給 httpDNS 服務器，httpDNS 服務器完全由應用的服務商提供，可以實現完全自主的全網流量調度。

數據中心之外：CDN

對于靜態資源來講，其實在真實的訪問機房內的對象存儲之前，在最最接近用戶的地方，可以先通過 CDN 進行緩存，這也是高并發應用的一個總體的思路，能接近客戶，盡量接近客戶。

CDN 廠商的覆蓋范圍往往更廣，在每個運營商，每個地區都有自己的 POP 點，所以總有更加靠近用戶的相同運營商和相近地點的 CDN 節點就近獲取靜態數據，避免了跨運營商和跨地域的訪問。

在使用了 CDN 之后，用戶訪問資源的時候，和上面的過程類似，但是不同的是，DNS 解析的時候，會將域名的解析權交給 CDN 廠商的 DNS 服務器。

而 CDN 廠商的 DNS 服務器可以通過 CDN 廠商的 GSLB，找到最最接近客戶的 POP 點，將數據返回給用戶。

當 CDN 中沒有找到緩存數據的時候，則需要到真正的服務器中去拿，這個稱為回源，僅僅非常少數的流量需要回源，大大減少了服務器的壓力。

數據中心邊界與核心：邊界路由、核心交換、等價路由

如果真的需要回源，或者訪問的壓根就不是靜態資源，而是動態資源，則需要進入數據中心了。

剛才***節中說到，最終 GSLB 返回了 6 個 IP 地址，都是內部負載均衡 SLB 的 IP 地址，說明這 6 個 IP 地址都是公網可以訪問的，那么公網如何知道這些 IP 地址的呢？

這就要看機房的結構了，如下圖：

一個機房一般會有邊界路由器、核心交換機，每個 AZ 有匯聚交換機，6 個 SLB 是在 AZ 里面的，所以他們的 IP 地址是通過 iBGP 協議告知邊界路由器的。

當用戶從 6 個 IP 里面選擇了 1 個 IP 地址進行訪問的時候，可以通過公網上面的路由，找到機房的邊界路由器。

邊界路由器知道當時這個路由是從哪個 AZ 里面給它的，于是就通過核心交換一層，將請求轉發給某一個 AZ，這個 AZ 的匯聚交換機會將請求轉發給這個 SLB。

如果一個 AZ 出現了問題，是否可以讓對某個公網 IP 的訪問給另一個 AZ 呢？當然是可以的，在核心路由和核心交換之間，可以做 ECMP 等價路由。

當然也可以在邊界路由上將外部地址 NAT 成為內部的一個 VIP 地址，通過等價路由實現跨 AZ 的流量分擔。

數據中心可用區中：負載均衡 SLB、LVS、HAProxy

進入一個可用區 AZ 之后，首先到達的是負載均衡 SLB，可以購買商用的 SLB，也可以自己搭建，例如通過 LVS 實現基本的負載均衡功能。

LVS 的性能比較好，很多工作通過內核模塊 ipvs 完成，如下圖：

LVS 可使用 keepalived 實現雙機熱備，也可以通過 OSPF 使用等價路由的方式，在多個 LVS 之間進行流量分擔，往往作為統一的負載均衡入口，承載大的流量。

有時候需要更加復雜的 4 層和 7 層負載均衡，則會在 LVS 后面加上 HAProxy 集群，也即將 LVS 導入的流量，分發到一大批 HAProxy 上。

這些 HAProxy 可以根據不同的應用或者租戶進行隔離，每個租戶獨享單獨的 HAProxy，但是所有的租戶共享 LVS 集群。

如果有云環境，則 HAProxy 可以部署在虛擬機里面，可以根據流量的情況和租戶的請求進行動態的創建和刪除。

數據中心可用區中：接入層 Nginx、接入層緩存

在負載均衡之后，是接入網關，或者 API 網關，往往需要實現很多靈活的轉發策略，這里會選擇使用 Nginx+Lua 或者 OpenResty 做這一層。

由于 Nginx 本身也有負載均衡機制，有的時候會將 HAProxy 這一層和 Nginx 這一層合并，LVS 后面直接跟 Nginx 集群。

API 的聚合

使用微服務之后，后端的服務會拆分的非常的細，因而前端應用如果要獲取整個頁面的顯示，往往需要從多個服務獲取數據，將數據做一定的聚合后，方能夠顯示出來。

如果是網頁其實還好，如果你在 Chrome 的 debug 模式下，打開一個復雜的電商主頁的時候，你會發現這個頁面同時會發出很多的 HTTP 請求，最終聚合成為一個頁面。

如果是 App 的話，其實也沒有問題，但是會有大量的工作要在客戶端做，這樣會非常的耗電，用戶體驗非常不好，因而***有一個地方可以將請求聚合，這就是 API 網關的職責之一。

這樣對于前端 App 來講，后端似乎是一個統一的入口，即后端的服務的拆分和聚合，灰度發布，緩存策略等全部被屏蔽了。

服務發現與動態負載均衡

既然統一的入口變為了接入層，則接入層就有責任自動的發現后端拆分、聚合、擴容、縮容的服務集群，當后端服務有所變化的時候，能夠實現健康檢查和動態的負載均衡。

對于微服務來講，服務之間也是需要做服務發現的，常見的框架是 Dubbo 和 Spring Cloud，服務的注冊中心可以是 ZooKeeper、Consul、etcd、Eureka 等。

我們以 Consul 為例子，既然服務之間的調用已經注冊到 Consul 上，則 Nginx 自然也可以通過 Consul 來獲取后端服務的狀態，實現動態的負載均衡。

Nginx 可以集成 consul-template，可監聽 Consul 的事件, 當已注冊 service 列表或 key/value 發生變化時，consul-template 會修改配置文件同時可執行一段 Shell，如 nginx reload。

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

consul-template 模式配置相對復雜，需要 reload nginx。

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

upstream test { 
        server 127.0.0.1:11111; 
        # 所有的后端服務列表會從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不強依賴consul 
        upsync_dump_path /usr/local/nginx/conf/servers/servers_test.conf; 
} 

還有一種方式是 OpenResty+Lua，相對 nginx-upsync-module，可以加入更多自己的邏輯，init_*_by_lua 階段通過 http api 獲取服務列表載入 Nginx 內存，并設置 timer 輪訓更新列表，balancer_by_lua 階段讀取內存的列表, 設置后端服務器。

Lua 實現同樣可以不 reload nginx，相比 nginx-upsync-module 來說更加可擴展。

動靜資源隔離、靜態頁面緩存、頁面靜態化

為什么靜態資源需要隔離呢？靜態資源往往變化較少，但是卻往往比較大，如果每次都加載，則影響性能，浪費帶寬。其實靜態資源可以預加載，并且可以進行緩存，甚至可以推送到 CDN。

所以應該在接入層 Nginx 中配置動態資源和靜態資源的分離，將靜態資源的 url 導入到 Nginx 的本地緩存或者單獨的緩存層如 Varnish 或者 Squid，將動態的資源訪問后端的應用或者動態資源的緩存。

在 Nginx 中，可以通過配置 expires、cache-control、if-modified-since 來控制瀏覽器端的緩存控制。使得瀏覽器端在一段時間內，對于靜態資源，不會重復請求服務端。這一層稱為瀏覽器端的緩存。

當有的請求的確到達了接入層 Nginx 的時候，也不用總是去應用層獲取頁面，可以在接入層 Nginx 先攔截一部分熱點的請求。

在這里可以有兩層緩存。一是 Nginx 本身的緩存 proxy_cache，二是緩存層的 Varnish 或者 Squid。

在使用接入層緩存的時候，需要注意的是緩存 key 的選擇，不應該包含于用戶相關的信息，如用戶名、地理信息、cookie、deviceid 等，這樣相當于每個用戶單獨的一份緩存，使得緩存的***率比較低。

在分離了靜態和動態資源之后，就存在組合的問題，可以通過 Ajax 訪問動態資源，在瀏覽器端進行組合，也可以在接入層進行組合。

如果在接入層聚合，或者 Varnish 進行聚合，則可以讓接入層緩存定時輪詢后端的應用，當有數據修改的時候，進行動態頁面靜態化。

這樣用戶訪問的數據到接入層就會被攔截，缺點是更新的速度有些慢，對于大促場景下的并發訪問高的頁面，可以進行如此的處理。

動態資源緩存

在動靜分離之后，靜態頁面可以很好的緩存，而動態的數據還是會向后端請求。

動態頁面靜態化延時相對比較高，而且頁面數目多的時候，靜態化的工作量也比較大，因而在接入層還可以通過 Redis 或者 Memcached，對動態資源進行緩存。

資源隔離

接入層的 Nginx 集群不是一個，而是不同的請求可以有獨立的 Nginx 集群。

例如搶券或者秒殺系統，會成為熱點中的熱點，因而應該有獨立的 Nginx 集群。

統一鑒權、認證、過濾

API Gateway 的另一個作用是統一的認證和鑒權。

一種是基于 Session 的，當客戶端輸入用戶名密碼之后，API Gateway 會向后端服務提交認證和鑒權，成功后生成 Session，Session 統一放在 Redis 里面，則接下來的訪問全部都帶著 Session 進行。

另一種方式是通過統一的認證鑒權中心，分配 Token 的方式進行。

這是一個三角形的結構，當 API Gateway 接收到登陸請求的時候，去認證中心請求認證和授權，如果成功則返回 Token。

Token 是一個加密過的字符串，里面包含很多的認證信息，接下來的訪問中，API Gateway 可以驗證這個 Token 是否有效來認證，而真正的服務可以根據 Token 來鑒權。

限流

在大促過程中，常常會遇到真實的流量遠遠大于系統測試下來的可承載流量，如果這些流量都進來，則整個系統一定垮掉，***誰也別玩。所以常采用的方式是限流。

限流是從上到下貫穿整個應用的，當然接入層作為最外面的屏障，需要做好整個系統的限流。

對于 Nginx 來講，限流有多種方式，可以進行連接數限制 limit_conn，可以進行訪問頻率限制 limit_req，可以啟用過載保護 sysgurad 模塊。

對請求的目標 URL 進行限流（例如：某個 URL 每分鐘只允許調用多少次）。

對客戶端的訪問 IP 進行限流（例如：某個 IP 每分鐘只允許請求多少次）。

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

對于首頁和活動頁，是讀取比較多的，可以返回緩存中的老的頁面，或者 App 定時刷新。

對于加入購物車、下單、支付等寫入請求被限流的，可以返回等待頁面，或者返回一個圈圈轉啊轉，如果過了一段時間還轉不出來，就可以返回擠爆了。

對于支付結果返回，如果被限流，需要馬上返回錯誤頁面。

灰度發布與 AB 測試

在接入層，由于可以配置訪問路由，以及訪問權重，可以實現灰度發布，或者 AB 測試，同時上線兩套系統，通過切入部分流量的方式，測試新上系統的穩定性或者是否更受歡迎。