專欄系列

-SaaS 電商設計 (一) 如何設計一套適應多規格的商品服務
-SaaS 電商設計 (二) 私有化部署-緩存中間件適配
-SaaS 電商設計 (三) 電商黃金流程(商詳,購物車,提單)梳理,持續更新(建議收藏)
-SaaS 電商設計 (四) 談一談電商系統高并發多耦合上下游的系統壓測怎么做
-SaaS 電商設計 (五) 私有化部署-實現 binlog 中間件適配(附源碼)
-SaaS 電商設計 (六) 實現 id 生成器本地化生產 (附源碼)
-SaaS 電商設計 (七) 利用 Spring 擴展點 ImportBeanDefinitionRegistrar 實現 toB 系統對接(附源碼)

-SaaS 電商設計 (八) 直接就能用的一套電商商品池完整設計方案(建議收藏)

一.背景

購物車是電商交易流程中的關鍵模塊，承上啟下，作為導購環節的最后一環，為用戶在多個場景下進行購物決策提供便利。除了支持用戶對自己的購物車進行常規的增刪改查操作外，購物車還提供了豐富的功能，如湊單、換購、手動換促銷、自動切換最優促銷、自動領券結算、設置常購商品、篩選搜索等，以提高用戶的操作效率和決策能力。此外，購物車還具備一系列營銷能力，包括砸京蛋、跨店滿減、每日一促、無貨推薦和營銷氛圍增強等，以增加用戶的購買欲望和促進銷售額的增長。

????如上圖是某電商購物車的底部一個彈層功能,提供的是當前勾選商品后具體結算金額的明細.如:優惠券優惠明細,plus95折明細.plus會員購物返利等.是一個用戶結算的工具.

1.1 業務背景

????話不多說,書歸正傳.從開頭圖例來看,在具體研發過程中其實是存在很多種底部彈層的場景.目前是業務場景玩法越來越多的背景下,迭代速度也日漸頻繁.對于后端技術同學不得不在這些業務插入諸多的樓層代碼去補齊業務場景邏輯.而且通過增加字段的方式每次的變更都需要聯合前后端同時的迭代開發,考慮到 app 端開發發版節奏相對低頻且成本較大.存在業務訴求和開發迭代周期之間的 gap .能否存在僅后端發布解決迭代更新的可能?而且盡可能少的改動去完成迭代開發?

底部彈層的業務場景迭代頻率較高

1.2 技術負債

????在這些頻繁的業務場景迭代過程中,研發側不得不更緊湊的迭代周期去完成指定的迭代任務.導致不得不在歷史諸多代碼中龍飛鳳舞,后來者更是不敢錯過一行,小心翼翼找尋代碼,更新改動.長此以往愈演愈烈,這批代碼就成為不可被替代開發者之代碼.不用說開閉原則,優雅維護起來也變得遙不可及.如下是其中一個小類,關注與左下角. 5k+ 行.

????每每服務端更新相應邏輯, app 移動端不得不跟隨改動,發布集成,更新版本.周期較長.

長期的版本更新,代碼維護性較差
不可擴展的更新,導致移動端跟隨發布

二.技術目標

• 在高頻的業務迭代節奏中盡可能去低改動去完成業務目標
• 技術實現盡可能可擴展,利于維護(滿足開閉原則)
• 鑒于移動端發版周期長.盡可能移動端不改動,不迭代.即減少聯調成本也利于快速排查問題.

三.方案設計

3.1 解決移動端頻繁發版

3.1.1 場景分析

鑒于以上的一個公共特征,如上分析我們看起來可以抽象一個類 floor 去完成每一行的渲染,每一行的副標題也是同樣可以繼續復用.以此來解決每次新增場景,同步新增字段來處理的邏輯.這樣的話除了共減場景的渲染其他看起來是一致的.所有的渲染移動端可以通過遍歷 floor 的數組去完成整個彈層的渲染.這樣一來的話,移動端的工作就變得非常簡單,僅僅開發一次看起來就解決了問題.這樣就解決了我們的第三個技術目標.完成移動端免除跟隨發版的困擾.具體如下:

3.1.2 技術方案

其中 sort 字段是為了支持產品的一些排序訴求.這里就比較簡單了.通過實現 Comparable 接口即可.具體渲染后是這樣

{"floorDetails": [{"floorItemCode": "spze","floorItemName": "商品總額","floorItemPrice": "￥20.90","styleExt": ["bold"]},{"floorItemCode": "lj","floorItemName": "立減","floorItemPrice": "-￥5.00"},{"floorItemCode": "coupon","floorItemName": "優惠券","floorItemPrice": "-￥6.00","floorItemSubName": "已領券 -￥6.00"},{"floorItemCode": "plus95","floorItemName": "PLUS專享95折","floorItemPrice": "-￥1.04","floorItemSubName": "本月剩余優惠額度 ￥1,000.00"}]
}

如上的數據結構 app 端就可以通過數組遍歷的形式來獲取指定樓層渲染的邏輯.在后端動態增加item時,也盡可能的做到少改動,甚至不改動即可做到支持.解決我們第一個技術目標:在高頻的業務迭代節奏中盡可能去低改動去完成業務目標

3.2 減少后端壞味道代碼&無法靈活擴展問題

3.2.1 通過抽象接口完成各自單獨樓層渲染邏輯

如上我們抽象一個 FloorBuilder 類接口,通過具體的 FloorItemCode 來進行尋找指定的類進行渲染.這樣一來每個 code 對應的渲染和獲取邏輯都能夠在各自的類中,避免都在同一個類中書寫大量邏輯.對于修改和新增來說,后來的同學去追尋歷史邏輯的成本相對較低.

3.2.2 通過配置能力做到部分字段可配

如上通過結合配置中間件的能力,做到部分字段可配置,下發配置后可以通過遍歷所有的配置.通過配置code來獲取指定的策略類來完成指定樓層渲染.解決我們第二個技術目標:技術實現盡可能可擴展,利于維護(滿足開閉原則)

四.升級上線(普適于高并發大流量的業務場景的功能上線更新)

如上是大概的技術方案,整體的迭代過程中僅僅是完成了功能的改造.能感受到整體的改動還是非常大的.尤其是作為技術側的一個優化.再加上本身是一個黃金流程中非常重要的一環.本身來說穩定性是第一位的.所以這里關于升級發布的流程也做一個大致的介紹.要知道,如此高并發的場景出了一個問題,不用問就是要被拖入**“廣進”**的,小伙子你也不想的吧.

上線第一要義:穩定穩定還是穩定.穩定壓倒一切.到底怎么做.

• 1.第一要支持灰度
• 2.最好要有支持版本控制
• 3.最次最低要支持開關降級,實在不行下線相應功能完成動態完成問題功能下線

總結起來就是首先要小流量試跑,出問題要有后路.給程序留后路也是給目前經濟不景氣的自己留后路哈.兄弟們.話不多說,一圖勝千言.上圖.

總體上一個非常普適的高流量高并發通用的線上發布功能流程.略去了一些細節,大體上的思路還是能看的到.具體介紹下.

• step1:第一個是開發功能(含分支管理的流程)

稍微擴展下.大廠的場景基本上如此.
稍有不同的是,貓廠是各個feature branch 合并動作是自動通過aone來控制的,并且合并master的動作是整體的上線流程完成之后自動通過aone完成.
狗廠的流程目前各個feature branch 手動合并到本次一個vxx branch ,最后通過合并到master來進行線上部署.

ps:貓廠整體流程化還是相對來說要更加自動化一些.

• step2:完成預發環境的驗證

這里有兩個點.
– 合并后的 vxx branch 功能合集驗證,比如說本次的技術樓層優化.
– 本次功能代碼鏈接線上配置,數據庫,服務等預線上環境驗證.

這里如果還涉及到一些接口的改造,其實還需要有壓力驗證,這里就沒有體現

• step3:上線流程前的一個review
  對于本次的話,技術優化可能相對來說比較大一個改造.通常盡量是做到組內的一次上線前的review,確定切量范圍,確定版本控制,確定回滾方案,確定降級方案

-step4:上線過程中的流量切換

流量切換前一定要保證流量切掉后,剩余的機房能夠支持現有日常流量這個就要大家各自參考各自系統目前的水位情況以及日常qps了.

1. 流量切換到001機房,完成002,003機房部署以及部署后的單機驗證.np掛載.掛載后的vip驗證.

2. 流量切換到002機房,003機房.摘除001機房流量.這樣保持盡量長的時間(12h),利用線上的用戶流量做一次灰度流量驗證.(一般的功能驗證),其實如果是較大的功能且功能較大,可以在整體之前加一個內部pin驗證.對應倒數第二組的圖內容.

3. 步驟2的過程中沒有任何問題,此時001機房已經摘量,可以繼續完成鏡像部署.還是同樣的流程,完成單機驗證,多集群部署,np掛載,vip驗證.也就是最后一組圖中的內容.

贈人玫瑰 手有余香 我是柏修 一名持續更新的晚熟程序員
期待您的點贊,關注加收藏，加個關注不迷路，感謝
您的鼓勵是我更新的最大動力
↓↓↓↓↓↓