本篇文章來自于2018年12月22日舉辦的《阿里云棲開發(fā)者沙龍—Java技術(shù)專場》，梁笑專家是該專場第一位演講的嘉賓，本篇文章是根據(jù)梁笑專家在《阿里云棲開發(fā)者沙龍—Java技術(shù)專場》的演講視頻以及PPT整理而成。

摘要：2018年雙十一平穩(wěn)度過，海量訂單、零點流量高峰，阿里是如何實現(xiàn)供應(yīng)鏈99.9%的下單成功率？本次分享中，阿里2018年雙十一大促供應(yīng)鏈服務(wù)保障平臺負責(zé)人向大家詳細闡述大促前4個月的全程經(jīng)歷。面對大促第一步需要做什么，流量峰值如何評估，性能優(yōu)化從何處著手，一套有條不紊的供應(yīng)鏈服務(wù)平臺迎接大促的解決方案至關(guān)重要。

演講嘉賓簡介：

梁笑，阿里新零售供應(yīng)鏈平臺事業(yè)部，擅長 Java、Spring、OOP、分布式、架構(gòu)設(shè)計，參與過供應(yīng)鏈服務(wù)決策平臺、雙十一大促等項目，對業(yè)務(wù)開發(fā)、大促保障、架構(gòu)設(shè)計等有所涉獵。

本次直播視頻精彩回顧，戳這里！

PPT下載地址：https://yq.aliyun.com/download/3183

以下內(nèi)容根據(jù)演講嘉賓視頻分享以及PPT整理而成。

本文圍繞雙十一大促歷程，從以下幾方面介紹供應(yīng)鏈服務(wù)平臺如何迎接大促：

1. 概述

2. 梳理鏈路

3. 峰值評估

4. 容量評估

5. 性能優(yōu)化

6. 依賴改造

7. 保障協(xié)同

8. 壓測檢驗

9. 項目協(xié)同

10. 監(jiān)控治理

11. 戰(zhàn)前準(zhǔn)備

12. 總結(jié)

一、概述

大家熟悉的供應(yīng)鏈服務(wù)包括庫存控制、計劃調(diào)撥等，這里介紹的供應(yīng)鏈服務(wù)更偏向于交易側(cè)。例如在淘寶或天貓購買物品時，會有今日下單預(yù)計某日送達等物流提示，這種物流時效承諾即是由供應(yīng)鏈服務(wù)平臺提供。再如，購買電冰箱、空調(diào)等大件需要預(yù)約配送時，需要選擇指定的配送商或者貨到付款、拆單合單等物流透出，都需要供應(yīng)鏈服務(wù)平臺的支持。除了這些大家作為消費者可以直觀感受到的服務(wù)外，商家的商品入庫發(fā)貨等操作也都離不開供應(yīng)鏈服務(wù)平臺。因為大促時物流服務(wù)需要實時透出，服務(wù)平臺是需迎接雙十一實時下單的高流量的，此外服務(wù)平臺還需要承接物流發(fā)貨的服務(wù)透出，例如發(fā)貨的倉庫、路線、發(fā)貨時效及服務(wù)等。因此，供應(yīng)鏈服務(wù)平臺在阿里體系中扮演了一個上承交易、下接物流的腰部力量，主要包括物流服務(wù)、物流透出、商家訂購、容量管控等功能。物流服務(wù)及物流透出上述已提及，商家訂購包含倉訂購和快遞資源訂購，容量管控是指物流干線的容量能力，例如從北京到上海，可以在當(dāng)日送達的物流能力為一千單，超過一千單外的便無法達到這樣的物流時效訴求。至此，大家應(yīng)大致了解了供應(yīng)鏈服務(wù)平臺的概念。

供應(yīng)鏈服務(wù)平臺保障的過程如下圖所示：

如何在業(yè)務(wù)容量峰值時保障系統(tǒng)，該采取哪些措施，這是一個不小的挑戰(zhàn)。首先，需要分析出哪些接口需要重點保障，哪些薄弱點或性能低下的鏈路需要重點評估。接下來，需要對這些進行優(yōu)化操作。然后，對優(yōu)化后的接口通過自測或壓測進行驗證。驗證過程中可能會發(fā)現(xiàn)，已有的問題解決了但是出現(xiàn)了新的問題，這就需要再次分析優(yōu)化。這是個螺旋上升形的過程。上圖右側(cè)是保障過程的階段描述，會在接下來進行詳細闡釋。

二、梳理鏈路

如果給你一個系統(tǒng)，在你不了解的情況下，讓你在流量峰值下保障系統(tǒng)的穩(wěn)定性，首先你需要明確要做的事情，清晰目標(biāo)任務(wù)的范圍。因此，第一步就是梳理系統(tǒng)業(yè)務(wù)的鏈路，對系統(tǒng)有宏觀全面的認識，這是保障大促穩(wěn)定性的前提。但是，以服務(wù)平臺的現(xiàn)狀來說，有以下幾個通病：祖?zhèn)鞔a、上古應(yīng)用、文檔缺失、無人可問。阿里的服務(wù)平臺自2011年開始經(jīng)歷過三次較大的升級改造，每次升級大部分核心功能會下架升級，但仍有某些小功能無法改造。這就造成在2018年的大促保障時還需要閱讀2011或2012年的代碼，甚至某些應(yīng)用都無法打印日志。文檔缺失、無人可問也使系統(tǒng)保障更加困難。

梳理鏈路可以分為以下四步進行：

1. 梳理對外接口。在日常開發(fā)中，主要的業(yè)務(wù)邏輯代碼大約包含四五個對外接口，但是通常來說實際會比這要多。在對服務(wù)平臺的鏈路梳理中，新老三版系統(tǒng)包含大約80多個對外接口。但在實際工作中，只會涉及十個接口左右。可見，這些接口存在巨大的冗余。某些接口可能已不再使用，或某些接口有使用者，但使用者并沒有意識到在調(diào)用該接口。因此，梳理對外接口就是梳理出接口是否在實際提供服務(wù)。

2. 移除無用接口。在剩下的70多個接口中，一定有無用的部分，移除這些接口也是移除了潛在的bug出現(xiàn)。這可以通過查看調(diào)用者、分析流量或者咨詢使用者來進行移除。在這個階段，阿里的供應(yīng)鏈服務(wù)系統(tǒng)大約下架了近40個廢接口，如此大幅縮小了需要保障的系統(tǒng)范圍。

3. 梳理剩余接口。這個階段中將各接口按照重要性進行保障力度的劃分，例如某些接口是需要重點保障的，而某些接口無需重點保障，不應(yīng)占用寶貴的機器資源、數(shù)據(jù)庫資源等，例如一些查詢功能的端頁面，在大促時出現(xiàn)問題也不會產(chǎn)生重大影響。

4. 確認強弱依賴。對劃分出的需要重點保障的接口需再次梳理出相互間的強弱依賴關(guān)系，這就需要理清系統(tǒng)的業(yè)務(wù)邏輯。例如在阿里的大促系統(tǒng)中，如果庫存出現(xiàn)問題，那么緊接其后的訂單、配送等接口也都會混亂，這便是一個強依賴過程。因此，這里應(yīng)設(shè)置成如果庫存出現(xiàn)問題，下單只能返回失敗。弱依賴過程則不同，例如根據(jù)歷史數(shù)據(jù)得知某消費者經(jīng)常使用某一個自提站點，如果在大促中，自提站點的鏈路掛掉，分配的不是這個自提點，雖然這可能會導(dǎo)致消費者的愉悅感下降，但下單過程不會產(chǎn)生太大的問題。此外，還需對接口的調(diào)用量和調(diào)用比例進行統(tǒng)計梳理，例如調(diào)用一次A接口，可能會在下游調(diào)用一次或若干次B或C接口，通過這個比例可以根據(jù)A接口流量的增長幅度計算下游的接口流量。

如此梳理完成后便可以產(chǎn)出一份鏈路文檔，大致掌握了需要重點保障的部分、可能的調(diào)用方、可能的消費者、消費的量級、涉及的數(shù)據(jù)庫、緩存中間件、鏈路的強弱依賴等信息，這是后續(xù)工作的綱領(lǐng)性文件。

三、峰值評估

在有了這份綱領(lǐng)性文件之后，則需要明確任務(wù)目標(biāo)。對這樣實時下單的強依賴系統(tǒng)來說，最直觀的的目標(biāo)是要支撐住雙十一零點的交易峰值。這就需要評估這個交易峰值是多少，畢竟每個系統(tǒng)被核心的交易系統(tǒng)調(diào)用的頻率并不相同。峰值可以根據(jù)交易下單量、業(yè)務(wù)預(yù)測和歷史經(jīng)驗來進行評估。交易下單量相對來說確定性較高，因為這在系統(tǒng)內(nèi)部可以通過限流解決。當(dāng)下單量超出了系統(tǒng)的承受力，則直接返回下單失敗，讓消費者再次下單即可。因此每秒的最高下單量是相對確定的值。業(yè)務(wù)預(yù)測是指對每個行業(yè)線的下單量進行預(yù)測。即使知道每秒的下單總量，卻無法知道例如天貓超市或者某個行業(yè)線的細化下單量，那么便收集該行業(yè)線下的店鋪信息，再根據(jù)一些專業(yè)知識進行評估。這樣的業(yè)務(wù)預(yù)測值是缺少瞬值的，例如它可能可以預(yù)測出一天的單量，但無法預(yù)測0點那一秒的單量。因此，還是需要根據(jù)歷史經(jīng)驗來彌補這個缺陷。例如根據(jù)前三年的大促流量分布、雙十一前的三八大促九九大促流量分布等數(shù)據(jù)，進行流量預(yù)估得到流量漏斗。甚至在大促前，對某些鏈路進行了改造變更等操作的，也需要在流量預(yù)估的過程中詳盡考慮。由上述可見，在這樣輸入有限的情況下，需要抽絲剝繭得出一份可能性較高的峰值評估。

這樣的峰值評估主要為兩方面，如下圖所示。一部分是接口峰值，這會用于指導(dǎo)保障整個系統(tǒng)。例如若下單量為十萬，那么商品詳情接口大約會產(chǎn)生三十萬流量，渲染下單接口十二萬到十五萬，真正下單扣減約七到八萬，這些值會指導(dǎo)進行系統(tǒng)下單時的重點保障。另一部分是行業(yè)峰值。例如下單量為十萬時，快消品牌和美妝產(chǎn)品各自的單量為多少，這會直接顯示出系統(tǒng)各行業(yè)所需要的下單承受能力。

四、容量評估

確定了任務(wù)目標(biāo)后，就需要評估現(xiàn)有的機器容量是否可以支撐預(yù)估的流量峰值。阿里的供應(yīng)鏈服務(wù)平臺是一個單元化的應(yīng)用，可以理解為一個跨城市跨機房的異地部署過程。每個單元（機房）有不同的流量承受能力，例如可以在華北設(shè)立機房承受30%流量，華南機房承受30%流量，華東機房承受40%流量。接著通過壓測等方法可以方便的得出單機性能，測試出健康情況下單機的QPS流量。例如，UNSZ（深圳單元）需要承擔(dān)6.52%的流量，結(jié)合單機性能預(yù)估需要的機器數(shù)量，根據(jù)比例得出預(yù)估QPS值。接下來需要考慮，現(xiàn)有的機器能滿足預(yù)估狀況嘛？是否有缺口？如果存在缺口，是可以通過優(yōu)化還是申請預(yù)算解決呢？最短的木板（壓力最大的部分）是哪里？因為各個機房的實際性能存在差異，這部分差異也需要考慮在內(nèi)。根據(jù)最短木板確定限流保護值，重點保障最危險的單元。此外，在容量評估時，最好預(yù)留一定的buffer，保障可能超出的流量。

五、性能優(yōu)化

基于已有的機器預(yù)算，和之前梳理出的接口鏈路，接下來需要一些手段優(yōu)化性能來支持峰值流量。不僅包括對古老代碼的優(yōu)化，也需要對新產(chǎn)生的代碼進行改進。下圖展示了供應(yīng)鏈服務(wù)平臺的大促性能優(yōu)化中采取的主要手段：

這些細節(jié)化手段這里不再贅述，大家可以參考一些web技術(shù)文檔即可了解，這里重點為大家介紹如何梳理上述優(yōu)化過程。沒有一個整體的方法論，貿(mào)然入手消耗的精力暫且不談，達到的效果可能也不盡人意。這些優(yōu)化手段主要通過分析阿里的業(yè)務(wù)特點及雙十一的玩法特點得出。例如，若某一地區(qū)的倉配產(chǎn)能不高，無法實現(xiàn)物流時效承諾，那么撤下物流時效承諾的同時，與其相關(guān)的鏈路也可以一同撤下，這便大大提升了這一塊的性能。因此，提升性能不只是通過內(nèi)存調(diào)優(yōu)等，也可以根據(jù)業(yè)務(wù)邏輯來調(diào)整。優(yōu)化的各個步驟如下：

1. 減少流量。在客戶端或服務(wù)端屏蔽流量，降低不必要的調(diào)用，這樣的性能優(yōu)化效果最為可觀。

2. 移除或降級IO。根據(jù)業(yè)務(wù)需求盡可能的下線無用的IO邏輯或者根據(jù)業(yè)務(wù)特點降級部分IO。

3. 減少IO調(diào)用。例如在貨品查詢IO中，可能會采用多個for循環(huán)來進行查詢，那么便可以采用批量查詢來代替單個查詢。

4. 移除本地IO。移除和檢查沒用的日志和濫用的日志。某些debug代碼在平時產(chǎn)生的流量不會引起大家注意，但是在全鏈路壓測驗證時就可能產(chǎn)生非常多流量以致線程卡住。

5. 使用緩存。短時間內(nèi)數(shù)據(jù)不變的情況下，進行緩存，避免多余的IO。這種方式在大促時效果尤為明顯。在電商行業(yè)，類似某個店鋪與貨品的綁定關(guān)系在大促時間內(nèi)基本不會變化，這種不變的數(shù)據(jù)使用緩存效果最佳。

6. 緩存命中率。在平時緩存可能設(shè)定失效時間為幾十分鐘，但是大促時可以禁止該類影響穩(wěn)定性的操作，將失效時間設(shè)置為幾個小時甚至十幾小時。拉長緩存失效時間，可以極大的提高緩存命中率，平時的命中率大約在60%-70%左右，在大促時這個數(shù)據(jù)提升到了99.99%。此外，還需要充分預(yù)熱。

7. 緩存吞吐。除了本地緩存外，大家可能都會使用遠程緩存，例如redis等。阿里巴巴使用tair緩存，對其序列化方式進行了修改。java自帶的序列化方式性能較差，得到的序列化對象也字節(jié)較大，因此將其改成了Hessian方式（沒有選擇kryo或protobuf是因為當(dāng)時轉(zhuǎn)換成Hessian方式最為簡便）。同時精簡字段，假設(shè)某個返回對象有十個字段，但對外接口只需使用兩三個。大家知道，帶寬一定的情況下，單個數(shù)據(jù)量越大，同時能通行的數(shù)據(jù)就越少。流量峰值時，帶寬通常都會比較緊張，那么便無需將剩下的廢字段也存入緩存。進行了上述改進，緩存的吞吐有了很大程度的好轉(zhuǎn)。

8. 本地緩存。盡量使用本地緩存在tair前擋一層，避免網(wǎng)絡(luò)IO。本地緩存不可能存太多，但是在某些極限情況，例如卡券類或紅包等，當(dāng)天調(diào)用極其頻繁并且不會變化，這樣的數(shù)據(jù)可以緩存在堆外內(nèi)存中。

9. 數(shù)據(jù)庫。在解決了數(shù)據(jù)IO的大部分問題后，便可以采取一些更細致的優(yōu)化手段。例如檢查慢的SQL，索引使用是否正確，有沒有離線拖庫任務(wù)，是否可以清理一些碎片等。

10. 本地代碼。去掉高頻率低效的本地代碼。但根據(jù)經(jīng)驗，這種手段得到的優(yōu)化效果有限。

因此，縱觀整個優(yōu)化思路，減少IO和使用緩存是優(yōu)化性能的效果較為明顯的方法。

六、依賴改造

在性能優(yōu)化后，大致不會在峰值時出現(xiàn)宕機的情況，但仍需要進行強弱依賴的改造，即強依賴改為弱依賴，弱依賴改為強依賴。強依賴是指如果對兄弟系統(tǒng)、數(shù)據(jù)庫或緩存的調(diào)用出現(xiàn)問題，那么流程直接中斷。弱依賴指即使這部分宕掉，可以直接設(shè)置超時或者熔斷，并不會影響流程的后續(xù)。強弱依賴的改造其實是一個兜底的過程。將某些錯誤的強依賴改為弱依賴，使其不會影響核心流程，防止雪崩。其次，將一些弱依賴改為強依賴。第一種是確定性的依賴更改。例如如果下單成功需要將扣減庫存數(shù)量，如果庫存數(shù)量沒有扣減成功，會導(dǎo)致后續(xù)各種問題，如果之前采用的措施是將這個異常catch住繼續(xù)后面的流程，那么這里就需要更改為拋出異常阻斷流程。第二種是下游重依賴的數(shù)據(jù)。第三種是可能會造成資損的數(shù)據(jù)。強弱依賴更改實際上就是對業(yè)務(wù)負責(zé)和保障的過程。

七、保障協(xié)同

作為系統(tǒng)的負責(zé)人，做到上述性能優(yōu)化等工作對本系統(tǒng)來說足夠了，但是其他兄弟系統(tǒng)的保障協(xié)同也是重要的一環(huán)。在阿里，每次中間件大規(guī)模要求升級時，大促也就近了。供應(yīng)鏈服務(wù)平臺重度依賴的其他系統(tǒng)，例如商品中心、庫存中心、訂購中心和容量中心等也各自針對大促做了不同程度的優(yōu)化。例如商品中心預(yù)熱手段發(fā)生了變化，重點流量做出分組操作，并專門留出了部分機器給服務(wù)平臺系統(tǒng)做流量分割。庫存中心升級了新模型，改進了緩存等，那么服務(wù)平臺系統(tǒng)也需要針對這部分進行相應(yīng)的協(xié)同。和訂購中心的協(xié)同主要在預(yù)熱和防雪崩，假如宕掉時間過長，就避免調(diào)用數(shù)據(jù)庫，而去調(diào)用緩存。容量中心之前只支持單個扣減， 現(xiàn)在可以支持批量扣減，或者修改了表結(jié)構(gòu)。這些兄弟系統(tǒng)諸如此類的優(yōu)化也從側(cè)面使得服務(wù)平臺更加健康。

八、壓測檢驗

完成優(yōu)化和協(xié)同保障后，當(dāng)然需要壓測檢驗。在雙十一期間總共經(jīng)歷12次全鏈路壓測，因為無法再造一個全鏈路系統(tǒng)，所以只能使用真實系統(tǒng)壓測。為了不影響真實系統(tǒng)的運行和消費者的感觀，壓測通常在半夜進行。在壓測過程中，發(fā)現(xiàn)了不少問題，這里舉出以下三個例子：

1. 本地線程池滿。jstack查看線程堆棧時，發(fā)現(xiàn)很多線程卡在logback輸出日志的地方。查看源碼后發(fā)現(xiàn)是使用log.error打印了一個很大的JSON對象，且每次調(diào)用都會打印，這就造成本地線程池立刻滿了。因為系統(tǒng)較老，依靠個人的代碼review無法發(fā)現(xiàn)此類問題，這就需要壓測這種真實的流量手段來發(fā)現(xiàn)。

2. 超時請求。鷹眼（阿里全鏈路監(jiān)控系統(tǒng)）發(fā)現(xiàn)有一個長達3s的請求，一般請求為毫秒級別，檢查后發(fā)現(xiàn)是該部分數(shù)據(jù)緩存未預(yù)熱，查詢數(shù)據(jù)庫超時引起。因為該部分數(shù)據(jù)在大促時不會調(diào)用，因此在壓測時是可以提前將其撤下的。但在壓測時出現(xiàn)這個問題可能會影響到其他業(yè)務(wù)的穩(wěn)定。

3. Jmap超時。阿里的服務(wù)平臺通過手工執(zhí)行jmap命令觸發(fā)GC來釋放內(nèi)存，發(fā)現(xiàn)在執(zhí)行jmap時（會先下線對應(yīng)服務(wù)），對應(yīng)的機器仍然對外服務(wù)，并且大多超時。查看了對應(yīng)的下線腳本后發(fā)現(xiàn)，由于鏡像升級，導(dǎo)致Linux命令輸出與老腳本預(yù)期不一致。這也影響了線上服務(wù)的穩(wěn)定。

上述問題只有壓測驗證才會檢查出來，因此，壓測的意義不容置否。每一次壓測都是對上一輪優(yōu)化結(jié)果的驗證，同時，每次壓測發(fā)現(xiàn)的問題，也是下一次優(yōu)化的主要方向。

九、項目協(xié)同

服務(wù)平臺內(nèi)部的工作同事便有10人左右，更要包括對外的例如中間件的部門、依賴和被依賴的兄弟系統(tǒng)部門。人員眾多導(dǎo)致各種協(xié)同問題的產(chǎn)生，這就需要一個協(xié)同機制。需要明確每個項目的負責(zé)人，有固定的聯(lián)系方式。任務(wù)拆解要細致，每個部分的任務(wù)交給指定的人解決。另外需要文檔沉淀，得出的文檔不僅是這次大促的回顧總結(jié)，也是下次大促的一個參考。2018年的大促能夠完成，也是依靠了之前的多次大促經(jīng)驗文檔。驗證考核也必不可少，驗證此次的優(yōu)化是否達到了設(shè)定的目標(biāo)。某些在測試時沒有顯現(xiàn)出的問題會在真實的流量下被發(fā)現(xiàn)，因此事后的驗證考核會幫助發(fā)現(xiàn)更潛在的bug。最后，風(fēng)險識別，某些問題可能因為歷史原因無法修復(fù)，那么這種問題要識別出來，和業(yè)務(wù)人員或產(chǎn)品人員共同找一個可以彌補的方法。例如可以將由于這個bug產(chǎn)生的問題訂單使用工具單獨拋出，再行安排。這些都是作為一個項目PM需要注意的重點。當(dāng)然，如果能有一個項目間供大家face to face探討各種問題是最好了。

十、監(jiān)控治理

傳統(tǒng)意義上的監(jiān)控治理有兩個訴求：看圖和告警。看圖主要關(guān)注各類曲線是否有波動是否穩(wěn)定等，告警是在產(chǎn)生問題時可以通過短信、郵件等方式告知。除去傳統(tǒng)的系統(tǒng)監(jiān)控指標(biāo)，例如GC次數(shù)、內(nèi)存使用率、QPS高低、系統(tǒng)反應(yīng)時間，還需要業(yè)務(wù)監(jiān)控，這需要通過日志或離線采集進行統(tǒng)計，如此才能對系統(tǒng)和業(yè)務(wù)都有直觀的認識。當(dāng)然，“會出錯的事總會出錯”，過程中難免會出現(xiàn)問題。如果出現(xiàn)問題，則需要及時統(tǒng)計產(chǎn)生影響的商家數(shù)量、單量、消費者數(shù)量，以便后續(xù)緊急處理，采取拉單、擴容或下線服務(wù)等手段防止過大損失，這便是消防處理。

十一、戰(zhàn)前準(zhǔn)備

所有優(yōu)化和監(jiān)控措施完成后，大促開始前1-2天，按部就班執(zhí)行各類計劃動作。首先是執(zhí)行前置預(yù)案，例如下線了某些業(yè)務(wù)鏈路要執(zhí)行觀察效果。其次是預(yù)熱，在大促前一天將一切準(zhǔn)備就緒，準(zhǔn)備迎接峰值流量。接著進行一致性檢查，單元化的核心應(yīng)用涉及到成千的機器，可以通過計算MD5校驗值，來確保所有的機器上的zip、jar、war包等是一致的。然后資源檢查，對于大促當(dāng)天的數(shù)據(jù)庫、機器、中間件、內(nèi)存等資源做一個檢查，確保資源到位。清理數(shù)據(jù)庫，如壓測使用后廢棄的表可以刪除。最后，jmap釋放內(nèi)存，將可能會觸發(fā)GC的內(nèi)存全部釋放。

十二、總結(jié)

回顧整個大促過程，今年的供應(yīng)鏈服務(wù)平臺比去年更加穩(wěn)定，核心下單鏈路成功率接近99.9%，沒有發(fā)生限流等嚴重影響用戶體驗的情況。從8月開始思考雙十一的籌備工作，整個大促保障期間，涉及到眾多的系統(tǒng)、人員和業(yè)務(wù)，每個系統(tǒng)和業(yè)務(wù)分別由不同的團隊負責(zé)，需要做鏈路分析、模型分析、容量評估、目標(biāo)評估，要協(xié)調(diào)和明確各節(jié)點間的職責(zé)劃分、要做各類優(yōu)化、壓測、監(jiān)控和反饋等等，持續(xù)了長達三四個月。

“這個過程是一次人與人、人與對象間的碰撞，精密的儀器產(chǎn)生完美的作品。”

---

本文作者：李博bluemind

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的阿里专家梁笑：2018双十一下单成功率99.9%！供应链服务平台如何迎接大促的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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