2.3　资源调度成功率

资源调度性能和资源调度成功率是两个关键指标。性能反映处理的快慢，成功率反映处理结果是否符合预期。在实践过程中，我们发现定义成功率的计算口径存在多样性，这是因为在不同的场景下有不同的关注点。从用户资源申请端到端的视角，成功率要求底层资源、调度系统、链路管控的协同配合。通过定义端到端的成功率，可以发现任何一个环节的问题。因为中间节点出现问题，将导致端到端的成功率下降。从资源的视角来看，成功率被限定在计算实例分配、生产的阶段，而不是针对全链路而言的。例如，在容器环境下，启动容器和启动应用场景是分离的，可以分为资源交付成功率和应用交付成功率；在虚拟机环境下，一般先生产虚拟机，然后上层系统进行应用发布部署，这时成功率体现出虚拟机资源分配、虚拟机启动的成功。

对于成功率，常用的定义方式如下：

成功率（资源层）=实际成功创建的实例数量/发起请求的数量

这里以一次调度失败的场景为例，对这个定义的使用场景进行解释。假设链路存在约束校验、容量校验、资源选择等节点系统，当链路上游约束和限制被击穿时，链路下游会交付失败。比如上游额度约束和底层资源没有配合好，导致额度校验通过，生产时却没有足够的资源。再比如在资源并发查询的同时并发申请，导致部分申请失败。这种情况与抢火车票类似，在查询余票时大家都可能看到结果，而真正下单成功的是部分用户。还有一种调度失败的场景，就是在申请资源时资源诉求参数填写错误，导致无法分配资源。

成功率提升实践建议

成功率最大的意义在于，在进行突发资源申请时，能够可预期地拿到资源，及时扩大服务容量。建议：

● 用户资源额度和资源池容量联动，实现额度驱动的申请。

● 重视资源规整，类似于JVM的GC（垃圾回收），定期对资源池的碎片资源进行整理，并采取重调度适当地进行实例迁移、腾挪。

● 有时候，成功率辅助重试也是不错的选择。

● 采用全链路DryRun[12]，确保各个节点的可用性、连通性，以及关键功能点的常态化运作。