[[351519]]

本文轉(zhuǎn)載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽。轉(zhuǎn)載本文請聯(lián)系虞大膽的嘰嘰喳喳公眾號。  

最近我們直播可能要邀請一個明星，據(jù)說帶來的在線人數(shù)比較高。

聽到這個事情，我的第一反應(yīng)不是直播系統(tǒng)本身的壓力，反而是整個系統(tǒng)的壓力，因為有人看直播，必須注冊、登陸、進入直播間，這些流量帶來的壓力不是很好評估。

解決復(fù)雜問題的第一步就是分解問題，所以可以先專注直播系統(tǒng)本身，至少要讓它健壯的運行。

對于直播，分為兩部分，核心推拉流用的第三方的，暫時忽略;第二部分就是一些輔助API接口(比如進入房間，在線用戶列表)，這些是需要重點衡量的。

直播系統(tǒng)API本身相對容易做容量評估，為什么呢?你把它當(dāng)作一個封閉的系統(tǒng)單元，比如開一場直播，調(diào)用了那些接口，接口調(diào)用量都可以直接grep統(tǒng)計出來，也能找到峰值，注意這個峰值可以是單接口的峰值，也可以是匯總接口的峰值，第二個指標(biāo)更有意義，可以統(tǒng)計出峰值對應(yīng)的在線用戶數(shù)，資源消耗量(流量，redis，mysql)，從而進行容量預(yù)估。

各個接口之間的調(diào)用比例是多少呢?可以取平均值(這是我這次學(xué)習(xí)到的)，比如在線用戶接口平均每秒是10次，進入房間接口平均每秒1次，通過這種關(guān)系，大概明確了什么接口對系統(tǒng)的影響更大，什么接口響應(yīng)時間較慢。

這種接口調(diào)用比例實際上對真實的壓測非常有意義。

那為什么現(xiàn)在沒有統(tǒng)計出呢?核心原因在于資源使用目前是耦合的，所以暫且拋開系統(tǒng)壓測和容量預(yù)估部署，解決復(fù)雜問題最好的方法就是隔離、隔離。

隔離的好處是什么?互不影響;更方便的統(tǒng)計;進一步衡量系統(tǒng)的健壯性。

首先考慮web服務(wù)器，就是阿里云ECS，直播系統(tǒng)的高峰是可控的，比如知道那個明顯要來了，也許高峰期可能就2小時，所以采用按量付費的ECS非常合適，1小時不到2元。

乘著這次機會重新安裝了一臺web服務(wù)器(包括所需要的軟件)，然后做了個鏡像，再申請ECS的時候就可以直接選擇這個現(xiàn)成的鏡像，非常方便，如果不考慮現(xiàn)在更流行的docker&k8s，這種云服務(wù)的可擴展性也是讓人很驚嘆的。

當(dāng)然這種方式不是說秒級就能擴容，還是有很多細(xì)節(jié)的問題，比如預(yù)先并不知道新申請服務(wù)器的ip地址，掛載到slb的時候，也要手動配置。

雖然阿里云也有云服務(wù)API(不用登陸控制臺)，可以通過程序控制ECS的啟動，配置，但目前至少我們可以不采用，畢竟前提是我們知道直播高峰期什么時候來，可以提前做準(zhǔn)備。

其次考慮SLB，這次把直播SLB也剝離出來了，原來我傾向購買包年包月的實例，有兩點原因。

1：官方說包年包月峰值帶寬更有保障。2：如果一個業(yè)務(wù)平時訪問畢竟均勻，使用包年包月成本更低。

但我們業(yè)務(wù)突飛猛進，動不動就能一個峰值，而為了這個峰值，需要購買更高流量包(包年包月)，確實比較耗費成本。

最終選擇直播SLB購買按量付費，成本可控，而且非高峰期也可以回收，使用原有SLB，這個過程能夠自動化就更好了。

然后是數(shù)據(jù)庫，直播系統(tǒng)本身使用的數(shù)據(jù)存儲量并不高，所以暫時沒有使用阿里云RDS，使用自建且獨立的mysql 5.7，不知道其他公司是如何的，從成本角度考慮，自建mysql和阿里云RDS可以并行存在。

最后就是Redis，隔離Redis也很簡單，如果直播業(yè)務(wù)是將redis當(dāng)緩存使用，或者redis數(shù)據(jù)也會同步到mysql，那么購買按量付費的redis也是比較合適的。

選擇何種規(guī)格的redis，建議關(guān)注連接數(shù)，只是目前還沒有找到峰值和redis連接數(shù)之間的關(guān)系。

對于高峰，首先要做壓測，其次要做容量評估，接著是隔離，最后是應(yīng)用層優(yōu)化。

對于應(yīng)用層優(yōu)化要持續(xù)做，原因很簡單，優(yōu)化一小步，成本就會減少很多，系統(tǒng)的支撐能力就會變大。

遇到一個問題，我的第一反映就是先優(yōu)化，本質(zhì)上是沒有錯誤的，但是優(yōu)化的成本要小于優(yōu)化的效果，至少別影響業(yè)務(wù)開發(fā)，經(jīng)驗告訴我們，在初期，優(yōu)化的效果是很明顯的。

三板斧：減少接口調(diào)用，數(shù)據(jù)緩存化，策略優(yōu)化(結(jié)合需求)。

后面還會再寫兩篇，理理思路。