关于弹性调度系统设计细节

一、关于应用的接入准则与标准

这个应用什么时候可以触发扩容呢？什么时候可以触发缩容呢？这个应用的评判标准是什么？是要看它的QPS吗？当QPS达到一定的量的时候会不会触发应用自身的限流行为，有些应用比如是进程跑任务的应用，可能都没有rt，即没有提供外部的API供外部调用，那看rt其实没有意义的。可能就是在不断消费消息的。

所以我的方案是：

针对不同的应用打不同的标。可以定义这个应用是APP、计算型。不同的应用有没的核心指标作为弹性扩缩容的依据。比如正常的提供RPC服务的应用，那肯定是检查接口的RT。

那会不会涉及到一个应用提供了10个接口，其中有一个是占比90%的调用量，我们看的RT也是希望看到这个接口的RT值。

比如这个接口是一个消费处理消息的应用，那可能要看这个应用对CPU的消耗情况，比如Load5的值。

不同类型的应用触发标准不一样，我觉得需要区别对待。

二、关于流程引擎

流程引擎 + 各个执行器可以串起来，流程引擎可以编排不同的处理逻辑与流程。可以做的比较灵活。

比如在做资金业务的时候，针对不同的业务流程，比如用户提现可以做一个流程编排。针对用户充值也可以做个流程编排。然后把各个原子操作做到可幂等可重复执行然后依据流程引擎串起来。

问题：流程引擎是否支持重试机制，比如这个流程有10步，某一步失败了，那下次再发起的时候是不是会从指定这一步失败的地方继续执行下去？