• <ul id="t53qs"></ul>

        <strike id="t53qs"></strike>
        1. <div id="t53qs"><listing id="t53qs"></listing></div>

          聯(lián)系我們
          15608181518??? 18683438262
          歡迎進(jìn)入德天信科技(服務(wù)區(qū)域:貴陽、成都、重慶)
          網(wǎng)站/微信/小程序/APP
          1500+客戶一致的選擇
          APP開發(fā)如何才能做到支撐高并發(fā)量
          日期:2023-12-22 00:00:00

          APP開發(fā)除了在功能上滿足需求以外,在性能上也要能滿足需求。一些用戶量大,對并發(fā)量要求高的APP,在開發(fā)前就要設(shè)計(jì)好架構(gòu),在服務(wù)器硬件和系統(tǒng)軟件上,都要能支撐高并發(fā)的需求。

          image.png

          APP開發(fā)如何做到支撐高并發(fā)量

          以京東為例,618大促,京東的網(wǎng)關(guān)承載了幾十億的流量和調(diào)用,在這種情況下,網(wǎng)關(guān)系統(tǒng)必須保證整個(gè)系統(tǒng)的穩(wěn)定性和高可用,保證高性能和可靠,以支撐業(yè)務(wù)。這是一個(gè)非常復(fù)雜的問題,基于這種復(fù)雜問題,怎樣做到很好地提高它的性能和穩(wěn)定性、復(fù)雜技術(shù)之間怎么整合保證整體網(wǎng)關(guān)的高可用?

           

          網(wǎng)關(guān)系統(tǒng)主要有兩種:

          第一種叫客戶端網(wǎng)關(guān)主要用來接收一些客戶端的請求,也就是APP的服務(wù)端;

          第二種叫開放網(wǎng)關(guān),主要是公司(比如京東)對于第三方合作伙伴提供接口。

          這兩種不同網(wǎng)關(guān)所使用的技術(shù)非常類似。

           

          流量比較大的網(wǎng)關(guān)面臨的難點(diǎn)包括:

           

          第一,網(wǎng)關(guān)系統(tǒng)需要扛幾十億的流量調(diào)用,接口的平穩(wěn)運(yùn)行、每一個(gè)接口在后端服務(wù)之后的性能耗損都非常重要。比如我們使用了一個(gè)Redis集群,然后構(gòu)建了兩個(gè)機(jī)房,每一個(gè)機(jī)房都搭建了一個(gè)Redis集群,這樣的話就能夠很好地保證高可用。在面對一個(gè)瞬間流量的時(shí)候,我們采用了一些緩存技術(shù),或者更前置的Nginx+lua+Redis技術(shù),讓這種大流量應(yīng)用能夠脫離開JVM的依賴。還有我們需要梳理各個(gè)接口,通過降級的策略把一些弱依賴的接口進(jìn)行降級,從而保證核心應(yīng)用的可用。

           

          第二,網(wǎng)關(guān)系統(tǒng)其實(shí)就是一個(gè)把Http請求拓展到后端服務(wù)的過程。我們的網(wǎng)關(guān)承接了一千以上的后端服務(wù)接口,面對這種情況,怎樣做到服務(wù)與服務(wù)之間相互不影響?架構(gòu)層面怎樣能夠杜絕蝴蝶效應(yīng)、防止雪崩?就是說當(dāng)一個(gè)接口出現(xiàn)問題的時(shí)候,不至于影響到其他接口的健康運(yùn)行。這個(gè)說起來簡單,但實(shí)際卻不然。

           

          一千個(gè)以上的接口,每個(gè)接口性能都不一致,而且每個(gè)接口所依賴的外部資源、數(shù)據(jù)庫緩存等都不一樣,幾乎每天都會出現(xiàn)各種各樣的問題,我們怎樣通過一些隔離技術(shù)、治理技術(shù)等,保證當(dāng)這些接口出現(xiàn)問題的時(shí)候,不會影響到全局?

           

          第三,我們對外暴露了一千個(gè)服務(wù)接口,所有接口的后面意味著幾十個(gè)甚至上百個(gè)團(tuán)隊(duì)每天在不停地開發(fā),每天都可能上線新的需求。面對這么復(fù)雜的情況,我們不可能每次后端服務(wù)器有任何修改,都需要有網(wǎng)關(guān)的修改或上線,這樣網(wǎng)關(guān)會變得非常脆弱,穩(wěn)定性極低。

           

          我們采用了一個(gè)動態(tài)接入的技術(shù),讓后端的網(wǎng)關(guān)能夠通過一種接入的協(xié)議進(jìn)行無縫接入,之后通過一些動態(tài)代理的方式,直接讓后端的接口,不管做任何修改或上線,都可以通過后端管理平臺從網(wǎng)關(guān)上對外進(jìn)行透傳發(fā)布,很好地解決了我們網(wǎng)關(guān)所面臨的依賴于后端接口服務(wù)的上線問題。

           

          網(wǎng)關(guān)的四個(gè)技術(shù)方向:

           

          第一,統(tǒng)一接入。就是前端(包括APP或其他來源)的流量,能夠都在統(tǒng)一網(wǎng)絡(luò)層進(jìn)行接入。這一層所面臨的問題是:高性能透傳、高并發(fā)接入、高可效性,以及當(dāng)前端流量來了之后,怎樣能夠進(jìn)行一個(gè)負(fù)載的往后端的轉(zhuǎn)發(fā)。

           

          第二,流量管控,主要指流量治理部分。面對海量流量,我們怎樣通過一些防刷技術(shù),保障網(wǎng)關(guān)不被大流量沖垮;以及怎樣通過一些像限流、降級、熔斷等技術(shù),對網(wǎng)關(guān)進(jìn)行全方位保護(hù)。

           

          第三,協(xié)議適配。就是前文提到的,網(wǎng)關(guān)會透傳后端上千個(gè)服務(wù),而這些服務(wù)一定不是每一個(gè)都需要網(wǎng)關(guān)去開發(fā)配置的。我們通過一個(gè)協(xié)議適配的轉(zhuǎn)換,讓后端的各種服務(wù)通過我們指定的協(xié)議、通過http的方式從網(wǎng)關(guān)開放出去,當(dāng)然網(wǎng)關(guān)不單單是http協(xié)議,還有一些TCP的。京東內(nèi)部的協(xié)議相對比較統(tǒng)一,有Http的restful的協(xié)議,也有JSF的接口,JSF是京東內(nèi)部自研的一個(gè)框架,一個(gè)RPC調(diào)用框架,和double是類似的,然后基于注冊發(fā)現(xiàn)的一個(gè)rpc框架。

           

          第四,安全防護(hù)。這一部分對于網(wǎng)絡(luò)來說非常重要,因?yàn)榫W(wǎng)關(guān)是整個(gè)公司對外的一個(gè)出口,在這一層我們要做一些防刷,比如防清洗一些惡意流量、做一些黑名單,當(dāng)有一些惡意流量的話,通過限制IP等限制手段把它拒絕在整個(gè)網(wǎng)關(guān)之外,防止這些惡意流量把網(wǎng)關(guān)沖垮。


          ?