《京東技術解密》試讀章節(jié)共71頁，我花了兩天時間仔細讀完，讀了過后感到意猶未盡，非常想一口氣把整本讀完，然而只能將試讀章節(jié)反復讀了好幾遍，收獲頗多，遂有此文，借此總結京東十年來的技術變遷和迅速發(fā)展。

之所以對這本書感興趣基于兩個原因：一是自己最近剛好在讀一本書《不戰(zhàn)斗不成功：劉強東和京東商城的“野蠻”奮斗史》，見識到了劉強東本人豐富的創(chuàng)業(yè)經(jīng)歷，與當當網(wǎng)拼圖書、與淘寶網(wǎng)拼百貨、與蘇寧易購拼家電，京東真是什么都賣，這份處處競爭的心也值得佩服。二是自己一直對京東印象不錯，覺得京東是“正品多、假貨少、物流快”，也經(jīng)常在上面買東西。作為一名技術人員，也就非常想知道支撐京東背后的技術架構是什么。

文中一開頭劉強東大哥總結的就很好，直接說明本書的目的所在：

京東可以高速發(fā)展到今天的規(guī)模的原因，其中最核心的是堅持“倒三角”戰(zhàn)略：建立出色的團隊；打造財務、物流和技術三大核心系統(tǒng)；降低成本、提升效率；為用戶帶來最佳體驗。在《京東技術解密》一書中，大家會看到技術驅動的力量，這也是京東第一次全面展示自己的技術體系。

從2004年京東剛上線只有一組簡單展示IT產(chǎn)品的網(wǎng)頁，到如今京東已經(jīng)是覆蓋PC端、移動端，并完整支撐物流、訂單、交易、商品、財務系統(tǒng)的巨大電商平臺；從當初的四五個人到如今的4000+人；從簡單的.Net+SQLServer 系統(tǒng)到主要基于Java 的大規(guī)模分布式系統(tǒng)。十年來，京東的技術平臺實現(xiàn)了高速成長，漸漸的從業(yè)務主導型轉為技術驅動型。

京東的系統(tǒng)比較復雜，涵蓋電商全流程全價值鏈，從前端的交易系統(tǒng)到供應鏈，到倉儲、配送、客服以及售后，除了財務報表之外，幾乎全部系統(tǒng)都是自己研發(fā)的。下面總結京東的技術和管理變遷。

如何管理4000人的團隊？

1. 組織架構優(yōu)化的重要性

以前的京東其技術團隊一直是職能化結構：產(chǎn)品部、研發(fā)部、測試部以及運維部門。但當員工越來越多時，這樣的技術團隊協(xié)作、溝通、優(yōu)先級劃分都很困難，因此14年京東對技術團隊做了調(diào)整：研發(fā)體系分為9 大模塊4 個平臺。

9大模塊：提供基礎設施的云平臺和運維、實現(xiàn)網(wǎng)上營銷的營銷研發(fā)部、針對COO體系的運營研發(fā)部、實現(xiàn)內(nèi)部信息化管理的職能研發(fā)部、提供統(tǒng)一的大數(shù)據(jù)技術平臺的大數(shù)據(jù)部、負責移動客戶端研發(fā)的移動部、負責全國研究院建設的研究院和主要負責管理體系建設的技術研發(fā)管理部。

4個平臺：技術平臺（打造基于云的技術架構，支撐其上所有的應用）、大數(shù)據(jù)平臺（數(shù)據(jù)獨立、大數(shù)據(jù)處理）、電商開發(fā)API平臺（以API 服務的方式進行服務）、應用平臺（包括自己的網(wǎng)站、移動客戶端、內(nèi)部的ERP及外部的ISV 開發(fā)應用）。

組織結構的調(diào)整解救了京東因為團隊人多導致組織混亂和管理困難的問題。

2. IT 管理123：1 個愿景、2 個重點、3 個體系

• 1個愿景：即希望或目標，“做中國最有影響力的技術團隊”。hope是很重要的，有了hope就有了動力、有了干勁，幾千人為同一個目標共同奮斗、努力是一件很值得自豪的事情。
• 2個重點：文化和結構。我個人一直認為公司的文化和氛圍非常重要，你工作的開不開心、值不值或有沒有干勁與公司的文化息息相關，好的文化會讓人們覺得工作是享受的，而不好的文化會讓人厭惡工作、抱怨老板。我一直認為華為這么國內(nèi)外都很知名、強大的公司為什么口碑如此不好，是與其差的公司文化直接相關的（個人愚見），培養(yǎng)好的文化需要關注3個詞：信任、分享和成長。結構就不用說了，基本上現(xiàn)在稍微大點的公司都會出現(xiàn)人才梯隊，比如阿里的P系列，京東與騰訊一樣是T系列。
• 3 個體系：產(chǎn)品體系、架構體系、管理體系。京東打造了讓產(chǎn)品經(jīng)理說了算的文化，避免了業(yè)務部門、產(chǎn)品部門和研發(fā)部門互相綁架的局面。架構也是讓架構師說了算，不是管理者說了算。

與騰訊ECC融合背后的故事

2014 年3 月10 日上午，京東集團與騰訊宣布建立戰(zhàn)略合作伙伴關系。當時這條消息爆炸在各大IT圈中，我當時也在納悶：一個賣東西的和一個聊天的怎么能合作的起來。當然，當時了解的信息不多，也沒用過QQ網(wǎng)購平臺和拍拍。直到看了本書這章后，才徹徹底底明白了兩者融合的前因后果和過程的艱辛不易。

這次融合讓京東從自營為主的B2C 業(yè)務轉變成自營B2C+平臺B2C+C2C 的完整電商生態(tài)系統(tǒng)。且在移動端，騰訊微信的流量優(yōu)勢以及三四線顧客群的覆蓋，使得騰訊與京東形成優(yōu)勢互補。

1. 京東與易迅的整合

這需要完成技術對接，包括商品、訂單和庫存的對接。說起來容易，做起來難，雙方的體量都很大，易迅的主流系統(tǒng)有十幾個，京東的主流系統(tǒng)更有幾十個，而易迅在被騰訊收購之后又對系統(tǒng)進行了幾次調(diào)整，其復雜性可想而知。因此怎樣最快解決問題、推出商品，對雙方都是很大的考驗。

• 首先需要解決快速溝通的問題：雙方的研發(fā)體系龐大，人員眾多，系統(tǒng)對接工作涉及一百多人，溝通過程中怎樣快速找到相關人，信息怎樣準確傳遞，都令人困擾。有時候打電話溝通不清楚，就當面溝通——出差，經(jīng)常在北上深之間飛奔。
• 做中間轉換接口匹配數(shù)據(jù)：京東和易迅兩個網(wǎng)站的用戶群體的偏好存在很大的差異，雙方網(wǎng)站用戶的重合度非常低，而用戶和流量是電商平臺最重要的資產(chǎn)，因此所有產(chǎn)品的對接和系統(tǒng)設計都要以用戶體驗為第一，否則可能會引起用戶的流失，進而導致流量的下降。但雙方系統(tǒng)都各自運行了很多年，不管是用戶體驗，還是業(yè)務場景上都有很大的不同，比如在配送環(huán)節(jié)，易迅有一日三送，而京東是定時達等等。這些都不能簡單統(tǒng)一為一個，而必須能互相兼容，且用戶體驗只能增強。類似這樣的不同點多達幾十處，最后的方案就是做一個中間轉換接口，分別來解析和匹配兩邊的數(shù)據(jù)對接，并通過歷史記憶來自動匹配。

2. 京東與QQ網(wǎng)購的融合

融合目標一旦確定下來，就容不得半點遲疑，北京即刻成立了專門的項目小組，并在京東會議室資源非常緊張的情況下申請了一間專用會議室作為戰(zhàn)時指揮部，主要項目組成員隨即打點行囊入駐、封閉，還需要北京、深圳兩地多個業(yè)務、產(chǎn)品、研發(fā)團隊無數(shù)次的溝通、修正和冥思苦想。此次的融合是空前的，不同的文化、不同的地域、獨立的系統(tǒng)，要全面打通面臨著各種技術、商務、工作方式等方面的不同。需求上的、技術上的以及要平衡各個相關方的利益而產(chǎn)生的各種待確認問題，像一場又一場密集的流星雨，每天在項目指揮部的上空火花帶閃電般接踵而至。從項目伊始到項目結尾，這期間經(jīng)歷的艱辛與努力很值得我們細細回味和學習。

3. 京東與拍拍的融合

京東的加入讓拍拍煥然一新，之前臃腫不堪的首頁即刻換成了如今的清新大方，商品也豐富了不少，賬戶系統(tǒng)的打通歷經(jīng)了N條方案和無數(shù)群組討論，期間寧愿延遲項目發(fā)布也不犧牲用戶體驗的做法很值得推崇。

京東的大數(shù)據(jù)平臺演變歷程

現(xiàn)在沒有哪個大公司不關注大數(shù)據(jù)的，13年初的時候，在京東制定的下一個10 年發(fā)展規(guī)劃中明確提出，大數(shù)據(jù)戰(zhàn)略將成為公司重點戰(zhàn)略方向之一。

京東大數(shù)據(jù)平臺從無到有，從集中式到如今的分布式，從Oracle數(shù)據(jù)倉庫到JDW2.0，4 年期間完成了復雜的演變。技術的變遷都是需求驅動的，京東也不例外。

1. 自建數(shù)據(jù)倉庫—解決數(shù)據(jù)服務不能自主的困境

數(shù)據(jù)多了，就需要成立專門的數(shù)據(jù)部門（Tiger 團隊），其工作重點是數(shù)據(jù)分析與數(shù)據(jù)報表，但在沒有數(shù)據(jù)倉庫的年代里，分析師們只能依靠DBA 提供的兩臺查詢機排隊寫SQL 提數(shù)，然后再拿回來做分析。遇到業(yè)務需求方描述不清或口徑不明確時，往往要花大量時間溝通調(diào)研，反復提取數(shù)據(jù)，這個過程耗時費力不說，還會被需求方不斷催促，使得效率非常低下。Tiger的解決方案就是：自建數(shù)據(jù)倉庫，這是做到自主數(shù)據(jù)服務的必由之路。且采用的是基于開源的MySQL，采用集群（Cluster）應用架構，支持大規(guī)模數(shù)據(jù)存儲與計算應用，而沒有使用有著強大數(shù)據(jù)處理能力的Oracle BIEE 商業(yè)智能平臺。據(jù)提取與報表展現(xiàn)產(chǎn)品同樣采用開源技術自主研發(fā)，后臺Java 程序，前端采用Ajax 框架Extjs。這種輕量級的數(shù)據(jù)產(chǎn)品在穩(wěn)定性及服務能力上與BIEE相比雖然有一定差距，但支持快速迭代及無與倫比的靈活性這些優(yōu)點也是成熟商業(yè)產(chǎn)品所無法替代的。正是自主研發(fā)、快速迭代和靈活應用這些適用于互聯(lián)網(wǎng)企業(yè)的特點，使得一系列產(chǎn)品和技術方案在快速成長的京東很好地支持了各種場景的數(shù)據(jù)需求，也成就了今天的京東大數(shù)據(jù)平臺。這對于其他成長中的互聯(lián)網(wǎng)企業(yè)也具有重要的借鑒意義。

2. 開始建設分布式數(shù)據(jù)倉庫

基于Hadoop，以Mapreduce 作為計算引擎的分布式數(shù)據(jù)倉庫開始建設，因為分布式的威力，Oracle漸漸的退出了京東數(shù)據(jù)倉庫。調(diào)度平臺功能逐漸完善，生產(chǎn)模式也由原來的單節(jié)點調(diào)度升級到分布式調(diào)度。今天的京東企業(yè)級數(shù)據(jù)倉庫JDW 便是在這樣的歷程中演變而來的。

京東大數(shù)據(jù)產(chǎn)品

• 調(diào)度平臺：虛擬節(jié)點的引入、Plumber 技術的采用非常重要。
• 數(shù)據(jù)集成開發(fā)平臺：里程碑產(chǎn)品，結束了數(shù)據(jù)分析師和業(yè)務部門數(shù)據(jù)需求人員通過客戶端工具手工提取數(shù)據(jù)的痛苦經(jīng)歷。從Extjs到Bootstrap前端技術的轉變也值得關注。
• 數(shù)據(jù)知識管理平臺：提供類wiki的功能，這讓我想起了Confluence這款軟件，不知道使用它作為知識管理工具的公司多不多。
• 京東分析師：實現(xiàn)類Tableau的桌面系統(tǒng)。
• 數(shù)據(jù)挖掘平臺：采用基于內(nèi)存的存儲引擎，集群資源調(diào)度與管理基于Hadoop Yarn 框架。
• 數(shù)據(jù)質(zhì)量監(jiān)控平臺：實現(xiàn)數(shù)據(jù)的及時性、準確性和完整性。

大數(shù)據(jù)技術創(chuàng)新

我覺得這一點非常重要，業(yè)界對大數(shù)據(jù)處理的技術方案幾乎已經(jīng)形成一套通用的技術架構，但為什么還有很多公司還是自己研發(fā)一套系統(tǒng)架構（典型的如阿里），主要是因為不同的行業(yè)及不同的實際業(yè)務需求，通用的方案一方面可能很臃腫，有許多不需要的功能，另一方面不夠靈活，不能實現(xiàn)特殊需求，因此大數(shù)據(jù)平臺建設所用核心技術依然需要付出一定的研發(fā)投入來實現(xiàn)定向的技術突破與應用，即所謂的“定制開發(fā)”。京東在通用的開源技術架構基礎上進行定制開發(fā)和產(chǎn)品化，從技術和產(chǎn)品兩個層面實現(xiàn)微創(chuàng)新和突破性創(chuàng)新，打造堅實的平臺基礎。技術微創(chuàng)新主要體現(xiàn)在平臺的基礎架構上，產(chǎn)品層面的突破性創(chuàng)新主要體現(xiàn)在大數(shù)據(jù)管理應用上，其中總結的創(chuàng)新點具有借鑒意義，需要的可以細看。

在需求的驅動下，京東不斷研發(fā)出了海量數(shù)據(jù)實時計算平臺“漢江”、海量數(shù)據(jù)實時查詢產(chǎn)品“三峽”、基于分布式架構的聯(lián)機分析處理系統(tǒng)和海量日志數(shù)據(jù)分析處理平臺，文中分別介紹了它們的技術架構。

這些大數(shù)據(jù)技術最終實現(xiàn)了精準營銷（例如通過郵件個性化推薦產(chǎn)品）、電商C2B 定制（例如京東的JDPhone 計劃）、用戶畫像（解決把數(shù)據(jù)轉化為商業(yè)價值的問題）、店鋪評級系統(tǒng)的搭建。

最后一章是介紹幾位京東技術大咖，看了過后除了跪拜還是跪拜，每個公司都有不少的技術大牛，希望自己以后也能成為其中的一員吧。

總結

以上是生活随笔為你收集整理的十年京东，十年技术发展—畅读《京东技术解密》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。