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

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

 

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

第一種叫客戶端網(wǎng)關(guān)主要用來(lái)接收一些客戶端的請(qǐng)求，也就是APP的服務(wù)端；

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

這兩種不同網(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集群，這樣的話就能夠很好地保證高可用。在面對(duì)一個(gè)瞬間流量的時(shí)候，我們采用了一些緩存技術(shù)，或者更前置的Nginx+lua+Redis技術(shù)，讓這種大流量應(yīng)用能夠脫離開(kāi)JVM的依賴。還有我們需要梳理各個(gè)接口，通過(guò)降級(jí)的策略把一些弱依賴的接口進(jìn)行降級(jí)，從而保證核心應(yīng)用的可用。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

以上只是應(yīng)對(duì)高并發(fā)量http://ajyzddn.com/a/news/appzx/384.html的一個(gè)方面。要做到更好的應(yīng)對(duì)高并發(fā)，還有很多方面的工作需要做。我們下次再接著聊這個(gè)話題。