APP開發除了在功能上滿足需求以外，在性能上也要能滿足需求。一些用戶量大，對并發量要求高的APP，在開發前就要設計好架構，在服務器硬件和系統軟件上，都要能支撐高并發的需求。

以京東為例，618大促，京東的網關承載了幾十億的流量和調用，在這種情況下，網關系統必須保證整個系統的穩定性和高可用，保證高性能和可靠，以支撐業務。這是一個非常復雜的問題，基于這種復雜問題，怎樣做到很好地提高它的性能和穩定性、復雜技術之間怎么整合保證整體網關的高可用？

 

網關系統主要有兩種：

第一種叫客戶端網關主要用來接收一些客戶端的請求，也就是APP的服務端；

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

這兩種不同網關所使用的技術非常類似。

 

流量比較大的網關面臨的難點包括：

 

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

 

第二，網關系統其實就是一個把Http請求拓展到后端服務的過程。我們的網關承接了一千以上的后端服務接口，面對這種情況，怎樣做到服務與服務之間相互不影響？架構層面怎樣能夠杜絕蝴蝶效應、防止雪崩？就是說當一個接口出現問題的時候，不至于影響到其他接口的健康運行。這個說起來簡單，但實際卻不然。

 

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

 

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

 

我們采用了一個動態接入的技術，讓后端的網關能夠通過一種接入的協議進行無縫接入，之后通過一些動態代理的方式，直接讓后端的接口，不管做任何修改或上線，都可以通過后端管理平臺從網關上對外進行透傳發布，很好地解決了我們網關所面臨的依賴于后端接口服務的上線問題。

 

網關的四個技術方向：

 

第一，統一接入。就是前端（包括APP或其他來源）的流量，能夠都在統一網絡層進行接入。這一層所面臨的問題是：高性能透傳、高并發接入、高可效性，以及當前端流量來了之后，怎樣能夠進行一個負載的往后端的轉發。

 

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

 

第三，協議適配。就是前文提到的，網關會透傳后端上千個服務，而這些服務一定不是每一個都需要網關去開發配置的。我們通過一個協議適配的轉換，讓后端的各種服務通過我們指定的協議、通過http的方式從網關開放出去，當然網關不單單是http協議，還有一些TCP的。京東內部的協議相對比較統一，有Http的restful的協議，也有JSF的接口，JSF是京東內部自研的一個框架，一個RPC調用框架，和double是類似的，然后基于注冊發現的一個rpc框架。

 

第四，安全防護。這一部分對于網絡來說非常重要，因為網關是整個公司對外的一個出口，在這一層我們要做一些防刷，比如防清洗一些惡意流量、做一些黑名單，當有一些惡意流量的話，通過限制IP等限制手段把它拒絕在整個網關之外，防止這些惡意流量把網關沖垮。

 

以上只是應對高并發量//chinawinegroup.net/a/news/appzx/384.html的一個方面。要做到更好的應對高并發，還有很多方面的工作需要做。我們下次再接著聊這個話題。