開發(fā)APP在什么情況下架構(gòu)需要分布式部署 ？
分布式部署階段研發(fā)任務(wù)依然很重，架構(gòu)特點是原有的單機部署架構(gòu)已經(jīng)不足以支撐業(yè)務(wù)的發(fā)展和高性能、高可用的要求，需要考慮某些組件獨立部署、集群或分布式等架構(gòu)方案，依然優(yōu)先考慮云服務(wù)完成這些架構(gòu)方案。在這個階段，深圳APP開發(fā)公司規(guī)劃整理架構(gòu)演進如圖10-15所示。
APP開發(fā)分布式架構(gòu)部署示意10-15百萬級到千萬級架構(gòu)圖
在圖10-15中，新增了專門用于連接內(nèi)部服務(wù)器的ssh服務(wù)的外網(wǎng)通道，保證ssh操作隨時可用。因為隨著訪問量的增大，ssh操作和普通的用戶訪問共用一個外網(wǎng)通道在訪問量高峰期會出現(xiàn)一個問題：帶寬給其他用戶占滿了，當(dāng)運維人員需要通過ssh連接服務(wù)器根本連不上，就算運氣好勉強連入服務(wù)器，因為帶寬不足，輸入一個命令，要好久才有反應(yīng)，甚至隔會兒就中斷一下。如果這時服務(wù)器出了什么問題需要運維人員連接服務(wù)器緊急排查，卻因為帶寬不足的原因而無法連接服務(wù)器，那就沒辦法處理問題。當(dāng)然了，不一定只在這個階段才需要新
增ssh通道，運維人員如果覺得有這個必要，也可以在前階段就新增ssh通道。
同時使用多臺應(yīng)用服務(wù)器組成的應(yīng)用服務(wù)器集群，通過負載均衡ULB把用戶請求轉(zhuǎn)發(fā)到集群中的應(yīng)用服務(wù)器，提供整個集群應(yīng)對高訪問量的能力。如果有更大的訪問量，就通過在應(yīng)用服務(wù)器集群添加更多的服務(wù)器應(yīng)對訪問量的壓力，使應(yīng)用服務(wù)器的負載壓力不再成為系統(tǒng)的瓶頸。負載均衡ULB的高可用由云服務(wù)提供商保證，應(yīng)用服務(wù)器集群的架構(gòu)就具備了高可用的特性。
為了保證Redis緩存擴容和保證足夠的QPS，繼續(xù)優(yōu)先使用云內(nèi)存存儲UMem服務(wù)（兼容Redis協(xié)議），而不是考慮使用Twemproxy或Codis等需要大量運維成本的分布式緩存方案。云內(nèi)存存儲UMem能滿足大多數(shù)應(yīng)有的要求，內(nèi)存空可可臥在0-500GB之句動態(tài)調(diào)整，1GB內(nèi)存的最大QPS (query per second)為4000，若發(fā)現(xiàn)當(dāng)前系統(tǒng)的QPS快到峰值，可通過升級內(nèi)存提高QPS的上限。同時云內(nèi)存存儲UMem服務(wù)通過3個方面保證了高可用。
·數(shù)據(jù)實時保存到磁盤，防止機器重啟后數(shù)據(jù)丟失。
·數(shù)據(jù)保存在主各兩臺機器中，任何臺機器上磁盤損壞數(shù)據(jù)不會丟失。
·主機宕機，系統(tǒng)會自動將各機切換為主機，整個過程幾秒內(nèi)就能完成，無須人工干預(yù)隊列服務(wù)可以繼續(xù)選擇Redis，減少運維成本．但如果需要更專業(yè)的隊列服務(wù)．APP開發(fā)愛好者可以選擇本站前面分享文章，常見的一些消息隊列產(chǎn)品”一節(jié)中介紹的隊列產(chǎn)品。
主從數(shù)據(jù)庫，也是優(yōu)先考慮使用云數(shù)據(jù)庫UDB提供的功能搭建數(shù)據(jù)庫主從架構(gòu)，其原生就支持高性能和高可用，優(yōu)點如下：
·數(shù)據(jù)庫支持主從架構(gòu)，確保線上數(shù)據(jù)安全。支持主庫或從庫備份及7天內(nèi)多時間節(jié)點備份策略，保證災(zāi)備數(shù)據(jù)安全，讓寶貴數(shù)據(jù)沒有丟失的風(fēng)險，減少了大量的運維成本，增加數(shù)據(jù)的安全性。
·支持使用SSD硬盤，針對SSD硬盤的多項硬件和軟件優(yōu)化，極大提供了數(shù)據(jù)庫的讀寫能力。
隨著業(yè)務(wù)的發(fā)展，某些數(shù)據(jù)表的規(guī)模會以幾何級增長，當(dāng)數(shù)據(jù)達到定規(guī)模的時候，查詢、讀取性能就下降得很厲害，數(shù)據(jù)庫主從的架
構(gòu)不能應(yīng)對業(yè)務(wù)上的讀寫壓力，這時架構(gòu)上要考慮分表，分表有兩種方法。
·水平拆分
·垂直拆分
當(dāng)業(yè)務(wù)不斷發(fā)展，數(shù)據(jù)庫分表后的讀寫性能也可能沒法滿足業(yè)務(wù)上的需求，這時只能采用進一步的拆分策略：分庫。用Cobar或MvCat等關(guān)系型數(shù)據(jù)的分布式處理系統(tǒng)后，分庫的架構(gòu)如圖10-16所示。
APP開發(fā)架構(gòu)分布式部署之?dāng)?shù)據(jù)庫示意10-16分表分庫的架構(gòu)圖
關(guān)于MvSQL的主從、分表、分庫等優(yōu)化策略，各位可查閱“本站APP開發(fā)知識欄目架構(gòu)優(yōu)化”一節(jié)。
如果數(shù)據(jù)庫是使用MongoDB，則可以采用其原生的副本集、分片等優(yōu)化策略，各位可查詢“本站APP開發(fā)知識欄目高可用集群”
這個階段的總結(jié)如下。
·開始考慮高性能和高可用，優(yōu)先使用云服務(wù)商提供的基礎(chǔ)組件來確保高性能和高可用，當(dāng)云服務(wù)無法滿足需求時，才考慮使用第三方開源軟件。
·繼續(xù)保持快速迭代速度。
好了，APP開發(fā)公司本文關(guān)于《開發(fā)APP在什么情況下架構(gòu)需要分布式部署 ？》就分享到這里，謝謝關(guān)注，如有需要您可以在線聯(lián)系我們客服獲取專業(yè)解答。博納網(wǎng)絡(luò)編輯整理。
