动态资源调度优化：12年架构师全链路复盘

　　去年一月份那场资源调度事故，我现在想起来还后怕——线上报警那一刻，监控大屏突然红了半边，QPS曲线跟坐过山车似的往下掉，运维小王冲过来喊“资源池被占满了”，我盯着日志里一堆“No available instance”的报错，心里直骂娘：这动态调度算法不是上周刚调过吗？怎么又崩了？

　　说白了，动态资源调度这玩意儿，我原以为就是“按需分配”四个字，结果跑了大半年才发现，根本不是那么回事。去年那套算法，是照着“负载均衡+空闲回收”的思路写的，逻辑看着挺简单：每个服务实例上报当前负载，调度中心根据阈值判断要不要扩容或缩容。可实际跑起来，问题全来了——比如有个老服务，代码写得跟屎一样，CPU占用率常年飘在八十以上，调度中心一看“负载高”，立马给它加实例，结果新实例刚启动就被拖垮，反而把整个资源池的可用实例全耗光了。

　　工位对面的前端小李凑过来瞅了一眼监控，说：“你们这调度算法是不是太蠢了？怎么不学学K8s的HPA，按CPU和内存双指标调？”我白了他一眼：“K8s那是理想环境，咱们这儿的服务，十个有八个指标不准！就说上周那个订单服务，监控显示内存占用才百分之三十，结果实际跑起来，JVM老年代都快满了，GC卡顿能把接口耗时干到三秒——这种服务，你按内存调，分分钟炸给你看。”

　　咖啡凉了，我端起来抿了一口，苦得皱眉。其实后来复盘才发现，问题的核心根本不是算法本身，而是“优胜劣汰”的机制没跑通。咱们之前调度，是“一刀切”的——只要负载超过阈值，不管服务是“真忙”还是“假忙”，先扩容再说。可实际上，有些服务是“虚胖”，比如那个日志服务，写日志时CPU会飙高，但业务影响不大；有些服务是“真瘦”，比如支付服务，稍微卡一下，订单就丢了。调度中心得能区分这两类服务，把资源优先给“真瘦”的，而不是“虚胖”的。

　　后来我们改了策略：给每个服务打“健康分”，分高的优先调度。健康分的算法挺复杂，涉及接口成功率、耗时波动、依赖服务稳定性这些指标——说白了，就是看这服务“是不是真的在干活”。比如那个日志服务，虽然CPU高，但接口成功率一直是百分之百，耗时也稳定，健康分就低；支付服务哪怕CPU只到六十，但接口成功率掉到九十九，健康分立马飙高，调度中心会优先给它加实例。改了之后，资源池的利用率反而上去了，之前那种“忙的忙死，闲的闲死”的情况少了很多。

文章配图，仅供参考

　　其实说到这，我挺佩服那些能把动态调度玩明白的公司——比如阿里，他们那个Sigma调度系统，据说能根据业务优先级、实例健康度、资源历史使用率这些维度，动态调整调度策略，连“冷启动”的实例都能预判资源需求。我原以为咱们也能搞，结果跟运维老张聊了才知道，人家背后有一整套数据中台支撑，咱们连服务画像都画不全，搞个屁的智能调度。老张说：“你们架构师啊，就是爱搞大而全的东西，实际跑起来，还是得靠‘土办法’——比如咱们现在这个健康分，虽然土，但管用。”

　　窗外天黑了，工位上的灯亮得刺眼。我揉了揉眼睛，继续翻日志——最近又有个新服务上线，调度中心老是给它分配到老旧的机器上，导致接口耗时比其他实例高百分之二十。我查了半天，发现是调度算法里的“资源亲和性”参数没调好——老机器的CPU型号和新服务不兼容，调度中心却以为“能用就行”。我改了参数，重启了三回调度中心，问题才解决。运维小王在旁边吐槽：“你们架构师写的代码，怎么比我们运维脚本还难维护？”我白了他一眼：“有本事你来写？”他嘿嘿一笑：“我可不写，我只负责重启。”

　　现在回头看，动态资源调度这玩意儿，真不是“调个算法”就能搞定的。它得跟服务的健康度、业务的优先级、资源的异构性这些乱七八糟的东西绑定在一起，稍微哪块没考虑到，就会出幺蛾子。我原以为“优胜劣汰”是个简单的逻辑，结果跑起来才发现，连“优”和“劣”的标准都难定——有些服务是“短期优”，比如促销活动时的订单服务；有些服务是“长期优”，比如用户中心。调度中心得能区分这两类，把资源在“短期”和“长期”之间动态平衡，这难度，不比写个分布式事务低。

　　最近我又在琢磨，要不要把“服务依赖关系”加到调度算法里——比如A服务依赖B服务，如果B服务健康分低，A服务的调度优先级也得降。可运维老张说：“别搞了，现在算法已经够复杂了，再加依赖关系，调度中心得跑死。”我想想也是，可不服气——难道动态调度就只能这么“土”下去？说不定哪天，我得找前端小李聊聊，看看他们那套“智能推荐”的算法，能不能借鉴到调度里来——虽然他上次说我“算法太蠢”，但说不定，他真有点东西呢？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!