一個社交App需實現(xiàn)的功能
用戶關(guān)注的常規(guī)社交功能、活動、地理位置、探索功能、新鮮事、視頻照片分享等等，需要提供的功能不勝枚舉，所以從技術(shù)角度來說，開發(fā)者需要解決的問題也是異常復(fù)雜的。
當(dāng)一款社交App發(fā)布之初，用戶訪問量比較小，使用一臺服務(wù)器就能夠支撐全部的訪問壓力和數(shù)據(jù)存儲需求，但是互聯(lián)網(wǎng)應(yīng)用具有病毒式的傳播特點。一款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)，使得后端的服務(wù)完全無法使用，用戶體驗急劇下降。本文將會通過一個真實的案例來分享一個社交應(yīng)用如何構(gòu)建一個具備高伸縮性的后端系統(tǒng)。
社交App在最初的時候，后端架構(gòu)相對比較簡單，最初是部署在基礎(chǔ)網(wǎng)絡(luò)之上。最前面放置一臺綁定了公網(wǎng)IP的nginx服務(wù)器作負(fù)載均衡，后面放置3臺應(yīng)用服務(wù)器來負(fù)責(zé)處理所有業(yè)務(wù)上的請求，最后面搭建一臺MySQL Database數(shù)據(jù)庫。
隨著產(chǎn)品的不斷迭代、用戶數(shù)的持續(xù)增長、數(shù)據(jù)量的積累，App就需要改進自己的后端架構(gòu)，即開始構(gòu)建私有網(wǎng)絡(luò)。用戶可以使用私有網(wǎng)絡(luò)構(gòu)建自己的網(wǎng)絡(luò)拓?fù)洹獎?chuàng)建路由器和私有網(wǎng)絡(luò)，將后續(xù)加入的用于運行內(nèi)部服務(wù)的主機放置在私用網(wǎng)絡(luò)中，可以有效地和云平臺其他用戶主機，在網(wǎng)絡(luò)上實現(xiàn)100%二層隔離。主機對外開放的僅僅只有80端口，這樣系統(tǒng)安全性上多了一層保障。
在上面的架構(gòu)圖中，最前面的是防火墻，后面接負(fù)載均衡器，然后接路由器和私有網(wǎng)絡(luò)，很多互聯(lián)網(wǎng)應(yīng)用都存在讀多寫少的情況，這個比例有時可以達到8:2，所以我們首先通過引入緩存分?jǐn)倲?shù)據(jù)庫讀壓力。其次，引入負(fù)載均衡器，替換最初架構(gòu)中的nginx proxy，負(fù)責(zé)均衡器在這里其主要用于分發(fā)請求到后端多臺應(yīng)用服務(wù)器，，當(dāng)其中一臺應(yīng)用服務(wù)器掛掉，負(fù)載均衡器可以進行自動隔離。
App隨著并發(fā)訪問量和數(shù)據(jù)量不斷增大，首先想到橫向擴容Web服務(wù)。水平擴容業(yè)務(wù)服務(wù)器的前提是要保證每臺服務(wù)器都是無狀態(tài)的，將session信息下放到緩存或數(shù)據(jù)庫中存儲，保證請求被負(fù)載到任何一臺服務(wù)器可以正常處理。
從上圖中看到，在前一步「構(gòu)建私有網(wǎng)絡(luò)」之后，增加了一個新的私有網(wǎng)絡(luò)來擴展網(wǎng)絡(luò)層，這里可以利用自有映像功能，將原有的應(yīng)用服務(wù)器制作成模板，后續(xù)就可以基于這個模板快速啟動新的主機。另外可以利用Auto-scaling（自動橫向擴展）功能，根據(jù)后端服務(wù)器的負(fù)載請求，動態(tài)調(diào)整服務(wù)器的數(shù)量。
一個社交應(yīng)用的后端會提供很多服務(wù)請求接口，比如添加好友、刷新新鮮事、瀏覽頁面等，可以通過日志分析每一個接口的耗時，將耗時長但非重要業(yè)務(wù)的請求分到單獨的Web服務(wù)器上進行處理，從而給主Web服務(wù)器留出更多資源去處理關(guān)鍵業(yè)務(wù)的請求。
隨著產(chǎn)品功能的不斷迭代，業(yè)務(wù)代碼會越來越復(fù)雜，出現(xiàn)故障的可能性也在加大，當(dāng)一個局部功能出現(xiàn)問題時，都會影響整個服務(wù)的可用性。此時可以構(gòu)建面向服務(wù)的架構(gòu)，將一個完整且龐大的服務(wù)拆分為一個個的子服務(wù)，服務(wù)之間通過接口交互。如下圖所示：
社交App的服務(wù)被拆分成了四個子服務(wù)——新鮮事（News Feed）、用戶資料（Profile）、廣告（Ads）和探索（Explore），不同的服務(wù)之間通過消息通信框架（例如ZeroMQ）來進行交互。把一個大服務(wù)拆分為幾個小的子服務(wù)的好處不言而喻，主要是：
業(yè)務(wù)增長也會給數(shù)據(jù)庫帶來諸多問題，當(dāng)最初架構(gòu)中單臺數(shù)據(jù)庫（數(shù)據(jù)庫同時提供讀和寫）不足已支撐起App訪問壓力時，首先需要做數(shù)據(jù)副本Replication。市面上常見的MySQL、MongoDB等數(shù)據(jù)庫都提供Replication功能，以MySQL為例，從高層來看，Replication可分成三步：
具體實現(xiàn)該過程的第一部分就是Master記錄二進制日志。在每個事務(wù)更新數(shù)據(jù)完成之前，Master在二進制日志記錄這些改變。MySQL將事務(wù)串行的寫入二進制日志，即使事務(wù)中的語句都是交叉執(zhí)行的。在事件寫入二進制日志完成后，Master通知存儲引擎提交事務(wù)。
下一步就是Slave將Master的binary log拷貝到它自己的中繼日志。首先，Slave開始一個工作線程——I/O線程。I/O線程在Master上打開一個普通的連接，然后開始binlog dump process。Binlog dump process從Master的二進制日志中讀取事件，如果已經(jīng)跟上Master，它會睡眠并等待Master產(chǎn)生新的事件。I/O線程將這些事件寫入中繼日志。
SQL slave thread處理該過程的最后一步。SQL線程從中繼日志讀取事件，更新Slave的數(shù)據(jù)，使其與Master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會位于OS的緩存中，所以中繼日志的開銷很小。
此外，在Master中也有一個工作線程：和其它MySQL的連接一樣，Slave在Master中打開一個連接也會使得Master開始一個線程。復(fù)制過程有一個很重要的限制——復(fù)制在Slave上是串行化的，也就是說Master上的并行更新操作不能在Slave上并行操作。
對于云計算使用者來說，只需要知道數(shù)據(jù)庫的IP和端口即可進行使用。具體實現(xiàn)見下圖：
第一步要做的是擴充Slave，將單機Master變成Master+3臺Slave的架構(gòu)，而在其中的Slave上搭建一個內(nèi)網(wǎng)的負(fù)載均衡器（Load Balancer），對于最上層的Data Service來說，只要配置一個MySQL Master節(jié)點和一個LB節(jié)點即可，今后因業(yè)務(wù)變化進行增減Slave對上層來說完全是透明的。
此做法可以帶來兩個好處，第一是提高可用性，若是一臺Master出現(xiàn)錯誤，則可以提升某一臺的Slave作為Master繼續(xù)提供服務(wù)，從而保證數(shù)據(jù)可用性；第二個是分?jǐn)傋x壓力，對于一個社交App來說，讀寫分離是在數(shù)據(jù)層優(yōu)化第一步要做的事情，利用上面的架構(gòu)可以很輕易地做到將讀的請求分擔(dān)到MySQL Slave上進行查詢，而寫留給Master。但是讀寫分離時會有數(shù)據(jù)庫一致性的問題，即在數(shù)據(jù)寫至Master之后同步到Slave有一個延遲的時間，對于社交應(yīng)用來說，這是可以接受的，只要保證數(shù)據(jù)的最終一致性即可。
在上圖的最下面有一個Snapshot，即定期對數(shù)據(jù)進行冷備份，這不同于單純對MySQL Master進行復(fù)制的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)里的各個服務(wù)和組件是否正常運行，以及通過日志的信息（http access log / application log / database slow log ）分析各個服務(wù)的性能瓶頸。
下一步業(yè)務(wù)的調(diào)整要進行數(shù)據(jù)庫的分區(qū)和擴容。第一，構(gòu)建緩存集群，在開始的架構(gòu)中引用了Memcached緩存，是單機數(shù)據(jù)庫緩存。當(dāng)數(shù)據(jù)量增長，，需要把數(shù)據(jù)分散到多臺緩存服務(wù)器上，常用的是HashRing算法，好處在于不管是添加結(jié)點還是刪除結(jié)點時，只會使得少部分?jǐn)?shù)據(jù)失效。還可以引用NoSQL數(shù)據(jù)庫，這里用到了Redis把社交數(shù)據(jù)里對于關(guān)系要求不強但對查詢效率要求很高的數(shù)據(jù)從MySQL里拿到Redis里存。Redis尤其適合存儲列表類數(shù)據(jù)，比如好友關(guān)系列表、排行榜數(shù)據(jù)等。
除此以外可以考慮做數(shù)據(jù)分區(qū)對于MySQL第一步是垂直拆分，把原來單獨的數(shù)據(jù)庫按照功能模塊分別拆分成：好友新鮮事、用戶資料、廣告數(shù)據(jù)以及探索數(shù)據(jù)。對于Redis也同樣，將原來的單臺Redis按照功能模塊拆成四個，分別為：排行榜數(shù)據(jù)、好友、廣告數(shù)據(jù)、探索數(shù)據(jù)。
接下來會遇到的瓶頸是單表過大的問題，這時候我們需要做水平拆分——把一個表拆分成多個表，需要選取一個分區(qū)Key，比如對用戶表做拆分時，通常選取User ID。分區(qū)key的選擇主要是看所有的查詢語句頻繁使用哪個查詢字段，就選擇那個字段作為分區(qū)key這樣能保證大部分的查詢可以落在單個數(shù)據(jù)表上，少量沒有帶分區(qū)Key的查詢語句，可能要遍歷一遍所有切分后的數(shù)據(jù)表。
構(gòu)建完整測試服務(wù)器時需要創(chuàng)建新的路由器和私有網(wǎng)絡(luò)、獨立的網(wǎng)絡(luò)環(huán)境和帶寬資源、內(nèi)網(wǎng)GRE隧道打通路由器、VPN撥入網(wǎng)絡(luò)和SSH密鑰管理。
這個過程你可以創(chuàng)建一個包含所有系統(tǒng)服務(wù)的all-in-one的環(huán)境，將其制作成自有映像。如果后續(xù)你的團隊來新的人，需要獨立的完整開發(fā)環(huán)境，只需基于自有鏡像快速創(chuàng)建主機即可；還可以利用User Data定制化功能，在主機啟動執(zhí)行一段你上傳的腳本，來初始化環(huán)境。你可以將這兩個功能結(jié)合起來用，把所有你所需要用的服務(wù)全部安裝部署完畢后做成映像，并用User Data腳本從代碼庫里更新代碼。因為代碼的變動相對于環(huán)境的更新更加頻繁，不可能每次代碼的更新都要構(gòu)建一個新的自有鏡像。通過這種方式構(gòu)建起一個完整的測試服務(wù)器，讓每個工程師都可以有自己獨立的測試服務(wù)器。
在App發(fā)布上線時需要連到線上環(huán)境怎么辦？這兩個網(wǎng)絡(luò)本身完全100%隔離，可利用GRE隧道的功能，把兩個路由器打通，實現(xiàn)測試環(huán)境網(wǎng)絡(luò)和線上生產(chǎn)環(huán)境網(wǎng)絡(luò)的完全連通。
為了讓后端架構(gòu)更可靠和業(yè)務(wù)更穩(wěn)定，就需要實施多機房部署和混合組網(wǎng)。具體原因有以下三點：
如上所示，有三個機房，中間是QingCloud北京1區(qū)機房，負(fù)責(zé)主營業(yè)務(wù)。左邊是亞太1區(qū)機房，主要服務(wù)亞太和海外的客戶。這兩個機房都使用了QingCloud私有網(wǎng)絡(luò)部署，利用路由器，通過GRE隧道或者IPsec加密隧道的方式進行互通。如果對數(shù)據(jù)傳輸過程的安全性要求較高，可以用IPsec的方式把兩個機房相互打通，這時的訪問只能通過內(nèi)網(wǎng)IP進行訪問。右邊是辦公室機房，工程師在這個環(huán)境下進行開發(fā)。
在實現(xiàn)混合組網(wǎng)時，只要機房路由器或者網(wǎng)寬設(shè)備支持標(biāo)準(zhǔn)的GRE隧道協(xié)議、IP隧道協(xié)議，就可以將傳統(tǒng)物理世界的機房與路由器連通，并最終打通公有云環(huán)境。多機房部署通常見的方案有這些：
把主機房全套業(yè)務(wù)在異地重新構(gòu)建一遍，且不需要提供線上服務(wù)，只有在主機房出現(xiàn)故障的時候才切換到備用機房，部署相對要簡單一些。但有兩方面缺點，一是成本比較高，需要雙倍的費用且只是用來做冷備份，平時完全用不上；另外，當(dāng)主機房突然掛掉時，備用機房再起動起來提供服務(wù)，數(shù)據(jù)需要預(yù)熱，這是非常緩慢的過程，可能會出現(xiàn)服務(wù)響應(yīng)慢，甚至不能正常提供服務(wù)。
從易到難有三階段：第一，反向代理，用戶請求到第二個機房，但不做任何處理被轉(zhuǎn)向第一個機房這樣會對兩地的延時有一定的要求。第二，在第二個機房部署應(yīng)用服務(wù)器和緩存，大部分的數(shù)據(jù)請求可以從緩存中讀取，不用進行跨機房請求，但當(dāng)緩存失效時，依然落到第一個機房的數(shù)據(jù)庫去查詢。所以，這個方式不太徹底；第三，全套服務(wù)的部署，包括HTTP服務(wù)器、業(yè)務(wù)服務(wù)器、緩存和數(shù)據(jù)庫的 slave。此方式使得進入第二個機房的請求，只需要在機房內(nèi)就可以完成請求處理，速度更快，但會遇到數(shù)據(jù)一致性和緩存一致性的問題，針對這點也會有一些解決方法。除了數(shù)據(jù)同步過程中的不一致問題，還需要面對緩存。
構(gòu)建穩(wěn)定可靠的業(yè)務(wù)系統(tǒng)需要注意以下這些：
不同的業(yè)務(wù)有不同的行業(yè)屬性和特點，對于社交來講，比較典型的特點是數(shù)據(jù)量龐大、數(shù)據(jù)查詢維度多，比如查詢6月11日-7月15日在xx咖啡廳我所有好友里拍過照片的人，查詢條件包括好友維度、照片維度、地點維度、隱私狀態(tài)維度等，這時就需要合理的做數(shù)據(jù)層面的擴展。
電商的特點是定期舉辦大促銷活動，屆時會需要大量的計算資源、應(yīng)用服務(wù)器來扛流量峰值，此時可利用云計算平臺的彈性實現(xiàn)快速擴展業(yè)務(wù)，而在自己業(yè)務(wù)壓力、促銷來臨時調(diào)用API接口，及AutoScaling擴展后端計算資源。視頻業(yè)務(wù)有非常明顯的流量高峰期和低峰期，流量高峰期通常是白天或者大家晚上下班回家那段時間，晚上2點到早上6點是流量非常低的時候，可利用云計算彈性優(yōu)勢，來調(diào)用API方式調(diào)整業(yè)務(wù)帶寬資源，從而達到節(jié)省成本目的。
