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