[[194622]]

【51CTO.com原創(chuàng)稿件】近幾年，蘇寧易購隨著業(yè)務的發(fā)展，用戶使用習慣的改變，不斷強化移動端發(fā)展，加強與視頻直播，娛樂、體育營銷等各類內容媒體的合作，創(chuàng)新營銷產品，不斷提升移動端日活，2017 年 3 月移動端訂單數量已占線上整體比例的 83%。

為了進一步提高移動端訪問速度，提升用戶體驗，移動團隊潛心研究網關、http2.0技術，最終決定上線統(tǒng)一接入層。

下面從三個方面解析蘇寧易購移動端統(tǒng)一接入層：

• 統(tǒng)一接入層設計
• 統(tǒng)一接入層的功能、實現
• 統(tǒng)一接入層的性能

統(tǒng)一接入層的設計

蘇寧易購的架構演進

蘇寧易購的網絡架構不斷發(fā)展演進，2014 年接入應用防火墻，為 Web 應用提供安全保護。2015 - 2016 年，整體架構更加健壯穩(wěn)定，保障了業(yè)務需求，支撐了線上業(yè)務的飛速發(fā)展。

2017 年，隨著統(tǒng)一接入層的加入，系統(tǒng)封裝了應用程序的內部結構?？蛻舳酥恍枰W關交互，而不必調用特定的服務。并在此基礎上，系統(tǒng)做了域名收斂，使用 http2.0 協議，重點提高了移動端的訪問速度。

統(tǒng)一接入層的架構劃分

統(tǒng)一接入層內部架構分為三層：

• 代理層，有多臺代理 proxy，由 go 語言實現，將請求向后轉發(fā);
• 一個個虛擬的集群，每個集群對應一個業(yè)務系統(tǒng)，并且管理著系統(tǒng)的服務器;
• 服務器，該服務器為目前線上各個系統(tǒng)的服務器。配置信息存儲在 zookeeper 上，后臺管理系統(tǒng)對 zookeeper 上的配置數據進行統(tǒng)一的管理。

從上往下，統(tǒng)一接入層對移動端的請求做了接管，然后轉發(fā)到相應的服務器上去。代理層用 go 語言實現，主要是利用 go 的高性能，以及線程***制。后臺管理系統(tǒng)使用 Java 實現，為了統(tǒng)一管理，使用公司內部 passport、統(tǒng)一后臺管理等。

目前，移動端系統(tǒng)接入統(tǒng)一接入層后，iOS 和 Android 客戶端發(fā)出的請求全部收斂為一個域名，并且走 http2.0 協議。請求經 CDN 到達代理層 proxy，proxy 再將請求轉發(fā)到各個集群系統(tǒng)，回源協議支持 http2.0，http1.1。

統(tǒng)一接入層功能、實現

統(tǒng)一接入層的一項重要功能是轉發(fā)請求，我們首先考慮基于 Nginx 做整個代理層，但綜合分析，其與我們團隊技術方向不一致，修改 Nginx 成本較高，不便于定制個性化需求。

然后，我們選擇使用 go 語言，一是被其簡潔的語法所吸引，二是其性能確實強悍，后期的壓測數據，也證實了這一點，讓我們感到驚喜。

技術實現方案

下面介紹在整個實現過程中，我們應用的技術點，和接入層具備的功能：

• 采用高效的 fasthttp 組件做請求接入和轉發(fā)層，性能直逼 Ngnix，經過測試每個轉發(fā)請求包括網絡傳輸平均只增加了 0.1 毫秒。
• fasthttp是 Go 的一款不同于標準庫 net/http 的 HTTP 實現，其性能可以達到標準庫的 10 倍。
• 在匹配路由規(guī)則上，通過快速查找算法和精準匹配算法的互補，可以既保證性能又保證準確性。
• 在對后端請求的轉發(fā)上，使用 TCP 鏈路復用的方式，使得請求在轉發(fā)層面上猶如同一臺機器，大量的減少網絡交互。
• 對于后端服務的檢活，是用主動檢活加被動檢活相結合的方式，提高了對后端服務快速容錯的能力。
• 所有的規(guī)則配置通過 zookeeper 快速配置，可以實現線上配置實時生效的功能。
• 對于內部組件 filter 層，使用的 go 1.8 支持的 plugin 的方式，通過線上動態(tài)打補丁的方式來支持新需求的功能增加。
• 整個 proxy 基本是無狀態(tài)的，對 zookeeper 部署上也考慮了多機房同步的方案，所以整個統(tǒng)一接入層也具備多機房部署能力。
• 支持修改請求的 HOST，統(tǒng)一接入層修改了請求的域名，但一些系統(tǒng)的 Apache 上針對原域名有配置，尤其是需要登錄的接口。

為應對這一點，支持在后臺配置請求的原始域名，proxy 轉發(fā)時，HOST 的值為原始域名，這樣一來，請求就能正確的響應，并且原系統(tǒng)不需要修改服務器配置，對接入層無感知。

轉發(fā)規(guī)則動態(tài)配置

所有配置數據(轉發(fā)規(guī)則)存放在 zookeeper 上，支持動態(tài)配置，由后臺管理系統(tǒng)統(tǒng)一管理。

• 代理(proxy)，代理機器在 zookeeper 注冊臨時節(jié)點，如果代理機器與 zookeeper 的連接斷開，臨時節(jié)點自動刪除，利用臨時節(jié)點的特性檢活 proxy。
• 轉發(fā)規(guī)則(api)，存放的是 url 的路由規(guī)則，如下圖，統(tǒng)一接入層根據url轉發(fā)，將匹配 / mtspre /* 的請求，轉發(fā)到集群 mtspre，并且重寫轉發(fā)后的請求地址。

• 集群(cluster)，存放每個集群的信息，集群中包含的服務器和轉發(fā)策略，支持隨機和哈希兩種方式。

• 服務器(server)，存放所有服務器的信息，包括檢活周期和超時時間。
• 綁定關系(bind)，存放集群和服務器的綁定關系。

proxy 代理層監(jiān)聽 zookeeper 的每一個節(jié)點，一旦節(jié)點數據發(fā)生變化，可以實時的獲取***的配置，立即生效，改變請求的路由策略。

為了保證可靠性，應對 zookeeper 所在的虛擬機宕機，所有配置信息入庫，并且寫文件，極端情況下，proxy可以從文件中讀取配置信息，正常啟動。

協議

移動端發(fā)出的請求統(tǒng)一走 http2.0 協議，Android 端使用 okhttp 實現，iOS 端使用 AFNetworking。

相比 HTTP/1.x，HTTP/2，系統(tǒng)在底層傳輸做了很大的改動和優(yōu)化：

• HTTP/2 采用二進制格式傳輸數據，而非 HTTP/1.x 的文本格式。
• HTTP/2 對消息頭采用 HPACK 進行壓縮傳輸，能夠節(jié)省消息頭占用的網絡流量。而 HTTP/1.x 每次請求，都會攜帶大量冗余頭信息，浪費了很多帶寬資源。
• 多路復用，直白的說就是所有的請求都是通過一個 TCP 連接并發(fā)完成。同時，流還支持優(yōu)先級和流量控制。
• Server Push：服務端能夠更快的把資源推送給客戶端。例如服務端可以主動把 JS 和 CSS 文件推送給客戶端。

HTTP/2 主要是 HTTP/1.x 在底層傳輸機制上的完全重構，HTTP/2 是基本兼容 HTTP/1.x 的語義。Content-Type 仍然是 Content-Type，只不過它不再是文本傳輸了。

域名收斂

接入統(tǒng)一接入層后，客戶端使用到的域名都收斂成一個域名，域名后面的***個目錄，標記了該請求所屬的系統(tǒng)，即路由規(guī)則，程序員據此將請求轉發(fā)到不同的系統(tǒng)。客戶端收斂域名，不僅有效的減少***訪問的DNS解析次數，最主要的是為了充分利用 http2.0 的特性——多路復用。

因為只有一個域名，所有請求只需要建立一條連接即可發(fā)送完畢，大大減少等待時間，真正實現并發(fā)。如下圖所示的鏈路復用，只進行了一次 ssl 握手(紫色部分)，其他請求復用此鏈路，并且同時發(fā)出。

后端服務器檢活

做請求轉發(fā)，檢查后端 server 的健康性非常重要，我們目前有兩套檢活方案，同時運行。

(1)前臺代理層 proxy 被動檢活

proxy 向后端服務器轉發(fā)請求，如果返回失敗，則將這臺服務器的 checkFailCount 加1，checkFailCount 超過 3，就會將服務器標記為 down，不再向它發(fā)起轉發(fā)請求。默認檢活超時是 3s，3s 之內，后端 server 沒有再次返回失敗，將 checkFailCount 清零。

(2)后臺管理系統(tǒng)主動檢活

后臺主動檢活，在后臺管理系統(tǒng)啟動時便開始運行，可以設置檢活周期和超時時間。檢活線程根據服務器的 IP 及端口號，主動與每一臺服務器建立 socket 連接，建立連接超時則認為服務器不可用，將其狀態(tài)標記為 down;成功建立連接，則將狀態(tài)標記為 up。

前后主動、被動檢活的結合，保證了在服務器不可用的時候，停止向其轉發(fā)請求。同時，在服務器重新可用時，將其狀態(tài)標記為up，前臺proxy可以繼續(xù)向其轉發(fā)請求。

開關

(1)降級開關

為了保證可靠性，統(tǒng)一接入層修改了原有的網絡鏈路，上線必須有降級開關。目前，我們設計了一套開關，可以針對 APP 版本號，以及操作系統(tǒng)類型設置開關的狀態(tài)。

開關打開時，將原域名轉換成收斂后的域名，請求走統(tǒng)一接入層;關閉開關，域名恢復成原域名，請求不經過統(tǒng)一接入層，直接走原鏈路，支持線上實時切換。

(2)協議轉換開關

http2.0 的應用還在起步階段，目前網絡鏈路上存在一定的風險，這是我們所不能接受的，為此設計了另外一套開關，可以將協議在 http2.0 和 http1.1 之間切換，將風險降低到***。

統(tǒng)一接入層性能

系統(tǒng)性能

為了測試統(tǒng)一接入層的性能，能否達到上線要求。移動團隊對蘇寧易購 APP 端的生產接口進行了壓測，場景 1 是請求走原始鏈路，場景 2 是請求經過統(tǒng)一接入層，壓測數據如下。

請求走原始鏈路，平均 tps 為 9130，平均響應時間是 11 ms，通過統(tǒng)一接入層的請求，tps 達到 14200，提高了 50%，響應時間 6ms，縮短了近一半。這得益于 go 語言的高性能，快速路由選擇算法，以及后端 tcp 連接的復用。

真實用戶數據采集

為了提高系統(tǒng)的訪問性能，也為了檢驗統(tǒng)一接入層在實際生產環(huán)境中的表現，我們將部分接口接入了統(tǒng)一接入層，運行到生產環(huán)境中，經過不間斷的監(jiān)控，我們采集到了真實的用戶數據。

未接入統(tǒng)一接入層的接口，請求數據：

接入統(tǒng)一接入層的接口，請求數據：

圖 1 為原始鏈路接口的 top99，71% 的請求平均響應時間為 72ms，圖 2 是接入統(tǒng)一接入層的接口，域名收斂，協議走 http2.0，然后經過系統(tǒng)的 proxy 轉發(fā)，87% 的請求平均響應時間為 62ms，top99 數據有明顯的提高。

結語

本文主要分享了統(tǒng)一接入層的技術實現方案和功能，利用 go 語言的快速、高效、高性能，搭上 http2.0 的快車，為用戶提供更好的購物體驗。上線以來，通過 24 小時不間斷監(jiān)控和采集數據，統(tǒng)一接入層功能穩(wěn)定，性能提升了 20% 左右，達到了我們的預期。

但是，目前統(tǒng)一接入層處于起步階段，移動團隊最終的目標是接入核心系統(tǒng) 80% 以上的請求，將移動端訪問性能提升 30% 以上。相信通過團隊的共同努力，不斷創(chuàng)新，移動端性能還可以有更大的提升。

任良成

蘇寧云商 IT 總部架構師

主要承擔蘇寧易購 https 改造，負責統(tǒng)一接入層上線，在網絡性能優(yōu)化方面有很深的思考和領悟，現正和研發(fā)團隊一起建設統(tǒng)一接入層，持續(xù)優(yōu)化網關層，做出更高效穩(wěn)健的網關。

王一硼

蘇寧云商 IT 總部高級架構師

擁有多年 IT 平臺研發(fā)和管理工作經驗，先后在蘇寧，阿里，惠普等大型互聯網和 IT 企業(yè)工作，對 SOA 企業(yè)架構，高并發(fā)高可用的系統(tǒng)設計有多年的實戰(zhàn)經驗，專注于分布式，高并發(fā)，高性能/性能調優(yōu)，架構拆分和整合，大數據等技術領域。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】