完整社交APP需求分析原型設(shè)計(jì)整體架構(gòu)前端后端架構(gòu)

1、一個社交App需實(shí)現(xiàn)的功能用戶關(guān)注的常規(guī)社交功能、活動、地理位置、探索功能、新鮮事、視頻照片分享等等，需要提供的功能不勝枚舉，所以從技術(shù)角度來說，開發(fā)者需要解決的問題也是異常復(fù)雜的。當(dāng)一款社交App發(fā)布之初，用戶訪問量比較小，使用一臺服務(wù)器就能夠支撐全部的訪問壓力和數(shù)據(jù)存儲需求，但是互聯(lián)網(wǎng)應(yīng)用具有病毒式的傳播特點(diǎn)。一款A(yù)pp很可能會面臨一夜爆紅的現(xiàn)象，訪問量和數(shù)據(jù)量在短時間內(nèi)呈現(xiàn)爆發(fā)式增長，這時候會面臨的局面是每天上億PV、數(shù)百萬新增用戶和活躍用戶、流量飆升至每秒數(shù)百兆。這些對于一個只部署了簡單后端架構(gòu)的應(yīng)用來講是無法支撐的，會直接導(dǎo)致服務(wù)器響應(yīng)緩慢甚至超時，以及在高峰期時服務(wù)呈現(xiàn)癱瘓狀態(tài)，使

2、得后端的服務(wù)完全無法使用，用戶體驗(yàn)急劇下降。本文將會通過一個真實(shí)的案例來分享一個社交應(yīng)用如何構(gòu)建一個具備高伸縮性的后端系統(tǒng)。社交App最初部署的后端架構(gòu)解析社交App在最初的時候，后端架構(gòu)相對比較簡單，最初是部署在基礎(chǔ)網(wǎng)絡(luò)之上。最前面放置一臺綁定了公網(wǎng)IP的nginx服務(wù)器作負(fù)載均衡，后面放置3臺應(yīng)用服務(wù)器來負(fù)責(zé)處理所有業(yè)務(wù)上的請求，最后面搭建一臺MySQLDatabase數(shù)據(jù)庫。構(gòu)建私有網(wǎng)絡(luò)隨著產(chǎn)品的不斷迭代、用戶數(shù)的持續(xù)增長、數(shù)據(jù)量的積累，App就需要改進(jìn)自己的后端架構(gòu)，即開始構(gòu)建私有網(wǎng)絡(luò)。用戶可以使用私有網(wǎng)絡(luò)構(gòu)建自己的網(wǎng)絡(luò)拓?fù)湟灰粍?chuàng)建路由器和私有網(wǎng)絡(luò)，將后續(xù)加入的用于運(yùn)行內(nèi)部服務(wù)的主機(jī)放

3、置在私用網(wǎng)絡(luò)中，可以有效地和云平臺其他用戶主機(jī)，在網(wǎng)絡(luò)上實(shí)現(xiàn)100%二層隔離。主機(jī)對外開放的僅僅只有80端口，這樣系統(tǒng)安全性上多了一層保障。在上面的架構(gòu)圖中，最前面的是防火墻，后面接負(fù)載均衡器，然后接路由器和私有網(wǎng)絡(luò)，很多互聯(lián)網(wǎng)應(yīng)用都存在讀多寫少的情況，這個比例有時可以達(dá)到8:2,所以我們首先通過引入緩存分?jǐn)倲?shù)據(jù)庫讀壓力。其次，引入負(fù)載均衡器，替換最初架構(gòu)中的nginxproxy,負(fù)責(zé)均衡器在這里其主要用于分發(fā)請求到后端多臺應(yīng)用服務(wù)器，當(dāng)其中一臺應(yīng)用服務(wù)器掛掉，負(fù)載均衡器可以進(jìn)行自動隔離。業(yè)務(wù)分區(qū)與擴(kuò)展App隨著并發(fā)訪問量和數(shù)據(jù)量不斷增大，首先想到橫向擴(kuò)容Web服務(wù)。水平擴(kuò)容業(yè)務(wù)服務(wù)器的前提是

4、要保證每臺服務(wù)器都是無狀態(tài)的，將session信息下放到緩存或數(shù)據(jù)庫中存儲，保證請求被負(fù)載到任何一臺服務(wù)器可以正常處理。從上圖中看到，在前一步構(gòu)建私有網(wǎng)絡(luò)之后，增加了一個新的私有網(wǎng)絡(luò)來擴(kuò)展網(wǎng)絡(luò)層，這里可以利用自有映像功能，將原有的應(yīng)用服務(wù)器制作成模板，后續(xù)就可以基于這個模板快速啟動新的主機(jī)。另外可以利用Auto-scaling（自動橫向擴(kuò)展）功能，根據(jù)后端服務(wù)器的負(fù)載請求，動態(tài)調(diào)整服務(wù)器的數(shù)量。一個社交應(yīng)用的后端會提供很多服務(wù)請求接口，比如添加好友、刷新新鮮事、瀏覽頁面等，可以通過日志分析每一個接口的耗時，將耗時長但非重要業(yè)務(wù)的請求分到單獨(dú)的Web服務(wù)器上進(jìn)行處理，從而給主Web服務(wù)器留出更多

5、資源去處理關(guān)鍵業(yè)務(wù)的請求。面向服務(wù)的架構(gòu)隨著產(chǎn)品功能的不斷迭代，業(yè)務(wù)代碼會越來越復(fù)雜，出現(xiàn)故障的可能性也在加大，當(dāng)一個局部功能出現(xiàn)問題時，者B會影響整個服務(wù)的可用性。此時可以構(gòu)建面向服務(wù)的架構(gòu)，將一個完整且龐大的服務(wù)拆分為一個個的子服務(wù)，服務(wù)之間通過接口交互。如下圖所示：Mg社交App的服務(wù)被拆分成了四個子服務(wù)一一新鮮事（NewsFeed）、用戶資料（Profile）、廣告（Ads）和探索（Explore）,不同的服務(wù)之間通過消息通信框架（例如ZeroMQ）來進(jìn)行交互。把一個大服務(wù)拆分為幾個小的子服務(wù)的好處不言而喻，主要是： 故障隔離：子服務(wù)出現(xiàn)故障不會影響全局，比如廣告業(yè)務(wù)出現(xiàn)問題并不會讓整

6、個App不能使用，依然可以查看新鮮事等； 獨(dú)立擴(kuò)展：每一個被拆分出的子服務(wù)有著不同的訪問壓力，比如新鮮事的調(diào)用相比一些二級頁面的用戶資料要高很多，所以前者會被分配更多的Web服務(wù)器； 獨(dú)立部署：一個大服務(wù)的配置因功能過多會異常復(fù)雜，一旦被拆分就可根據(jù)不同的特性需求定制配置項(xiàng)，從而提高可管理性； 團(tuán)隊(duì)協(xié)作開發(fā)：開發(fā)者都有著自己精通的方向，從而提高開發(fā)效率； 抽象出數(shù)據(jù)訪問：在后續(xù)進(jìn)行數(shù)據(jù)層面（數(shù)據(jù)庫、緩存）擴(kuò)展時，可通過修改子服務(wù)的DataService,實(shí)現(xiàn)對下層數(shù)據(jù)的透明。數(shù)據(jù)庫Replication業(yè)務(wù)增長也會給數(shù)據(jù)庫帶來諸多問題，當(dāng)最初架構(gòu)中單臺數(shù)據(jù)庫（數(shù)據(jù)庫同時提供讀和寫）不足已支撐起

7、App訪問壓力時，首先需要做數(shù)據(jù)副本Replication。市面上常見的MySQL、MongoDB等數(shù)據(jù)庫都提供Replication功能，以MySQL為例，從高層來看，Replication可分成三步：1. Master將改變記錄到二進(jìn)制日志（binarylog）中（這些記錄叫做二進(jìn)制日志事件，binarylogevents）;2. Slave將Master的binarylogevents拷貝到它的中繼日志（relaylog）;3. Slave重做中繼日志中的事件，將改變反映它自己的數(shù)據(jù)。具體實(shí)現(xiàn)該過程的第一部分就是Master記錄二進(jìn)制日志。在每個事務(wù)更新數(shù)據(jù)完成之前，Master在二進(jìn)制

8、日志記錄這些改變。MySQL將事務(wù)串行的寫入二進(jìn)制日志，即使事務(wù)中的語句都是交叉執(zhí)行的。在事件寫入二進(jìn)制日志完成后，Master通知存儲引擎提交事務(wù)。下一步就是Slave將Master的binarylog拷貝到它自己的中繼日志。首先，Slave開始一個工作線程I/O線程。I/O線程在Master上打開一個普通的連接，然后開始binlogdumpprocess。Binlogdumpprocess從Master的二進(jìn)制日志中讀取事件，如果已經(jīng)跟上Master,它會睡眠并等待Master產(chǎn)生新的事件。I/O線程將這些事件寫入中繼日志。SQLslavethread處理該過程的最后一步。SQL線程從中繼

9、日志讀取事件，更新Slave的數(shù)據(jù)，使其與Master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會位于OS的緩存中，所以中繼日志的開銷很小。此外，在Master中也有一個工作線程：和其它MySQL的連接一樣，Slave在Master中打開一個連接也會使得Master開始一個線程。復(fù)制過程有一個很重要的限制一一復(fù)制在Slave上是串行化的，也就是說Master上的并行更新操作不能在Slave上并行操作。對于云計(jì)算使用者來說，只需要知道數(shù)據(jù)庫的IP和端口即可進(jìn)行使用。具體實(shí)現(xiàn)見下圖:第一步要做的是擴(kuò)充Slave,將單機(jī)Master變成Master+3臺Slave的架構(gòu)，而在其中的S

10、lave上搭建一個內(nèi)網(wǎng)的負(fù)載均衡器(LoadBalancer),對于最上層的DataService來說，只要配置一個MySQLMaster節(jié)點(diǎn)和一個LB節(jié)點(diǎn)即可，今后因業(yè)務(wù)變化進(jìn)行增減Slave對上層來說完全是透明的。此做法可以帶來兩個好處，第一是提高可用性，若是一臺Master出現(xiàn)錯誤，則可以提升某一臺的Slave作為Master繼續(xù)提供服務(wù)，從而保證數(shù)據(jù)可用性；第二個是分?jǐn)傋x壓力，對于一個社交App來說，讀寫分離是在數(shù)據(jù)層優(yōu)化第一步要做的事情，利用上面的架構(gòu)可以很輕易地做到將讀的請求分擔(dān)到MySQLSlave上進(jìn)行查詢，而寫留給Master。但是讀寫分離時會有數(shù)據(jù)庫一致性的問題，即在數(shù)據(jù)寫

11、至Master之后同步到Slave有一個延遲的時間，對于社交應(yīng)用來說，這是可以接受的，只要保證數(shù)據(jù)的最終一致性即可。在上圖的最下面有一個Snapshot,即定期對數(shù)據(jù)進(jìn)行冷備份，這不同于單純對MySQLMaster進(jìn)行復(fù)制的Slave因?yàn)榫€上bug或誤操作會刪除Master上的數(shù)據(jù)，這時會立即同步到slave上造成數(shù)據(jù)丟失這時冷備份Snapshot就會起到數(shù)據(jù)保護(hù)作用。運(yùn)行過程中肯定需要監(jiān)控，用戶可以利用Linux上的工具進(jìn)行統(tǒng)計(jì)分析top/iotop/df/free/netstat等工具去監(jiān)控系統(tǒng)里的各個服務(wù)和組件是否正常運(yùn)行，以及通過日志的信息(httpaccesslog/applicat

12、ionlog/databaseslowlog)分析各個服務(wù)的性能瓶頸。數(shù)據(jù)分區(qū)與擴(kuò)容Memcached緩存,HashRing算法，好處在于下一步業(yè)務(wù)的調(diào)整要進(jìn)行數(shù)據(jù)庫的分區(qū)和擴(kuò)容。第一，構(gòu)建緩存集群，在開始的架構(gòu)中引用了是單機(jī)數(shù)據(jù)庫緩存。當(dāng)數(shù)據(jù)量增長，需要把數(shù)據(jù)分散到多臺緩存服務(wù)器上，常用的是不管是添加結(jié)點(diǎn)還是刪除結(jié)點(diǎn)時，只會使彳#少部分?jǐn)?shù)據(jù)失效。還可以引用NoSQL數(shù)據(jù)庫，這里用到了Redis把社交數(shù)據(jù)里對于關(guān)系要求不強(qiáng)但對查詢效率要求很高的數(shù)據(jù)從MySQL里拿到Redis里存。Redis尤其適合存儲列表類數(shù)據(jù)，比如好友關(guān)系列表、排行榜數(shù)據(jù)等。MasterCache#NRead/Explor

13、eSlaveFeedMasterProfileMa&terFeedStoreProfitStaveAdsSlaveHashRingCache#1RankStoreExptoreMasterCache#2除此以外可以考慮做數(shù)據(jù)分區(qū)對于MySQL第一步是垂直拆分，把原來單獨(dú)的數(shù)據(jù)庫按照功能模塊分別拆分成：好友新鮮事、用戶資料、廣告數(shù)據(jù)以及探索數(shù)據(jù)。對于Redis也同樣，將原來的單臺Redis按照功能模塊拆成四個，分別為：排行榜數(shù)據(jù)、好友、廣告數(shù)據(jù)、探索數(shù)據(jù)。接下來會遇到的瓶頸是單表過大的問題，這時候我們需要做水平拆分一一把一個表拆分成多個表，需要選取一個分區(qū)Key,比如對用戶表做拆分時，通

14、常選取UserID。分區(qū)key的選擇主要是看所有的查詢語句頻繁使用哪個查詢字段，就選擇那個字段作為分區(qū)key這樣能保證大部分的查詢可以落在單個數(shù)據(jù)表上，少量沒有帶分區(qū)Key的查詢語句，可能要遍歷一遍所有切分后的數(shù)據(jù)表。構(gòu)建完整的測試環(huán)境構(gòu)建完整測試服務(wù)器時需要創(chuàng)建新的路由器和私有網(wǎng)絡(luò)、獨(dú)立的網(wǎng)絡(luò)環(huán)境和帶寬資源、內(nèi)網(wǎng)GRE隧道打通路由器、VPN撥入網(wǎng)絡(luò)和SSH密鑰管理。MainApplication這個過程你可以創(chuàng)建一個包含所有系統(tǒng)服務(wù)的all-in-one的環(huán)境，將其制作成自有映像。如果后續(xù)你的團(tuán)隊(duì)來新的人，需要獨(dú)立的完整開發(fā)環(huán)境，只需基于自有鏡像快速創(chuàng)建主機(jī)即可；還可以利用UserData定

15、制化功能，在主機(jī)啟動執(zhí)行一段你上傳的腳本，來初始化環(huán)境。你可以將這兩個功能結(jié)合起來用，把所有你所需要用的服務(wù)全部安裝部署完畢后做成映像，并用UserData腳本從代碼庫里更新代碼。因?yàn)榇a的變動相對于環(huán)境的更新更加頻繁，不可能每次代碼的更新都要構(gòu)建一個新的自有鏡像。通過這種方式構(gòu)建起一個完整的測試服務(wù)器，讓每個工程師都可以有自己獨(dú)立的測試服務(wù)器。在App發(fā)布上線時需要連到線上環(huán)境怎么辦？這兩個網(wǎng)絡(luò)本身完全100%隔離，可利用GRE隧道的功能，把兩個路由器打通，實(shí)現(xiàn)測試環(huán)境網(wǎng)絡(luò)和線上生產(chǎn)環(huán)境網(wǎng)絡(luò)的完全連通。多機(jī)房部署與混合組網(wǎng)為了讓后端架構(gòu)更可靠和業(yè)務(wù)更穩(wěn)定，就需要實(shí)施多機(jī)房部署和混合組網(wǎng)。具體

16、原因有以下三點(diǎn)： 異地容災(zāi)：在復(fù)雜的網(wǎng)絡(luò)環(huán)境下，機(jī)房可能會出現(xiàn)網(wǎng)絡(luò)狀況，導(dǎo)致一些比較關(guān)鍵性的業(yè)務(wù)的可用性降低，備份機(jī)房后可保證服務(wù)不會出現(xiàn)明顯的長時間中斷； 負(fù)載分?jǐn)偅簡为?dú)一個機(jī)房可能不足以支撐全部的請求，這時可以把一部分的請求壓力分擔(dān)到另一個機(jī)房； 加速區(qū)域訪問：在國內(nèi)網(wǎng)絡(luò)環(huán)境下，南方和北方相互之間網(wǎng)絡(luò)訪問時有較高的延遲。通過做多機(jī)房部署實(shí)現(xiàn)加速區(qū)域用戶的訪問。如上所示，有三個機(jī)房，中間是QingCloud北京1區(qū)機(jī)房，負(fù)責(zé)主營業(yè)務(wù)。左邊是亞太1區(qū)機(jī)房，主要服務(wù)亞太和海外的客戶。這兩個機(jī)房都使用了QingCloud私有網(wǎng)絡(luò)部署，利用路由器，通過GRE隧道或者IPsec加密隧道的方式進(jìn)行互通。

17、如果對數(shù)據(jù)傳輸過程的安全性要求較高，可以用IPsec的方式把兩個機(jī)房相互打通，這時的訪問只能通過內(nèi)網(wǎng)IP進(jìn)行訪問。右邊是辦公室機(jī)房，工程師在這個環(huán)境下進(jìn)行開發(fā)。在實(shí)現(xiàn)混合組網(wǎng)時，只要機(jī)房路由器或者網(wǎng)寬設(shè)備支持標(biāo)準(zhǔn)的GRE隧道協(xié)議、IP隧道協(xié)議，就可以將傳統(tǒng)物理世界的機(jī)房與路由器連通，并最終打通公有云環(huán)境。多機(jī)房部署通常見的方案有這些： 異地冷備份把主機(jī)房全套業(yè)務(wù)在異地重新構(gòu)建一遍，且不需要提供線上服務(wù)，只有在主機(jī)房出現(xiàn)故障的時候才切換到備用機(jī)房，部署相對要簡單一些。但有兩方面缺點(diǎn)，一是成本比較高，需要雙倍的費(fèi)用且只是用來做冷備份，平時完全用不上;另外，當(dāng)主機(jī)房突然掛掉時，備用機(jī)房再起動起來提供

18、服務(wù)，數(shù)據(jù)需要預(yù)熱，這是非常緩慢的過程，可能會出現(xiàn)服務(wù)響應(yīng)慢，甚至不能正常提供服務(wù)。 異地多活從易到難有三階段：第一，反向代理，用戶請求到第二個機(jī)房，但不做任何處理被轉(zhuǎn)向第一個機(jī)房這樣會對兩地的延時有一定的要求。第二，在第二個機(jī)房部署應(yīng)用服務(wù)器和緩存，大部分的數(shù)據(jù)請求可以從緩存中讀取，不用進(jìn)行跨機(jī)房請求，但當(dāng)緩存失效時，依然落到第一個機(jī)房的數(shù)據(jù)庫去查詢。所以，這個方式不太徹底；第三，全套服務(wù)的部署，包括HTTP服務(wù)器、業(yè)務(wù)服務(wù)器、緩存和數(shù)據(jù)庫的slave。此方式使得進(jìn)入第二個機(jī)房的請求，只需要在機(jī)房內(nèi)就可以完成請求處理，速度更快，但會遇到數(shù)據(jù)一致性和緩存一致性的問題，針對這點(diǎn)也會有一些解決方法。除了數(shù)據(jù)同步過程中的不一致問題，還需要面對緩存。好的系統(tǒng)架構(gòu)不是設(shè)計(jì)出來的，而是進(jìn)化而來的構(gòu)建穩(wěn)定可靠的業(yè)務(wù)系統(tǒng)需要注意以下這些： 分析用戶行為，