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

宋小菜一直聚焦做中國生鮮的分銷網路

宋小菜從2014年年底建立,到今天為止,3年多的時間只做了一件事情,摸索到蔬菜供應鏈的上游,為什麼宋小菜要把業務持續往“上”做了?做B2B業務,只有控制供應,優化供應效率和成本才能將業務做成。3年的發展過程中,宋小菜公司整體的思路就是反向供應鏈,先有需求,後有供應。我們從一二線城市收集客戶(宋小菜內部稱呼服務城市端菜市場賣菜的菜販客戶為小B)訂單,通過區域集單,將訂單轉化成上游蔬菜產區的採購單,入駐宋小菜平臺的供應商會拿到這個採購單,然後通過第三方提供物流服務將商品傳送到城市端的宋小菜服務網點。宋小菜的業務模式如下圖所示:

宋小菜技術起步輕,走的快

2015年3月10號,宋小菜反向供應鏈模式在武漢進行業務測試,在武漢馬湖菜市場開了第一個服務小B的服務站點,並在完成第一筆訂單。當時技術團隊的背景如下:

• 2015年1月份宋小菜產品技術團隊正式組建，並開始搭建系統架構
• 團隊成員組成:1個開發同學，1個產品，2個外包同學,開發主力是外包同學。 為了快速支援當時的業務需要,宋小菜的技術體系從0到1搭建的很輕,但是在核心技術選型上,又會做的比較重,我們會基於3到5年後宋小菜業務的情況來做技術選型的考慮。下面會從4個維度(開發語言、基礎設施、後端服務、移動端)來介紹宋小菜技術是怎麼樣從0到1的過程進行技術體系搭建的。

開發語言

在創業公司的初始階段,技術團隊架構搭建和技術選型會決定產品技術對業務是可以快速支撐,還是會綁架了業務,阻礙業務發展。不管是業務驅動型的公司，還是產品驅動型的公司或者技術驅動型公司，都會面臨這樣的問題。選擇技術架構就決定了對公司業務的影響。 開發語言選擇是創業公司技術選型的第一個面對的問題。在當前社會環境下,分工越來越細,開發工程師使用的語言工具會越來越侷限，雖然很多網際網路公司鼓勵全棧工程師的培養，但是長期來說，大部分工程師還是隻精於一種開發語言的使用。選擇一種開發語言，就決定了技術團隊的組織架構。大部分網際網路企業開始搭建後端服務時使用了類似node.js,python,php等語言,這些語言在早期開發時可以快速搭建服務,並快速支援產品功能變更,在創業初期會帶來很多靈活性。而宋小菜技術團隊早期選擇java作為後端核心開發語言,在我2015年5月份加入宋小菜時,感覺比較詫異,映象中的創業公司很少用java這種航母級的語言進行早期產品開發的。經過3年多的實戰經驗積累,證明選擇java作為後端開發語言是比較滿足宋小菜業務發展需求的。宋小菜作為一個電商領域的服務平臺，吸收了很多電商平臺的歷史經驗和教訓。淘寶網從2003年建立,使用php搭建服務,2004年開始整個後端服務使用java改寫,當時外包給sun的團隊來做。杭州有些電商平臺在剛建立的時候使用php搭建服務,3年後開始全面切換到java。這些大的電商平臺具體為什麼切換到java開發語言，不知道確切的原因，至少在電商領域使用java會帶來如下看的到的優勢。

• java語言的工程能力,工程搭建的可持續整合能力為後續企業的平臺能力沉澱和建設提供了保障。
• 具有強大的業務表達能力,可以將商業需求轉化成產品系統。
• 成熟的企業級解決方案(rpc,mq,快取,分庫分表,分散式事務)，在面對業務量指數級增長的時候，可以利用成熟的社群解決方案(或者類似阿里雲paas平臺的)快速進行水平擴充套件
• 因為java的開發過程比較重，會倒逼需求方和產品對待需求更慎重,在需求階段就可以過濾掉一些偽需求，避免造成開發資源的浪費。
• 在杭州地區以阿里巴巴為代表的網際網路公司培養了大量的java工程師,組建技術團隊資源更多,更容易擴充和壯大團隊。 所以創業團隊在技術選型上，想走的遠走的穩，使用java進行產品開發是較好的方案。

基礎設施

2014年之後籌建的創業公司基本選擇阿里雲這類Iaas平臺作為基礎設施的提供方。阿里雲這個產品本身是從歷年的天貓雙十一中淬鍊出來的，服務的高可用得到了證明，而且也支援快速擴容(微博在遇到熱門事件時選擇臨時購買阿里雲的ECS進行短期緊急擴容)，而阿里雲還在不斷提供網際網路公司需要的服務能力和解決方案，這些解決方案很好滿足了電商公司的需要。宋小菜從第一個服務上線開始一直在使用阿里雲的基礎設施服務。下面是宋小菜使用的阿里雲服務列表

上表反映出,使用阿里雲的服務時,我們沒有把6個服務全部開啟使用,而是分階段使用阿里雲的服務,貼著公司的業務需要,從效率和成本出發考慮。有個很好的例子說明了我們進行技術選型的思路,早期宋小菜的資料庫是自己搭建的,只有一個mysql例項,也沒有進行資料備份和資料庫服務容災處理,在2015年7月份之前宋小菜的業務只在一個城市開展,所以資料庫的TPS不大,沒有一開始就使用阿里雲的RDS服務,而在2015年6月份開始,宋小菜計劃同時開啟3個城市的業務,考慮到業務量上漲3倍以上後,系統的壓力也會翻3倍以上,而所有的訪問量都會壓在資料庫上,資料庫要進行擴容以支撐業務量的增長,結合公司資料安全的考慮,我們沒有考慮擴容當前的資料庫,而是直接遷移到RDS上。 經過3年的阿里雲服務使用後,阿里雲提供的基礎設施服務和解決方案不僅可以保證我們的服務質量的要求,而且節省了技術團隊的人力投入。到目前為止,我們沒有專職PE和DBA,開發同學在日常工作中只用承擔簡單的運維工作,這樣開發同學可以專注在開發和新技術的預研上。另一方面,因為阿里雲在基礎設施上提供了高可用性，在業務發展過程中我們避免了服務不穩定造成的公司損失。 在使用阿里雲的服務時,很多人都會擔心對阿里雲的依賴越來越重,會造成後期自己的技術升級和轉型會受制於阿里雲,其實這些影響不會太大,Netflix現在做到了千億美金市值的公司,網路流量是全球網際網路公司第一,服務依然架設在AWS上面。如果公司的技術能力比較好,建議把後端服務都裝到Docker中,發生極端情況時,出雲和遷移到其他雲上的遷移成本也會很小。 這3年不斷增加對阿里雲的服務的使用,讓我也體會到,企業級解決方案如此成熟的今天,非雲端計算公司的後端技術團隊,其核心能力應該是對業務的抽象和建模能力,這也是為什麼從2016年開始嘗試DDD,並不斷試錯使用的原因。

後端服務

早期的宋小菜只有一個ERP系統，這個系統使用springmvc框架搭建了典型的mvc架構。值得一提的是使用springmvc搭建mvc架構是很高效的,配置簡單,擴充套件性也比較高,基本滿足了簡單系統對於登陸驗證、許可權控制等功能需求。因為當時就一個後端系統,所以網頁端和移動端跟後端通訊都是基於http協議。這個系統剛開始設計的時候沒有考慮到後期的水平擴充套件,到現在只能單點部署,所以一直是線上服務的一個雷區。 當時沒有進行系統層次的規劃，雖然分成了controller和service 2層結構，但是很多業務邏輯都放在controller中，造成各個業務域的核心業務邏輯都散落在controller中.當時服務端開發人員只有3個人,這種Megalith Platform對於小團隊還是比較ok的,單一系統單一開發人員,可以快速響應產品需求。但是隨著業務快速發展,技術團隊持續擴張,在沒有工程結構規範和系統文件缺失的情況下,人人都在erp系統上開發產品需求,宋小菜採配銷業務的產品功能都整合到這個系統上,erp系統不可避免成為了宋小菜的一個巨無霸,造成了後面多重問題爆發:

• 重複的程式碼開發
• controller層和service層程式碼臃腫
• 打包部署時間長
• 開發迭代速度越來越慢
• 系統穩定性問題
• 訪問效能問題 這個時期的erp系統基本覆蓋了宋小菜的所有業務鏈路,從採購端到配送端,再到銷售端,內部員工要依賴erp完成工作。在銷售端,宋小菜對小B客戶提供售後服務,具體包括提貨簽收、退貨賠款等服務,而這些服務都是在erp上完成的,所以公司在每個開展業務的菜市場都租了一個辦公室(公司內部業務名詞叫服務站),並配備銷售人員全職服務菜市場的小B客戶,每個服務站配置了電腦和印表機(有些服務站還配備了UPS,防止菜市場停電)。現在回想起當初的技術解決方案對於業務來說確實太重了,這種情況一直延續到2016年4月份才解決,2016年4月份之後銷售端的業務操作都在移動端app宋小福(銷售crm產品)上完成的,移動端的解決方案不僅節省了硬體成本,也擴大了銷售的工作半徑。從這個案例證明了之前聊到的技術架構和技術方案一旦落地就會限制和綁架業務的結論,這個案例讓我明白了架構師這個角色需要有市場思維,同時也需要有產品思維,在設計產品的技術方案時,需要充分理解使用者的需求本質,用最簡單且低成本的方案滿足使用者需求。

移動端

在宋小菜起步階段,移動端只有宋小菜app一款app,而且只有android版本,服務的使用者是菜市場的小B客戶。當時銷售同學在跑完一遍武漢市場後反饋小B客戶使用android手機的比例最高(有些上年紀的小B使用的是非智慧手機)，所以在起步階段只提供android版本。

                                        宋小菜app第一版首頁 早期移動端的可用性是比較低的,產品技術團隊一直沒有配備專職測試,測試工作交由產品經理來做,所以類似適配各種android機型的相容性測試都做不了(要達到覆蓋度較高的android相容性測試,需要購買市面上10多款主流裝置,這個成本對於早期創業公司還是比較大的)。在開發流程中,產品經理進行功能性驗證後,就通過宋小菜自己渠道釋出app出去,沒有很完備的測試,上線之後就進入了開發工程師的持續性人肉運維過程。這個時期,宋小菜還沒有app端異常收集的工具,小B暴露問題後第一時間反饋給銷售,銷售再轉到產品技術這邊。在業務試跑階段,開發貼著業務現場快速響應問題並解決問題。

app端的使用體驗一直不太好,加上app的使用者是50歲左右的在菜市場賣菜的大爺大媽,銷售在小B客戶的業務場景中承擔很多客服職責,銷售的很多時間在幫助和教育小B怎麼使用宋小菜app進行下單。在2015年4G使用不太普及的,小B客戶在2G、3G環境下使用宋小菜app,首頁響應速度很慢(10s左右),銷售為了快速跑單,是先用本子記下來,回到服務站電腦前使用erp幫小B代下單。 今天再回過來想下起步階段在移動端上的技術選型還是太重了,當時整個技術團隊就一個外包android開發,整體開發能力達不到要求,如果起步階段藉助微信的平臺能力來連線我們的小B客戶,不僅能滿足小B使用宋小菜服務(代採、配送、售後)的需要,而且也減少了銷售在服務小B客戶上的成本。通過產品來運營小B也會規避我們後期業務中出現的問題，後面的章節會說到這些問題。這裡額外說下技術之外的話題,在一個類似宋小菜這樣的在早期靠業務驅動的公司,做業務的同學使用網際網路思維(平臺思維、產品思維)來規劃和推進業務是很關鍵的,直接影響業務推進速度和規模。

總結

在起步階段,宋小菜的技術架構有做的好的地方也有做的不好的地方。如果再重新做一遍宋小菜的架構,我會這樣去思考的,這些思考和總結對初創公司進行技術選型和技術架構搭建有比較好的參考價值。

1.技術選型要結合公司長期業務方向

• 長期的技術路徑一定要規劃清晰,包括搭建什麼樣的技術團隊來匹配公司業務方向長期需要。如上文提到宋小菜採用了java這種開發模式很重的語言來搭建整套後端系統,採用了這套技術路徑,就決定了長期的解決方案選擇。
• 起步階段專注在公司的核心業務的開發工作上,伺服器運維和資料庫運維等交由第三方專業的Iaas服務商提供支援。
• 不要起步就做服務化架構,系統架構需要和技術團隊規模相匹配.起步階段搭建一個大而全的系統對業務需求的響應速度是最快的。

2.技術實現上做輕

• 技術架構上,前後端做到簡單可擴充套件,一定不要把技術方案做複雜了,避免過渡設計。使用最小可交付原則(MVP),將互動和內容做到儘量簡單,並且保證產品的使用者路徑資料閉環(產品使用有迴路反饋),使用PDCA(計劃-執行-檢查-行動)模式保證產品的持續快速迭代。
• 在不確定和未知業務上,保持技術實現的簡單,因為技術實現越複雜,出錯的概率就越大。

關於如何搭建高效率的生鮮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 技術共享第七篇）》

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

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