Category: High Concurrency, Circuit Breaker, Rate Limit, Load Balance,etc…

常见的调度系统往往兼顾了准确度却牺牲了性能，容器调度的复杂性使得很难在准确和效率之间找到平衡点，尤其是在交互式调度的场景下，可取的解决方案更是捉襟见肘。 随着分布式计算集群规模的不断扩张，任务调度系统的稳定性成为了整个集群稳定的关键因素。随着容器技术的快速兴起，基于容器的计算平台被大量应用，任务调度的规模及频率快速上升，这对任务调度系统提出了更为严苛的挑战。 常见的调度系统往往兼顾了准确度却牺牲了性能，容器调度的复杂性使得很难在准确和效率之间找到平衡点，尤其是在交互式调度的场景下，可取的解决方案更是捉襟见肘。本篇文章就以此为背景，介绍大规模调度场景下分布式任务调度的难点、解决策略及现有的一些方案。

让我们结合复杂度来源和架构设计原则，通过一个模拟的设计场景“前浪微博”，和你一起看看在实践中究竟如何进行架构设计。 我们假想一个创业公司，名称叫作“前浪微博”。前浪微博的业务发展很快，系统也越来越多，系统间协作的效率很低，例如： 用户发一条微博后，微博子系统需要通知审核子系统进行审核，然后通知统计子系统进行统计，再通知广告子系统进行广告预测，接着通知消息子系统进行消息推送……一条微博有十几个通知，目前都是系统间通过接口调用的。每通知一个新系统，微博子系统就要设计接口、进行测试，效率很低，问题定位很麻烦，经常和其他子系统的技术人员产生分岐，微博子系统的开发人员不胜其烦。 用户等级达到 VIP 后，等级子系统要通知福利子系统进行奖品发放，要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理……等级子系统的开发人员也是不胜其烦。