背景
隨着業務的逐步發展，系統的部署結構也是會跟着演進的。
正常來說，會經歷下面幾個階段。
階段一
業務初期，沒有什么數據量和訪問量，這個時候往往是單機部署，快速應對業務的迭代。
雖然是單機，相信大部分還是會把數據庫和應用獨立開的。
階段二
業務快速發展，訪問量和數據量開始大了起來，一台機器的瓶頸慢慢的出來的，這個時候就會考慮引入反向代理來實現負載均衡。
也就是我們最常說的堆機器。
階段三
業務高速發展，訪問量和數據量成倍上升，單個反向代理壓力也逐步上來了，需要多個反向代理來分擔壓力，這個時候會引入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，分擔了部分請求壓力。
那么接下來就看看這個雙活具體怎么弄吧。