構建高可用服務端

一. 什麼是高可用性

服務端，顧名思義就是爲用戶提供服務的。
停工時間，就是不能向用戶提供服務的時間。
高可用，就是系統具備高度可用性，儘可能減小停工時間。

停工的緣由通常有：

1. 服務器故障。例如服務器宕機，服務器網絡出現問題，機房或者機架出現問題等。
2. 訪問量急劇上升，致使服務器壓力過大。致使訪問量急劇上升的緣由有：
   1. 時間和訪問量均可以預見的，例如秒殺活動，售票系統。
   2. 時間和訪問量都不能夠預見的，例如特發性新聞（馬航失聯的事件）

停工的緣由，能夠理解爲災難，因此係統的高可用性就是容災，即應對災難的能力，系統有較好的容災能力，也就是即便災難出現，系統依然能夠正常工做。

二. 怎麼提高系統的高可用性

1. 機器層面的災難

例如：

• 機器宕機（其中一臺服務器宕機了）
• 機房故障（機房被水淹了）
• 網絡異常（電信的某條光纖被挖斷了）

從範圍了說，有多是一臺機器，也有多是多臺機器（機房或者某個區域，例如廣東），甚至所有機器（那就沒救了。。）。

思路就是在多臺機器上部署服務，即便一臺機器出現問題，其餘機器依然能夠提供服務。固然，比較可靠的是，多臺機器最好在不一樣的機房，不一樣的地域，可是對應的成本也會上升。

1. 主從方式

主服務負責提供服務，從服務負責監測主服務器的心跳。當主服務出現問題，馬上轉換爲從服務器提供服務。例如Mysql的主從架構。

2.多機多工方式

在N臺機器上面，運行N個服務，經過負載均衡，把請求分發到不一樣的機器。當其中一臺機器出現問題。系統會自動的切換流量，也就是把請求都導流到其餘正常的機器上。

2. 業務層面的災難

例如：

• 程序出bug了
• 訪問量急劇上升（預計QPS是1k，忽然去到1w）

優化思路：

1. 大系統小作。一個大系統，必然會有許多模塊，把這些模塊切分爲多個小服務。例如用戶系統，是一個獨立的服務，消費系統，是一個獨立的服務。每一個服務都提供訪問的API，給其餘服務訪問。缺點是服務與服務之間的通信成本增長，開發成本也會增長，由於要開發API。可是好處是：
   1. 必要的時候，這些API能夠提供給外部
   2. 符合高內聚低耦合的原則
   3. 當某個服務壓力上升時，或者服務出現bug時，其餘不依賴於問題服務的服務，依然能夠正常工做。例如消費服務出現問題，可是聊天服務能夠依然能夠正常工做。
2. 有損服務。讓服務延遲執行，以保證核心需求獲得很好的處理。例如微信搶紅包，核心需求是馬上知道搶紅包的結果，因此服務端先返回搶紅包的結果，而用戶對是否即時入帳並不關心，因此，把入帳這個過程，放在異步隊列裏面作。
3. 柔性可用。在正常服務和停工之間增長一個狀態：部分可用。當壓力上來的時候，能夠中止某些非必要服務，以保證必要服務能夠正常運行。又例如遇到bug的時候，短期內不能馬上修復，並且出bug的業務又是非必要業務，能夠先中止bug的業務，固然，這些要事先跟產品方商量好。
4. 快速拒絕（過載保護）。檢查當前系統的負載請求，若是負載太高，馬上返回等待提示，例如：系統繁忙，請稍後再試。不然，用戶會不斷重試，讓已經負載很高的系統雪上加霜。在客戶端，要限制重試的頻率，例如30s後才能重試，或者沒有收到服務端的返回前，不能再次提交請求。也能夠在Nginx層加入限制，同一IP1秒內不能發送多於N個請求，多於的就快速拒絕，防止被攻擊。

3. 驗證高可用

當咱們採用了各類措施來提高系統的容災能力後，怎麼測試咱們的措施是否有用呢？

1. 模擬客戶端低網速。這個能夠經過Fiddler來模擬
2. 模擬服務端丟包。可使用netern和tc
3. 使用ab進行壓測。
4. 模擬服務器宕機，能夠直接斷開服務器網絡來模擬

3、應用

應用通常都是針對上面的機器問題致使的機器層面的災難，由於業務層面的，通常是在代碼開發階段考慮的。

高可用能夠分爲兩個關鍵點：

• 多節點
• 自動切換流量

多節點，也就是要部署多個節點，不管其餘節點是掛起狀態（主從），仍是工做昨天（多機多工）。
當有了多節點後，仍是不夠的，由於當災難來臨的話，若是要人工去切換流量，必然要花費較長時間，因此須要有自動切換流量的機制。
自動切換流量的另外一個功能就是，當損壞的節點恢復後，流量又會自動得切回去。

4、HTTP的應用

經常使用的服務端架構，通常是這樣：

• 客戶端從DNS服務器獲取服務器的IP
• 客戶端發起請求，請求先到Nginx層
• Nginx層分發請求到服務層
• 若是須要，服務層會請求上游的服務層，例如向用戶系統獲取用戶數據。通常會已經過HTTP來實現。
• 若是須要，服務層會訪問緩存層，獲取數據
• 若是須要，服務層會訪問數據庫層，獲取數據

1. 客戶端層到Nginx層

會部署多個Nginx層，DNS服務器中部署多個IP，這樣DNS服務器會把流量均勻地分到多個Nginx。
缺點是：

• 不能自動切換流量。當其中一臺Nginx不可用了，DNS服務器並不知道，因此不會自動切換流量

本機的hosts配置中，能夠設置一個域名對應多個IP，設置方法：
192.168.137.130 www.test.com
192.168.137.133 www.test.com
hosts的解析策略是，先訪問第一個IP，若是失敗，纔會訪問第二個IP
因此沒有負載均衡的功能，可是有自動流量切換的功能。

2. Nginx到服務層

Nginx裏面能夠配置多個服務層。
Nginx有監聽服務層是否可用的機制（upstream），因此能夠實現自動切換流量

nginx配置

upstream gunicorn_pool
{
    #server 地址:端口號 weight表示權值，權值越大，被分配的概率越大;max_fails表示在fail_timeout中失敗的最大次數，若是達到該次數，就再也不導流量到該server
    server 192.168.137.130:9098 weight=4 max_fails=2 fail_timeout=30s;
    server 192.168.137.133:9098 weight=4 max_fails=2 fail_timeout=30s;
}

server {
    listen 80;
    server_name 127.0.0.1 www.test.com;
    access_log /data/logs/nginx_access.log;
    error_log /data/logs/nginx_error.log;
    location @gunicorn_proxy {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://gunicorn_pool;
    }
}

配置一個upstream，gunicorn_pool。裏面有兩個服務層（130和137）
若是兩個服務層都正常，Nginx會把流量根據weight值，導流到兩個服務器。
同一個請求中，若是nginx導流到server1，發現返回的是錯誤響應（例如502），nginx會把請求再發送server2，至關於重試。這時會記錄server1的fail次數+1
若是再fail_timeout時間內，server1的fail次數超過max_fails，在fail_timeout時間內，nginx就不會再把其餘請求導流到server1了。

上面的機制，就能夠實現自動的流量切換。固然也有負載均衡的功能，這個就是高併發的範疇了。

3. 服務層到上游服務器

1. DNS服務器。使用DNS服務器把流量均分到上游服務層。缺點也是不能自動切換流量
2. RPC-client。在服務器的機器中，部署一個RPC-client，通常的實現方案是啓動一個Nginx，利用Nginx的upstream功能來分發流量，同時能夠實現自動流量切換。服務層到上游服務層的請求，會先發到RPC-client，而後再到上游服務層，至關於加了一個HTTP代理。

4.服務層到緩存層

經常使用的緩存有redis和mongodb

1.redis

• 主從架構
• 哨兵架構
• 集羣架構

redis cluster

2.mongo

• 主從架構
• 副本集架構
• 分片

mongo HA

5.服務層到數據庫層

經常使用的數據庫就是Mysql了。

• 一主多從（主從複製）
• 二主多從（主主複製）

5、TCP的應用

1. DNS方法

配置DNS服務器，一個域名，對應多個IP。
缺點是不能實現流量自動切換，例如S1掛了，DNS仍是會返回S1的iP給客戶端。客戶端可能要重試幾回，纔會拿到其餘Server的IP，才能實現鏈接。

2.get-ip接口

因爲TCP是長鏈接，因此獲取IP的請求是不多的，因此能夠本身寫一個接口，客戶端經過接口來獲取TCP Server的IP地址。
這樣接口裏面就能夠作到自動切換流量了。例如A機器已經掛了，就不會返回A機器的IP了。
TCP Server能夠把自身的狀態在Redis，而後接口那邊就能夠獲取TCP Server的狀態了
也能夠TCP Server提供一個http接口，返回自身的狀態，供get-ip接口那邊調用。

參考：
柔性可用——移動互聯網時代的一秒響應祕訣
發這麼多紅包 微信IT架構爲啥沒崩潰？
高可用性
騰訊大講堂：發10億個紅包，微信爲啥沒崩潰？
關於柔性可用的一些思考