国产色视频网免费

OFC的重要性

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

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

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

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

OFC的形成

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

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

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

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

技術(shù)的改造

.Net到Java

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

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

這里要給大家解釋一下：

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

211訂單履約率提升項目

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

改造前的系統整體設計圖

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

改造后的系統整體設計圖

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

SOP合頁(yè)單項目

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

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

轉移架構升級

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

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

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

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

轉移系統整體流程圖

不得不愛(ài)的運維

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

從618到雙11

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

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

支持海量訂單處理

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

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

解決數據一致性問(wèn)題

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

支撐運營(yíng)工作

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

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

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

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

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

海量數據的開(kāi)始

總原則

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

OFC整體架構圖

系統保護

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

分布式系統

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

分布式系統架構

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

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

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

分布式任務(wù)隊列設計

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

系統部署如下圖所示：