聊一聊小團隊如何作同城雙活

基於阿里雲作低配版的同城雙活方案

背景

隨着業務的逐步發展，系統的部署結構也是會跟着演進的。

正常來講，會經歷下面幾個階段。

階段一

業務初期，沒有什麼數據量和訪問量，這個時候每每是單機部署，快速應對業務的迭代。

雖然是單機，相信大部分仍是會把數據庫和應用獨立開的。

階段二

業務快速發展，訪問量和數據量開始大了起來，一臺機器的瓶頸慢慢的出來的，這個時候就會考慮引入反向代理來實現負載均衡。

也就是咱們最常說的堆機器。

階段三

業務高速發展，訪問量和數據量成倍上升，單個反向代理壓力也逐步上來了，須要多個反向代理來分擔壓力，這個時候會引入LVS或F5來讓多個反向代理負載均衡。

階段四

在階段三種，單個機房裏面的機器已經多了不少了，萬一遇到機房出問題了，業務基本就處於不可服務的狀態了。

因此這個時候會引入DNS輪詢將請求分發給多個機房，避免單個機房故障致使業務崩潰。

這裏比較常見的就是同城雙活和異地雙活兩種。到了這一階段，其實成本就慢慢在上來了。

這個階段再日後就是異地多活了。

上面這幾個階段，應該大部分人都有過了解，不過卻不必定有過實踐。

真正實踐起來仍是會有一些坑要踩的。

老黃公司是作互聯網醫療的，雖然量級不大，可是領導對這一塊仍是挺看重的，因此咱們仍是有作一個低配版的同城雙活。

作這個的初衷也是避免單點故障問題，不想把雞蛋都放在同一個籃子裏面。

下面老黃就分享一下相關的實踐經驗吧。

對用了雲服務的狀況下，其實不少內容都簡化了。

首先是在同一個城市下面，分了不少個可用區，其實這就很好的知足了同城雙活的基本條件了。

其次，負載均衡產品都是集羣部署，避免單節點故障問題。

下面那個項目來講一下吧。

項目實戰

現狀

這個項目是部署在阿里雲上面的，因此這裏用的都是阿里雲的雲產品。

掛在一個 slb.s2.medium 規格的 SLB 上面，這個規格最大能夠支持鏈接數: 100000，新建鏈接數 (CPS): 10000，每秒查詢數 (QPS): 10000。

日均訪問量在三千萬左右，峯值QPS會去到 1.2K 往上，1.2K 的QPS會很容易達到這個規格 SLB 的瓶頸，由於這裏會很容易觸及一個雷區。

雖然規格的最大可支持數看上去很高，可是這些數字都要除以 7 纔是真正的值。7+1的模式部署，其中1是備機。

若是這個實例的 QPS 一直持續在 最大能夠支持鏈接數 / 7，就要考慮升級規格了。以前不清楚這個，從日誌服務發現不少503請求去提工單問了才知道這個雷。具體詳見文末工單內容。

這個 SLB 後面有三臺機器提供負載，大概結構以下：

這算是一個比較典型的結構方案。

再來看看引入雙活以後的：

變化不會特別大，就是在 DNS 的後面加多了一個 SLB，分擔了部分請求壓力。

那麼接下來就看看這個雙活具體怎麼弄吧。