《頁游運維“摸爬滾打”那些年~》要點:
本文介紹了頁游運維“摸爬滾打”那些年~,希望對您有用。如果有疑問,可以聯(lián)系我們。
業(yè)界運維圈子的童鞋都有這么個共識,運維真是一種苦逼的生活了,不僅繁雜多樣變幻多端,整個生態(tài)鏈涉及網(wǎng)絡(luò)、系統(tǒng)、安全、數(shù)據(jù)庫等戰(zhàn)線極長極長,關(guān)鍵在其中某些環(huán)節(jié),還有Ta在不斷的搞事,搞事,搞事,(神馬骨干波動、神馬機房被攻擊、神馬開發(fā)誤操作刪庫了)實在是苦的一逼,看慣了高大上的技術(shù),今天我們轉(zhuǎn)換下眼球,嘮一嘮基層大眾農(nóng)民工曾經(jīng)苦澀的那些年—運維前一代的些許無奈及改進(jìn)優(yōu)化之路.
相信各位盆友在搬磚的過程中,肯定也遇到讓你很藍(lán)瘦香菇而又無能為力的事吧,比如咱們即將要闡述的主題,曾經(jīng)一度讓小學(xué)畢業(yè)的俺很受傷,也很懵逼,甚至痛苦到懷疑人生.下面我們正經(jīng)的來瞅瞅,到底是啥玩意這么犀利.
2.1.1 DDos攻擊
ddos攻擊是最讓人頭痛的問題,大流量的DDOS攻擊,會導(dǎo)致機房出口被堵,嚴(yán)重影響游戲業(yè)務(wù)正常訪問,下面是被擼的一些情形:
在兩三年前,針對ddos攻擊,我們只能依靠機房本身的綜合實力,除此之外,沒有其它好的辦法,只有干瞪眼的份,好一點的機房會有一些措施,如:
而現(xiàn)在,如果攻擊者攻擊的是自有項目服務(wù)器,咱們可以通過以下的方式進(jìn)行嘗試防護
當(dāng)然,還有其它的方式,比如之前公眾號提到的,安裝輕量型DDos防護工具-Dshield,可能也可以起到一定的作用,但如果攻擊流量規(guī)模達(dá)幾十G,還是得架構(gòu)、CDN分流、第三方云盾來著手.
2.2.1 更新/合服斷線問題
更新合服操作方式老套,很low的在機器上面跑ssh并發(fā)腳本進(jìn)行更新維護,若出現(xiàn)網(wǎng)絡(luò)抖動,則更新合服操作等都會因此而中斷,特別是如果剛好是進(jìn)行數(shù)據(jù)庫的處理時,那就比較尷尬了,將需要重新恢復(fù)數(shù)據(jù)然后再進(jìn)行處理.
優(yōu)化改進(jìn)
使用salt替代原始的上機器跑并發(fā)腳本的方式,防止網(wǎng)絡(luò)中斷所引起的更新問題,當(dāng)因網(wǎng)絡(luò)抖動而重新連接機器時,可使用salt-run jobs 來查看任務(wù)執(zhí)行情況,如:
當(dāng)然salt博大精深,這邊介紹的只是其中的一個點,想進(jìn)一步了解的盆友,可參加官網(wǎng)或者本公眾號文章“saltstack的取經(jīng)之路”,反正俺的感覺是自從用上了salt,發(fā)現(xiàn)腰不酸了,腿不疼了,搬磚也更有勁了,心情瞬間舒暢了許多,幸福感飆升呀,salt你值得擁有的.
2.2.2 批量裝服
經(jīng)歷過頁游時代的小伙伴應(yīng)該有同感,當(dāng)頁游開服量逐漸增大時,會給運維效率帶來了極大的挑戰(zhàn),傳統(tǒng)的一個一個服部署的方式已經(jīng)不能滿足日常的運維要求,如下面此款游戲的日開服量達(dá)到70+,按傳統(tǒng)的方式部署的話,莫非這是要通宵部署的節(jié)奏,什么,要通宵?感覺整個人都不好了,反正咱內(nèi)心是拒絕的.
優(yōu)化改進(jìn)
為滿足日益嚴(yán)峻的運維需求,我們優(yōu)化了部署方式,總體思路為:通過采集數(shù)據(jù),達(dá)到自動推薦服務(wù)器群集的功能,從而實現(xiàn)批量部署.
自動推薦群組的兩個基本閥值是群組字段中的“最低內(nèi)存”和“最低CPU”
自動推薦群組的功能:藍(lán)海后臺系統(tǒng)每天凌晨零點到客戶端進(jìn)行一次服務(wù)器性能數(shù)據(jù)采集,而客戶端數(shù)據(jù)采集核心參考如下:
通過上面信息采集與分析,從而實現(xiàn)如下圖樣的批量部署界面圖,部署完幾十上百個區(qū)服也只是分分鐘的事,動動鼠標(biāo)就可以,So easy .
2.2.3 域名重新解析
頁游開服量逐漸增大,帶來的必然是合服量也日常增大,如下圖某游戲的日合服量將近80,如果是用A記錄解析的域名,則在合服時將面臨著大量域名重新解析的問題
?
手動的人工解析,二十只手腳指一起忙活,估計也是累的夠嗆,可能還不能滿足需求,咱們可是集網(wǎng)絡(luò)、系統(tǒng) 、開發(fā)于一身的高質(zhì)量高學(xué)歷的“復(fù)合性人才”,怎么可以做這么low的事呢,那必須不行啊,這是不符合身份的
優(yōu)化改進(jìn)
開發(fā)自動化域名解析后臺,實現(xiàn)海量域名自動化自助化的批量解析
除此之外,也可通過整改游戲架構(gòu)的方式,統(tǒng)一前端入口,把所有前端集合在一臺或者多臺機器上面,當(dāng)區(qū)服被合服時,源服的前端直接軟鏈到目標(biāo)服,從而實現(xiàn)訪問源機會自動連接目標(biāo)服的結(jié)果,規(guī)避掉重新解析域名,如下圖:
當(dāng)然還可以以cname 的方式解析,但cname方式同樣是需要重新解析一遍,并且隨著合服次數(shù)的增多,某目標(biāo)服存在多次合服的可能,這樣cname重數(shù)多了,可能會引起問題,不確定喲.
2.3.1 BGP轉(zhuǎn)發(fā)
游戲玩家分布全國各地,而國內(nèi)網(wǎng)絡(luò)錯綜復(fù)雜,會存在因為種種網(wǎng)絡(luò)問題導(dǎo)致部分玩家連不上游戲gateway的端口,像一些小運營商網(wǎng)絡(luò)的玩家,因為本身網(wǎng)絡(luò)運營商的原因,我們會不可控,眼睜睜的看著玩家流失.再加上時不時的南北骨干網(wǎng)絡(luò)抽風(fēng)一下,站在技術(shù)小白玩家的角度來說,會造成極差的體驗,最后就是玩家會說:“怪我咯?肯定都是你們的錯了.”
優(yōu)化改進(jìn)
選用優(yōu)質(zhì)網(wǎng)絡(luò)的BGP機房部署中轉(zhuǎn)服務(wù)器,結(jié)合客戶端的邏輯判斷處理,如果玩家連接不上游戲服gateway的端口則嘗試通過中轉(zhuǎn)機器進(jìn)行重連,以增大游戲聯(lián)通率.通過我們最新的定制策略,大概可以挽回10%左右用戶的游戲體驗.
2.3.2 APM實時地域性監(jiān)控報警
以前沒有APM時,當(dāng)玩家登錄異常報障,往往需要玩家配合幫忙收集信息才能定位問題,特別是手游時代更是繁瑣,例如需要安裝DNS&Ping軟件啥的,加上大世界手游產(chǎn)品模塊架構(gòu)本身就相對復(fù)雜,玩家到游戲的整個邏輯交互過程不透明,若是發(fā)生區(qū)域性網(wǎng)絡(luò)問題,那就更坑爹了,巨耗時間不說,吃力也不討好呀.
優(yōu)化改進(jìn)
開發(fā)APM性能監(jiān)控后臺,把玩家連接游戲的整個邏輯交互過程數(shù)據(jù)化、透視化.
具體的思路為:跟手游客戶端研發(fā)協(xié)商,把游戲內(nèi)部的邏輯交互埋點打日志,通過接口統(tǒng)一上報至APM后臺,APM后臺主要做web可視化呈現(xiàn).這樣既能準(zhǔn)確、有效地定位異常問題,也能為研發(fā)、運維、運營提供優(yōu)化指標(biāo).
上述問題及優(yōu)化來源于我們的“錯題本”的歸納與總結(jié),都是曾經(jīng)的血淚史,若對你產(chǎn)生點點作用,請不吝點贊打賞,哈哈,最后 我們走的可能不快,但我們一直在進(jìn)步,just do it,肯定有一份收獲屬于你.干了這碗毒雞湯,繼續(xù)搬磚了,哎媽,骨干又抽了……
原文來自微信公眾號:運維軍團
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/4263.html