地理分布式云中的 QoS 感知服务组合

复合云服务通常由一条工作流完成，而不是由单个服务端点独立完成。工作流的每个阶段都可能有多个功能等价的服务，它们分布在不同地域，在时延、成本、容量、可用性和信誉等方面各有差异。系统需要为每个阶段选择一个候选，同时保证整条工作流满足 SLA。

逐个选择响应时间最短的服务，未必能得到最快的组合。如果这些服务之间的跨数据中心链路质量较差，整体时延仍会很高。因此，QoS 感知服务组合必须把服务自身属性和服务之间的网络条件放在同一个选择问题中考虑。

先确定哪些服务在功能上可替换

假设工作流包含 $L$ 个抽象任务。功能发现先构建候选集合 $\mathcal{S}_i$ ，供任务 $i$ 使用；非功能属性选择再从中取出

x=(x_1,\ldots,x_L), \qquad x_i\in\mathcal{S}_i.

功能发现和 QoS 选择必须分开。一个服务即使评分再高，只要接口或语义不满足任务要求，就不应进入优化结果。功能兼容性负责界定搜索空间，QoS 只负责给这个空间内的可行组合排序。

顺序工作流可能产生的组合数量为

|\mathcal{X}|=\prod_{i=1}^{L}|\mathcal{S}_i|.

即使每个任务只有数量适中的候选，组合空间也会快速膨胀。若工作流还包含分支、并行和条件执行，就需要加入相应的聚合规则与决策依赖。工作流结构必须在建模阶段明确，不能等算法运行结束后再补充。

按整条工作流聚合 QoS

对于顺序工作流，时延模型应同时包括服务执行时间和网络传输时间：

T(x)=\sum_{i=1}^{L}t_i(x_i) +\sum_{i=0}^{L}d_i(x_i,x_{i+1}),

其中， $t_i$ 表示服务执行时间， $d_i$ 表示相邻部署位置之间的网络时延； $x_0$ 和 $x_{L+1}$ 可以表示面向用户的入口与出口。若系统只记录服务响应时间，却不计算数据传输时延，那么它并没有真正反映地理分布带来的影响。

不同 QoS 属性需要采用不同的聚合规律。可加成本和相互独立组件的可用性常写为

C(x)=\sum_{i=1}^{L}c_i(x_i), \qquad A(x)=\prod_{i=1}^{L}a_i(x_i).

可用性连乘以各组件独立失效为前提。如果多个服务共享数据中心、网络、电源域或软件依赖，独立性假设便不成立；重视韧性时，应显式建模相关失效。吞吐量通常由瓶颈限制，而不是简单相加；并行分支的时延则可能由最慢分支决定。每项 QoS 属性都应根据工作流语义选择聚合方式。

SLA 可以规定 $T(x)\le \overline{T}$ 、 $C(x)\le \overline{C}$ 和 $A(x)\ge \underline{A}$ 等硬约束，偏好则用于排列已经满足约束的方案。若把硬性 SLA 与任意罚权重混在一个分数里，看似较高的得分仍可能对应违约方案；目标值好看不等于组合可行。

合并多项指标前先归一化

时延与可用性的单位不同，优化方向也相反。构造标量目标前，需要把各属性转换成无量纲、方向一致的量。归一化范围应来自事先声明的边界或当前候选总体，并明确说明离群值和缺失测量如何处理。

加权和便于计算和解释，但权重本身是一项策略选择，不能消除目标之间的冲突，也未必能覆盖 Pareto 前沿的非凸部分。当多个折中方案都具有实际意义时，多目标方法可以先返回一组非支配组合，再由业务策略作最终选择。

输入数据还具有时间属性。服务时间、队列深度和网络时延的变化速度，可能比组合部署更快。调度器需要记录测量数据的年龄，采用稳健统计量或不确定性边界，避免给出遥测数据无法支撑的精度。

Skyline 能做什么，不能做什么

在一组功能等价的候选中，如果候选 $u$ 在所有选定 QoS 维度上都不差于候选 $v$ ，并且至少有一项严格更好，就称 $u$ 支配后者。Skyline 只保留没有被其他候选支配的服务。

Skyline 可以剔除明显较差的候选，也可以为后续搜索提供质量较高且具有多样性的初始解。但它并非在任何情况下都适合作为全局预处理：某个服务的节点属性虽然被支配，却可能与前后阶段之间具有更好的网络连接。此时，要么把网络属性纳入支配关系，要么等部署上下文确定后再作比较。

这一问题在地理分布式系统中尤其明显。服务 QoS 属于单个节点，网络 QoS 属于一对部署位置，而且两个方向的网络条件还可能不同。

把遗传搜索写成透明的启发式方法

遗传算法可以直接编码这一组合问题：

一条染色体为工作流中的每个任务记录一个候选索引。
初始种群同时包含随机生成的可行组合和 Skyline 引导的种子。
选择操作偏向质量较好的可行解，同时保留种群多样性。
交叉操作交换彼此兼容的工作流片段。
变异操作把某个任务的选择替换为同一功能集合中的另一候选。
在条件允许时，通过修复算子或保持可行性的算子处理硬约束。

适应度函数必须能够被检查和复现。归一化方法、各项 QoS、偏好权重以及约束处理方式都应写清楚。轮盘赌选择要求分数非负，而且相对比例具有明确含义；当原始分数可能为负或彼此非常接近时，排序选择或锦标赛选择通常更容易控制。

遗传搜索不能证明全局最优。结果会受到编码方式、种群规模、初始化、遗传算子、停止条件和随机性的影响。可信的实验应与简单基线比较，在多组随机种子下报告可行率和目标值分布，并测量候选规模增加时的运行时间。对于小规模实例，还可以用精确方法或带界方法估计启发式解与最优解之间的差距。

OpenRaaS 中的部署问题

公开的 OpenRaaS 工程描述了一种去中心化的 Resource-as-a-Service 平台，将应用的运行环境、持久化文件以及渲染或计算任务分开部署。其架构包含负责协调的 MasterNode，以及计算、文件存储和镜像仓库三类工作节点。

在这个系统中，组合不只是从一组可互换的 Web API 中作选择，还可能需要为多个资源角色挑选能够协同工作的部署节点。节点位置会共同影响启动时延、传输成本和用户侧响应时延。计算节点、文件存储和镜像仓库形成的是一条相互依赖的服务路径，不能拆成三个彼此独立的排名问题。

公开仓库能够说明系统角色和部署构想，但不能据此证明某种遗传调度器达到最优，也不能证明系统已经取得特定幅度的 SLA 改善。要支持这些结论，还需要明确的工作负载、可复现实现和对比测量。

如何做可复现的评估

给出工作流图和每个任务的候选集合。
定义各项 QoS 的单位与聚合规律。
把硬性 SLA 可行性和软偏好分开处理。
记录节点与网络指标的测量方法和测量时间。
说明染色体、遗传算子、修复规则、参数和随机种子。
与随机选择、贪心选择以及条件允许时的精确或带界方法比较。
报告可行率、目标值、尾时延、运行时间和波动，而不是只展示最好的一次。
测试遥测过期、服务不可用和相关故障等情况。

服务组合的质量不只取决于搜索算法，还取决于工作流模型、QoS 聚合方式、可行性规则和实验依据。启发式方法能够提高大规模组合空间的搜索效率，却无法弥补含糊的目标定义或错误的 SLA 模型。