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

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

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

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

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

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

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

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