宋小菜技术如何应对生鲜 B2B 业务的快速变化（B2B 技术共享第六篇）

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

一、《如何搭建高效率的生鲜 B2B 平台（B2B 技术共享第一篇）》

二、《宋小菜如何切入生鲜 B2B 市场（B2B 技术共享第二篇）》

三、《生鲜 B2B 平台的产品体系如何迭代（B2B 技术共享第三篇）》

四、《生鲜 B2B 如何搭建高效的技术团队（B2B 技术共享第四篇）》

五、《如何从 0 到 1 搭建生鲜 B2B 的技术体系（B2B 技术共享第五篇）》

六、《宋小菜技术如何应对生鲜 B2B 业务的快速变化（B2B 技术共享第六篇）》

七、《生鲜 B2B 技术平台的前端团队该如何搭建（B2B 技术共享第七篇）》

八、《宋小菜有关“能力”的设计和思考（B2B 技术共享第八篇）》

九、《服务拆分的设计和思考（B2B 技术共享第九篇）》