APP開發如何才能做(zuò)到支撐高(gāo)并發量

APP開發除了(le)在功能上滿足需求以外，在性能上也(yě)要能滿足需求。一些用(yòng)戶量大(dà)，對(duì)并發量要求高(gāo)的(de)APP，在開發前就要設計好架構，在服務器硬件和(hé)系統軟件上，都要能支撐高(gāo)并發的(de)需求。

以京東爲例，618大(dà)促，京東的(de)網關承載了(le)幾十億的(de)流量和(hé)調用(yòng)，在這(zhè)種情況下(xià)，網關系統必須保證整個(gè)系統的(de)穩定性和(hé)高(gāo)可(kě)用(yòng)，保證高(gāo)性能和(hé)可(kě)靠，以支撐業務。這(zhè)是一個(gè)非常複雜(zá)的(de)問題，基于這(zhè)種複雜(zá)問題，怎樣做(zuò)到很好地提高(gāo)它的(de)性能和(hé)穩定性、複雜(zá)技術之間怎麽整合保證整體網關的(de)高(gāo)可(kě)用(yòng)？

 

網關系統主要有兩種：

第一種叫客戶端網關主要用(yòng)來(lái)接收一些客戶端的(de)請求，也(yě)就是APP的(de)服務端；

第二種叫開放網關，主要是公司（比如京東）對(duì)于第三方合作夥伴提供接口。

這(zhè)兩種不同網關所使用(yòng)的(de)技術非常類似。

 

流量比較大(dà)的(de)網關面臨的(de)難點包括：

 

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

 

第二，網關系統其實就是一個(gè)把Http請求拓展到後端服務的(de)過程。我們的(de)網關承接了(le)一千以上的(de)後端服務接口，面對(duì)這(zhè)種情況，怎樣做(zuò)到服務與服務之間相互不影(yǐng)響？架構層面怎樣能夠杜絕蝴蝶效應、防止雪(xuě)崩？就是說當一個(gè)接口出現問題的(de)時(shí)候，不至于影(yǐng)響到其他(tā)接口的(de)健康運行。這(zhè)個(gè)說起來(lái)簡單，但實際卻不然。

 

一千個(gè)以上的(de)接口，每個(gè)接口性能都不一緻，而且每個(gè)接口所依賴的(de)外部資源、數據庫緩存等都不一樣，幾乎每天都會出現各種各樣的(de)問題，我們怎樣通(tōng)過一些隔離技術、治理(lǐ)技術等，保證當這(zhè)些接口出現問題的(de)時(shí)候，不會影(yǐng)響到全局？

 

第三，我們對(duì)外暴露了(le)一千個(gè)服務接口，所有接口的(de)後面意味著(zhe)幾十個(gè)甚至上百個(gè)團隊每天在不停地開發，每天都可(kě)能上線新的(de)需求。面對(duì)這(zhè)麽複雜(zá)的(de)情況，我們不可(kě)能每次後端服務器有任何修改，都需要有網關的(de)修改或上線，這(zhè)樣網關會變得(de)非常脆弱，穩定性極低。

 

我們采用(yòng)了(le)一個(gè)動态接入的(de)技術，讓後端的(de)網關能夠通(tōng)過一種接入的(de)協議(yì)進行無縫接入，之後通(tōng)過一些動态代理(lǐ)的(de)方式，直接讓後端的(de)接口，不管做(zuò)任何修改或上線，都可(kě)以通(tōng)過後端管理(lǐ)平台從網關上對(duì)外進行透傳發布，很好地解決了(le)我們網關所面臨的(de)依賴于後端接口服務的(de)上線問題。

 

網關的(de)四個(gè)技術方向：

 

第一，統一接入。就是前端（包括APP或其他(tā)來(lái)源）的(de)流量，能夠都在統一網絡層進行接入。這(zhè)一層所面臨的(de)問題是：高(gāo)性能透傳、高(gāo)并發接入、高(gāo)可(kě)效性，以及當前端流量來(lái)了(le)之後，怎樣能夠進行一個(gè)負載的(de)往後端的(de)轉發。

 

第二，流量管控，主要指流量治理(lǐ)部分(fēn)。面對(duì)海量流量，我們怎樣通(tōng)過一些防刷技術，保障網關不被大(dà)流量沖垮；以及怎樣通(tōng)過一些像限流、降級、熔斷等技術，對(duì)網關進行全方位保護。

 

第三，協議(yì)适配。就是前文提到的(de)，網關會透傳後端上千個(gè)服務，而這(zhè)些服務一定不是每一個(gè)都需要網關去開發配置的(de)。我們通(tōng)過一個(gè)協議(yì)适配的(de)轉換，讓後端的(de)各種服務通(tōng)過我們指定的(de)協議(yì)、通(tōng)過http的(de)方式從網關開放出去，當然網關不單單是http協議(yì)，還(hái)有一些TCP的(de)。京東内部的(de)協議(yì)相對(duì)比較統一，有Http的(de)restful的(de)協議(yì)，也(yě)有JSF的(de)接口，JSF是京東内部自研的(de)一個(gè)框架，一個(gè)RPC調用(yòng)框架，和(hé)double是類似的(de)，然後基于注冊發現的(de)一個(gè)rpc框架。

 

第四，安全防護。這(zhè)一部分(fēn)對(duì)于網絡來(lái)說非常重要，因爲網關是整個(gè)公司對(duì)外的(de)一個(gè)出口，在這(zhè)一層我們要做(zuò)一些防刷，比如防清洗一些惡意流量、做(zuò)一些黑(hēi)名單，當有一些惡意流量的(de)話(huà)，通(tōng)過限制IP等限制手段把它拒絕在整個(gè)網關之外，防止這(zhè)些惡意流量把網關沖垮。

 

以上隻是應對(duì)高(gāo)并發量http://www.lexintech.com/a/news/appzx/384.html的(de)一個(gè)方面。要做(zuò)到更好的(de)應對(duì)高(gāo)并發，還(hái)有很多(duō)方面的(de)工作需要做(zuò)。我們下(xià)次再接著(zhe)聊這(zhè)個(gè)話(huà)題。