在上一篇文章(如何从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领域沉淀的核心产品和技术平台公开，希望更多行业的人能深入了解，少走一些弯路，希望对大家有帮助，本系列文章分布如下（会继续更新）：

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