幕思城>電商行情>開店>開網店>閑魚策略中樞業(yè)務擴展模塊實現(xiàn)

閑魚策略中樞業(yè)務擴展模塊實現(xiàn)

2022-11-13|14:42|發(fā)布在分類 / 開網店| 閱讀：84

擴展能力是我們在做平臺、中臺時都會面臨的技術思考。為了平臺能盡可能覆蓋更多的業(yè)務場景，我們需要設計可擴展，可復用的擴展模塊，不斷拓寬平臺能力的邊界。本文介紹閑魚策略中樞平臺Luxury做業(yè)務擴展模塊時遇到的問題以及解決思路，希望能為同樣做平臺擴展模塊的讀者提供一些啟發(fā)。

背景

閑魚策略中樞Luxury是面向閑魚全域業(yè)務的用戶精細化策略運營平臺，旨在引導用戶認識、參與閑魚的各業(yè)務場景、精準的傳遞平臺價值。

以下面的紅包投放為例，它就是Luxury的一條投放策略投放到客戶端上之后的展現(xiàn)形式。

一條投放策略包含了：

規(guī)則(策略觸發(fā)時機)。對應紅包例子，觸發(fā)時機就是用戶打開客戶端首頁時識別有未使用紅包
觸點(投放的素材樣式)。對應紅包例子，素材樣式就是整個Pop大卡片樣式
鉤子(填充觸點的動態(tài)數(shù)據)。對應紅包例子，鉤子就負責填充pop卡片中的紅包金額，和標題文案

其中，鉤子的定位是負責對接二三方的接口與服務，為素材投放提供動態(tài)數(shù)據。

現(xiàn)狀

因為二三方服務接口格式都不同，做統(tǒng)一和抽象很困難。早期Luxury為了支撐業(yè)務快速上線，二三方服務接入都是用hard code的形式，case by case的解決。這種方式帶來的影響有：不僅不能支撐快速迭代的業(yè)務需求，并且已有服務也不能沉淀提供給其他策略復用。
鉤子到觸點的映射需要運營同學手動填寫解析表達式，如下圖所示。需要運營同學理解后端的返回數(shù)據格式，配置成本高且容易配錯。

目標

具備易用性：對運營來說不感知鉤子的底層差異，能夠快速完成鉤子到觸點的數(shù)據映射

可擴展：能夠覆蓋大部分的業(yè)務接入場景

可復用：能夠對鉤子進行一定程度抽象，避免每次業(yè)務接入都要開發(fā)新勾子

可沉淀：鉤子沉淀為可復用資產，逐漸拓寬平臺能力邊界

技術方案

鉤子模塊的總體思路是采用適配器模式，抽象出鉤子接口層，二三方服務可以通過實現(xiàn)接口來接入Luxury平臺。

適配器模式是可擴展性的經典解決方案。例如：

云原生監(jiān)控系統(tǒng)Prometheus的exporter用來解決各種異構數(shù)據源metrics上報的問題

服務網格ServiceMesh的Mixer用來解決每次http調用時注入額外的業(yè)務邏輯

適配器模式做統(tǒng)一抽象的解決方案一般是對出入參做數(shù)據映射，適配到統(tǒng)一的接口模型，對上層屏蔽底層實現(xiàn)差異。

鉤子模塊架構圖：

鉤子模塊鏈路圖：

入參構造

問題：鉤子是策略鏈路上獨立可復用的模塊，因此鉤子不與某個具體策略耦合，也不與某個具體的客戶端調用耦合。這意味著客戶端的每次調用不知道要傳哪些參數(shù)給鉤子。
解決方案：該類問題的常規(guī)解決思路是把入參的結構信息傳遞到調用方，讓調用方感知每次調用的入參格式。但這意味著需要拆分成兩次調用，一次獲取入參結構，一次發(fā)起調用。但在我們在橫向分析了自己的業(yè)務場景，發(fā)現(xiàn)策略的入參往往是精簡，有限，可枚舉的，比如用戶id、商品id、頁面id等等。因此我們轉變方案，通過每次調用時客戶端傳遞盡可能全的上下文，而鉤子從調用上下文里取需要的字段。通過冗余的參數(shù)換取更簡單的設計，更少的調用次數(shù)。

靜態(tài)配置可視化

問題：運營需要在后臺配置鉤子的靜態(tài)配置，但問題是每個鉤子的靜態(tài)配置結構都不一樣，服務端的靜態(tài)配置結構需要透傳到后臺生成表單讓運營感知并且理解。傳統(tǒng)解決前后端參數(shù)傳遞的方式是前后端約定接口協(xié)議并且開發(fā)頁面表單，但這種方式對鉤子不太適用。每次變更都涉及到前后端聯(lián)調，發(fā)布，不能滿足鉤子敏捷擴展的需求。
解決方案：要解決表單多變且可持續(xù)拓展的問題，用schema動態(tài)生成表單是一個好的解決方案。該方案需要前后端約定schema協(xié)議，前端提供schema生成表單的引擎，后端提供類生成schema的工具。這樣后端的類能直接映射為前端的表單樣式，前端表單的一份配置就對應一個后端類實例。整個開發(fā)流程能大幅度縮短，支撐鉤子敏捷迭代。

一份生成的表單與對應的schema例子如下：

{"type": "object","properties": {"appId": {"type": "integer","title": "app id","required": true},"callSource": {"type": "string","default": "fleamarket","title": "call source","required": true},"tppParam": {"type": "array","items": {"type": "object","properties": {"key": {"type": "string","title": "tpp入參","required": true},"value": {"type": "string","default": "${input.}","description": "支持從input或config從動態(tài)獲取參數(shù)","title": "解析表達式","required": true}}},"description": "從input或config中根據mvel表達式獲取參數(shù)，最后組裝為kv結構的tppParam","title": "tpp請求param"}}}

出參標準化

問題：鉤子作為業(yè)務擴展模塊，出參結構是不可窮舉的，難以約束和進一步抽象。但矛盾在于如果不做統(tǒng)一的抽象，就會把出參的復雜度暴露給外部，外部就需要感知鉤子各種case下的數(shù)據結構，如何對出參做統(tǒng)一與抽象，屏蔽出參的復雜性？
分析：我們配置觸點與數(shù)據的映射時。觸點用一個一個占位符挖出來動態(tài)數(shù)據的“坑”，“坑”是有限且是單一層級的，不會出現(xiàn)一個“坑”里填了個大對象或者大列表的場景。
解決方案：制定規(guī)范，要求將鉤子的出參映射為平鋪的結構，每份平鋪的出參都是一份字典(KVKV結構)，每個KV語義清晰，運營同學配置策略時，從字典里挑選需要的動態(tài)數(shù)據字段填入觸點，“將有限的數(shù)據填入有限的坑”。平鋪經驗證是滿足擴展性需求的，就算是嵌套的List結構，例如K[0:[0,1], 1:[0,1]]也能平鋪為K_0_0，K_0_1，K_1_0，K_1_1這種結構。

一個通過字典配置觸點的例子如下：

數(shù)據映射可配置化

問題：在做紅包權益鉤子的時候，我們發(fā)現(xiàn)紅包權益鉤子的可復用性不強，因為它僅是TPP算法中臺上的一種業(yè)務場景，我們一旦需要接TPP算法中臺的另一個算法業(yè)務場景，就需要重新擴展實現(xiàn)一遍鉤子。

分析：可復用性不強的原因在于對接中臺類鉤子時，中臺本身有很強的拓展能力，而我們的出入參的數(shù)據映射針對中臺上的一種業(yè)務場景寫死的，導致不能復用到中臺上的其他業(yè)務場景。因此，我們需要做到數(shù)據映射的可配置化。

解決方案：當發(fā)現(xiàn)數(shù)據映射成為擴展性的瓶頸時，就要著手解決數(shù)據映射靈活性的問題。因此需要實現(xiàn)數(shù)據映射的可配置化，鉤子實現(xiàn)可配置的數(shù)據映射引擎，將入參出參的數(shù)據映射配置關系抽出放到靜態(tài)參數(shù)里。這樣中臺鉤子就不與任意一個場景耦合，變更場景時只需要修改數(shù)據映射配置，不需要重新開發(fā)。當鉤子實現(xiàn)不與具體場景耦合時，也就實現(xiàn)了最大化靈活性。

效果

運營同學可以獨立配置鉤子到觸點的映射關系，鉤子成為了可以靈活替換的數(shù)據字典，可以按需挑選自己需要的動態(tài)數(shù)據。
沉淀了常見中臺鉤子，能夠覆蓋大部分場景需求，服務接入僅需0.5day配置成本。
覆蓋促買入、促發(fā)布、促瀏覽、活動互動等多個業(yè)務場景。

總結

擴展模塊的設計都很“難”，難的原因在于為了保證可擴展性，在方案設計階段就不能預設接入服務的結構。接入服務可以是任意一個接口，任意一個服務。對于這樣沒有邊界的服務要做統(tǒng)一和抽象是很困難的。

關鍵的地方在于統(tǒng)一接口層的定義，也是“規(guī)范”和“協(xié)議“定義。需要我們從業(yè)務特點出發(fā)，在保證可擴展性的前提下，保證接口層的語義清晰，在可擴展性和易用性之間找到最佳的平衡點。

這個問題還有疑問的話，可以加幕.思.城火星老師免費咨詢，微.信號是為: msc496。

難題沒解決？加我微信給你講！【僅限淘寶賣家交流運營知識，非賣家不要加我哈】