TCP接入層的負載均衡、高可用、擴展性架構

作者：58沈劍 2017-05-08 08:44:07

開發開發工具

本文主要介紹TCP接入層如何實施負載均衡、如何保證高可用以及擴展性架構。

一、web-server的負載均衡

互聯網架構中，web-server接入一般使用nginx來做反向代理，實施負載均衡。整個架構分三層：

上游調用層，一般是browser或者APP
中間反向代理層，nginx
下游真實接入集群，web-server，常見web-server的有tomcat，apache

整個訪問過程為：

browser向daojia.com發起請求
DNS服務器將daojia.com解析為外網IP(1.2.3.4)
browser通過外網IP(1.2.3.4)訪問nginx
nginx實施負載均衡策略，常見策略有輪詢，隨機，IP-hash等
nginx將請求轉發給內網IP(192.168.0.1)的web-server

由于http短連接，以及web應用無狀態的特性，理論上任何一個http請求落在任意一臺web-server都應該得到正常處理(如果必須落在一臺，說明架構不合理，不能水平擴展)。

問題來了，tcp是有狀態的連接，客戶端和服務端一旦建立連接，一個client發起的請求必須落在同一臺tcp-server上，此時如何做負載均衡，如何保證水平擴展呢?

二、單機法tcp-server

單個tcp-server顯然是可以保證請求一致性：

client向tcp.daojia.com發起tcp請求
DNS服務器將tcp.daojia.com解析為外網IP(1.2.3.4)
client通過外網IP(1.2.3.4)向tcp-server發起請求

方案的缺點?

無法保證高可用。

三、集群法tcp-server

通過搭建tcp-server集群來保證高可用，客戶端來實現負載均衡：

client內配置有tcp1/tcp2/tcp3.daojia.com三個tcp-server的外網IP
客戶端通過“隨機”的方式選擇tcp-server，假設選擇到的是tcp1.daojia.com
通過DNS解析tcp1.daojia.com
通過外網IP連接真實的tcp-server

1. 如何保證高可用呢?

如果client發現某個tcp-server連接不上，則選擇另一個。

2. 潛在的缺點?

每次連接前，需要多實施一次DNS訪問：

難以預防DNS劫持
多一次DNS訪問意味著更長的連接時間，這個不足在手機端更為明顯

3. 如何解決DNS的問題?

直接將IP配置在客戶端，可以解決上述兩個問題，很多公司也就是這么做的(俗稱“IP直通車”)。

4. “IP直通車”有什么新問題?

將IP寫死在客戶端，在客戶端實施負載均衡，擴展性很差：

如果原有IP發生變化，客戶端得不到實時通知
如果新增IP，即tcp-sever擴容，客戶端也得不到實時通知
如果負載均衡策略變化，需要升級客戶端

四、服務端實施負載均衡

只有將復雜的策略下沉到服務端，才能根本上解決擴展性的問題。

增加一個http接口，將客戶端的“IP配置”與“均衡策略”放到服務端是一個不錯的方案：

client每次訪問tcp-server前，先調用一個新增的get-tcp-ip接口，對于client而言，這個http接口只返回一個tcp-server的IP
這個http接口，實現的是原client的IP均衡策略
拿到tcp-server的IP后，和原來一樣向tcp-server發起TCP長連接

這樣的話，擴展性問題就解決了：

如果原有IP發生變化，只需要修改get-tcp-ip接口的配置
如果新增IP，也是修改get-tcp-ip接口的配置
如果負載均衡策略變化，需要升級客戶端

然而，新的問題又產生了，如果所有IP放在客戶端，當有一個IP掛掉的時候，client可以再換一個IP連接，保證可用性，而get-tcp-ip接口只是維護靜態的tcp-server集群IP，對于這些IP對應的tcp-server是否可用，是完全不知情的，怎么辦呢?

五、tcp-server狀態上報

get-tcp-ip接口怎么知道tcp-server集群中各臺服務器是否可用呢，tcp-server主動上報是一個潛在方案，如果某一個tcp-server掛了，則會終止上報，對于停止上報狀態的tcp-server，get-tcp-ip接口，將不返回給client相應的tcp-server的外網IP。

該設計存在的問題?

誠然，狀態上報解決了tcp-server高可用的問題，但這個設計犯了一個“反向依賴”的耦合小錯誤：使得tcp-server要依賴于一個與本身業務無關的web-server。

六、tcp-server狀態拉取