有用標(biāo)準(zhǔn)App用戶關(guān)注的常規(guī)社交功能、活動(dòng)、地理位置、探究功能、穎事、視頻照片共享等等，需要供給的功能不勝枚舉，所以從技術(shù)角度來(lái)說(shuō)，開(kāi)發(fā)者需要解決的問(wèn)題也是特別簡(jiǎn)潔的。當(dāng)一款社交App公布之初，用戶訪問(wèn)量比較小，使用一臺(tái)效勞器就能夠支撐全部的訪問(wèn)壓力和數(shù)據(jù)存儲(chǔ)需求，但是互聯(lián)網(wǎng)應(yīng)用具有病毒式的傳播特點(diǎn)。一款A(yù)pp很可能會(huì)面臨一夜爆紅的現(xiàn)象，訪問(wèn)量和數(shù)據(jù)量在短時(shí)間內(nèi)呈現(xiàn)爆發(fā)式增長(zhǎng)，這時(shí)候會(huì)面臨的局面是每天上億PV、數(shù)百萬(wàn)增用戶和活潑用戶、流量飆升至每秒數(shù)百兆。這些對(duì)于一個(gè)只部署了簡(jiǎn)潔后端架構(gòu)的應(yīng)用來(lái)講是無(wú)法支撐的，會(huì)直接導(dǎo)致效勞器響應(yīng)緩慢甚至超時(shí)，以及在頂峰期時(shí)服務(wù)呈現(xiàn)癱瘓狀態(tài)，使得后端的效勞完全無(wú)法使用，用戶體驗(yàn)急劇下降。本文將會(huì)通過(guò)一個(gè)真實(shí)的案例來(lái)共享一個(gè)社交應(yīng)用如何構(gòu)建一個(gè)具備高伸縮性的后端系統(tǒng)。社交App最初部署的后端架構(gòu)解析社交App在最初的時(shí)候，后端架構(gòu)相比照較簡(jiǎn)潔，最初是部署在根底網(wǎng)絡(luò)之上。最前面放置一臺(tái)綁定了公網(wǎng)IP的nginx效勞器作負(fù)載均衡，后面放置3臺(tái)應(yīng)用效勞器來(lái)負(fù)責(zé)處理全部業(yè)務(wù)上的懇求，最終面搭建一臺(tái)MySQLDatabase有用標(biāo)準(zhǔn)構(gòu)建私有網(wǎng)絡(luò)App10080端口，這樣系統(tǒng)安全性上多了一層保障。有用標(biāo)準(zhǔn)在上面的架構(gòu)圖中，最前面的是防火墻，后面接負(fù)載均衡器，然后接路由器和私有網(wǎng)絡(luò)，很多互聯(lián)網(wǎng)應(yīng)用都存在讀多寫少的狀況，這個(gè)比例有時(shí)可以到達(dá)8:2，所以我們首先通過(guò)引入緩存分?jǐn)倲?shù)據(jù)庫(kù)讀壓力。其次，引入負(fù)載均衡器，替換最初架構(gòu)中的nginxproxy，負(fù)責(zé)均衡器在這里其主要用于分發(fā)懇求到后端多臺(tái)應(yīng)用效勞器，，當(dāng)其中一臺(tái)應(yīng)用效勞器掛掉，負(fù)載均衡器可以進(jìn)展自動(dòng)隔離。業(yè)務(wù)分區(qū)與擴(kuò)展App隨著并發(fā)訪問(wèn)量和數(shù)據(jù)量不斷增大，首先想到橫向擴(kuò)容Web效勞。水平擴(kuò)容業(yè)務(wù)效勞器的前提是要保證每臺(tái)效勞器都是無(wú)狀態(tài)的，將session信息下放到緩存或數(shù)據(jù)庫(kù)中存儲(chǔ)，保證懇求被負(fù)載到任何一臺(tái)效勞器可以正常處理。有用標(biāo)準(zhǔn)從上圖中看到，在前一步「構(gòu)建私有網(wǎng)絡(luò)」之后，增加了一個(gè)的私有網(wǎng)絡(luò)來(lái)擴(kuò)展網(wǎng)絡(luò)層，這里可以利用自有映像Auto-scaling〔自動(dòng)橫向擴(kuò)展〕功能，依據(jù)后端效勞器的負(fù)載懇求，動(dòng)態(tài)調(diào)整效勞器的數(shù)量。一個(gè)社交應(yīng)用的后端會(huì)供給很多效勞懇求接口，比方添加好友、刷穎事、掃瞄頁(yè)面等，可以通過(guò)日志分析每一個(gè)接口的耗時(shí)，將耗時(shí)長(zhǎng)但非重要業(yè)務(wù)的懇求分到單獨(dú)的Web效勞器上進(jìn)展處理，從而給主Web效勞器留出更多資源去處理關(guān)鍵業(yè)務(wù)的懇求。面對(duì)效勞的架構(gòu)隨著產(chǎn)品功能的不斷迭代，業(yè)務(wù)代碼會(huì)越來(lái)越簡(jiǎn)潔，消滅故障的可能性也在加大，當(dāng)一個(gè)局部功能消滅問(wèn)題時(shí)，都有用標(biāo)準(zhǔn)會(huì)影響整個(gè)效勞的可用性。此時(shí)可以構(gòu)建面對(duì)效勞的架構(gòu)，將一個(gè)完整且浩大的效勞拆分為一個(gè)個(gè)的子效勞，效勞之間通過(guò)接口交互。如以以下圖所示：社交App的效勞被拆分成了四個(gè)子效勞——穎事〔NewsFeed〕、用戶資料〔Profile〕、廣告〔Ads〕和探究〔Explore〕，不同的效勞之間通過(guò)消息通信框架〔例如ZeroMQ〕來(lái)進(jìn)展交互。把一個(gè)大效勞拆分為幾個(gè)小的子效勞的好處不言而喻，主要是： 故障隔離：子效勞消滅故障不會(huì)影響全局，比方廣告業(yè)務(wù)消滅問(wèn)題并不會(huì)讓整個(gè)App不能使用，照舊可以查看穎事等； 獨(dú)立擴(kuò)展：每一個(gè)被拆分出的子效勞有著不同的訪問(wèn)壓力，比方穎事的調(diào)用相比一些二級(jí)頁(yè)面的用戶資料要高很多，所以前者會(huì)被安排更多的Web效勞器； 獨(dú)立部署：一個(gè)大效勞的配置因功能過(guò)多會(huì)特別簡(jiǎn)潔，一旦被拆分就可依據(jù)不同的特性需求定制配置項(xiàng)，從而提高可治理性；團(tuán)隊(duì)協(xié)作開(kāi)發(fā)：開(kāi)發(fā)者都有著自己精通的方向，從而提高開(kāi)發(fā)效率； 抽象出數(shù)據(jù)訪問(wèn)：在后續(xù)進(jìn)展數(shù)據(jù)層面〔數(shù)據(jù)庫(kù)、緩存〕擴(kuò)展時(shí)，可通過(guò)修改子效勞的DataService，實(shí)現(xiàn)對(duì)下層數(shù)據(jù)的透亮。有用標(biāo)準(zhǔn)數(shù)據(jù)庫(kù)Replication業(yè)務(wù)增長(zhǎng)也會(huì)給數(shù)據(jù)庫(kù)帶來(lái)諸多問(wèn)題，當(dāng)最初架構(gòu)中單臺(tái)數(shù)據(jù)庫(kù)〔數(shù)據(jù)庫(kù)同時(shí)供給讀和寫〕缺乏已支撐起App訪Replication。市面上常見(jiàn)的MySQL、MongoDB等數(shù)據(jù)庫(kù)都供給Replication功MySQLReplicationMaster〔binarylog〕中〔這些記錄叫做二進(jìn)制日志大事，binarylogevents〕；SlaveMasterbinarylogevents拷貝到它的中繼日志〔relaylog〕；Slave重做中繼日志中的大事，將轉(zhuǎn)變反映它自己的數(shù)據(jù)。具體實(shí)現(xiàn)該過(guò)程的第一局部就是Master記錄二進(jìn)制日志。在每個(gè)事務(wù)更數(shù)據(jù)完成之前，Master在二進(jìn)制日志記錄這些轉(zhuǎn)變。MySQL將事務(wù)串行的寫入二進(jìn)制日志，即使事務(wù)中的語(yǔ)句都是穿插執(zhí)行的。在大事寫入二進(jìn)制日志完成后，Master下一步就是Slave將Master的binarylog拷貝到它自己的中繼日志。首先，Slave開(kāi)頭一個(gè)工作線程——I/O線I/O線程在MasterbinlogdumpprocessBinlogdumpprocess從Master的二進(jìn)制日志中讀取大事，假設(shè)已經(jīng)跟上Master，它會(huì)睡眠并等待Master產(chǎn)生的大事。I/O線程將這些大事寫入中繼日志。SQLslavethread處理該過(guò)程的最終一步。SQL線程從中繼日志讀取大事，更Slave的數(shù)據(jù)，使其與Master中的數(shù)據(jù)全都。只要該線程與I/O線程保持全都，中繼日志通常會(huì)位于OS的緩存中，所以中繼日志的開(kāi)銷很小。此外，在Master中也有一個(gè)工作線程：和其它MySQL的連接一樣，Slave在Master中翻開(kāi)一個(gè)連接也會(huì)使得Master開(kāi)頭一個(gè)線程。復(fù)制過(guò)程有一個(gè)很重要的限制——復(fù)制在Slave上是串行化的，也就是說(shuō)Master上的并Slave有用標(biāo)準(zhǔn)對(duì)于云計(jì)算使用者來(lái)說(shuō)，只需要知道數(shù)據(jù)庫(kù)的IP和端口即可進(jìn)展使用。具體實(shí)現(xiàn)見(jiàn)以以下圖：第一步要做的是擴(kuò)大Slave，將單機(jī)Master變成Master+3臺(tái)SlaveSlave上搭建一個(gè)內(nèi)網(wǎng)的負(fù)載均衡器〔LoadBalancer〕，對(duì)于最上層的DataServiceMySQLMaster節(jié)點(diǎn)和一個(gè)LB節(jié)點(diǎn)即可，今后因業(yè)務(wù)變化進(jìn)展增減Slave此做法可以帶來(lái)兩個(gè)好處MasterSlave作為Master連續(xù)供給效勞，從而保證數(shù)據(jù)可用性；其次個(gè)是分?jǐn)傋x壓力，對(duì)于一個(gè)社交App來(lái)說(shuō)，讀寫分別是在數(shù)據(jù)層優(yōu)化第一步要做的事情，利用上面的架構(gòu)可以很輕易地做到將讀的懇求分擔(dān)到MySQLSlave上進(jìn)展查詢，而寫留給Master。但是讀寫分別時(shí)會(huì)有數(shù)據(jù)庫(kù)全都性的問(wèn)題，即在數(shù)據(jù)寫至Master之后同步到Slave有一個(gè)延遲的時(shí)間，有用標(biāo)準(zhǔn)對(duì)于社交應(yīng)用來(lái)說(shuō)，這是可以承受的，只要保證數(shù)據(jù)的最終全都性即可。在上圖的最下面有一個(gè)SnapshotMySQLMasterSlave，由于線上bug或誤操作會(huì)刪除Master上的數(shù)據(jù)，這時(shí)會(huì)馬上同步到slave上造成數(shù)據(jù)喪失這時(shí)冷備份Snapshot就會(huì)起到數(shù)據(jù)保護(hù)作用。運(yùn)行過(guò)程中確定需要監(jiān)控，用戶可以利用Linuxtop/iotop/df/free/netstat等工具去〔accesslog/applicationlog/databaseslowlog〕分析各個(gè)效勞的性能瓶頸。數(shù)據(jù)分區(qū)與擴(kuò)容下一步業(yè)務(wù)的調(diào)整要進(jìn)展數(shù)據(jù)庫(kù)的分區(qū)和擴(kuò)容。第一，構(gòu)建緩存集群，在開(kāi)頭的架構(gòu)中引用了Memcached緩存，是單機(jī)數(shù)據(jù)庫(kù)緩存。當(dāng)數(shù)據(jù)量增長(zhǎng)，，需要把數(shù)據(jù)分散到多臺(tái)緩存效勞器上，常用的是HashRing算法，好處在于不管是添加結(jié)點(diǎn)還是刪除結(jié)點(diǎn)時(shí)，只會(huì)使得少局部數(shù)據(jù)失效。還可以引用NoSQL數(shù)據(jù)庫(kù)，這里用到了Redis把社交數(shù)據(jù)里對(duì)于關(guān)系要求不強(qiáng)但對(duì)查詢效率要求很高的數(shù)據(jù)從MySQL里拿到Redis里存。Redis尤其適合存儲(chǔ)列表類數(shù)據(jù)，比方好友關(guān)系列表、排行榜數(shù)據(jù)等。有用標(biāo)準(zhǔn)除此以外可以考慮做數(shù)據(jù)分區(qū)對(duì)于MySQL第一步是垂直拆分，把原來(lái)單獨(dú)的數(shù)據(jù)庫(kù)依據(jù)功能模塊分別拆分成：好友穎事、用戶資料、廣告數(shù)據(jù)以及探究數(shù)據(jù)。對(duì)于Redis也同樣，將原來(lái)的單臺(tái)Redis依據(jù)功能模塊拆成四個(gè)，分別為：排行榜數(shù)據(jù)、好友、廣告數(shù)據(jù)、探究數(shù)據(jù)。區(qū)Key，比方對(duì)用戶表做拆分時(shí)，通常選取UserID。分區(qū)key的選擇主要是看全部的查詢語(yǔ)句頻繁使用哪個(gè)查詢字段，就選擇那個(gè)字段作為分區(qū)key這樣能保證大局部的查詢可以落在單個(gè)數(shù)據(jù)表上，少量沒(méi)有帶分區(qū)Key的查詢語(yǔ)句，可能要遍歷一遍全部切分后的數(shù)據(jù)表。有用標(biāo)準(zhǔn)構(gòu)建完整的測(cè)試環(huán)境構(gòu)建完整測(cè)試效勞器時(shí)需要?jiǎng)?chuàng)立的路由器和私有網(wǎng)絡(luò)、獨(dú)立的網(wǎng)絡(luò)環(huán)境和帶寬資源、內(nèi)網(wǎng)GRE隧道打通路由器、VPNSSH這個(gè)過(guò)程你可以創(chuàng)立一個(gè)包含全部系統(tǒng)效勞的all-in-oneUserData定制化功能，在主機(jī)啟動(dòng)執(zhí)行一段你上傳的腳本，來(lái)初始化環(huán)境。你可以將這兩個(gè)功能結(jié)合起來(lái)用，把全部你所需要用的效勞全部安裝有用標(biāo)準(zhǔn)部署完畢后做成映像，并用UserData腳本從代碼庫(kù)里更代碼。由于代碼的變動(dòng)相對(duì)于環(huán)境的更更加頻繁，不行能每次代碼的更都要構(gòu)建一個(gè)的自有鏡像。通過(guò)這種方式構(gòu)建起一個(gè)完整的測(cè)試效勞器，讓每個(gè)工程師都可以有自己獨(dú)立的測(cè)試效勞器。在App公布上線時(shí)需要連到線上環(huán)境怎么辦？這兩個(gè)網(wǎng)絡(luò)本身完全100%隔離，可利用GRE隧道的功能，把兩個(gè)路由器打通，實(shí)現(xiàn)測(cè)試環(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)。具體緣由有以下三點(diǎn)： 異地容災(zāi)：在簡(jiǎn)潔的網(wǎng)絡(luò)環(huán)境下，機(jī)房可能會(huì)消滅網(wǎng)絡(luò)狀況，導(dǎo)致一些比較關(guān)鍵性的業(yè)務(wù)的可用性降低，備份機(jī)房后可保證效勞不會(huì)消滅明顯的長(zhǎng)時(shí)間中斷；負(fù)載分?jǐn)偅簡(jiǎn)为?dú)一個(gè)機(jī)房可能缺乏以支撐全部的懇求，這時(shí)可以把一局部的懇求壓力分擔(dān)到另一個(gè)機(jī)房； 加速區(qū)域訪問(wèn)：在國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下，南方和北方相互之間網(wǎng)絡(luò)訪問(wèn)時(shí)有較高的延遲。通過(guò)做多機(jī)房部署實(shí)現(xiàn)加速區(qū)域用戶的訪問(wèn)。有用標(biāo)準(zhǔn)如上所示，有三個(gè)機(jī)房，中間是QingCloud北京1區(qū)機(jī)房，負(fù)責(zé)主營(yíng)業(yè)務(wù)。左邊是亞太1區(qū)機(jī)房，主要效勞亞太和海外的客戶。這兩個(gè)機(jī)房都使用了QingCloud私有網(wǎng)絡(luò)部署，利用路由器，通過(guò)GRE隧道或者IPsec加密隧道的方式進(jìn)展互通。假設(shè)對(duì)數(shù)據(jù)傳輸過(guò)程的安全性要求較高，可以用IPsec的方式把兩個(gè)機(jī)房相互打通，這時(shí)的訪問(wèn)IP在實(shí)現(xiàn)混合組網(wǎng)時(shí)，只要機(jī)房路由器或者網(wǎng)寬設(shè)備支持標(biāo)準(zhǔn)的GRE隧道協(xié)議、IP隧道協(xié)議，就可以將傳統(tǒng)物理世界的機(jī)房與路由器連通，并最終打通公有云環(huán)境。多機(jī)房部署通常見(jiàn)的方案有這些：異地冷備份另外，當(dāng)主機(jī)房突然掛掉時(shí)，備用機(jī)房再起動(dòng)起來(lái)供給效勞，數(shù)據(jù)需要預(yù)熱，這是格外緩慢的過(guò)程，可能會(huì)消滅服務(wù)響應(yīng)慢，甚至不能正常供給效勞。有用標(biāo)準(zhǔn)異地多活從易到難有三階段：第一，反向代理，用戶懇求到其次個(gè)機(jī)房，但不做任何處理被轉(zhuǎn)向第一個(gè)機(jī)房這樣會(huì)對(duì)兩地的延時(shí)有確定的要求。其次，在其次個(gè)機(jī)房部署應(yīng)用效勞器和緩存，大局部的數(shù)據(jù)懇求可以從緩存中讀取，不用進(jìn)展跨機(jī)房懇求，但當(dāng)緩存失效時(shí)，照舊落到第一個(gè)機(jī)房的數(shù)據(jù)庫(kù)去查詢。所以，這個(gè)方式不太徹底；第三，全套效勞的部署，包括效勞器、業(yè)務(wù)效勞器、緩存和數(shù)據(jù)庫(kù)的slave。此方式使得進(jìn)入其次個(gè)機(jī)房的懇求，只需要在除了數(shù)據(jù)同步過(guò)程中的不全都問(wèn)題，還需要面對(duì)緩存。好的系統(tǒng)架構(gòu)不是設(shè)計(jì)出來(lái)的，而是進(jìn)化而來(lái)的構(gòu)建穩(wěn)定牢靠的業(yè)務(wù)系統(tǒng)需要留意以下這些：分析用戶行為，理解你的業(yè)務(wù)，如社交、電商、視頻；不同的業(yè)務(wù)有不同的行業(yè)屬性和特點(diǎn)，對(duì)于社交來(lái)講，比較典型的特點(diǎn)是數(shù)據(jù)量浩大、數(shù)據(jù)查詢維度多，比方查詢6月11日-7月15日在xx咖啡廳我全部好友里拍過(guò)照片的人，查詢條件包括好友維度、照片維度、地點(diǎn)維度、隱私狀態(tài)維度等，這時(shí)就需要合理的做數(shù)據(jù)層面的擴(kuò)展。電商的特點(diǎn)是定期舉辦大促銷活動(dòng)，屆時(shí)會(huì)需要大量的計(jì)算資源、應(yīng)用效勞器來(lái)扛流量峰值，此時(shí)可利用云計(jì)算平臺(tái)的彈性實(shí)現(xiàn)快速擴(kuò)展業(yè)務(wù)，而在自己業(yè)務(wù)壓力、促銷降落時(shí)調(diào)用API接口，及AutoScaling擴(kuò)展后端計(jì)算資源。2點(diǎn)到早上6點(diǎn)是流量格外低的時(shí)候，可利用云計(jì)算彈性優(yōu)勢(shì)，來(lái)調(diào)用API。 合理規(guī)劃系統(tǒng)，預(yù)估系統(tǒng)容量，如1