文章簡(jiǎn)介：《京東技術(shù)解密》從618大促銷、產(chǎn)品演進(jìn)、技術(shù)演進(jìn)、創(chuàng)新激發(fā)、牛人專家五個(gè)側(cè)面詳細(xì)描述了京東研發(fā)團(tuán)隊(duì)的發(fā)展。本文摘自《京東技術(shù)解密》第4章節(jié)：完美風(fēng)暴——海量訂單處理。

OFC的重要性

2014年的618顯得和以往任何店慶促銷日都不同，不僅僅是因?yàn)殡娮由虅?wù)本身在中國(guó)不斷飛速發(fā)展對(duì)京東系統(tǒng)帶來的挑戰(zhàn)，更為重要的是2014年5月22日剛走入美國(guó)納斯達(dá)克殿堂的京東聚集了最耀眼的光芒，能不能保持這樣的光芒，618則會(huì)是一份很有說服力的答卷，當(dāng)然我們最終給出了滿意的結(jié)果。作為一個(gè)普通的購(gòu)物者，當(dāng)我們?cè)跒g覽器中輸入www.jd.com并回車，便可以看到京東商城的首頁，根據(jù)自己的需要選擇喜歡的商品，然后加入購(gòu)物車，提交訂單后，即可享受京東的極速物流體驗(yàn)，最終完成一次簡(jiǎn)單快樂的購(gòu)物歷程。其實(shí)，訂單提交后，需要經(jīng)歷多個(gè)環(huán)節(jié)和各個(gè)系統(tǒng)的處理才能完成使命。其中有一個(gè)環(huán)節(jié)是訂單必須經(jīng)過的，而且這個(gè)環(huán)節(jié)連接了用戶下單和訂單在庫房的生產(chǎn)，就是訂單履約中心（OFC，Order Fulfillment Center），本章我們就為各位解密這個(gè)部門。

2014年的618后，京東技術(shù)團(tuán)隊(duì)分享了如何應(yīng)對(duì)店慶日及以往促銷活動(dòng)在技術(shù)方面的經(jīng)驗(yàn)和探索。其中有一講“電商海量訂單處理OFC系統(tǒng)的關(guān)鍵技術(shù)環(huán)節(jié)”（見京東技術(shù)開放日第一期），說的就是這個(gè)部門做的事情。

這個(gè)部門的職責(zé)，用彭青的話講就是，轉(zhuǎn)換用戶訂單為各終端系統(tǒng)的生產(chǎn)單，并且按要求送達(dá)到相應(yīng)終端系統(tǒng)。舉個(gè)例子，就好比我們將采集到的原始食材按照客戶的不同口味（不同系統(tǒng)）進(jìn)行烹制，并且在指定的時(shí)間內(nèi)做好后送到客人（終端系統(tǒng)）那里，整個(gè)過程包括訂單的拆分轉(zhuǎn)移和訂單的下傳。其實(shí)我們從網(wǎng)站下的訂單（也叫原始單）在庫房是直接生產(chǎn)不了的，需要經(jīng)過OFC這個(gè)環(huán)節(jié)的處理后，才能到達(dá)各個(gè)生產(chǎn)系統(tǒng)。由此可見，這個(gè)環(huán)節(jié)必然會(huì)有大量數(shù)據(jù)需要處理，而且還要保證時(shí)間。

想必大家知道關(guān)于京東的211、311等配送方式，如果用戶選擇不同的配送時(shí)間，京東的快遞就必須在用戶指定的時(shí)間送達(dá)，而如果下游的生產(chǎn)系統(tǒng)收到訂單數(shù)據(jù)比較晚，就會(huì)影響后續(xù)的配送時(shí)間，最終會(huì)影響客戶體驗(yàn)?，F(xiàn)在訂單下傳，對(duì)接的全國(guó)庫房近150個(gè)，需要調(diào)用的外部處理訂單服務(wù)也有近20個(gè)，而每個(gè)系統(tǒng)的處理能力和響應(yīng)能力又各不同，這就需要我們進(jìn)行相應(yīng)的調(diào)節(jié)流量的配置，這其中只要有一個(gè)系統(tǒng)存在問題，就可能會(huì)影響訂單的下傳。

OFC的形成

2003年京東網(wǎng)站創(chuàng)立之后，迎來全國(guó)電商的快速發(fā)展，京東的業(yè)務(wù)隨之不斷增加，導(dǎo)致相應(yīng)的業(yè)務(wù)系統(tǒng)也在持續(xù)增加。直到2011年，隨著系統(tǒng)增多及業(yè)務(wù)的需要，逐漸成長(zhǎng)出來一個(gè)小團(tuán)隊(duì)，負(fù)責(zé)在各個(gè)系統(tǒng)之間進(jìn)行數(shù)據(jù)的傳輸，將客戶訂單數(shù)據(jù)傳到庫房，同時(shí)需要將非客戶訂單，如采購(gòu)單、供應(yīng)商、內(nèi)配單等二十多個(gè)業(yè)務(wù)傳輸?shù)较鄳?yīng)的業(yè)務(wù)系統(tǒng)，至此OFC成形。

初期由于各個(gè)系統(tǒng)的不完善，導(dǎo)致數(shù)據(jù)傳輸總是存在各種各樣的問題，訂單總會(huì)卡在這一環(huán)節(jié)，而作為傳輸環(huán)節(jié)又必須保證數(shù)據(jù)能正確傳輸完畢，這就需要我們必須了解上下游系統(tǒng)的業(yè)務(wù)及數(shù)據(jù)處理的過程，只有這樣才能知道問題產(chǎn)生的原因，才能知道該如何去處理問題。但是由于上下游的系統(tǒng)是需要經(jīng)常上線新需求的，我們每天需要及時(shí)了解上下游系統(tǒng)業(yè)務(wù)的處理，才能保證我們的環(huán)節(jié)沒有問題。

那段時(shí)間兄弟們真的很辛苦，每天需要處理上千個(gè)工單，加班更是常事，以至于一個(gè)同事說睡夢(mèng)中都在處理問題單。由于業(yè)務(wù)領(lǐng)域劃分存在問題，系統(tǒng)邊界不明確，導(dǎo)致出現(xiàn)許多莫名其妙的問題，兄弟們干得很苦很累，直到彭青來了之后。彭青帶著一個(gè)厚厚的黑色全框眼鏡，個(gè)子不算太高卻有個(gè)小肚腩，學(xué)生族的發(fā)型讓人感覺很親切。彭青根據(jù)他多年的工作經(jīng)驗(yàn)和對(duì)系統(tǒng)的理解，對(duì)這塊業(yè)務(wù)進(jìn)行重新劃分，逐漸將非客戶工單的數(shù)據(jù)傳輸工作交接給對(duì)應(yīng)系統(tǒng)進(jìn)行處理，將兄弟們解放出來，開始客戶訂單處理的新征程。

到2011年底的時(shí)候，在彭青的帶領(lǐng)下我們已經(jīng)成為了二十多人的團(tuán)隊(duì)。為了更進(jìn)一步拓展在客戶訂單方面的業(yè)務(wù)領(lǐng)域，我們主動(dòng)接手了訂單拆分系統(tǒng)和訂單轉(zhuǎn)移系統(tǒng)。這兩套元老級(jí)系統(tǒng)是用.Net編寫的，由于前輩們大都不在職了，文檔也不完善，對(duì)于系統(tǒng)內(nèi)部業(yè)務(wù)了解的人很少，修改非常難。而此時(shí)每天由于系統(tǒng)問題導(dǎo)致的事件單多達(dá)上百，也就是說每天運(yùn)維帶來的工作量都是可觀的，在這樣的情況下，接手這兩個(gè)系統(tǒng)自然全無阻力。

技術(shù)的改造

.Net到Java

系統(tǒng)接過來了，第一步要做的事情當(dāng)然是重寫。對(duì)技術(shù)的選取，根據(jù)當(dāng)時(shí)公司技術(shù)發(fā)展戰(zhàn)略以及Java的普及，我們選用了Java。重寫過程中需要梳理已有的業(yè)務(wù)，自然少不了不斷和原來系統(tǒng)的人員進(jìn)行交流，去確認(rèn)業(yè)務(wù)流程和技術(shù)處理細(xì)節(jié)。經(jīng)過一個(gè)多月，系統(tǒng)的重寫總算完成，接下來的工作就是上線了。

開始小流量地切，我們通過開關(guān)進(jìn)行控制，通過省市縣區(qū)域分流，到2012年2月系統(tǒng)算是上線了，而之前的.Net系統(tǒng)也逐漸退休了。到這時(shí)候，OFC逐漸根據(jù)業(yè)務(wù)劃分為3塊，第一塊是訂單拆分，第二塊是訂單的轉(zhuǎn)移，第三塊就是我們前面提到的訂單下傳和回傳。

這里要給大家解釋一下：

1. 訂單拆分，可能大家想到了，就是將用戶下的訂單，根據(jù)我們庫房的不同分布，比如大家電倉(cāng)、百貨倉(cāng)等進(jìn)行拆分。當(dāng)然這是拆分最初的也是最基本的理解，到后面會(huì)給大家講講現(xiàn)在的拆分是什么樣子。
2. 訂單的轉(zhuǎn)移則是根據(jù)拆分完的訂單以及庫存等屬性，將訂單轉(zhuǎn)移到下游的系統(tǒng)。
3. 訂單下傳和回傳主要是指，轉(zhuǎn)移之后的訂單調(diào)用庫房相關(guān)的預(yù)分解、打包等服務(wù)環(huán)節(jié)，進(jìn)行訂單下傳和生產(chǎn)，當(dāng)訂單順達(dá)客戶手里，還需要將訂單的相關(guān)數(shù)據(jù)進(jìn)行回傳。當(dāng)然這里只是粗略介紹，后面我們會(huì)更詳細(xì)地給大家呈現(xiàn)。

211訂單履約率提升項(xiàng)目

重寫完之后，系統(tǒng)總算可以正常運(yùn)轉(zhuǎn)了，而接下來的事情就是對(duì)系統(tǒng)的進(jìn)一步梳理和優(yōu)化，以更好地支持將來業(yè)務(wù)需求的發(fā)展以及技術(shù)方面的擴(kuò)展。當(dāng)然有的時(shí)候系統(tǒng)的改進(jìn)往往是由于外部業(yè)務(wù)的無法適應(yīng)導(dǎo)致的，這也符合變革的本質(zhì)。用戶體驗(yàn)至上一直是每一位京東人追求的目標(biāo)，就連我們的老劉也會(huì)隔三差五在網(wǎng)上下單來體驗(yàn)一下，而這次老劉發(fā)現(xiàn)了一些問題。當(dāng)他下單后，等了半天才收到訂單，這讓老劉無法忍受。經(jīng)過調(diào)查后發(fā)現(xiàn)，從下單到庫房竟然花了兩個(gè)多小時(shí)。

改造前的系統(tǒng)整體設(shè)計(jì)圖

于是老劉立即成立了一個(gè)叫作“211訂單履約率提升”的項(xiàng)目，該項(xiàng)目涉及11個(gè)系統(tǒng)的升級(jí)改造，包括訂單交易系統(tǒng)、訂單管道系統(tǒng)、拆分系統(tǒng)、轉(zhuǎn)移系統(tǒng)、訂單任務(wù)系統(tǒng)、OFC相關(guān)系統(tǒng)、預(yù)分揀系統(tǒng)、面單系統(tǒng)、增值稅資質(zhì)服務(wù)、發(fā)票系統(tǒng)、WMS系統(tǒng)。其中4個(gè)系統(tǒng)需要全面改造，3個(gè)系統(tǒng)需要大量改造，剩下的4個(gè)需要少量改造，而且由于與訂單相關(guān)的業(yè)務(wù)點(diǎn)多且邏輯復(fù)雜，無法在測(cè)試環(huán)境下全面測(cè)試。這不僅影響著整個(gè)訂單的正常生產(chǎn)，甚至?xí)绊懾?cái)務(wù)相關(guān)業(yè)務(wù)。項(xiàng)目任務(wù)非常重要，要求兩個(gè)月內(nèi)保證訂單從下單到庫房的時(shí)間縮短到5分鐘內(nèi)。大家馬上開始了工作——需求討論6天，設(shè)計(jì)方案5天，開發(fā)15天，功能測(cè)試20天，性能測(cè)試44天，上線部署調(diào)試26天，總計(jì)工時(shí)達(dá)5066小時(shí)，最終實(shí)現(xiàn)了項(xiàng)目目標(biāo)。與此同時(shí)訂單下傳各環(huán)節(jié)的服務(wù)性能指標(biāo)也得到了規(guī)范，使得訂單下傳趨于穩(wěn)定，理順了訂單下傳流程。技術(shù)方面也得到了鍛煉，使用了Zookeeper分布式配置、CXF Timeout設(shè)置、Log4j多Tomcat示例配置、Oracle數(shù)據(jù)庫分區(qū)轉(zhuǎn)歷史方案，數(shù)據(jù)庫使用了OracleExadata、MySQL。在這過程中和Oracle技術(shù)團(tuán)隊(duì)直接溝通多達(dá)10次，在數(shù)據(jù)庫設(shè)計(jì)方面、性能調(diào)優(yōu)、轉(zhuǎn)歷史數(shù)據(jù)方面都得到了提升。更為重要的是鍛煉了團(tuán)隊(duì)，對(duì)于戰(zhàn)勝艱巨任務(wù)有了更大的信心。下面是系統(tǒng)的整體設(shè)計(jì)圖。

改造后的系統(tǒng)整體設(shè)計(jì)圖

對(duì)于拆分，在幾位大牛對(duì)系統(tǒng)的業(yè)務(wù)進(jìn)行梳理后，發(fā)現(xiàn)部分業(yè)務(wù)有些混亂，業(yè)務(wù)領(lǐng)域劃分得不是很清楚，拆分系統(tǒng)中除了需要根據(jù)商品的不同屬性進(jìn)行拆分外，還需要對(duì)訂單中使用的金額、優(yōu)惠、運(yùn)費(fèi)等信息進(jìn)行分?jǐn)偺幚怼＿@幾位大牛敏銳地發(fā)現(xiàn)系統(tǒng)這樣設(shè)計(jì)是有問題的，于是就把金額信息處理邏輯拿出來，專門做成一個(gè)服務(wù)——OCS訂單金額計(jì)算服務(wù)（OCS），拆分只需要對(duì)其調(diào)用就可以。同時(shí)，我們對(duì)OCS分?jǐn)偨Y(jié)果的數(shù)據(jù)進(jìn)行了持久化數(shù)據(jù)存儲(chǔ)。系統(tǒng)這樣設(shè)計(jì)，不僅解耦了拆分服務(wù)之前混亂的業(yè)務(wù)處理邏輯，OCS的數(shù)據(jù)也一舉填補(bǔ)了公司這方面數(shù)據(jù)的空白，成為其他系統(tǒng)使用和處理業(yè)務(wù)邏輯的數(shù)據(jù)基礎(chǔ)來源。到現(xiàn)在為止，直接使用OCS數(shù)據(jù)的系統(tǒng)就有二十多個(gè)，其重要性不言而喻。

SOP合頁單項(xiàng)目

2013年，公司級(jí)項(xiàng)目SOP合頁單要啟動(dòng)，即用戶購(gòu)物車?yán)锛扔芯〇|自營(yíng)的商品同時(shí)有POP商家的商品（SOP）。在結(jié)算的時(shí)候只需要提交一次（之前只能分開提交，類似淘寶多商家的商品只能單獨(dú)提交）。為了改善用戶體驗(yàn)，同時(shí)需要將提交之后拆分完的子單結(jié)果顯示出來，需要我們團(tuán)隊(duì)提供一個(gè)拆分服務(wù)供交易組使用，這是一個(gè)重大的考驗(yàn)。下單環(huán)節(jié)的速度非?？?，TP99一般都是幾十毫秒，而我們目前的服務(wù)則是幾十秒，完全不在一個(gè)數(shù)量級(jí)。為了保證項(xiàng)目能夠順利完成，我們既需要滿足日常的業(yè)務(wù)需求，同時(shí)要新切出一個(gè)分支進(jìn)行修改，用于此次項(xiàng)目，同時(shí)需要將針對(duì)新需求的代碼及時(shí)同步到這兩個(gè)分支上，任務(wù)非常艱巨。解決了開發(fā)問題后，就要想著如何在性能上有所提升，比如，可以放在內(nèi)存里處理的就放在內(nèi)存中操作；盡量減少對(duì)外部服務(wù)的依賴；對(duì)于非同步化的操作進(jìn)行異步化；對(duì)于部分服務(wù)我們甚至采用降級(jí)的方式，在必要時(shí)通過開關(guān)進(jìn)行降級(jí)，保證整個(gè)服務(wù)的整體性能。如此這般后，我們主動(dòng)要求性能測(cè)試組對(duì)我們的服務(wù)進(jìn)行性能測(cè)試，在代碼級(jí)別進(jìn)行了優(yōu)化，最后在指定的時(shí)間內(nèi)成功地完成項(xiàng)目。而此時(shí)我們?cè)诰S護(hù)著同樣級(jí)別的3份拆分服務(wù)代碼，老的下單對(duì)應(yīng)的我們前面說的老拆分，新的下單對(duì)應(yīng)的我們新的拆分，還有我們?yōu)榻灰紫到y(tǒng)提供的預(yù)拆分。

而在此時(shí)最困擾我們的不是維護(hù)這些系統(tǒng)，而是經(jīng)常會(huì)由于網(wǎng)絡(luò)不好，使一個(gè)訂單的服務(wù)超時(shí)，進(jìn)而導(dǎo)致服務(wù)進(jìn)行重試，而事實(shí)上訂單已經(jīng)提交成功。這就可能使我們錯(cuò)誤地提交兩次甚至是多次訂單，比如客戶下一個(gè)原始單，需要拆分成兩單，但是由于上述原因可能會(huì)得到多單；如果用戶選擇貨到付款，會(huì)給用戶造成困擾，會(huì)帶來配送的成本，如果是在線支付的話則會(huì)導(dǎo)致公司的損失。剛開始的時(shí)候沒有解決方案，只能通過監(jiān)控去發(fā)現(xiàn)，發(fā)現(xiàn)后人為鎖定這些訂單，而這樣不但增加了運(yùn)維壓力，而且人工處理難免會(huì)有失誤。由于我們?cè)谔峤蛔訂沃皶?huì)獲取訂單號(hào)，每一次獲取的訂單號(hào)都是新的，這會(huì)導(dǎo)致調(diào)用這個(gè)服務(wù)時(shí)對(duì)訂單號(hào)是無法防重的。后來海波想到一個(gè)防重方案，就是我們?cè)谡{(diào)用這個(gè)服務(wù)之前將訂單號(hào)信息輸入自己的防重庫，新訂單來的時(shí)候先在防重庫中進(jìn)行查儲(chǔ)，如果有訂單信息則說明之前提交過，本次提交失敗，然后直接把庫里相同訂單號(hào)的數(shù)據(jù)拿出來提交即可，這樣還可以節(jié)省訂單號(hào)。如果庫里沒有查到，我們將該訂單號(hào)插入庫中，同時(shí)調(diào)用服務(wù)。問題得到有效解決。本次提交經(jīng)過這一系列的處理優(yōu)化，系統(tǒng)總算是比較穩(wěn)定了。

轉(zhuǎn)移架構(gòu)升級(jí)

轉(zhuǎn)移系統(tǒng)也進(jìn)行了大規(guī)模的調(diào)整，為了進(jìn)一步保證訂單及時(shí)準(zhǔn)確地轉(zhuǎn)移到下游的庫房系統(tǒng)，轉(zhuǎn)移團(tuán)隊(duì)在業(yè)務(wù)和技術(shù)架構(gòu)上進(jìn)行了一系列的改進(jìn)：業(yè)務(wù)和數(shù)據(jù)處理異步化，即將可以異步化處理的業(yè)務(wù)和數(shù)據(jù)放入分布式隊(duì)列，由對(duì)應(yīng)的模塊處理；使主流程業(yè)務(wù)簡(jiǎn)單快速流轉(zhuǎn)；數(shù)據(jù)處理并行化，將數(shù)據(jù)切割成多個(gè)業(yè)務(wù)單元，并行處理業(yè)務(wù)單元；針對(duì)變化少、實(shí)時(shí)性要求不嚴(yán)格的熱點(diǎn)數(shù)據(jù)，使用緩存并配以更新機(jī)制，以提高性能；對(duì)于業(yè)務(wù)洪峰，通過平滑控制保護(hù)后續(xù)系統(tǒng)不被洪峰壓垮。

在業(yè)務(wù)流程方面也進(jìn)行了優(yōu)化。由于涉及訂單生產(chǎn)流程，需求變化速度非常快，需要不斷梳理現(xiàn)有流程，去除不必要的流程，減少有新需求時(shí)對(duì)不必要業(yè)務(wù)流程和分支的考慮。同時(shí)，需要對(duì)現(xiàn)有分散業(yè)務(wù)不斷地抽象和改造，以方便業(yè)務(wù)擴(kuò)展。

面對(duì)這么多的優(yōu)化和改進(jìn)，每次上線的風(fēng)險(xiǎn)無疑是巨大的，如何規(guī)避風(fēng)險(xiǎn)呢？那就是要分流、可配置化，以及運(yùn)營(yíng)工具先行。由于新上線的項(xiàng)目風(fēng)險(xiǎn)較高，特別是容易忽視一些對(duì)外交互的小功能，而發(fā)生線上問題時(shí)又無法及時(shí)切換。因此，需要對(duì)業(yè)務(wù)上線進(jìn)行分流，并且通過靈活便捷的配置中心隨時(shí)進(jìn)行控制。對(duì)于異常情況一定要優(yōu)先考慮，并且開發(fā)相應(yīng)運(yùn)營(yíng)工具，以備緊急情況使用。尤其不能抱有僥幸心理，認(rèn)為小概率事件不會(huì)發(fā)生在自己身上。

轉(zhuǎn)移團(tuán)隊(duì)的負(fù)責(zé)人鐵總（大家總是這樣稱呼他）已經(jīng)從事電商十余年了。這個(gè)來自湘西的漢子對(duì)待工作總是嚴(yán)肅認(rèn)真，但面對(duì)生活卻又充滿熱情；結(jié)婚前總會(huì)泡在游戲中，或者癡迷羽毛球，女兒出生后便成為了他的一切。在談到轉(zhuǎn)移未來的規(guī)劃和發(fā)展時(shí)，他充滿自信地說：“將來會(huì)在保證客戶體驗(yàn)的同時(shí)，更多地通過在成本和流程上優(yōu)化來降低成本。庫存分配將在保證訂單履約的前提下，打破現(xiàn)在先下單先占庫存的規(guī)則，提高商品庫存周轉(zhuǎn)率和現(xiàn)貨率，同時(shí)給客戶提供更早的收貨時(shí)間選擇”。

轉(zhuǎn)移系統(tǒng)整體流程圖

不得不愛的運(yùn)維

剛開始負(fù)責(zé)客戶訂單系統(tǒng)時(shí)，每天要處理上千條Ticket（訂單事件），而現(xiàn)在只需處理幾十條。這種銳減，不僅說明了系統(tǒng)日漸健康、業(yè)務(wù)逐漸規(guī)范，更證明了我們的運(yùn)維流程和運(yùn)維制度正日趨成熟。這些成果都離不開善于分析總結(jié)的文杰，他是一位來自山東的80后，在團(tuán)隊(duì)中主要負(fù)責(zé)運(yùn)營(yíng)流程優(yōu)化和與協(xié)調(diào)相關(guān)的工作，團(tuán)隊(duì)在運(yùn)維方面的問題目前還沒有他解決不了的。OFC是連接用戶和全國(guó)終端庫房的重要的通道樞紐，這其中的任何系統(tǒng)出了問題，都會(huì)導(dǎo)致訂單無法正確實(shí)時(shí)地到達(dá)終端庫房，后果都是不堪設(shè)想的。因此，每新增加一個(gè)庫房都需要團(tuán)隊(duì)進(jìn)行庫房的終端系統(tǒng)部署和調(diào)試，直至生產(chǎn)系統(tǒng)測(cè)試完成為止，我們稱此為開倉(cāng)過程。隨著公司不斷發(fā)展壯大，訂單業(yè)務(wù)不斷完善，全國(guó)現(xiàn)存?zhèn)}庫已超過150個(gè)，這都是文杰和團(tuán)隊(duì)無數(shù)日夜的付出換得的。支持審計(jì)也是不可忽略的一部分工作，每季度我們都會(huì)給同事講解新業(yè)務(wù)，給他們解釋差異訂單的原因。同時(shí)，我們還負(fù)責(zé)新業(yè)務(wù)的學(xué)習(xí)推廣，讓團(tuán)隊(duì)的新成員能夠快速了解業(yè)務(wù)知識(shí)、熟悉業(yè)務(wù)系統(tǒng)。伴隨著業(yè)務(wù)和系統(tǒng)的日漸完善，我們也在不斷地嘗試和推廣系統(tǒng)的智能化運(yùn)維與支持，相信在不久的將來我們一定會(huì)實(shí)現(xiàn)無人化系統(tǒng)運(yùn)維。

從618到雙11

從2012年開始，店慶促銷活動(dòng)力度在逐次增加，訂單量則成倍增長(zhǎng)。伴隨著訂單量的增加，系統(tǒng)面臨的挑戰(zhàn)與日俱增——訂單業(yè)務(wù)越來越繁雜，業(yè)務(wù)處理流程也越來越多，很容易出現(xiàn)數(shù)據(jù)不一致問題。因此，在處理海量訂單時(shí)保障數(shù)據(jù)一致性非常關(guān)鍵。系統(tǒng)整體控制上要采用流程控制中心，而不是階梯式控制。之前由于直接依賴數(shù)據(jù)庫，數(shù)據(jù)庫最終會(huì)成為影響訂單處理的瓶頸，數(shù)據(jù)的一致性很難得到保證，而采用流程控制中心模式則可以大大減少數(shù)據(jù)不一致發(fā)生的幾率，同時(shí)可以借助工作流和狀態(tài)機(jī)實(shí)現(xiàn)中心控制，這樣既便于運(yùn)營(yíng)，又方便及時(shí)發(fā)現(xiàn)和解決問題單據(jù)。

流程控制中心和階梯式控制

支持海量訂單處理

無論系統(tǒng)如何優(yōu)化，單個(gè)系統(tǒng)總有瓶頸，要支持不斷增長(zhǎng)的訂單處理量，關(guān)鍵在于提高系統(tǒng)的擴(kuò)展能力。首先，核心系統(tǒng)的每一層都要有擴(kuò)展能力，可以以實(shí)例為單位進(jìn)行擴(kuò)展，也可以以集群為單位進(jìn)行擴(kuò)展。其次，系統(tǒng)整體要有擴(kuò)展能力，可以根據(jù)實(shí)際業(yè)務(wù)特點(diǎn)，從業(yè)務(wù)上進(jìn)行垂直拆分以實(shí)現(xiàn)擴(kuò)展，也可以通過分布式部署來方便地增加一個(gè)具備整體功能的集群，從而快速增加處理能力。這相比僅做備份系統(tǒng)而言，節(jié)約了成本。

所有核心的OFC訂單處理系統(tǒng)已實(shí)現(xiàn)了水平擴(kuò)展能力，部分系統(tǒng)實(shí)現(xiàn)了分布式部署改造。在2014年618大促前，正是由于系統(tǒng)具備這種擴(kuò)展能力，才能夠在非常短的時(shí)間內(nèi)擴(kuò)展了處理能力，保障了大促的順利開展。我們的最終目標(biāo)是，所有核心系統(tǒng)都要完成分布式部署。

解決數(shù)據(jù)一致性問題

早期的訂單處理流程分散到多個(gè)應(yīng)用系統(tǒng)中，數(shù)據(jù)來源不統(tǒng)一，也缺乏統(tǒng)一的狀態(tài)機(jī)控制，經(jīng)常出現(xiàn)數(shù)據(jù)不一致問題。但同時(shí)，也不可能由一個(gè)系統(tǒng)來管理所有的流程，因?yàn)榫S護(hù)和管理工作會(huì)非常龐雜。解決辦法是，梳理出訂單處理的主流程和狀態(tài)機(jī)，然后由主流程系統(tǒng)負(fù)責(zé)整體流程的調(diào)度和數(shù)據(jù)的推送。這個(gè)主流程可能跨大的業(yè)務(wù)域，如物流領(lǐng)域和資金領(lǐng)域，每個(gè)領(lǐng)域內(nèi)可以有工作流，但不能與主流程沖突。識(shí)別出主流程系統(tǒng)還有其他的優(yōu)點(diǎn)：一是可只重點(diǎn)建設(shè)主流程相關(guān)系統(tǒng)，使其成為穩(wěn)定的系統(tǒng)集群，而非主流系統(tǒng)則可以投入較少的成本，從而既有利于保障業(yè)務(wù)順利開展，又能降低整體建設(shè)成本；二是主流程系統(tǒng)可以有效地保障生產(chǎn)計(jì)劃的執(zhí)行；三是主流程系統(tǒng)可調(diào)節(jié)系統(tǒng)流量，有效地平滑業(yè)務(wù)高峰，保護(hù)主流程相關(guān)各主要系統(tǒng)的穩(wěn)定運(yùn)行。

支撐運(yùn)營(yíng)工作

對(duì)運(yùn)營(yíng)工作的支持，包括搶險(xiǎn)、預(yù)防，以及“治理+預(yù)防的升級(jí)”。在早期階段，系統(tǒng)架構(gòu)主要是支撐業(yè)務(wù)功能的實(shí)現(xiàn)，沒有為運(yùn)營(yíng)而設(shè)計(jì)，線上系統(tǒng)會(huì)因?yàn)楦鞣N意外而影響業(yè)務(wù)，讓系統(tǒng)團(tuán)隊(duì)疲于應(yīng)付。后來，確立了為可運(yùn)營(yíng)而設(shè)計(jì)的理念和原則，設(shè)計(jì)時(shí)必須考慮可監(jiān)控、可運(yùn)營(yíng)，同時(shí)把可用性、穩(wěn)定性、健壯性等列為設(shè)計(jì)的重點(diǎn)，在實(shí)踐過程中確立了自己的方法論。

第一，對(duì)系統(tǒng)進(jìn)行梳理，識(shí)別出核心系統(tǒng)，把核心系統(tǒng)建設(shè)成為可用性高、可靠性高的系統(tǒng)，保障這些系統(tǒng)少出問題，出問題后系統(tǒng)要能自動(dòng)恢復(fù)。

第二，保證系統(tǒng)出現(xiàn)問題后能快速發(fā)現(xiàn)問題，甚至在問題發(fā)生前發(fā)出報(bào)警。為此需要有對(duì)數(shù)據(jù)積壓量趨勢(shì)的監(jiān)控，以及在有積壓情況下吞吐能力的監(jiān)控。這些監(jiān)控需要及時(shí)，我們針對(duì)分布式系統(tǒng)，開發(fā)了分布式監(jiān)控系統(tǒng)，能夠迅速地反應(yīng)每個(gè)部署的每一個(gè)實(shí)例的情況，又能收集整體的運(yùn)行情況。

第三，保證發(fā)現(xiàn)問題后可以快速定位和處理。為此我們?cè)O(shè)計(jì)了集系統(tǒng)處理能力、數(shù)據(jù)積壓情況、數(shù)據(jù)處理情況、日志、系統(tǒng)負(fù)載于一體的統(tǒng)合分析工具。

第四，一個(gè)系統(tǒng)出現(xiàn)問題，往往會(huì)將影響傳遞到其他系統(tǒng)，系統(tǒng)治理勢(shì)在必行，目前我們已有SOA治理平臺(tái)（正在優(yōu)化過程中），目標(biāo)是能夠理清各系統(tǒng)的血緣關(guān)系，完善SLA體系；在出現(xiàn)問題后可以及時(shí)評(píng)估出受影響的系統(tǒng)，快速做出應(yīng)急響應(yīng)。

海量數(shù)據(jù)的開始

總原則

訂單處理系統(tǒng)與交易系統(tǒng)本身是存在區(qū)別的。交易系統(tǒng)直接面對(duì)客戶，所以系統(tǒng)可用性要求和性能要求非常高，特別是在高并發(fā)情況下的系統(tǒng)表現(xiàn)，所以交易系統(tǒng)在架構(gòu)上的重點(diǎn)在于解決這兩個(gè)方面的問題。而訂單處理則不同，系統(tǒng)短時(shí)間不可用，響應(yīng)出現(xiàn)延遲不會(huì)對(duì)客戶造成直接影響，也就說我們關(guān)心的是平均值而不是某時(shí)刻的峰值。訂單處理系統(tǒng)架構(gòu)設(shè)計(jì)的關(guān)鍵在于如何處理海量數(shù)據(jù)，以及數(shù)據(jù)一致性的保障。近年來，京東的業(yè)務(wù)領(lǐng)域不斷拓展，訂單量飛速增加，所以必須保障系統(tǒng)吞吐能力得到提升。與此同時(shí)由于涉及的系統(tǒng)眾多，各系統(tǒng)業(yè)務(wù)處理方式和流程不同，導(dǎo)致各系統(tǒng)性能指標(biāo)差異較大，所以要定義好各個(gè)系統(tǒng)的SLA指標(biāo)。由于訂單的業(yè)務(wù)越來越復(fù)雜，那么系統(tǒng)的業(yè)務(wù)流程也會(huì)越來越多，這就需要我們劃分好主次業(yè)務(wù)流程以及優(yōu)先級(jí)，同時(shí)需要設(shè)計(jì)靈活多樣的降級(jí)方案，保證主業(yè)務(wù)正常運(yùn)營(yíng)。

OFC整體架構(gòu)圖

系統(tǒng)保護(hù)

涉及OFC調(diào)用的訂單系統(tǒng)很多，而各個(gè)系統(tǒng)處理的能力均不相同，不是所有的系統(tǒng)都要承擔(dān)高峰值處理的壓力。這就需要有針對(duì)性地控制、調(diào)用這些系統(tǒng)，具備削峰和流量控制的功能，以間接保護(hù)上下游系統(tǒng)，防止調(diào)用方的系統(tǒng)雪崩式掛掉。還有就是監(jiān)控，要有統(tǒng)一的產(chǎn)能監(jiān)控；要防止過載，在過載之前要能進(jìn)行控制，要保證自身系統(tǒng)的安全穩(wěn)定，還可以采用快速拒絕的機(jī)制。

分布式系統(tǒng)

主要是在擴(kuò)展方面進(jìn)行設(shè)計(jì)，保證系統(tǒng)每個(gè)切片可以水平擴(kuò)展，也可以以集群為單位進(jìn)行擴(kuò)展，實(shí)現(xiàn)分布式任務(wù)隊(duì)列。我們每一個(gè)Group能處理的訂單量在可控制的范圍內(nèi)，一旦某一處出現(xiàn)瓶頸，可以隨時(shí)部署一個(gè)或一套Group。下圖中不同Group可以彼此獨(dú)立部署，也可以整體部署，當(dāng)某一處出現(xiàn)問題時(shí)可以單獨(dú)進(jìn)行部署，或者整體流量大時(shí)也可以復(fù)制部署。

分布式系統(tǒng)架構(gòu)

而分布式任務(wù)處理架構(gòu)圖如下，在分布式任務(wù)處理引擎的基礎(chǔ)上，我們可以通過在圖下方左側(cè)的分布式任務(wù)隊(duì)列（Redis緩存）中取任務(wù)，然后由我們的引擎一步一步去調(diào)度相應(yīng)的服務(wù)，將結(jié)果返回給對(duì)應(yīng)的服務(wù)進(jìn)行業(yè)務(wù)處理，同時(shí)也返回我們需要的結(jié)果，真正將交易快照數(shù)據(jù)轉(zhuǎn)換為生產(chǎn)單據(jù)，最后將數(shù)據(jù)推送到客戶端系統(tǒng)，比如庫房系統(tǒng)、POP商家系統(tǒng)。

分布式任務(wù)處理架構(gòu)

分布式任務(wù)隊(duì)列設(shè)計(jì)可以通過下圖說明。首先我們會(huì)對(duì)任務(wù)進(jìn)行分片，定義每一個(gè)任務(wù)為一片，然后將任務(wù)在任務(wù)執(zhí)行器中加以處理，而每個(gè)任務(wù)執(zhí)行器又有多個(gè)線程去處理和調(diào)用不同的服務(wù)，最終再將結(jié)果返回。這里還會(huì)有一個(gè)異常任務(wù)隊(duì)列，對(duì)于那些處理失敗的任務(wù)，會(huì)將其放入異常任務(wù)執(zhí)行隊(duì)列，進(jìn)行異常處理流程的執(zhí)行?？赡艽蠹視?huì)想，如果系統(tǒng)掛了，那個(gè)任務(wù)的數(shù)據(jù)也將丟失，沒有執(zhí)行完任務(wù)怎么辦。事實(shí)上只要我們的原始訂單數(shù)據(jù)存在，完全可以恢復(fù)為再次執(zhí)行，最多執(zhí)行會(huì)緩慢，但不會(huì)導(dǎo)致數(shù)據(jù)一致性出現(xiàn)問題。

分布式任務(wù)隊(duì)列設(shè)計(jì)

我們的分布式任務(wù)隊(duì)列采用了工作流的機(jī)制，支持靈活的流程配置，這主要通過Zookeeper來進(jìn)行分布式配置，可以動(dòng)態(tài)添加業(yè)務(wù)處理環(huán)節(jié)。同時(shí)，可以自動(dòng)調(diào)節(jié)系統(tǒng)的吞吐量，當(dāng)任何一個(gè)環(huán)節(jié)出現(xiàn)問題時(shí)，都會(huì)進(jìn)行自動(dòng)降速，當(dāng)問題得以解決后，我們會(huì)進(jìn)行自動(dòng)增速，保證系統(tǒng)的吞吐量；我們還可以通過配置對(duì)一些高級(jí)別的訂單進(jìn)行優(yōu)先生產(chǎn)處理。

系統(tǒng)部署如下圖所示：

系統(tǒng)部署圖

一直在路上的OFC人

從2011年6月初只有五六個(gè)人的小組，到今天三十多人的團(tuán)隊(duì)，從開始只負(fù)責(zé)非客戶訂單相關(guān)業(yè)務(wù)系統(tǒng)，到今天負(fù)責(zé)公司核心的0級(jí)訂單系統(tǒng)，OFC業(yè)務(wù)范圍橫跨了整個(gè)訂單生產(chǎn)過程的大半個(gè)生命周期。是的，就是這些普通人，在紛亂中不迷茫，在歡笑中不忘使命，表面屌絲內(nèi)心渴望前進(jìn)的OFC人，義無反顧地堅(jiān)持在訂單系統(tǒng)的一線上。回望著走過的路，我們竟如此平靜而淡定，遙望遠(yuǎn)方，我們依舊充滿激情，依舊會(huì)綻放陽光般的笑容。因?yàn)檫@是個(gè)偉大的時(shí)代，偉大的國(guó)度，因?yàn)檫@里有一群偉大的人在做著一件偉大的事情——為了讓購(gòu)物變得簡(jiǎn)單快樂，而我們便是那群人。

OFC開發(fā)團(tuán)隊(duì)及測(cè)試團(tuán)隊(duì)合影