摘要：四應(yīng)對(duì)流量爆發(fā)的架構(gòu)調(diào)整隨著用戶量并發(fā)量數(shù)據(jù)量越來(lái)越大，后端一些架構(gòu)在可用性負(fù)載均衡和數(shù)據(jù)量上都有一些挑戰(zhàn)。本文根據(jù)舉辦的期間楊福川先生對(duì)沈劍老師的采訪整理原創(chuàng)首發(fā)，轉(zhuǎn)載或節(jié)選內(nèi)容前需獲授權(quán)。感謝楊福川對(duì)采訪工作的支持。

一、APP架構(gòu)與WEB架構(gòu)的最大不同
移動(dòng)APP的架構(gòu)和傳統(tǒng)PC的WEB架構(gòu)有三點(diǎn)不同：
1、連接的穩(wěn)定性。在傳統(tǒng)的web端連接成功后就可以認(rèn)為它是穩(wěn)定的，但在移動(dòng)端、無(wú)線端，APP連接非常敏感，可能進(jìn)出電梯、隧道、地鐵，連接就會(huì)斷，所以連接的穩(wěn)定性是很顯著的區(qū)別，也是很大的挑戰(zhàn)。
2、流量的敏感性。傳統(tǒng)PC和web的應(yīng)用架構(gòu)可能不太關(guān)注數(shù)據(jù)量、流量，但移動(dòng)端、無(wú)線端，流量有限，用戶非常關(guān)注。所以在架構(gòu)和協(xié)議設(shè)計(jì)以及數(shù)據(jù)上，要給予非常重點(diǎn)的關(guān)注。
3、消息的可達(dá)性。在PC和web端一般認(rèn)為消息發(fā)出就能夠收到，而APP可能連接不穩(wěn)，消息發(fā)出去收不到。無(wú)線端在消息的可達(dá)性問(wèn)題上，需要在架構(gòu)上額外做一些事情來(lái)保證。

二、58在APP穩(wěn)定性的優(yōu)化實(shí)踐
現(xiàn)在用的最多的協(xié)議一般是兩種，一種是HTTP協(xié)議，一種是TCP的協(xié)議。?58這邊主要是有兩塊優(yōu)化：
一是針對(duì)HTTP的協(xié)議。HTTP傳統(tǒng)的方式是發(fā)一個(gè)HTTP請(qǐng)求，先要進(jìn)行一次DNS的解析，由域名解析出IP，然后根據(jù)這個(gè)IP訪問(wèn)一個(gè)Nginx，再把它轉(zhuǎn)發(fā)到對(duì)應(yīng)的后端Web?service上，這個(gè)過(guò)程對(duì)DNS敏感要求很高，同時(shí)它的路徑比較長(zhǎng)，需要經(jīng)過(guò)Nginx的轉(zhuǎn)發(fā)。在PC上這個(gè)架構(gòu)是完全沒(méi)有問(wèn)題的，但如果到了移動(dòng)端可能流程或處理時(shí)間上就過(guò)長(zhǎng)了。
因此我們針對(duì)http做的優(yōu)化是使用IP直連的方式：不使用域名，直接使用IP去連接，既避免了DNS解析，也減少了一次轉(zhuǎn)發(fā)，用來(lái)提高穩(wěn)定性，降低處理時(shí)間。
第二是TCP，傳統(tǒng)PC和WEB的應(yīng)用中，TCP與用戶后端綁定得非常緊密，一旦TCP斷開的話，它的session可能就清除掉了，你再次連接上需要走登陸的流程，成本非常高。WEB出現(xiàn)這種情況的概率小，但在APP端，無(wú)線不穩(wěn)、網(wǎng)絡(luò)環(huán)境不穩(wěn)時(shí)經(jīng)常斷線，如果每次都重新建立session的話，可能耗電量和數(shù)據(jù)量都非常大。
因此我們針對(duì)TCP做的優(yōu)化是將TCP和session進(jìn)行解耦。TCP斷開的時(shí)候，session不進(jìn)行清除而是繼續(xù)保持，讓用戶感覺(jué)不到斷開，我們后端可能有一些機(jī)制探測(cè)出來(lái)，然后偷偷連上，這個(gè)過(guò)程對(duì)于用戶來(lái)說(shuō)是無(wú)感知的。

三、58在降低使用流量消耗方面的優(yōu)化實(shí)踐
我們采取了一些技術(shù)手段來(lái)降低流量的傳輸。舉個(gè)例子，登陸一個(gè)APP的過(guò)程中，傳統(tǒng)方式可能要從服務(wù)端拉取很多數(shù)據(jù)，比如微信、QQ登錄時(shí)要拉取好友數(shù)據(jù)、群組數(shù)據(jù)、詳細(xì)信息數(shù)據(jù)等；APP端也需要拉取這些數(shù)據(jù)。
其實(shí)并不是每次都需要重復(fù)拉取這些數(shù)據(jù)——用戶登陸之后，本地已經(jīng)存儲(chǔ)了一些歷史數(shù)據(jù)，我們只要從服務(wù)端拉取那些增量變化的，而沒(méi)有變化的則可以直接使用本地?cái)?shù)據(jù)。
我們使用了一些機(jī)制從服務(wù)端拉取變化的最新數(shù)據(jù)以減少數(shù)據(jù)量的傳輸。這是我們使用的方法，希望給同行有所借鑒。

四、58應(yīng)對(duì)流量爆發(fā)的架構(gòu)調(diào)整
隨著用戶量、并發(fā)量、數(shù)據(jù)量越來(lái)越大，后端一些架構(gòu)在可用性、負(fù)載均衡和數(shù)據(jù)量上都有一些挑戰(zhàn)。
1、高可用性，任何一臺(tái)服務(wù)器宕機(jī)都不能影響服務(wù)的可用。解決可用性的問(wèn)題方向是進(jìn)行冗余。如果只有一份服務(wù)，那么它掛了的話可行性就會(huì)受到影響；如果有多份服務(wù)，就算掛了，也可以通過(guò)負(fù)載均衡或者一些導(dǎo)流的方式來(lái)保證服務(wù)可用。所以站點(diǎn)的可用性就是冗余站點(diǎn)；服務(wù)、數(shù)據(jù)也是這樣。這是可用性上的一些調(diào)整。
2、負(fù)載均衡，在接入層用一些傳統(tǒng)的負(fù)載均衡方式，在服務(wù)層依托連接池，在數(shù)據(jù)層用數(shù)據(jù)庫(kù)的連接值的負(fù)載均衡方式來(lái)保證負(fù)載均衡。
3、非常大的數(shù)據(jù)量對(duì)架構(gòu)也是極大的挑戰(zhàn)，本來(lái)在數(shù)據(jù)層可以選擇根據(jù)業(yè)務(wù)進(jìn)行垂直拆分，但數(shù)據(jù)量大的話就必須進(jìn)行水平拆分，用一些拆分的方式來(lái)保證大數(shù)據(jù)量下依然能夠響應(yīng)很高的并發(fā)和請(qǐng)求。

五、成為架構(gòu)師的2個(gè)能力
我在最開始也沒(méi)有非常明確的要在幾年內(nèi)成長(zhǎng)為架構(gòu)師的規(guī)劃，只是不斷地解決現(xiàn)實(shí)項(xiàng)目和系統(tǒng)中的問(wèn)題，然后慢慢接觸越來(lái)越多的架構(gòu)、業(yè)務(wù)和系統(tǒng)，不斷解決問(wèn)題，不斷學(xué)習(xí)和提高。
我給一些想成為架構(gòu)師的同學(xué)的建議：
第一，一定要落地在一線。在一線了解項(xiàng)目業(yè)務(wù)中出現(xiàn)了哪些問(wèn)題，然后解決它們，在解決問(wèn)題的過(guò)程中能力范圍實(shí)際是不斷提高和成長(zhǎng)的。我不具體舉例使用什么樣的架構(gòu)或者工具和知識(shí)，反正在解決問(wèn)題的過(guò)程中肯定會(huì)接觸和學(xué)習(xí)到不同的知識(shí)和工具以及相關(guān)的技術(shù)。
第二，一定要貼近業(yè)務(wù)。我的觀點(diǎn)是任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓?？赡苡行┕景l(fā)展到后期有一些為了架構(gòu)而架構(gòu)的技術(shù)方案，目的可能不單純，為了晉升或者是怎么樣。但實(shí)際上，一旦脫離業(yè)務(wù)，技術(shù)和架構(gòu)都是空談。
總而言之，要保持一線，時(shí)刻接觸業(yè)務(wù)，這是我的兩個(gè)建議。

（本文根據(jù)msup舉辦的TOP100Summit期間楊福川先生對(duì)沈劍老師的采訪整理原創(chuàng)首發(fā)，轉(zhuǎn)載或節(jié)選內(nèi)容前需獲授權(quán)。感謝楊福川對(duì)采訪工作的支持。）

「關(guān)于沈劍」：58同城技術(shù)委員會(huì)主席，高級(jí)系統(tǒng)架構(gòu)師，產(chǎn)品技術(shù)學(xué)院優(yōu)秀講師。負(fù)責(zé)過(guò)58同城即時(shí)通訊，支付系統(tǒng)重構(gòu)，攤銷系統(tǒng)重構(gòu)，數(shù)據(jù)庫(kù)中間件，58同城推薦系統(tǒng)，58同城商戶平臺(tái)App等多個(gè)系統(tǒng)與項(xiàng)目的設(shè)計(jì)、實(shí)現(xiàn)與重構(gòu)，現(xiàn)在負(fù)責(zé)58同城C2C技術(shù)部門。