如何从 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 技术共享第九篇）》