Scenario Driven MS Decomposition
场景驱动、自底向上的单体系统微服务拆分方法
评价
核心思想:把数据表之间紧密联系的聚在一起,作为拆分微服务的准则。
实际上是关于数据表的划分,微服务的其他方面比如class、method的划分没有提到。
AIBR
结合Scenario、Trace和Sql进行微服务拆分。
单体系统的微服务化拆分也可以借鉴传统软件模块化的思路和方法,已有不少这方面的研究
图1是整个流程图
- 标记权重:对用例标记权重(对于一些使用频率较高的用例增加权重)用例权重增加,用例包含的trace中边的权重都增加
- 监控工具:Kieker,收集trace的工具
- 日志类型:被调用方法的签名、调用链 ID、调用时间、调用顺序
- 轨迹图:见下图图3
- 共享群组+关联度矩阵(后面会提)
- 数据表权重图(关联矩阵添加权重的结果,用于聚类)
- 数据图表聚类(GN社区聚类算法)
- 计算拆分开销(later)
- 拆分方案生产
拆分方法
图3也很关键,一个scenario数据访问的trace。
同样还有图4,数据库的相关度graph(later)
数据表关联度
表关联度高表示表A和表B在一个场景要同时使用的情况比较多。比如说注册要用到user表和profile表。登录也要用到这两个表。就说明user表和profile表的关联度较高。
- sql的权重
- 两个数据表之间的关联度
表A和表B的关联度 = Cscenario + Ctrace + Csql
Cscenario = 同时操作表A+表B的场景之和 / 操作表A或表B中任意一张表的场景之和,trace、sql同理
共享群组
共享度高表示一张表被多个场景使用,更倾向于单独拆分成一个微服务。比如account表在注册场景、下单场景都用到了,说明account表的共享度较高。
共享度 = Sscenario + Strace + Ssql
Sscenario = 操作表t的场景数量 / 总场景数量,trace、sql同理
共享表的数量 = 共享表占比 * 所有表的数量
那么共享表占比是如何计算出来的呢?(没有提,可能是共享度达到某个值以上的就算是共享表吧)
表依赖度
和关联度、共享度类似,表示表A对表B的依赖程度。那和关联度有什么区别呢…依赖度高,表A和表B更有可能有一种主从关系。见图6
Dscenario = 同时操作表A和表B的场景 / 操作表A的场景之和(Tb对Ta的依赖)
共享群组条件
Ta和Tb的相互依赖程度(Ta -> Tb + Tb -> Ta)大于某一个值
将x张共享表划分为r个共享群组
数据表权重矩阵
有n张表,就能构建n*n的数据表关联矩阵。
共享群组的意义在于,将同一个共享群组内的表关联度权重加强,不在同一个共享群组的数据表关联度减弱。
数据表图聚类
上一步的权重矩阵作为聚类的图输入,GN聚类算法是一种社区发现算法,认为连接两个社区的边有更低的权重,将这些边删除,剩下的网络就被划分为独立的社区。见图4。
betweenness:经过某条边的所有最短路金的数量。重复计算Betweeness和删除Betweeness的过程。
Modularity
那么聚类到什么程度?引入了模块度Modularity的概念,模块度表示一个网络的紧密程度。 $$ Modularity = \sum_i^c (eii - ai^2) $$ eii表示社区i内所有边的权重占整个网络边权重的比例,ai表示与社区i内定点相连的所有边的权重占整个网络所有顶点所连边的权重的比例。
模块度的取值范围是[-0.5,1),值越大说明网络内的聚类特性越明显。
确定拆分方案
拆分开销 Cost
$$ Cost = µ1 * Vsql + µ2 * Vclass + µ3 * Vmethod $$
Vsql表示需要拆分sql的数量。µ表示权重。class和method的如何拆分没有介绍呀
推荐方案倾向于减小拆分开销。
确定拆分方案
对于每一个拆分方案Pi有: $$ Score = w1 * modularity(Pi) + w2 * cost(Pi) (其中w1+w2=1) $$ 得分最高的作为拆分方案
反馈调整
用户可以对得到的拆分方案进行调整
工具实现
直接看论文里的图吧。
疑问
Q 权重图的每个节点是什么
A 数据表权重图的每个节点表示一个数据表,每条边表示数据表和数据表之间的关联度
Q Method、Sql和Table之间的关系
A 见图3
Q 数据表权重图有更直观的例子吗
A 见图4