架构建模如何实践

在前面我们讲述了软件架构建模的方法论, 其中我们讨论做架构设计的目的是解决软件的复杂度, 而建模则是作为一项架构设计工具来辅助我们识别问题复杂度. 但方法始终是理论, 没有实践也很难体验到其中面临的困难, 学习不仅要知, 还要行, 即知行合一, 今天来聊聊我是如何进行架构建模实现推荐系统架构设计.

业务建模分析

关于业务模型, 我们可能都不知道业务模型是什么? 它主要的关注点是哪些呢? 同样我们借助AI来辅助我们答疑下:

业务模型: 包含价值主张、业务流程以及收益结构, 作用是指导技术实现, 确保技术与商业目标一致.

我结合对推荐系统的认知将上述业务模型的概述进行分解:

• 价值主张: 是企业提供给的需求价值, 比如推荐系统的个性化服务是帮助用户在“信息过载”下筛选自己感兴趣的物品, 提升用户体验;
• 业务流程: 比如我们要搭建一个推荐系统,那么推荐系统的业务流程是如何构成的? 即定义业务流程.
• 收益结构: 如何去衡量构建一个推荐系统的收益, 比如提升CTR、GMV指标等.

因此我们可以简易得到一个推荐系统顶层的业务模型如下:

在这里我将上述的业务流程定义为一个价值流, 价值流是业务流程的一个抽象, 而业务流程是价值流程的一个具体实现,而我们的业务流程结果是最终是业务能力的体现, 因此在我们的业务模型中,我们的价值流需要我们有对应的业务能力来支撑才能实现一个价值流, 而一个业务能力则需要我们的一个完整的推荐系统业务流程来提供.当我们理解业务模型之后, 我们就要考虑有哪些业务流程来赋予我们上述的业务能力了,也就是接下来的概念模型分析.

CIM建模分析

在CIM建模阶段, 其主要作用是描述业务需求和领域逻辑，分析并定义业务流程,识别业务复杂度.在这个阶段我们可以将上述的业务能力进行拆解,通过子业务能力的组装与关联共同支撑顶层业务能力的实现.即:

业务能力即业务流程交付的结果, 而通过业务能力我们可以逐步完善我们的业务流程, 通过业务流程我们会逐渐去补充我们不完善的业务能力. 通过上述的业务子能力的拆解我们就可以得到由这些子业务能力组装形成的业务流程, 即一个完整的推荐业务流程如下:

至此通过建立概念模型能让我们对推荐系统业务流程有了新的认知, 这个时候才考虑要如何去实现这样的一个推荐系统.最后,我再做一张进行总结如下, 概念模型的输出是建立我们的业务流程, 对整体业务流程环节要清楚.通过业务流程我们可以去识别其中的业务复杂度以及业务不确定性的问题.

PIM建模分析

在PIM建模阶段,主要目标是基于上述的业务流程转换为系统需求, 在这个阶段我们除了要基于业务流程进行技术转换,同时还要识别到系统的需求, 即非功能性需求. 这里我们的主要核心目标就是拆分将上述的业务流程进行分层、分模块以及分功能的细化.

通过上述的业务流程分析, 我们一个完整的推荐系统至少需要以下部分:

• 数据系统: 负责数据采集、清洗加工、存储以及数据可视化分析等模块.
• 画像与特征系统: 用户画像负责用户属性构建, 比如基础属性、静态属性以及动态行为序列属性的拆分, 物品画像复则是基于模型算法技术识别文本数据、标签系统建设以及知识图谱构建等; 特征层面负责建立单边特征、组合特征加工等模块
• AI预估系统: 负责模型模型数据编码转换、模型训练以及算法模型预估等模块
• 在线系统: 基于推荐算算法核心链路拆分数据检索、召回、排序以及规则过滤等模块
• AB系统: 主要包含在线流量AB分层分桶以及AB效果分析统计等模块

另外,我们从用户请求链路上看,基于上述的业务流程转换为系统层面的逻辑, 这个时候要求我们关注系统每个层面的职责,结合上述的模块分布, 我们将推荐系统进行分层设计如下:

• 用户请求流量如何分配,考虑推荐接入层/网关层, 用于将用户请求以及基于场景路由分发.
• 推荐引擎链路职责明确, 在软件架构分层上可以拆分为召回模块、排序模块以及重排模块等内部模块分层逻辑
• 物品索引层赋予统一数据查询能力提供上游的推荐引擎用于检索过滤
• 数据收集清洗,可采用大数据Lamda或者Kapper的架构方式来完成对应的数据加工.
• 在推荐系统链路层面增加管理与链路追踪,即如何增加业务层面的配置管理以推荐业务链路的可观测性.也就是非功能性需求.

这样我们又得到一个推荐系统逻辑层面的分层模型.这个模型也将帮助我们在后一个环节也就是我们的技术备选方案发挥不可或缺的作用, 比如我们的部署方式、服务拆分逻辑、性能评估等策略都会依赖于上述的系统分层架构来做指导和设计.上述的分层架构不是绝对,其实还要基于实际情况去做对应的层次划分.

PSM建模分析

在PSM层面有很多不同不同的模型产物, 在数据模型层面PSM是物理模型,即存储系统如何将数据转换为磁盘存储的设计实现.因此PSM层面我们更关注具体每个模块如何选择对应的技术来实现, 其中产生的模型只是我们设计过程的最终结果, 目的是用来辅助我们后续的具体技术实现细节.

在此进行PSM建模之前,我们先考虑以下业务背景, 即我们要搭建一个支持百万用户在线的直播推荐系统,其中高峰时段在每天晚上8点-8点05分会存在大量用户涌进平台看直播.同时这里我们仅考虑如何构建技术备选方案来实现推荐系统中的用户画像系统服务.

这个时候我们需要针对用户画像系统建立系统性能模型如下:

可以结合上述的存储技术组合对应的备选方案架构, 由于我们需要考虑高性能以及低延迟,因此Redis会在我们的架构设计方案中,因此我们可以得到以下三种备选架构设计方案:

通过上述设计的备选方案不同, 对应的架构设计属性也不同, 因此还是回归目标, 画像系统服务对架构属性的要求是怎样的, 对于画像系统数据一旦用户画像数据丢失, 直接影响到后续的特征以及模型预估, 导致出现质量偏低的推荐列表, 极大影响用户体验, 这与我们要提供的价值主张产生矛盾.因此可靠性以及可用性是我们首先要考虑的一点, 因而从上述备选架构方案中, 我们会选择Redis + Rocksdb 或者是Hbase + Redis的方式, 接下来要考虑满足低延迟的高性能要求, 这个时候我们会选择Redis + Rocksdb和Redis内存的架构设计方式, 同时满足上述可靠性+可用性+低延迟高性能要求, 我们将采用Rocksdb + Redis的架构技术方案. 最后我总结一点就是对架构属性进行排序选择合适的技术方案.

总结

至此我们完成了一个推荐系统从需求分析到最终的技术落地的架构建模过程,其实本质上还是通过从业务架构分层、分模块甚至是分功能的方式拆解每个业务流程的环节, 最后逐步从业务架构逐步转向应用架构层面的技术具体化.最后我先画一张图针对上述流程进行总结如下: