十個(gè)可以手動(dòng)編寫的 JavaScript 數(shù)組 API
JavaScript 中有很多API，使用得當(dāng)，會(huì)很方便，省力不少。 你知道它的原理嗎? 今天這篇文章，我們將對(duì)它們進(jìn)行一次小總結(jié)。現(xiàn)在開始吧。1.forEach()forEach()用于遍歷數(shù)組接收一參
訂單的履約之路就是從發(fā)貨開始，看似簡(jiǎn)單的發(fā)貨功能，其背后卻藏著許多的小秘密。
發(fā)貨的業(yè)務(wù)特點(diǎn)：
隨著公司業(yè)務(wù)的發(fā)展，訂單類型的增多，沒有進(jìn)行抽象的發(fā)貨邏輯隨著迭代的推進(jìn)難免會(huì)顯得落后。當(dāng)然，在迭代的過(guò)程中，也一直在優(yōu)化，一直在演進(jìn)，正所謂沒有最好，只有符合當(dāng)前業(yè)務(wù)現(xiàn)狀的最合理。
圖片
賣家發(fā)貨在一開始的時(shí)候，有N個(gè)接口。比如，現(xiàn)貨單個(gè)發(fā)貨，現(xiàn)貨批量發(fā)貨，現(xiàn)貨極速發(fā)貨，App發(fā)貨，直發(fā)發(fā)貨，定制發(fā)貨等。
有這么多發(fā)貨接口也是我們平臺(tái)的業(yè)務(wù)特性決定的，現(xiàn)貨就是賣家發(fā)貨到平臺(tái)，直發(fā)就是賣家發(fā)貨到買家，不同的業(yè)務(wù)有不同的流程。除了接口多這個(gè)問題，另一個(gè)問題是邏輯分散，每個(gè)接口都是獨(dú)立的邏輯，大量重復(fù)代碼的出現(xiàn)極大地增加了維護(hù)的成本。
比較簡(jiǎn)化的發(fā)貨流程如下：
在整個(gè)流程里面，存在很多可以優(yōu)化的點(diǎn)。如在訂單數(shù)據(jù)更新之后的很多操作都可以通過(guò)異步的方式去處理，這樣可以提高發(fā)貨整體的性能。
總結(jié)下之前賣家發(fā)貨存在的幾個(gè)問題：
前面也提到了，目前發(fā)貨是基于訂單類型分類來(lái)進(jìn)行編排。之所以要通過(guò)訂單類型去做分類是因?yàn)橹爸挥杏唵晤愋停械臉I(yè)務(wù)都是根據(jù)訂單類型去做區(qū)分。主要還是沒有站在履約的視角下去做發(fā)貨這件事情，所以導(dǎo)致每加一種訂單類型，對(duì)發(fā)貨都有一定的影響。
在履約視角下，會(huì)有履約單。履約單上有履約模式，目前有現(xiàn)貨，直發(fā)，倉(cāng)發(fā)，虛擬，服務(wù)單，跨境直發(fā)，跨境現(xiàn)貨，跨境在倉(cāng)。
履約模式是對(duì)貨品怎么從賣家交付到買家手里的一種業(yè)務(wù)模式，不同的模式在業(yè)務(wù)流程的處理上不一樣，在賣家發(fā)貨的場(chǎng)景下，只關(guān)注貨怎么到買家，而不需要關(guān)注訂單是什么類型。
現(xiàn)貨模式指的是賣家把貨發(fā)平臺(tái)，平臺(tái)質(zhì)檢/鑒別合格后再把貨發(fā)給買家。現(xiàn)貨類的訂單類型有普通現(xiàn)貨，極速現(xiàn)貨，極速預(yù)售，定金預(yù)售等。
直發(fā)模式指的是賣家直接把貨發(fā)到買家。直發(fā)類的訂單類型有品牌直發(fā)，定金預(yù)售直發(fā)，拍賣直發(fā)，眾籌直發(fā)，盲盒直發(fā)等。
倉(cāng)發(fā)模式指的是賣家提前將貨發(fā)到平臺(tái)倉(cāng)庫(kù)，買家下單后直接從倉(cāng)庫(kù)發(fā)出。
虛擬模式指的是在線履約，無(wú)需快遞配送。虛擬類的訂單類型有隨心省，洗護(hù)卡，虛擬卡卷等。
服務(wù)單指的是定制類的服務(wù)，需要將貨品從平臺(tái)寄到服務(wù)商，服務(wù)商完成定制服務(wù)后再寄回平臺(tái)，再由平臺(tái)寄給買家。
從履約模式的劃分可以看的出來(lái)，每個(gè)業(yè)務(wù)場(chǎng)景都有一個(gè)訂單類型，但從履約的方式來(lái)說(shuō)都一樣。二階段發(fā)貨會(huì)根據(jù)履約模式去做業(yè)務(wù)流程編排，不感知訂單類型，這樣就能沉淀平臺(tái)化的能力，而不是跟著上層業(yè)務(wù)每次都需要改變。如有特定的針對(duì)某種訂單類型的業(yè)務(wù)處理，這個(gè)邏輯會(huì)放在訂單側(cè)。
在穩(wěn)定性方面也做了一些改造，發(fā)貨雖然不是導(dǎo)購(gòu)下單鏈路，但也是非常重要的一個(gè)節(jié)點(diǎn)。發(fā)貨有問題就會(huì)導(dǎo)致訂單狀態(tài)無(wú)法推進(jìn)，后續(xù)會(huì)引發(fā)超時(shí)關(guān)單等問題，所以在穩(wěn)定性上必須嚴(yán)格保證。
整個(gè)發(fā)貨的操作，有失敗的會(huì)立刻告警出來(lái)，當(dāng)然這里會(huì)屏蔽一些正常的業(yè)務(wù)校驗(yàn)場(chǎng)景，否則告警太多就顯得毫無(wú)意義。同時(shí)也基于訂單目前現(xiàn)有的錯(cuò)誤碼大盤構(gòu)建了發(fā)貨的大盤，發(fā)貨失敗量，失敗的原因通過(guò)大盤一看便知有沒有問題。
圖片
作為研發(fā)同學(xué)，無(wú)論是業(yè)務(wù)研發(fā)還是中間件研發(fā)，都需要對(duì)自己負(fù)責(zé)的系統(tǒng)和功能的使用情況比較了解。構(gòu)建業(yè)務(wù)大盤就是一種非常好的能夠?qū)崟r(shí)感知業(yè)務(wù)情況的一種方式。
比如說(shuō)在發(fā)貨場(chǎng)景我們需要感知的數(shù)據(jù)有如下：
這次改造的收益如下：
我們做平臺(tái)化的業(yè)務(wù)，同時(shí)對(duì)多業(yè)務(wù)提供服務(wù)時(shí)，需要有標(biāo)識(shí)能夠區(qū)分每一次業(yè)務(wù)服務(wù)請(qǐng)求的身份，這樣就可以提供差異化個(gè)性化的服務(wù)，我理解這就是業(yè)務(wù)身份。
就好比消費(fèi)者去一家線下門店消費(fèi)，商家會(huì)讓消費(fèi)者辦會(huì)員卡，會(huì)員卡有不同的等級(jí)，比如黃金卡，鉑金卡等等。消費(fèi)者每次去店里消費(fèi)都會(huì)帶上這張卡，這張卡就是消費(fèi)者的身份，商家也能根據(jù)這張卡來(lái)給消費(fèi)者提供差異化的服務(wù)。
在構(gòu)建業(yè)務(wù)身份之前，我們是基于履約模式去處理差異化的業(yè)務(wù)流程。也并不是說(shuō)非得抽業(yè)務(wù)身份，而是到了某個(gè)階段，業(yè)務(wù)的復(fù)雜度不得不讓你改變現(xiàn)有模型，說(shuō)白了就是沒辦法支持多變的業(yè)務(wù)，就算能支持，改動(dòng)帶來(lái)的影響面比較大，對(duì)測(cè)試回歸的范圍比較廣。所以我們需要反思以什么樣的形式來(lái)解決復(fù)雜業(yè)務(wù)，同時(shí)又能支持后續(xù)業(yè)務(wù)的多變性，還能減少測(cè)試范圍，這就是我們構(gòu)建業(yè)務(wù)身份的根本原因。
上面說(shuō)的可能有點(diǎn)抽象，下面通過(guò)一個(gè)具體的例子來(lái)說(shuō)明下目前遇到的問題以及用業(yè)務(wù)身份如何解決這個(gè)問題，如何獲得高擴(kuò)展性。
在本文第四點(diǎn) 基于履約視角的賣家發(fā)貨中已經(jīng)說(shuō)明了最新的發(fā)貨是基于履約模式來(lái)進(jìn)行業(yè)務(wù)編排。直發(fā)和現(xiàn)貨模式都是基于實(shí)物的履約模式，需要使用快遞發(fā)貨。但我們還有一種虛擬履約模式，虛擬履約是不需要快遞發(fā)貨，而是線上進(jìn)行，比如月卡，游戲皮膚，票務(wù)（電子票）等等。
如下圖所示：
圖片
在虛擬模式中的票務(wù)目前僅僅支持電子票的形式，在最新的需求中，需要支持實(shí)體票。實(shí)體票默認(rèn)都是快遞配送，如果購(gòu)買時(shí)間臨近演出開始的時(shí)間，那么快遞配送在時(shí)間上肯定是不能滿足要求，這個(gè)時(shí)候另一種方式出現(xiàn)了，它就是現(xiàn)場(chǎng)取票。
此時(shí)可以看下圖，虛擬模式下又存在多種業(yè)務(wù)場(chǎng)景，當(dāng)虛擬訂單需要走快遞配送的鏈路，現(xiàn)有基于履約模式的業(yè)務(wù)編排沒辦法支撐。如果不談合理性，只實(shí)現(xiàn)需求的話只能在虛擬模式下再開一條新流程，處理快遞配送的流程。但是快遞配送相關(guān)的流程在直發(fā)和現(xiàn)貨的模式下都是現(xiàn)成的，這樣做后續(xù)維護(hù)成本和理解成本太高，這就是基于履約模式的發(fā)貨目前面臨的業(yè)務(wù)擴(kuò)展問題。
圖片
圖片
如上圖所示：底層能力不再跟履約模式進(jìn)行一一綁定，而是基于業(yè)務(wù)場(chǎng)景進(jìn)行了抽象。這樣做的好處在于這些底層能力可以被復(fù)用，怎么復(fù)用就需要抽象出具體的業(yè)務(wù)身份。
舉例說(shuō)明：
現(xiàn)貨通用業(yè)務(wù)身份 對(duì)應(yīng)的能力如下：
現(xiàn)貨App業(yè)務(wù)身份 對(duì)應(yīng)的能力如下：
虛擬通用業(yè)務(wù)身份 對(duì)應(yīng)的能力如下：
虛擬快遞業(yè)務(wù)身份 對(duì)應(yīng)的能力如下：
通過(guò)上面的例子我相信大家都看明白了業(yè)務(wù)身份的作用，結(jié)合業(yè)務(wù)抽象出業(yè)務(wù)身份，同時(shí)為業(yè)務(wù)身份綁定對(duì)應(yīng)的能力，這樣就能完全的復(fù)用底層能力。
當(dāng)然，這里的重點(diǎn)是如何提取出對(duì)應(yīng)的業(yè)務(wù)身份，業(yè)務(wù)身份是一個(gè)多維度聚合的一個(gè)結(jié)果，并不是隨便編造出來(lái)就可以。以賣家發(fā)貨的場(chǎng)景來(lái)分析，業(yè)務(wù)差異性體現(xiàn)在下面幾個(gè)點(diǎn)上：
這里的端指的是賣家發(fā)貨時(shí)使用的系統(tǒng)，比如App，商家后臺(tái)，開放平臺(tái)對(duì)接等等。
所以我們的業(yè)務(wù)身份就是對(duì)應(yīng)的端+履約模式，對(duì)于沒有差異性的可以定一個(gè)通用的業(yè)務(wù)身份，后面有差異性了再單獨(dú)提取出來(lái)。比如通用現(xiàn)貨，需要細(xì)分的那就是App現(xiàn)貨。
上面這個(gè)維度組成的業(yè)務(wù)身份能滿足大部分場(chǎng)景，還是有些場(chǎng)景無(wú)法滿足，那就是虛擬訂單走快遞配送的場(chǎng)景。也就是說(shuō)我只能識(shí)別出當(dāng)前的業(yè)務(wù)身份是虛擬模式，但是無(wú)法識(shí)別出虛擬模式下是要走快遞配送，還是現(xiàn)場(chǎng)取票，還是憑證發(fā)貨。
為此，增加了第三個(gè)維度來(lái)組成業(yè)務(wù)身份，這樣就能明確當(dāng)前的業(yè)務(wù)身份需要做哪些事情。所以對(duì)于虛擬的業(yè)務(wù)身份就會(huì)有虛擬通用，虛擬快遞發(fā)，虛擬現(xiàn)場(chǎng)取三個(gè)業(yè)務(wù)身份。
對(duì)業(yè)務(wù)身份來(lái)說(shuō)，也是會(huì)隨著業(yè)務(wù)而進(jìn)行演變，也許以后將整個(gè)履約鏈路標(biāo)準(zhǔn)化，提供給多業(yè)務(wù)使用，這個(gè)時(shí)候業(yè)務(wù)身份中就會(huì)增加非常重要的一個(gè)維度：租戶。
高擴(kuò)展性其實(shí)上面已經(jīng)講過(guò)了，通過(guò)業(yè)務(wù)身份編排的方式輕松的就支持了虛擬訂單走快遞配送的履約方式。根本不需要在之前很多邏輯里面加 if 進(jìn)行強(qiáng)判斷。
比如有個(gè)需求要對(duì)發(fā)貨時(shí)子母件（一個(gè)運(yùn)單多個(gè)包裹）的場(chǎng)景進(jìn)行攔截，只在某一種履約模式下進(jìn)行攔截。這個(gè)時(shí)候我們就可以新增一個(gè)子母件攔截的基礎(chǔ)能力，分別是攔截和不攔截。
然后給需要攔截的業(yè)務(wù)身份配置上攔截，給不需要攔截的業(yè)務(wù)身份配置上不攔截，這樣就只有指定的場(chǎng)景才會(huì)用到子母件攔截的能力。如果后面其他模式也要支持?jǐn)r截，直接改配置就可以了，無(wú)需改動(dòng)底層業(yè)務(wù)代碼。
高擴(kuò)展性的前提是有好的抽象和分層，發(fā)貨整體業(yè)務(wù)架構(gòu)如下圖所示：
圖片
測(cè)試成本低主要體現(xiàn)在改動(dòng)范圍都是可控的，因?yàn)檎麄€(gè)發(fā)貨流程中都抽象出了具體的能力。比如說(shuō)你改了A能力，A能力只作用在虛擬模式下，那么測(cè)試只需要回歸虛擬模式的流程即可。
以上面說(shuō)的子母件攔截的場(chǎng)景來(lái)講，也只需要測(cè)試現(xiàn)貨模式，而且老邏輯都不用看，因?yàn)槭切略龅哪芰c(diǎn)，完全不會(huì)影響老的業(yè)務(wù)邏輯。
或者說(shuō)在業(yè)務(wù)的發(fā)展下，新出現(xiàn)了一個(gè)業(yè)務(wù)身份，但是這個(gè)業(yè)務(wù)身份對(duì)應(yīng)的能力都是之前已經(jīng)存在的能力，只不過(guò)是有些能力不需要，這個(gè)時(shí)候只需要改兩個(gè)地方，一個(gè)是業(yè)務(wù)身份對(duì)應(yīng)能力的配置，另一個(gè)是計(jì)算業(yè)務(wù)身份的邏輯，能夠根據(jù)某些條件決策出當(dāng)前請(qǐng)求是這個(gè)新的業(yè)務(wù)身份。這個(gè)時(shí)候測(cè)試只需要簡(jiǎn)單的驗(yàn)證下即可，底層能力都是已經(jīng)在使用的，不同的點(diǎn)只在于編排。
無(wú)論是新增，還是修改，還是重新編排。都能很明確的知道當(dāng)前調(diào)整的范圍，這樣測(cè)試的成本自然也就比較低。不再需要像以前一樣，改動(dòng)了幾行代碼，不清楚什么場(chǎng)景在使用，然后全部回歸一遍。
目前發(fā)貨場(chǎng)景的底層能力數(shù)量不多，在某些場(chǎng)景還是會(huì)有簡(jiǎn)單的if判斷邏輯。在目前看來(lái)這些場(chǎng)景還沒有特別復(fù)雜，隨著業(yè)務(wù)的發(fā)展和規(guī)則的變化，這些邏輯越來(lái)越復(fù)雜的時(shí)候，就需要繼續(xù)去提取出原子級(jí)別的能力。
能力的提取和業(yè)務(wù)身份的抽象是個(gè)漫長(zhǎng)的過(guò)程，不存在一成不變的情況，只存在慢慢演進(jìn)和優(yōu)化的過(guò)程。
可視化編排在初期并不是重要的一環(huán)，隨著底層能力越來(lái)越豐富，業(yè)務(wù)規(guī)則越來(lái)越多且變化頻繁，此時(shí)研發(fā)側(cè)能否快速交付就變得很重要。通過(guò)可視化編排，不用依賴代碼改造和版本發(fā)布，就可以快速調(diào)整業(yè)務(wù)流程和新增一套完整的新流程。當(dāng)然，這也需要有很多相應(yīng)的機(jī)制來(lái)保證穩(wěn)定性，畢竟代碼變更是每次都經(jīng)過(guò)一個(gè)迭代的測(cè)試才能發(fā)布，這種動(dòng)態(tài)變更的也需要有相應(yīng)的灰度機(jī)制才行。
業(yè)務(wù)身份目前只在賣家發(fā)貨場(chǎng)景落地，在履約這邊有其他很多平臺(tái)化的能力，如何用平臺(tái)化的能力去支撐上層多變的業(yè)務(wù)是核心訴求。一旦業(yè)務(wù)身份確定，那么在整個(gè)履約鏈路中，都可以基于業(yè)務(wù)身份來(lái)做整體的流程編排，做差異化的處理。
本文鏈接：http://m.rrqrq.com/showinfo-26-5173-0.html電商訂單履約-賣家發(fā)貨演化史
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)