基于阿裡雲做低配版的同城雙活方案
背景
随着業務的逐漸發展，系統的部署結構也是會跟着演進的。
正常來說，會經曆下面幾個階段。
階段一
業務初期，沒有什麼資料量和通路量，這個時候往往是單機部署，快速應對業務的疊代。
雖然是單機，相信大部分還是會把資料庫和應用獨立開的。
階段二
業務快速發展，通路量和資料量開始大了起來，一台機器的瓶頸慢慢的出來的，這個時候就會考慮引入反向代理來實作負載均衡。
也就是我們最常說的堆機器。
階段三
業務高速發展，通路量和資料量成倍上升，單個反向代理壓力也逐漸上來了，需要多個反向代理來分擔壓力，這個時候會引入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，分擔了部分請求壓力。
那麼接下來就看看這個雙活具體怎麼弄吧。
實戰
詳見 https://mp.weixin.qq.com/s/YYozo7V6MkJGkiVYUaWJWQ
如果您認為這篇文章還不錯或者有所收獲，可以點選右下角的【推薦】按鈕，因為你的支援是我繼續寫作，分享的最大動力！
作者：Catcher Wong ( 黃文清 )
來源：http://catcher1994.cnblogs.com/
聲明：
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。如果您發現部落格中出現了錯誤，或者有更好的建議、想法，請及時與我聯系！！如果想找我私下交流，可以私信或者加我微信。