京東618：從演習、監控到預案，京東無線全面備戰

在京東上季度的財報中，無線端（包括移動端和微信等其他無線平臺）占比已經超過72%，這也給京東無線業務部帶來了巨大的壓力。今年，京東618主會場首次全面采用個性化策略，同時，618期間的一系列促銷活動，預計將為后端帶來超出日常20倍左右的流量洪峰，這都給無線業務部帶來了更大的挑戰。為了迎接挑戰，防止突發情況的發生，無線技術團隊從演習、監控到預案，制定了全方位的備戰計劃。

受訪嘉賓介紹

趙云霄，京東商城無線業務部首席架構師。2011年加入京東進入無線團隊，負責服務端的開發與架構設計工作。見證并參與了京東無線從小到大，由弱到強的整個過程。五年間，帶領團隊完成了無線服務端的兩次重大架構升級，無線服務端從一個簡單的Web應用進化成為支撐每天幾十億級訪問的分布式系統。目前負責京東無線網關系統的研發工作。

陳保安，京東商城無線業務部研發高級經理。從事研發工作十年，2011年加入京東。目前主要負責無線核心業務（搜索、商品、購物車、結算、收銀臺）的后端研發工作，多次帶領團隊進行系統架構升級和多次大促經歷磨練，為京東無線核心系統后端服務穩定性打下堅實基礎，支撐無線千萬級的活躍用戶和JD過半的訂單占比。

InfoQ：為了備戰今年的618大促，京東做了很多演習。請具體介紹一下移動端演習的內容、分類和流程，以及演習時的模擬數據是怎樣設定的。

趙云霄：大促前我們都會有一系列的演習，一般情況下，無線端會在大促前至少半個月開始演習，具體的時間由演習的不同性質來決定。當然我們的演習不可能只是一輪，一般是多輪的演習，具體幾輪視情況而定。

做 演習的目的 ，一方面是測試系統所能承受流量的能力，另一方面是，測試在某些環節出現問題時，我們切換預案的執行效率如何。這兩方面同時也是我們在做演習時的主要內容，所以演習相應地分為 壓力測試 和 預案切換 兩類。

• 壓力測試是基于工具的，用來測試我們對流量的承受能力，包括單機和系統整個集群的承受能力。壓力測試一般分為兩種，一種是工具測試，一種是線上流量。我們會把線上的流量引到其他一些少數的機器上去測試單機的性能。

• 預案切換類的測試，就是對預案進行演練。預案演練是指，有一些預案雖然已經定好了在出現問題怎樣去執行，但在現實的執行過程中仍有可能會出問題，所以我們需要提前去對預案進行演練。這類演習一般都是提前一個月或者一個多月先做一輪，先暴露出一些問題，然后根據暴露的問題來分析是否有必要再做一輪。如果再做了一輪還有問題，那么我們還會調整，再演習。但是一般情況下，不超過三輪我們就會發現很多問題，包括大數據要解決的問題。

演習的數據有兩種，一種是線上流量，一種是造數。

• 線上流量，一般就是使用線上的數據，例如將一個集群中的十臺機器摘掉九臺，看看一臺能不能支撐，以此來測試單機的性能。

• 造數是指由我們專門的測試團隊去造測試數據。但是這樣一來，一些寫操作，會引入一臟些數據。在造測試數據時，我們會盡量把SKU分散開，預估熱點SKU的數量，來做更真實的模擬。同時，我們會在壓測的請求URL中增加一個標識，來區分正常業務和壓測數據，以便后期清洗這些臟數據。

陳保安：我重點從下單之前和下單之后這兩個環節說一下模擬數據。

• 一是下單之前的模擬數據。我們通過測試，把線上的日志數據抓下來之后做回放，盡可能模擬真實用戶的請求。然后將它放大幾倍或者幾十倍去做壓測。這類數據所進行的操作分為兩種，一種是讀，另一種就是剛才提到的寫操作。讀操作的數據可以無限放大，因為這種東西不會對數據產生干擾。而寫操作的數據需要在最后清理出來，以免對真實數據造成影響。因此會設置標識來便于后期清洗臟數據。

• 二是下單之后的環節的模擬數據。在有些場景下，比如在我們整個京東的“軍演”過程中，使用的是線上的數據。它模擬的是我們下單之后，后端所有的支付、配送等所有的系統的壓力。我們會在“軍演”時“憋單”，使得管道里面存20萬單或者更多，然后一下把訂單下傳下去，模擬出給整個后端環節的壓力。

InfoQ：在618的期間的數據跟平時可能會有些不同，例如某些熱銷產品，數據變化較大，針對這種情況是不是會做一些特殊的處理？

陳保安：是的。618期間有一些數據會過熱，尤其是一些促銷力度過大的商品相關的數據。我們在演習的時也會去模擬這種數據。例如，拿線上50萬或300萬的數據去進行模擬時，我們會將其中50到100個商品的流量放得更大一些，來模擬部分商品熱度較高的情況。我們還會測試在過熱的情況下，例如一個商品受到了極限的訪問，甚至達到整體的訪問量那么大以后，我們的系統會不會有更好的處理。

趙云霄：因為過熱的商品會造成訪問數據集中在某一片緩存上，這有可能會暴露出系統設計上的問題。我們會通過技術的手段解決這種問題，然后將測試數據集中在上面，來看測試效果。

InfoQ：那方便說一下具體采用了哪些技術手段嗎？

陳保安：我們會對熱點數據 做更多的本地化的緩存 。例如單品頁，它整個核心流程訪問量最大，所以我們對單品頁設有多級緩存來扛單品頁的訪問。通過CDN來扛外網流量的訪問，主要適用APP的訪問，另外nginx的共享緩存也會增加熱點數據的緩存，因為有一些內網的調用不走CDN，第三方面在java進程堆內存中增加熱點緩存，這一層的緩存時間較長一些，透傳過來的流量會對上游基礎服務做一個保護，所以一級一級這么去保護，避免某些爆款商品拖垮整體服務。

趙云霄：總得來說就是，設置多級緩存，同時盡量讓第三方緩存的請求變得更散。

InfoQ：網絡的復雜情況給移動端帶來了很多問題。為了保障用戶的最佳體驗，京東做了很多適配工作，并在接口層面做了做了相應的設計。請您具體講解一下適配的標準，以及接口的設計根據618大促的需求做了哪些改變。

陳保安：因為網絡的復雜情況而帶來的這些問題主要是由于手機端與PC有著不一樣的特性。

首先，從網絡流量和耗電量來看，圖片加載對手機的消耗比較大。而從進到首頁到后端搜索，再到商品詳情，我們展現給用戶更多的就是圖片。所以，我們 對圖片會重點處理 ：根據不同的分辨率、不同的網絡類型、不同的手機系統版本（安卓4.X版本和之前的版本區別較大），指定了相應的標準。這里是有一個比較大的escape標準東西，就是說 有一個成熟的表單 ，它是由產品人員做了很多次測試得出的，在什么樣的位置上，圖片適配采用什么樣的大小尺寸都有標準。

第二是，PC端關于價格、商家信息、狀態跟蹤，包括一些庫存有一些信息，很多都是異步加載出來的。PC端的頁面呈現給用戶的信息可以在第一時間加載出來。然而手機端不一樣。因為網絡環境比較復雜，有可能這一秒有網，下一秒走到角落里可能就變成了弱網，甚至沒有網了。這種情況下去創建更多的連接，成本是比較高的。而京東的單品頁因為垂直的頻道比較多，所以會更加復雜，雖然僅僅是一個單品頁，但是它聚合了我們后端近50個基礎服務。針對手機端，我們不會在單品頁把 數據異步下發 ，而是由后端聚合之后一次下發給客戶端，這樣就減少了建立鏈接的成本。

這一次618我們做的比較大的改動，就是 規則的識別下發給了客戶端 。比如，剛剛提到的圖片的識別規則原來是在后端去處理的，要根據手機的分辨率、網絡類型、機器的版本去做適配，這樣一來就涉及到靜態化的數據，使得利用率變得非常非常低了。所以這一次我把這規則下放給了客戶端，客戶端只需要告訴后端是安卓的哪個版本，后臺會給它下發統一標準的數據。而規則是動態下發給客戶端的，比如說打開客戶端以后，后端就把規則下發給了客戶端。這樣一來，后端就不需要再去根據分辨率、網絡類型等去做適配，而是由客戶端去做適配工作。

具體的下發的規則是統一的，包括在2G、3G等網絡情況下分別對圖片有怎樣的要求。這一點是根據分辨率來固定相應的范圍的，不是所有的范圍，否則規則會太多。

趙云霄：總得來說是三點：

• 根據圖片不同的位置，采取不同的適配標準。例如單品頁商品展示的圖片會比較高清。

• Sever端的接口設計異于PC端的ajax異步加載。盡可能通過后端把數據聚合下發，減少客戶端和后端頻繁創建鏈接的過程。

• 單品頁圖片適配規則可動態變化。這是無線端針對618大促做的比較大的改動，單品頁圖片適配規則下發到客戶端來執行，規則是動態可變化的。這使得后端不需要依賴手機的網絡類型、系統版本等信息，可以極大地提高后端的Cache命中率。

InfoQ：京東曾提到，在系統升級的過程中，會盡量減少強依賴，將強依賴盡量轉化成弱依賴，并不是直接依賴于服務。能否舉例說明減少了哪些強依賴，是如何將強依賴盡量轉化成弱依賴的。

陳保安：強依賴轉變成這弱依賴，或者說盡量不依賴，就是說我們對這于實時性要求不高的，像商品的信息，包括圖片、特殊屬性、詳情、商家等信息，以前可能是完全依賴于基礎服務的，現在會把它的一些數據 異構 并存儲下來。在發生變化時，通過管道MQ去通知做出一些變更，達到最終不會實質依賴基礎服務去做商品聚合展示的目的。所以現在，其實是間接依賴。因為這雖然不是實時，但是是通過異步的方式給我的。而像價格、庫存等變化非常頻繁的數據，依舊是實時依賴。

還有比如說在下單之后，或者是在支付環節，會涉及到DB。而DB相關的數據，我們現在也是通過異步的方式落地的。因為這個說白了實質性要求沒那么高，無線收銀臺可以不完全依賴DB，更多地依賴實時用戶會話的緩存來于第三方支付機構進行交互。這也是因為在去年雙十一的過程中，DB遇到了一些麻煩，主要原因是連接數比較多，所以這從強依賴變成了弱依賴。

趙云霄：其實像京東的系統，是一個完備的包括所有業務的系統，是一個完全的服務化的系統。哪些是必須看成強依賴，哪些必須看出弱依賴，在我看來這個東西沒法去區分。

京東有幾百上千個服務，我們要去梳理這些東西，比如說哪些東西沒有必要直接同步的去調用它，讓它影響我們，我們會去把這些東西梳理出來。現在的套路，要不是異步化，要不就像保安說的有一些地方我可以用空間去換取更好的交互，所以要么是采用中間件，要么是異構一份數據到緩存中。那么所謂減少依賴都是在正常服務不可用的極端情況下可以去考慮的，在正常的服務化系統之間的交互，我們還是盡量保證專門的系統去做其專門的事。例如，在平時，我們會去依賴A、依賴B、依賴C，而且還會調度它們，但是我們還會有一個異步方案，在特殊情況下，比如說在流量非常大的時候，去切換到這個方案上，這個方案對后端壓力比較小。

所以我認為 沒有必要刻意總結哪些強依賴、哪些是弱依賴 。在一個比較龐大復雜的服務系統中，你沒有太多辦法要求別人的系統去做一個什么什么事，而我們的系統也要配合別人的系統去工作，所以這個復雜就會更高。所以我們只能想辦法，各自做一些在極端情況下能保護后端的方式，這就是我們減少依賴的目的，也是遵循了 前端保護后端的通用原則 。

InfoQ:那么也就是說在618期間流量比較大時，可能會做出一些取舍，比如用空間去換取交互效果。那么在大促結束之后，會不會換一套方案把之前做的犧牲再換回來？

趙云霄：這是有可能的。因為在嚴謹的系統設計中都會有備選，在特殊情況下必須用空間去換取想要的效果，但是日常的流量情況不需要犧牲額外的空間。既要節省成本，又要保證正常的交互。另外，就像剛才提到的很多弱依賴的場景其實是個別情況，在大部分交易流程中，很多依賴還是實時的。把需要實時反饋的數據轉換成弱依賴，實際上是我們做出的妥協。所有的這種妥協，在回歸正常情況時，我們都有可能收回。

陳保安：做出妥協是非常必要的，領導曾說，我們雖然要依賴一些基礎服務，但是基礎服務真的掛了的時候，自己還要保證能活，這就是我們的最終目標，就是說要在基礎服務出現問題的時候，我們能夠有辦法快速地去解決問題，而不是處于死等狀態。

趙云霄：任何一個大型在線系統，它的主干要是最強壯的。我們可以減少分支上無關緊要的東西，來保護最重要的部分免受大流量的破壞，讓它處于安全的保護之內，能提供正常服務。同時，由于用戶體驗非常重要，又涉及到京東很多用戶，所有我們會多考慮出20%，比如考慮流量達到120%的時候要做出什么方案來保護它。

InfoQ:這些預案都是來處理特殊情況的，而在實際的大促過程中，為了保證萬無一失，京東還做了很多監控工具和監控平臺，那么京東都是從哪些緯度來進行監控的？移動端的監控平臺有哪些？具體采用了什么技術？

趙云霄：事實上，在剛起步時，我們也缺少監控，經常半夜被叫醒處理技術問題。后來我們逐漸意識到，監控系統跟核心系統是同等重要，應當把監控系統看做正常業務系統的一部分。比如說，要新上一個業務系統，那么監控系統就占50%，沒有監控系統就不可以上線。

從無線端來看， 監控系統是多維度的 。從底層的操作系統的各項指標，到各個層面的業務系統，再到網絡都需要監控。

這些監控都是非常必要的，比如 業務監控 ，有時候業務表面上是存活的，但是業務不正常，有可能出現很多邏輯上的問題，所以移動端還有對訂單量、購物車、搜索等方面的監控，這些監控是業務指標級別的，也是應用層面的。我們有對應用主動調用的檢測，不同的VIP進來，這就是從應用層面的存活激活，還有一些其他。各個團隊如果感覺這應用不夠，還會自己添加一些小的應用系統跑在機器上去監控。

另外還有對 運維 、 云平臺 和 網絡層面 的監控，這些監控一起形成了一個比較立體的監控系統，從底層到最上層都有監控。

目前，移動端涉及到的 監控平臺 有以下幾個：

• 核心業務監控（cpm平臺）。主要有三個核心監控模塊，依賴基礎服務的返回碼錯誤監控，依賴基礎服務的異常監控和收銀臺全方位（機房、渠道、接入方、銀行等維度）的數據監控。

• monitor.m.jd.com：承擔無線運維主要的監控入口，包括一些核心業務指標以及服務器基礎監控等。分鐘級別的監控，第一時間對業務以及可用率抖動進行告警。

• 網關、httpdns探測系統——prism.m.jd.com：主要承擔網關、httpdns的服務器存活監控和網關連接池實時監控。監控系統每分鐘探測自動化部署中這兩個應用的所有服務器狀態并以圖形化的界面展示出來，只要連續兩次探測不存活就會報警，如果沒有及時修復，會持續報警，直到正常。實時監控網關連接池，根據它可隨時調整連接池參數。

• 愛馬仕監控平臺——hermes.m.jd.com，承擔網關全量接口的可用率、性能、調用次數監控及短信報警。同時，提供機房內外網、服務器IP、省份、運營商、客戶端版本等各種維度按需組合的監控。

• ZKCloud——zk.m.jd.com,為接入ZooKeeper用戶提供可視化操作與詳細操作日志，提供zk節點存活監控、各項指標性能監控，報警維度有短信、郵件、咚咚。

建設監控系統也有其相應的 監控原則 ，例如監控一定要報警，允許偶爾誤報，但不能不報。報警是多通道的，報警方式可以是短信、微信、郵件等。而且，報警至少要有兩個人以上的接受人。

所用的 監控技術 ，業內用的都差不多。我們主要就是埋點數據的升級，比如說在最基本的操作系統層面的監控會去采集利用相關文件，查看它的CPU、內存，在應用層面也會埋很多的點去上報這些數據。在獲得數據后，有專門的團隊來進行實時的數據分析，用最快的速度分析出結果，需要報警的話再走報警通道。對于重要的URL或者重要的請求，有探索工具來適配我們所希望的結果，如果探索不到這些結果，那么系統可能就有問題。總得來說，所用的技術就是數據實時分析和主動探測。

InfoQ:剛才提到，京東的監控做得非常立體，有很多團隊去做。那么有沒有統一的管理，或者說一些原則？有沒有專門的人去對監控系統做審查？

趙云霄：監控點的加入是滲透在系統的設計中的。例如，系統的初期就應該對業務指標的數據進行監控，這是一個上線之前的規則。我們會定期做考察，如果有些該設置埋點的地方沒有設，那么QA人員會做處理。

埋點的原則主要有以下四點：

• 資源調用處（接口、緩存、DB）必須埋點

• 埋點必須可動態關閉（通過配置下發）

• 數據收集類的埋點必須通過多層的代碼review

• 埋點數據收集不能影響系統性能，對埋點的SDK要有性能測試報告才可以使用

InfoQ:也就是說開發人員也要負責運維人員的監控環節嗎？開發人員需要跟蹤一段時間，來交接監控系統嗎？

趙云霄：是的，而且我們的 運維有研發能力 ，這是對互聯網研發人員一個最基本的要求。

陳保安：各個團隊做的職責不一樣。比如說各個機房的流量分配運維更偏向于網絡層、包括服務器層這些基礎組件的監控。網關層面更注重的是流量的監控，所以業務團隊除了一些基本業務指標監控之外，也會做一些業務細節的監控，比如可用率、性能、異常量、錯誤碼等等。比如說某個點的單量突然跌了，需要盡快定位到具體是什么原因引起，所以業務側的監控更多是能一眼就能聚焦到引起問題的某個點上，通過預案快速修復問題。

而且我們上線、發布新的業務，都是要有 灰度 的。比如上線一個業務之后，只是其中的一部分流量走新業務。此時，我們通過埋點監控，去對比新老業務，看用戶的反應，分析其影響，然后再做決策。

InfoQ:剛才提到埋點，那么大促過程中移動端設置的埋點跟平時有沒有不同？大促結束后會不會關閉某些埋點？

趙云霄：埋點的作用分兩種，一種是用來 收集業務數據 的埋點，另一種是 監測系統指標 的埋點。大促之前，我們會針對不同促銷會增加一些的收集業務數據的埋點。京東的業務非常復雜，跟單純做平臺其實是不一樣的。市場有時會做一些新業務，這時就可能要根據業務再判斷如何增加埋點。用來監測系統指標的這些埋點基本不會變。

埋點基本上都是可以去關閉的。埋點要么是通過現在的技術，通過APP內網去申報，要么就是寫在磁盤日志上。這兩種埋點對網卡和磁盤都會造成比較大的損耗，所以沒有用的埋點，我們會想辦法 動態關閉 。

InfoQ:京東做了一套立體的監控，又設置了很多埋點，那么肯定是可以監控到非正常用戶的。具體是怎樣篩選出非正常用戶的？移動端在管控這些非正常用戶方面做了哪些工作？怎樣保證快速隔離非正常的用戶？

陳保安：對于非正常用戶，我們會對接到京東集團的風控系統。風控系統利用對用戶的積累，對用戶做了很細致的分類，可以根據用戶的行為 采用模型算法對其進行識別 。例如，有的用戶每天就只有刷單操作，沒有搜索等行為；有的雖然模擬用戶進行多步操作再下單，但是下單的頻率比較頻繁，一秒鐘下單很多次；還有些用戶下單的商品全是無貨商品，也就是說在活動開始之前，腳本已經啟動了，而這段時間商品是無貨的。利用最簡單的這些特征，就能分析出來這些用戶是非正常用戶。

同時，在安全方面客戶端和服務端之間也有一些基本的接口調動時候的 安全限制 。比如說簽名，我會給你分配到簽名，你要拿到對應的簽名才能去訪問相應的服務，這里也會有幾種策略下發給客戶端去用。但是非正常用戶為什么可以刷單，就是因為破解了個別簽名。這也是為什么還需要后端不斷地去對用戶行為分析。

具體的 隔離方式 ：針對非正常用戶，在關鍵時刻我們會做非常嚴格的限制，否則會對系統和商品銷量造成很大的沖擊。例如，在618和雙十一零點時，會對識別出的用戶做特殊處理。表面上會給他們提供一些服務，但實際上會把他們引流到一個具體的集群中，性能、穩定化不做保障，如果他們掛掉了，我們也不負責，這樣才可以對正常用戶做到保護。而即使是引流，他們最終訪問的流量還是會透傳到各個基礎服務，在特殊緊急情況下，也會把這些用戶掐掉。這些不同級別的限流都已經經過了演習并報備，目的都是為了保證正常用戶。

InfoQ:相當于把非正常用戶加入了黑名單，那么這份黑名單是怎么得到的呢？

趙云霄：得到這份黑名單非常不容易。京東有非常多的數據，也希望能利用這些數據對用戶提供更好的服務。京東有一個專門的團隊，利用 大數據分析 ，通過 數據模型 不斷地調整、優化，再利用從前端到后端的 多級防控 ，才從海量的數據中分析得出用戶的畫像。無線團隊也會做一些比較簡單的用戶分析，也會要求他們為我們提出安全點。大家始終在做這種配合，然后根據用戶的不同級別，做一些反饋。比如，像剛才提到的，在特殊情況下掐掉的非正常用戶，都是我們真正有把握的非常用戶，而不是模棱兩可的。正常用戶去搶購商品是不會被加入黑名單的，這樣才能真正包含用戶的利益。

同時，我們隊黑名單也會做出 動態調整 。因為不同業務的業務模型是不一樣的，對用戶的分類是有差別的。所以需要跟專門的團隊去溝通，讓他們根據業務模型分析非正常用戶。實際上，非正常用戶的占比也是非常小的，這也讓我們非常欣慰。

陳保安：這模型建立固定好后，通過埋點實時地埋過去，就可以算出真正的非正常用戶。在大促時，經常遇到有人臨時去注冊一批用戶的情況，但是只要他開始刷單，我們很快就能夠識別出來。

InfoQ:據我所知，無線端對整個購物流程都做了非常細致的預案，能不能具體地說一下細致到了什么程度？開啟的方式是自動化嗎？在什么樣的情況下會啟動預案？

陳保安：整個京東針對618做了 上千種預案 ，而無線部門也做了幾百種預案，這個力度是都非常非常細的。大的預案例如機房的切換，而小的預案也有很多。

比如，京東App上搜索現在70%搜索的結果都是個性化的，這樣一來緩存命中率會降低，服務器的壓力就會增大。如果CPU使用率達到了40%，那么我們會通過降級個性化服務來保證用戶能夠快速訪問。再比如現在支付環節要依賴京東臺賬和訂單中心，如果服務出問題，我要通過降級保障用戶能正常支付。

開啟的方式有自動化的，也有人工的。比如httpDNS服務出現問題，客戶端會自動降級到普通的DNS服務解析，這個影響范圍比較大，那么就不能等人工去切換，要使用自動化方式。

關于何時啟動預案，雖然往年我們為了保證最基本的購物體驗，我們在零點時會做一些處理降級。但今年晨總要求了兩點，一是技術保障，最基本的要求，二是業務驅動指標，就是說不能隨便降級，要保障業務。所以，包括之前提到的個性化，以往在零點去做一些降級，但是 今年不會去做降級 。但是一切大前提就是保障基礎購物流程的體驗，關鍵時候系統自我的保護就會啟用一些預案，比如說單品頁下面的個性推薦，只要它達到基礎性能的某個比例后，我們就會采取一些緊急措施來保證整體商品的展示。

趙云霄：事實上每年都會做很多預案，在大促前都會有一個嚴格的評審。細致到什么程度呢？比如后端依賴某一個具體的接口，針對 每一個接口都要有一個預案 ，包括資源的依賴都會有原。我們是盡可能地去考慮可能出現的問題。

預案啟動的方式是自動還是人工需要看情況。

• 系統壓力過大，CPU達到了40%，有這樣的具體標準，那么可以采用 自動啟動 。在自動啟動預案時，都會向相關人員發送通知。

• 大促期間，有些情況比較復雜，是多種原因造成的，這時候就需要優秀的技術人員去處理，那么此時就需要 人工啟動 。相應級別的人會有判斷和執行的權利，但是在事前和事后都要周知一下。預案的執行有流程，也有反饋，這我們預案執行的大原則。

有了之前提到的強大監控系統來提供一些判斷依據，預案的執行效果還是比較好的。

事實上，預案有專門的分歸類，不同模塊的人會去管理自己的預案。在執行時也會遵循保證用戶正常體驗的大原則。

InfoQ:京東的無線端一步步發展至今，兩位想必有很多感慨吧？

陳保安：對，我跟云霄就是從無線成立到現在，一步一步走過來的。在四五年前，無線只是試水，那時我們還叫手機移動端。上了一萬單時，大家很開心，還專門慶祝了一番。現在，我們的訪問人次和訂單量在當時都是難以想象的，比如，過去一個月的日均活躍用戶數已經接近4000萬，技術團隊由最初的兩三個人發展到現在的過百人，有了比較完善的架構。

趙云霄：我們整個技術團隊也是隨著流量的不斷增加而慢慢成長起來的。開始，我們會參照別人的技術，羨慕別人的技術。后來，我們有了很多問題要去解決，在這個過程中也積累了很多經驗。現在，我們不需要再去參照別人了，而是要將自己的經驗分享給大家。因為我們發現，很多人一路走來，面臨的問題都是相似的，只是處于不同的階段。

京東給了移動端快速成長的機會，讓我們不斷進步。我們也一直保持著對技術的旺盛求知。網上有一些技術貼，說京東的技術如何如何，我們沒人去霹謠，因為謠言太多了。你可以說京東只是流量很大，但我會說京東的系統復雜度是最大的。我們經歷了這么一個體系的成長，現在也有了一個足可以讓我們自己去仰望的平臺。

我記得我在QCon做分享的時候，還有人跟我說，我是第一個京東無線部門出來分享的人，當時徐總也說這是五年磨一劍。我希望我們無線部門是京東一個非常好的代表，希望每一次分享都是一個非常經典的干貨，而不是同一個主題在各個大會上去講。

InfoQ:非常感謝兩位接受我們的采訪。

 

來自： http://www.infoq.com/cn/news/2016/06/jd-618-mobiledevelopment