大厂CRM系统架构优化实战

共 4745字,需浏览 10分钟

 ·

2024-04-11 00:00


点击下方“ JavaEdge ”,选择“ 设为星标

第一时间关注技术干货! 关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:中央/分销预订系统性能优化;活动&优惠券等营销中台建设;交易平台及数据中台等架构和开发设计。




1 背景

接入大网、KA及云仓三个条线商机,每个条线商机规则差异大,当前现状是独立实现三套系统分别支撑。

2 目标

完成 9 个新条线业务接入,完成销售过程线上化,实现销售规则统一。

3 问题

  • 前端实现数据存储与逻辑代码耦合一起,无法复用,无法扩展,组件化拆分难度大
  • 组件拆分颗粒度较大,业务功能抽象不充分,缺乏复用性
  • 代码重复编写,相似功能冗余严重,开发和维护效率低
  • 代码版本多,接口不统一,开发、运维成本高,难扩展
  • 每个条线阶段、条线内每个商机阶段推进规则都是通过代码单独实现,开发、维护成本高,规则调整都需要代码调整并上线,时效性低,同时阶段规则维护在代码中,无法直观呈现和规则统一收口,运维难度大

4 实现

4.1 方案调研

方案调研阶段,针对业务场景,多次组会对于底层实现方案进行充分讨论,列举每个方案优劣势,选择最适合当前业务场景的解决方案,最终选择上图的框架升级方案。

84c150eb5776b0fba35d0cb6676c6c65.webp

4.2 方案设计

4.2.1 设计思路

快速实现相似业务,减少相似代码,通过前端组件化、后端服务标准化、商机阶段配置化技术手段,支持各条线快速复用和灵活扩展。

4.2.2 前端组件化

① 前端现状

数据存储与逻辑代码耦合,无法复用/扩展,组件化拆分难。表现为 mixins 逻辑代码与 store 数据存储耦合:

  • 降低代码可读性
  • 也降低 store 数据读写灵活性

如人员信息集合,本可针对 name 和 sex 字段在各自组件维,可现实是两个组件不得不调用同一个 mixins 维护。

组件拆分颗粒度较大,业务功能抽象不充分,缺乏复用性。组件拆分没有清晰界限,没有依据业务功能拆分,导致有些组件不纯粹,不符合单一职责原则,无法复用。在后期维护组件逐渐臃肿。

代码重复编写,相似功能冗余严重,开发维护效率低。由于组件无法复用,在后期维护过程中,开发人员对于类似的功能,不得不写很多相似代码,致使整个项目代码冗余、重复,不可维护。

② 解决方案

针对本次商机条线接入功能,采用现有技术难对后续条线依次接入,一个条线一套代码实现,接入周期长人力成本高,按期完成目标是不可能完成挑战。经技术调研,决定搭建求同存异(同为各个条线共用部分,异为各个条线单独部分)的前端组件化方案。依业务功能,抽象独立业务组件模块,依据条线插拔式组装,搭建可维护、可扩展、灵活性高的组件积木化方案,在业务扩展性强的前端模块架构优势更显。

bb07dade790216a103f2cea884d2ef8a.webp
③ 组件积木化方案特点

方案采用积木化前端组件搭建,任一组件都可替换(webComponent),任一父组件都可扩展 n 个子组件。以上图商机信息组件为例,各条线商机信息所含字段存异,每个条线对应商机信息组件不同,最终根据条线选择对应组件加载。

c26faa1d0c044be8aa20c5ebc7514f3d.webp

数据统一管理(store),组件和数据之间为更新和依赖关系,当有组件更新数据,其他组件也立即更新,不用相互传值。以商机详情组件为例,商机详情中修改了商机名称字段,则所有用到商机名称的组件都更新。这需提前对组件和store进行数据依赖更新的建立,通过 computed 与 store 双向依赖和监控机制,当 computed 监听 store 数据变化,将变化数据更新到组件,组件中通过 store 的 mutaions 更新数据到store。

6cb24a30886fb6e940168f205a3f8cc9.webp

商机详情组件化抽象示意图:

d6a134c2534be833ec17df12ec36537b.webp

4.2.3 后端标准化后端现状

  • 未对条线的领域模型和功能模块抽象,烟囱林立
  • 每个条线接入都要重复开发多套代码,各端(PC、移动端)接口不统一,前后端联调对接接口都要区分多套
  • 各条线独立开发部署,随系统功能丰富及产品线持续增加,个性化需求和缺陷修复极大的消耗研发资源和精力

无法满足各条线商机阶段推进可定制的业务诉求:

38ff83ea67724bbe4edae754abf81154.webp
解决方案

通过梳理商机流程与功能可发现,商机中各条线既有相同功能模块,也有独有功能,如商机创建、关闭、激活等流程每个条线差异不大,但有些相似功能模块各条线也存异,如大宗的关闭商机与服务+中的关闭商机各自的关闭条件不一样;

基于此业务场景,需将主流程抽象出标准服务能力;如商机创建流程,定义为权限校验、参数校验、额外特殊校验、补充信息、模型转换、保存数据、跨区校验、后续额外处理等标准模板服务;每个步骤方法都是抽象的,后续每个条线都继承它,可重写逻辑;这就标准化一个创建商机流程。

上述即根据业务特性的模板抽象固化,但咋将整个架构按照条线来走,就要抽象每个条线的流程,如几乎每个条线都有创建商机、关闭商机、激活商机、修改商机等相同动作,将这些抽象成固定接口;然后各自条线都实现该接口并声明成策略,根据入参的识别自动分流至不同条线策略处理;也就形成按条线为策略锚点的模式。

总体利用策略 + 模板模式支持各条线快速复用和灵活扩展,整体服务抽象复用及扩展思路形成大致的核心类图:

c22aea6c6a8b9e19da223feed1334942.webp

整个商机的后端架构经单条线多套接口处理方式调整为适配所有条线统一接口接入;后端整体架构5层,核心层细分逻辑层,代理层及 Mapper 层。

  • 改造中统一接口层,不区分PC、JME端接口,统一以 JSF 接口形式提供
  • 借助物流网关配置PC认证及 JME 认证并一致以 Http 协议对接出去,保证接口层统一

适配层定义个策略适配器,扫描所有**@LineType**注解的策略处理器并缓存,根据解析入参中的条线进行自动匹配处理器进行分配处理,达到自动分配处理请求。核心层多是模板方法抽象与封装,分类抽象商机基本查询、基础 CMD 操作及商机相关联信息操作。将商机推进机制建立在规则引擎,将每个条线的推进规则提前配置在规则引擎的规则表,并在后端服务中统一提供一个推进入口,所有条线都将基于该入口推进,达到推进规则明确,入口统一,阶段可配置等可灵活扩展方式。

通过整体架构优化调整,可适配所有条统一接入、商机阶段可配置,推进规则可定义、接口统一等优点,大大节省研发接入成本。

1fe880e73cc681ef548da6040f89d5dd.webp

4.2.4 商机阶段配置化

① 场景现状

每个销售条线的商机流程阶段及相应规则都存异,甚至同一销售条线也多种业务,对应商机流程阶段不同,为支持多销售条线的差异化商机业务,要求:

  • 实现每个条线的商机阶段个数可配
  • 每个阶段的规则可配
② 方案选型

如图,列举几个条线的商机阶段生命周期,几乎每个条线商机生命周期都不一。阶段之间推进条件允许不一,所以存在不同条线存在相同的阶段,但到达该阶段的前置条件可能不一,就要求阶段规则可配置,但这也导致可复用性小。若编码实现每个条线的阶段生命周期,复杂且难维护。

经调研,这种场景模型即通过多个入参条件决定流程走向(通过、不通过)的简单形式,相对多入多出的模式还简单点,这种模式正已有好的解决方案,规则引擎!现有流程引擎(Flowable、Activity)都有规则引擎实现,如Drools。

对比几款规则引擎都满足,那就考虑系统维护成本。由于公司有部门内部已对 Flowable 二开,那就采用基于 Flowable 流程引擎中的 DMN,模型上来说即输入多个入参,然后根据规则配置判断走向,没有多分支相关联,所以选择 Flowable 规则引擎合适。

解决方案:通过规则引擎,配置商机阶段和阶段推进规则,解决各条线商机阶段差异化问题,将变化流程用配置化方式融入到整体流程:

0abc7bb7778b60ecab2f00e13f810772.webp
③ 效果

规则引擎提供决策表的表达式,决策表分为两个主要区域:

  • 输入表达式

    可定义变量,用于规则输入项(input entries)的表达式。可选Add Input(添加输入),定义多个输入表达式

  • 输出表达式

    可定义选择表执行结果要创建的变量(变量的值将用于输出项表达式,在下面解释)。可选 Add Output(添加输出),定义多个输出表达式

规则配置如图(以服务+条线举例),服务+ 权授权业务商机推进规则:jd-rule-crm_fwj_chance_authorized_business

28503c341358a84de0e05388f2558104.webp

服务+ B 线上业务商机推进规则:jd-rule-crm_fwj_chance_b_online_business

92729ce81ac4e5bf479dd17b76abe318.webp
④ 优势
  • 规则收口,每个条线商机阶段推进规则直观呈现,规则演化轨迹可以追踪,避免问题排查时,通过代码排查方式核对规则,提升运维效率
  • 规则调整可实时生效,避免代码维护和系统上线,提升研发效率
  • 一套代码实现所有条线阶段推进,只需根据条线添加不同输入

5 效果

5.1 提效

消灭烟囱系统,一套系统完成所有条线支撑,实现各条线、各端接口统一。开发成本低,易扩展,提升研发效率,降低运维成本。

按领域对商机拆分解耦,实现商机领域独立部署,在商机领域内,通过:

  • 前端组件化
  • 后端服务标准化
  • 商机阶段配置化

支持各条线快速复用灵活扩展。接入对比结果,研发效率提升显著,也降低运维成本。随标准流程抽象,底层基础服务完善,后续条线接入的效率进步提升:

  • 标准流程和通用基础服务,研测过程的效率
  • 大宗条线接入测试评估工时及实际工时

5.2 提质

交付演示过程中均未出现任何问题,验收全程未出现影响整体进度的阻塞性问题,验收过程顺畅无阻。

写在最后

编程严选网(www.javaedge.cn),程序员的终身学习网站已上线!

点击阅读原文,即可访问网站!

欢迎长按图片加好友,我会第一时间和你分享软件行业趋势面试资源学习途径等等。

添加好友备注【技术群交流】拉你进群,更多教程资源应有尽有

关注公众号后,在后台私信:

  • 回复 架构师 ,获取架构师学习资源教程
  • 回复【面试 ,获取最新最全的互联网大厂面试资料
  • 回复【 ,获取各种样式精美、内容丰富的简历模板
  • 回复 路线图 ,获取直升Java P7技术管理的全网最全学习路线图
  • 回复 大数据 ,获取Java转型大数据研发的全网最全思维导图
  • 微信【ssshflz】私信  【副业】 进副业交流群
  • 点击 阅读原文 ,即可访问程序员一站式学习网站
    
                                                            

最近在准备面试,为大家准备一份2024最新最全Java学习路线一条龙

浏览 17
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报