完整社交APP需求分析原型設計整體架構前端后端架構

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

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

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

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

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

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

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

8、日志記錄這些改變。MySQL將事務串行的寫入二進制日志，即使事務中的語句都是交叉執(zhí)行的。在事件寫入二進制日志完成后，Master通知存儲引擎提交事務。下一步就是Slave將Master的binarylog拷貝到它自己的中繼日志。首先，Slave開始一個工作線程I/O線程。I/O線程在Master上打開一個普通的連接，然后開始binlogdumpprocess。Binlogdumpprocess從Master的二進制日志中讀取事件，如果已經(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開始一個線程。復制過程有一個很重要的限制一一復制在Slave上是串行化的，也就是說Master上的并行更新操作不能在Slave上并行操作。對于云計算使用者來說，只需要知道數(shù)據(jù)庫的IP和端口即可進行使用。具體實現(xiàn)見下圖:第一步要做的是擴充Slave,將單機Master變成Master+3臺Slave的架構，而在其中的S

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

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

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

13、eSlaveFeedMasterProfileMa&terFeedStoreProfitStaveAdsSlaveHashRingCache#1RankStoreExptoreMasterCache#2除此以外可以考慮做數(shù)據(jù)分區(qū)對于MySQL第一步是垂直拆分，把原來單獨的數(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ù)表。構建完整的測試環(huán)境構建完整測試服務器時需要創(chuàng)建新的路由器和私有網(wǎng)絡、獨立的網(wǎng)絡環(huán)境和帶寬資源、內(nèi)網(wǎng)GRE隧道打通路由器、VPN撥入網(wǎng)絡和SSH密鑰管理。MainApplication這個過程你可以創(chuàng)建一個包含所有系統(tǒng)服務的all-in-one的環(huán)境，將其制作成自有映像。如果后續(xù)你的團隊來新的人，需要獨立的完整開發(fā)環(huán)境，只需基于自有鏡像快速創(chuàng)建主機即可；還可以利用UserData定

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

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

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

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