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