宋小菜技術如何應對生鮮 B2B 業務的快速變化（B2B 技術共享第六篇）

在上一篇文章(如何從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系統後面須要依賴幾十個業務模塊,以下圖所示:

              圖2.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.實施DDD的開發效率對比

4.要善於藉助外部能力來彌補本身技術的短板

在圖1的系統架構圖中,能夠看到咱們用了不少開源的技術框架,也大量使用阿里雲的付費解決方案。這是該篇文章裏第二個要拋出來的觀點。要善於藉助外部能力來彌補本身技術的短板。在今天的互聯網環境下,愈來愈多的小公司能夠在短短2到3年時間成長爲獨角獸,這樣的業務發展速度是須要足夠技術能力支撐的,而這些公司基本都使用了開源解決方案和相似阿里雲提供的商業解決方案來幫助公司在短時間內進行技術能力彎道超車。 ps:後面文章會補上宋小菜在推動生鮮B2B業務時,如何藉助外部能力的。

5.快速應對生鮮B2B業務變化的建議

• 在生鮮B2B業務裏,理解業務需求的本質才能快速交付符合業務需求的產品,而DDD的方法正好能夠來幫助架構師和開發同窗梳理和理解複雜多變的業務需求。
• 在生鮮B2B公司發展過程當中,技術團隊必定要善於藉助外部能力來快速提升本身的技術能力,將本身不擅長的和非公司核心能力部分交給第3方來運營,將本身的精力集中在覈心能力建設上,而建模能力絕對是技術團隊的核心能力。

關於如何搭建高效率的生鮮B2B平臺，由於包含的內容較多，也很複雜，沒法再一篇文章中給你們講清楚，本篇文章只是拋磚引玉，下面將分爲多篇文章從行業現狀、業務現狀、產品概述、技術團隊搭建、服務端技術平臺搭建、前端開發等多個維度來說述，咱們將三年多在B2B領域沉澱的核心產品和技術平臺公開，但願更多行業的人能深刻了解，少走一些彎路，但願對你們有幫助，本系列文章分佈以下（會繼續更新）：

一、《如何搭建高效率的生鮮 B2B 平臺（B2B 技術共享第一篇）》

二、《宋小菜如何切入生鮮 B2B 市場（B2B 技術共享第二篇）》

三、《生鮮 B2B 平臺的產品體系如何迭代（B2B 技術共享第三篇）》

四、《生鮮 B2B 如何搭建高效的技術團隊（B2B 技術共享第四篇）》

五、《如何從 0 到 1 搭建生鮮 B2B 的技術體系（B2B 技術共享第五篇）》

六、《宋小菜技術如何應對生鮮 B2B 業務的快速變化（B2B 技術共享第六篇）》

七、《生鮮 B2B 技術平臺的前端團隊該如何搭建（B2B 技術共享第七篇）》

八、《宋小菜有關「能力」的設計和思考（B2B 技術共享第八篇）》

九、《服務拆分的設計和思考（B2B 技術共享第九篇）》