构建面向复杂B端系统的敏捷架构

1. 赵嘉铎

2.

3. 目录

4.

5. 典型的复杂B端集成式业务平台，业务上呈现出鲜明的 ➢ ➢ ➢ ➢ ➢ 和特征：

6. ◆ ◆  客观原因：标准化逻辑拆解与封装机制缺失  主观原因：面向数据库编程的设计思想 ➢ 不同场景业务逻辑互相交织，系统拓展性差，导致开发者对变更的接受度低，甚至不得不让业务方做出妥协 ➢ 业务逻辑被掩藏在数据库增删改查操作中，代码中充斥着重复且分散数据读写与组装逻辑 ➢ 业务逻辑缺少边界约束，逻辑四处逃逸，业务梳理、问题定位与需求影响范围评估效率低下，缺陷扩散及变更影响范围大 ➢ 数据用啥查啥、用到哪查到哪，必须遍历整个工程才能厘清整个数据库结构，难以建立对完整数据模型的全景认知 ➢ 复杂业务流程代码实现冗长晦涩，迭代过程中只会进行局部修改，造成数据重复及碎片化读写，系统性能及稳定性迅速腐化 ➢ 全景认知的确实进一步导致信息孤岛，数据模型缺少统一的顶层设计，大量重复的实体定义导致模型规模野蛮生长，形成恶性循环

7.

8. ◆ ➢ ➢ ◆ ➢ ➢ ➢ ◆ ➢ ➢ ➢ ➢

9. ◆ ✓ ✓ ◆ ➢ ➢ ➢ ➢ ➢ ➢

10.  ➢ ➢ ➢ ➢ ➢  ➢ ➢ ➢

11.  标准规约：领域能力、领域服务 ➢ ➢  通用可执行实体路由机制 ➢ ➢  拓展点机制 ➢ O(n 1 × n 2 × ... × n m ) → O(n 1 +n 2 +...+n m )

12. 能力门面定义了能力节点的参数与上下文

13. (1) (3) (2) (4) (5)

14. ◆ ➢ 面向过程设计，业务规则处理与数据读写操作互相交织 ➢ 数据重复及碎片化读写 ◆ ➢ 定义领域服务与领域能力执行器四要素：参数、、返回值、标准执行步骤 ➢ ：参数预校验→ →上下文校验→业务逻辑处理→ →领域事件发布→返回值构造 ➢ 业务流程中各个子模块依赖的底层数据在中集中批量查询好 ➢ 执行过程中各个子模块直接从上下文中获取所，并将生成的中间数据放入上下文中 ➢ 流程最后在久化操作 ◆ 中统一执行数据的批量持

15. ◆ ➢ 领域服务负责定义完整业务流程，并在中将业务流程所需的所有依赖数据初始化到领域服务上下文中 ➢ 领域能力会被不同的领域服务复用，因此不能与某个特定的领域服务上下文绑定， ➢ ：调用能力前将服务上下文中的数据映射到能力上下文中，调用完成后再将能力上下文中的生成结果数据映射回服务上下文 ➢ 最后在领域服务的中将通过服务上下文收集到的所有结果数据持久化到相应的存储介质中  ➢ ➢ ➢ ➢

16. ◆ ：实现逻辑模块化拆解与组合复用：引入领域能力沉淀具业务逻辑，引入领域服务定义业务流程：上下文投影增加了能力组合串联的编码复杂度：模块化拆解造成数据重复及碎片化读写：领域服务与能力分别定义各自的上下文并进行数据投影 ➢  ➢  ：降低能力组合复用的编码复杂度， ➢ ，让业务开发者实现填空式开发 ➢ ：UI界面、外部DSL、 ➢ ： ➢ ：Netflix Conductor、LiteFlow、Zeebe、 ➢ 、产品、运营？ ➢ ：引入上下文机制在业务流程前后集中进行数据读写：领域能力不能与某个特定领域服务上下文绑定

17. 这是一个能力编排执行图的示例，它还能起到代码索引的作用，辅助快速定位特定模块的源码位置 ➢ ➢ ➢

18. ◆ ◆ ➢ 数据操作与业务逻辑互相交织， ➢ ➢ 流程执行到哪数据读写到哪，数据模型信息被分散到整个工程代码中， ➢ ➢ 以数据库表为基本单位维护数据读写逻辑， ➢ 底层存储结构直接映射到业务代码中， ➢ ➢

19. ◆ ➢ ➢

20. ◆ ➢ ➢ ➢ ◆ 解决措施 ➢ ➢ ➢ ➢ ◆ ✓ ✓ ✓

21. ◆ ➢ ➢ ➢ ➢ ◆ 应用场景 ➢ ➢ ➢ ➢

22.

23.

24. ➢ rtbad-framework：框架包，承载架构标准规约及分层架构图中基础设施层中的各项基础组件 ➢ rtbad-module/rtbad-support-module ：模型包，承载领域模型中各个聚合及聚合实体对象的定义，其中 support- module定义的是支撑域中的实体对象 ➢ rtbad-event：事件包，属于特殊的数据模型层，承载这领域事件对象的定义 ➢ rtbad-composite/rtbad-support-compoaite ：聚合服务包，对应分层架构中的领域能力及聚合服务层，承载领域能力及领域服务执行器的实现，其中support-composite用于承载支撑域领域能力及领域服务执行器的实现 ➢ rtbad-app：部署层，内部分为不同的子module，每一个子 module对应一个部署应用，根据应用职责组装composite层子 module，进而实现不同应用下能力及模型共享 ➢ rtbad-api：对外接口SDK包，承载了对外提供的API接口定义

25. 收益类型收益详情成本降低 • 人效提升：系统升级前后数据库访问量峰值下降近40% • ：中间数据全流程共享，避免重复查询；框架引导开发者主动利用异步、并行及批量等手段进行极致地性能优化 • ：传统架构下站外广告T媒体对接需 • ：为业务建模的落地实现提供标准脚手架，支求人力消耗38人日，二代架构下该媒体3.0升级需求耗时14人日、持在服务、能力、拓展点三种粒度上进行不同业务维度的灵活拓展 K媒体M-API对接需求耗时7人日 • ：站外广告B媒体预算重复解冻问题排查案例： 2分钟定位问题代码，5分钟定位问题原因 • ：某新投放平台搭建需求由一个没有在线广告业务背景的新团队接手开发，1.5小时完成广告投放业务流程熟悉及改动点评估，第二天即介入开发设计工作 • 体验提升带来收益的升级措施 • 核心接口性能提升20%~50% 二代架构下变更遗漏及同一模块下不同业务场景变更互相影响导致的线上问题数同比减少约40% • ：业务模型、数据模型及数据存储模型三分离，收口底层数据读写与实体间组装逻辑，辅助建立数据模型全景视图 • ：通过能力编排执行图清晰表达业务流程；业务逻辑实体化并支持索引式查找；通过聚合建立数据模型全景视图；通过代码元数据管理功能辅助逻辑梳理与开发 • ：中间数据全流程共享，避免重复查询；框架引导开发者主动利用异步、并行及批量等手段进行极致地性能优化 • ：业务规则实体化避免逻辑逃逸及梳理遗漏；可执行实体路由机制确保不同业务模式之间的代码分离，避免互相影响 • ：支持弹性扩缩容、负载均衡、故障转移等稳定性保障及容错机制，支持事务性事件，提供at-least-once语义，保障数据处理的最终一致性

26.

27.  问题  问题  问题新设计思想转变成本、框架API学习成本、系编码强依赖业务建模，落地收益在很大程度上代码中Java类数量膨胀，元空间内存占用增统重构阶段人力投入成本较高受制于业务建模质量，推行前期容易出现能力加，总代码行增加，服务启动速度变慢划分及功能归属不合理的问题  解决措施 ✓  解决措施  解决措施 ✓ ✓ ✓ ✓ ✓ ✓ ✓

28.

29.   ➢ ➢ ➢ ➢ ➢ ➢   ➢ ➢ ➢ ➢

30.

31. 欢迎交流，碰撞出有趣的点子！邮箱：rainman_zjd@163.com 踏实搞技术，用心做业务，京东广告投放团队诚邀您的加入！

32. 大模型正在重新定义软件 Large Language Model Is Redefining The Software