如何從 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進行短時間緊急擴容)，而阿里雲還在不斷提供互聯網公司須要的服務能力和解決方案，這些解決方案很好知足了電商公司的須要。宋小菜從第一個服務上線開始一直在使用阿里雲的基礎設施服務。下面是宋小菜使用的阿里雲服務列表

使用服務	解決問題	開始使用時間
ECS	服務器的管理和運維	2015年3月
RDS	數據庫的管理和運維	2015年6月
OSS	文件存儲的管理和運維	2015年8月
消息MQ	服務事件管理	2017年3月
EDAS	服務治理	2017年10月

上表反映出,使用阿里雲的服務時,咱們沒有把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領域沉澱的核心產品和技術平臺公開，但願更多行業的人能深刻了解，少走一些彎路，但願對你們有幫助，本系列文章分佈以下（會繼續更新）：

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

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

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

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

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

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

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

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

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