技术如何秒懂你？阿里百万级QPS资源调度系统揭秘

阿里妹导读：TPP(Taobao Personalization Platform, 也称阿里推荐平台 ) 平台承接了阿里集团300+重要个性化推荐场景，包括手淘首页猜你喜欢、首图个性化、购物链路等。除了提供应用层面的支持和封装，还肩负着机器分配和维护各场景运行稳定的重任。

理想情况下，TPP平台上的场景owner不需要关注底层的资源分配情况，平台尽可能的提高CPU利用率，同时保证平台上场景的稳定。QPS（每秒查询率）增加的时候扩容，QPS减少的时候缩容，未来这些在夜间被拿掉的机器可以用来混部离线任务等；另外，在2016年双11的时候，总的机器数目不足以维持所有的场景以最高性能运行，需要有经验的算法同学判断场景的优先级，从低优先级的场景上拿出来机器，补充到高优先级的场景中保证成交额。这些平台稳定性工作都是需要繁琐的人工调度，会有如下的缺点：

人力成本巨大：人肉无法监控和处理所有的场景；

反应时间较长：从发现场景出问题，找出可以匀出机器的不重要场景，到加到重要场景所需要的时间相对过长，而程序天然的有反应时间短的优势；

人力无法全局高效的调度资源， 而程序可以更敏感的发现场景的问题，更全面的搜索可以拿出来机器的场景，并可以准确计算拿出机器的数目，有更好的全局观。

基于如上的两点：日常的时候提高资源利用率，大促的时候解放人力，TPP智能调度系统就产生了。TPP智能调度系统以每个集群（一组机器，承载一个或多个场景）的CPU利用率，LOAD，降级QPS，当前场景QPS，压测所得的单机QPS为输入，综合判断每个集群是否需要增加或者减少机器，并计算每个场景需要增减机器的确切数目，输出到执行模块自动增减容器。 TPP智能调度系统有如下的贡献点：

日常运行期间，保证服务质量的情况下最大化资源利用率；

大促运行期间，能够更快速、更准确的完成集群之间的错峰资源调度；

支持定时活动事件的录入，如红包雨、手淘首页定时的Push，程序自动提前扩容，活动结束自动收回；

对重要场景提前预热，完成秒级扩容。

该系统由TPP工程团队和猜你喜欢算同学联合搭建而成，从2017年9月开始规划，到10月1日小批量场景上线，到10月13日三机房全量上线；经过一个月的磨合，参加了2017年双11当天从 00:15 %到 23:59的调度，峰值QPS达到百万级别。在日常运行中，集群平均CPU利用率提高3.37 倍， 从原来平均8%到27%；在大促期间，完成造势场景，导购场景和购后场景的错峰资源调度，重要服务资源利用率保持在 30% ，非重要服务资源利用率保持在50%, 99%的重要场景降级率低于2%。同时TPP智能调度系统的"时间录入"功能支持定时活动，如首页红包的提前录入，提前扩容，活动结束收回机器，改变了以前每天需要定时手动分机器的情况。

问题定义与挑战

TPP智能调度系统要解决的问题为： 如何在机器总数有限的前提下，根据每一个场景上核心服务指标KPI（异常QPS等）和场景所在集群物理层指标KPI(CPU,IO等)，最优化每一个场景机器数目，从而使得总体资源利用率最高。

更加直白一点，就是回答如下的问题：

怎么判断一个集群需要扩容？扩多少的机器

简单的CPU超过一定的水位并不能解决问题。不同的场景的瓶颈并不完全一致，有IO密集型的（如大量访问igraph），有CPU密集型的，一个场景可能在cpu不超过30%的情况下，就已经出现了大量的异常QPS，Load很高，需要增加机器。

如何给不同的场景自适应的判断水位？

有的场景30% CPU运行的很好，但是有的场景10%可能就出问题了。

如何防止某些实现有问题的场景，不停的出现异常，不断触发扩容，从而掏空整个集群，而实现效率较高的场景反而得不到机器，引发不公平。

如何用一套算法同时解决日常运行和大促运行的需求

当总的机器数目有限的情况下，如何分配不同场景之间的机器，最大化收益（有效pv）。如何用程序实现从某些场景拿机器去补充重要场景的运行。

对于运行JVM的容器，当一个新加容器在到达100%服务能力之前需要充分预热，预热过程会有异常QPS的产生。算法一方面要尽可能少的减少扩缩容的次数，另外一个方面，要尽可能快的发现扩容的需求，实现较高的扩容recall。如何在这两者之间做tradeoff？

系统架构

TPP智能调度涉及TPP的各方各面，其架构图如下所示，包括数据输入、算法决策和决策执行三个方面，但是为了更灵敏的、更及时的发现超载的场景并进行扩容，需要自动降级、秒级扩容、单机压测qps预估功能的保证。另外还有一些功能性的开发，如业务算法配置参数分离、调度大盘监控、烽火台规则运行平台等的支持。最底层的更加离不开容器化的全量部署 ，使得加减机器，快速部署环境成为了可能。

宁波整形美容医院http://www.lcmfgy.com/