研究背景
在工业互联网和服务计算领域,单个服务的功能有限。用户通常需要组合多个服务(形成 Mashup 或服务组合)来完成复杂业务需求。核心问题:给定成千上万的服务,如何推荐一组能协作良好的服务组合?
这个问题拆成三个子问题:
- 服务之间的协作关系如何度量?
- 历史上成功的服务组合有什么模式?
- 如何在协作度和 QoS 之间权衡?
参考文献
-
Compatibility-Aware Web API Recommendation for Mashup Creation via Textual Description Mining
- Qi L, Song H, Zhang X, et al.
- ACM Transactions on Multimedia Computing Communications and Applications, 2021
- 核心思路:通过 API 文本描述挖掘兼容性关系
-
Manufacturing service recommendation method toward industrial internet platform considering the cooperative relationship among enterprises
- Wang, Lei, et al.
- Expert Systems with Applications, 192 (2022): 116391
- 核心思路:考虑企业间协作关系的制造服务推荐方法
核心思路:构建服务协作关系图
二部图表示
服务协作可以建模为一个二部图:
Task 层 ┌──────┐ ┌──────┐ ┌──────┐
(Mashup/任务) │ T1 │ │ T2 │ │ T3 │
└──┬─┬─┘ └──┬───┘ └──┬─┬─┘
│ │ │ │ │
┌───────┘ │ ┌────┘ ┌─────┘ └───────┐
│ │ │ │ │
Service层 │ ┌───┴───┴───┐ ┌───┴───────┐ ┌─────┴────┐
│ │ S1 │ │ S2 │ │ S3 │
│ └───────────┘ └───────────┘ └──────────┘
关系:T1 调用了 S1 和 S2 → S1 和 S2 在 T1 中有协作关系
服务相似度矩阵计算
从二部图出发,可以将服务间的协作关系量化为相似度矩阵:
相似度 SR(Si, Sj) 的核心公式:
SR(Si, Sj) = 与 Si 和 Sj 都协作过的 Task 数量 / 与 Si 或 Sj 任一协作过的 Task 数量
(本质是 Jaccard 相似度在二部图上的应用)
不频繁项(协作次数少的服务)之间的相似度也可以通过这个矩阵计算——不需要显式的共现关系。
频繁共现模式挖掘:FP-growth
为什么需要频繁模式
单看两个服务之间的关系还不够。实际场景中,一组服务可能经常一起出现——这种 n 元共现关系包含了更丰富的协作信息。
FP-growth 原理
与 Apriori 算法相比,FP-growth 避免了反复扫描数据集的问题:
Apriori:
每次找 k+1 频繁项集都需要重新扫描一次数据库
计算量大,不适合大规模服务数据
FP-growth:
1. 扫描一次数据库,统计每个服务出现的频率
2. 构建 FP-Tree(频繁模式树)
3. 从 FP-Tree 递归挖掘频繁模式
不需要反复扫描数据库
应用到服务推荐:将每个历史 Mashup 看作一条交易记录(其调用的服务集合 = itemset),用 FP-growth 挖掘频繁共现的服务集合。
服务组合相似度评分方案
针对两个服务组合 A 和 B 的相似度评分,用频繁项和相似度矩阵结合:
| 场景 | 频繁项判断 | 相似度处理 | 评分规则 |
|---|---|---|---|
| A 和 B 的服务历史上都协作过 | 全都是频繁项 | - | 直接 +1 |
| 部分历史协作 | 部分是频繁项 | - | 频繁项 +1,不频繁项取最大相似度 |
| 协作过的部分是频繁项 | 局部频繁 | 不频繁项取相似度 | 同上的加权 |
| 协作过的都不是频繁项 | 都不是频繁项 | 全依赖相似度矩阵 | 取相似度的最大值(<1) |
| 没有历史协作 | 部分频繁项 | 频繁项贡献 +1 | 混合评分 |
| 完全没有历史数据 | 没有频繁项 | 全靠矩阵 | 相似度作为唯一指标 |
最终评分公式:
score(A, B) = [ Σ(频繁项权重=1) + Σ(不频繁项与频繁项的最大相似度) ]
/ (|A| + |B|)
这个公式保证了:
- 频繁共现的服务组合得高分
- 历史数据少的冷门服务不会完全被忽略
- 归一化到 [0, 1] 区间
结合多目标进化算法 (MOEA)
为什么需要多目标优化
推荐服务组合时有两个目标经常冲突:
- 内联协作度(相似度):服务之间配合好,指标越高越好
- QoS(质量指标):响应时间、吞吐量、可靠性、价格
高协作度的组合可能 QoS 不高(历史上协作好的服务可能是慢服务),而 QoS 最高的组合可能协作度低(两个高性能服务从没配合过)。
Pareto 前沿
QoS ↑
│ ★ 帕累托前沿的解
★ │ (无法在不降低协作度的情况下提高 QoS)
│ ★
│ · · ·
· │ · · 被支配的解
│ · ·
└─────────────────→ 协作度 →
多目标优化的输出不是一个"最优解",而是一组帕累托最优解
——由用户根据实际情况选择
算法流程
1. 初始化种群(随机生成服务组合)
2. 对每个个体计算两个目标:
- 内联协作度(基于上述相似度评分方案)
- QoS(响应时间、可用性等加权综合)
3. 基于 Pareto 支配关系进行选择
4. 交叉 + 变异(服务组合的交叉:交换子集)
5. 迭代至收敛
6. 输出帕累托前沿——用户选择最适合自己场景的组合
学术论文中的 MOEA 方法扩展
近年来关于 MOEA 的改进方向主要集中在:
NSGA-II(非支配排序遗传算法)
核心操作:
1. 非支配排序:将所有个体按 Pareto 支配关系分层
2. 拥挤度距离:同一层内,个体离邻居越远越好(保持多样性)
3. 合并父代和子代(2N 个体)→ 选前 N 个
MOEA/D(基于分解的多目标进化算法)
核心思想:将多目标优化分解为多个单目标子问题
- 每个子问题是一组权重的加权和
- 相邻子问题共享信息
- 适合于3个以上目标的场景
未来方向
- 冷启动问题:新服务没有历史数据,如何合理估计协作度?可以借助服务描述文本(如文献1)做语义相似度
- 动态更新:服务池经常增减,频繁项集需要增量更新而非全部重算
- 用户偏好建模:不同用户对 QoS vs 协作度的偏好不同,引入交互式进化算法(IGA)让用户直接参与选择过程
总结
- 服务组合推荐的核心挑战是冷门服务和协作关系发现
- FP-growth 挖掘频繁共现模式,二部图迭代相似度矩阵覆盖非频繁项
- 两者的结合评分方案能处理从”有丰富历史”到”完全没有历史”的不同情况
- MOEA 在协作度和 QoS 两个冲突目标之间找到帕累托最优解集
- 一个实际可用的服务推荐系统还需要解决:冷启动、动态更新、用户偏好建模
☕ 如果这篇文章对你有帮助
欢迎请我喝杯咖啡支持一下
评论