[[194622]]

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

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

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

• 統一接入層設計
• 統一接入層的功能、實現
• 統一接入層的性能

統一接入層的設計

蘇寧易購的架構演進

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

2017 年，隨著統一接入層的加入，系統封裝了應用程序的內部結構。客戶端只需要同網關交互，而不必調用特定的服務。并在此基礎上，系統做了域名收斂，使用 http2.0 協議，重點提高了移動端的訪問速度。

統一接入層的架構劃分

統一接入層內部架構分為三層：

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

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

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

統一接入層功能、實現

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

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

技術實現方案

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

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

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

轉發規則動態配置

所有配置數據(轉發規則)存放在 zookeeper 上，支持動態配置，由后臺管理系統統一管理。

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

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

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

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

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

協議

移動端發出的請求統一走 http2.0 協議，Android 端使用 okhttp 實現，iOS 端使用 AFNetworking。

相比 HTTP/1.x，HTTP/2，系統在底層傳輸做了很大的改動和優化：

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

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

域名收斂

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

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

后端服務器檢活

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

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

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

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

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

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

開關

(1)降級開關

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

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

(2)協議轉換開關

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

統一接入層性能

系統性能

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

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

真實用戶數據采集

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

未接入統一接入層的接口，請求數據：

接入統一接入層的接口，請求數據：

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

結語

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

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

任良成

蘇寧云商 IT 總部架構師

主要承擔蘇寧易購 https 改造，負責統一接入層上線，在網絡性能優化方面有很深的思考和領悟，現正和研發團隊一起建設統一接入層，持續優化網關層，做出更高效穩健的網關。

王一硼

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

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

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