在上一篇文章(如何從0到1搭建生鮮B2B的技術體系)裡,我們聊到如何在生鮮B2B業務中快速搭建技術體系來支援公司起步階段的需要,這篇文章會繼續擴充套件開來,來聊聊面對生鮮B2B業務的volatility(易變性)、uncertainty(不確定性)、complexity(複雜性)、ambiguity(模糊性),宋小菜技術是如何應對的。有些業務場景我們借鑑了業界成熟的解決方案，但更多業務場景是沒有可參考可借鑑的,我們只能用最輕的方式來嘗試-總結-優化,這個過程沉澱了宋小菜技術自身對於生鮮B2B的深入理解後的解決方案。宋小菜技術發展過程有些時候是見招拆招,因為業務的突然變化,我們會措手不及,沒有辦法快速支援業務需求,然後會背上公司業務瓶頸的"罪名",這篇文章也會記錄下我們在技術上犯的錯誤,同時會以重新再來一遍的視角來剖析問題,並給出合理的解決方案。所以這篇文章會有成功經驗分享,也有失敗教訓總結。
1.宋小菜的業務擴張帶來技術的挑戰
一個創業公司如果起步階段的商業模式跑通並驗證是可以複製的,那麼下個階段就是快速業務擴張。從2015年6月份開始,宋小菜從武漢出發,準備同時在全國新開3個城市(杭州、北京、上海)。這個時候我們面臨幾個問題:
- 技術團隊需要脫離外包開發團隊,完全獨立自主開發,外包團隊已經無法快速響應業務需求。
- 我們在上篇文章中提到,erp系統設計沒有考慮到水平擴充套件,業務量翻4倍,erp系統當時的單系統架構扛不住4倍增長的訪問量。
- erp系統中的倉儲模型和商品模型設計不能支援多城市擴張。
- erp系統上整合了資料包表的功能,而資料包表都是實時查詢線上資料庫,銷售同學每天在跑單高峰期都會頻繁查詢資料包表檢視自己的業績情況,因為資料量比較大,經常發生oom的問題影響到小B客戶的下單。 上述問題會嚴重影響到業務擴張,如果不在業務落地之前解決,我們就沒有辦法在新城市讓小B下單。而解決這些問題只有1個月的時間。時間緊迫、事情複雜、對線上業務影響大，我們從業務未來方向規劃了一版新的系統架構，如下圖所示:
圖1.系統架構
複製程式碼這個系統大圖基本確定了後面2年多的宋小菜技術方向,並支援了宋小菜2年多的業務發展,按照這個系統大圖,我們做了2件事情:
- 系統結構規範
- 模組化改造,剛開始沒有做服務化升級,使用jar包依賴的方式模組化各個業務域。
- 系統拆分,按照採配銷業務域搭建獨立的系統支撐。
- 核心模型抽象重構
- 倉儲模型支援多城市物流排程，一個城市一套倉儲。
- 商品模型支援上游鏈路集採,下游渠道定製上架銷售。
2.缺失統一架構思想,系統建設陷入混亂
這次系統架構升級暫時解決了宋小菜在15年到16年的銷售端規模擴張的問題,但是核心問題我們沒有看到也沒有解決。從圖1的系統架構可以看到技術團隊開始按照業務域劃分系統模組,並開始抽象和下沉核心服務能力(訂單中心、商品中心、庫存中心、使用者中心),而這些設計坦白講是參考了淘寶網的系統體系,套用在宋小菜的業務上。所以怎麼劃分業務域?沉澱哪些系統核心能力?在當時設計實施時,是沒有一套架構思想指導。在2016年，當時業務需求併發的時候,技術專案組沒有統一的架構規範，各自按各自對業務的理解進行模組拆分，造成了業務系統拆的太細，系統層次太深，模組依賴太多，一個CRM系統後面需要依賴幾十個業務模組,如下圖所示:
- 新人搭建工程成本增加,熟悉業務的深度和廣度加大。
- 依賴模組程式碼變更,打包測試都需要重新拉程式碼,增加系統整體維護成本。
- 每個模組維護同學不一樣,如果要調整功能和釋出系統,需要跟多個不同模組的同學協調溝通。 在2015年到2017年期間,技術團隊的規模不大(只有30人),團隊核心開發同學基本穩定,加上自動化的運維工具存在,所以上述問題基本沒有帶來太大影響。但是這種將系統模組拆太細,想一步跨入微服務架構的做法是不太推薦的。
3.理解需求本質才能設計出符合業務需要的系統
因為我們沒有理解業務的本質,所以當時設計的模型是不穩定的，一旦業務形態和業務打法發生變化,又需要重構線上的模型。在隨後2年時間裡,我們陸續3次重構了商品模型,到2016年底我們才意識到問題出在哪裡----沒有理解業務需求的本質。 很多同學在設計系統時,首先關注的是系統的訪問效能、穩定性、安全性等技術細節,然後考慮使用一些新框架和新技術來幫助系統模組間解耦和滿足未來系統的可擴充套件性,最後根據業務需求中需要的資訊維度來設計表,滿足資料儲存的需求。這個系統設計的過程,其實是忽略業務需求的本質。為什麼大家都有這樣的慣性思維了，因為在網際網路高速發展時期，技術圈子裡談的最多是各種通用的高併發，彈性可擴充套件的問題和解決方案，一旦熟練的使用這些解決方案，碰到任何系統需求，都會用這些現有解決方案來設計系統，這就類似一個熟練使用錘子的工人，看到任何東西就想用錘子釘釘子，陷入了認知思維陷阱。 那麼我想和大家聊下,什麼樣的系統設計過程才是正確的.所有的業務需求其實是想使用產品功能來解決商業上具體場景中的問題,而我們在設計系統的時候,在沒有理解問題的本質之前就使用現有的解決方案來解決問題,很大概率上會出現使用了一套完美的系統設計方案,卻在實施後沒有解決使用者問題的情況。就算系統設計方案再完備沒有缺陷,沒有解決使用者問題,也是一套失敗的系統設計方案,做了南轅北轍的事情。 所以系統設計過程中首要步驟是理解業務需求,找到業務需求背後想解決的根本問題。這時大家會想到,這個步驟難道不是產品經理要去做的麼？我們根據產品經理的產品方案來設計系統就可以了啊，作為架構師或者開發同學為什麼要去理解需求的本質了,這不是做了越俎代庖的事情麼？在沒有從0到1做一個業務系統之前,我也是這麼認為了.在經歷宋小菜3年的系統設計和開發,特別是經歷過上文提到的3年時間3次重構商品,我意識到系統設計人員一定要和產品經理一起來思考業務需求,理解需求的本質,幫助產品經理來優化產品方案,為什麼說是幫助產品經理？因為對業務系統最熟悉的人是架構師和開發同學,而架構師和開發同學和產品經理相比強於系統性思維和抽象思維,而在產品過程中(產品設計+產品開發落地)需要系統性思維和抽象思維來幫助產品方案的設計的。產品經理接到業務方的需求時,因為長時間在業務場景中,會很難從具體需求中做需求抽象、做需求系統化,缺少抽象和系統化設計的產品方案有可能只是簡單翻譯了業務需求,而沒有真正解決使用者問題。有個很典型的例子說明這個問題,20世紀初在美國,由於經濟發展速度很快,大家對於交通速度要求越來越高,當時美國民眾的主要交通工具是馬車,他們的需求是怎麼樣讓我的馬跑的更快,很多商人看到了這個機會,拼命研究怎麼讓馬跑的更快,改進馬蹄,讓馬吃更多。唯獨亨利·福特發明了適合大眾使用的汽車,並讓汽車作為陸地交通工具在全球普及,因為他理解了美國民眾需求的本質,不是要更快的馬,而是要更快到達目的地。 抽象和系統化就是要用模型來表達和思考,所以從2015年年底開始,我們開始尋找適合宋小菜業務的建模方法,偶然機會在網路上看到DDD(領域驅動設計)的介紹和要解決的問題。在系統性學習DDD之後,我們小範圍內嘗試了幾次,因為理解不深入,加上團隊對於業務抽象能力沒有達到實施DDD的要求,期間失敗了,之後打算放棄DDD實踐。但是從2017年開始,我們發現很多網際網路公司開始嘗試和實施(特別是阿里巴巴裡一些資深架構師在杭州技術圈中不停推廣DDD),然後2017年4月阿里資深架構師雷卷被邀請到宋小菜進行技術分享,帶來了新的關於DDD實施的經驗和建議,我們又開始持續在系統設計過程中實施和嘗試。在持續的實施過程中,我們發現基於DDD的架構思想是可以幫助我們梳理好系統,規劃出一套的符合業務需要的架構。即使在生鮮B2B業務的快速變化情況下,依然可以保證整體架構的清晰、業務系統快速響應需求。下圖展示的是使用DDD規劃的業務系統架構。
圖3.基於DDD的業務系統架構 在圖3中,我們根據公司當前的業務劃分了3個大的業務域(供應鏈業務域、物流業務域、買家業務域),然後從這3個業務域中抽象出核心的業務元素,這些業務元素就形成了系統能力層中的6大服務中心(商品中心、使用者中心、交易中心、工單中心、物流中心、倉儲中心)。在宋小菜3年的業務發展過程中,業務模式和業務打法是一直在變,但是業務方向和核心業務元素一直沒有變:
- 人
- 車
- 貨
- 倉
- 交易
- 協同 這些核心業務元素對應了能力層的服務中心
- 人->使用者中心
- 貨->商品中心
- 交易->交易中心
- 車->物流中心
- 倉->倉儲中心
- 協同->工單中心 對比圖1和圖3的系統架構,可以發現我們通過理解宋小菜的業務本質,沉澱了屬於宋小菜自己的核心服務能力,在未來的業務發展過程中,只要宋小菜業務方向不變,我們可以通過底層沉澱的核心服務能力快速構建出滿足上層不同業務域的不同業務打法的業務系統。這樣的架構方式抽象了業務,減少了重複的業務元素構建和開發,可以快速響應新業務需求和老業務迭代需求。下圖展示了業界對於使用DDD的構建系統方式和其他構建系統方式在開發效率上的對比總結。
4.要善於藉助外部能力來彌補自己技術的短板
在圖1的系統架構圖中,可以看到我們用了很多開源的技術框架,也大量使用阿里雲的付費解決方案。這是該篇文章裡第二個要丟擲來的觀點。要善於藉助外部能力來彌補自己技術的短板。在今天的網際網路環境下,越來越多的小公司可以在短短2到3年時間成長為獨角獸,這樣的業務發展速度是需要足夠技術能力支撐的,而這些公司基本都使用了開源解決方案和類似阿里雲提供的商業解決方案來幫助公司在短期內進行技術能力彎道超車。 ps:後面文章會補上宋小菜在推進生鮮B2B業務時,如何藉助外部能力的。
5.快速應對生鮮B2B業務變化的建議
- 在生鮮B2B業務裡,理解業務需求的本質才能快速交付符合業務需求的產品,而DDD的方法正好可以來幫助架構師和開發同學梳理和理解複雜多變的業務需求。
- 在生鮮B2B公司發展過程中,技術團隊一定要善於藉助外部能力來快速提高自己的技術能力,將自己不擅長的和非公司核心能力部分交給第3方來運營,將自己的精力集中在核心能力建設上,而建模能力絕對是技術團隊的核心能力。
關於如何搭建高效率的生鮮B2B平臺，因為包含的內容較多，也很複雜，無法再一篇文章中給大家講清楚，本篇文章只是拋磚引玉，下面將分為多篇文章從行業現狀、業務現狀、產品概述、技術團隊搭建、服務端技術平臺搭建、前端開發等多個維度來講述，我們將三年多在B2B領域沉澱的核心產品和技術平臺公開，希望更多行業的人能深入瞭解，少走一些彎路，希望對大家有幫助，本系列文章分佈如下（會繼續更新）：
1、《如何搭建高效率的生鮮 B2B 平臺（B2B 技術共享第一篇）》
2、《宋小菜如何切入生鮮 B2B 市場（B2B 技術共享第二篇）》
3、《生鮮 B2B 平臺的產品體系如何迭代（B2B 技術共享第三篇）》
4、《生鮮 B2B 如何搭建高效的技術團隊（B2B 技術共享第四篇）》
5、《如何從 0 到 1 搭建生鮮 B2B 的技術體系（B2B 技術共享第五篇）》
6、《宋小菜技術如何應對生鮮 B2B 業務的快速變化（B2B 技術共享第六篇）》
7、《生鮮 B2B 技術平臺的前端團隊該如何搭建（B2B 技術共享第七篇）》