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