淘宝TPP系统解析

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

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

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

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

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

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

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

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

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

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

该系统由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等)，最优化每一个场景机器数目，从而使得总体资源利用率最高。

更为直白一点，就是回答以下问题：

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

简单的CPU超水位并不能解决问题，不同场景的判断标准并不一致，有IO密集型的（大量访问igraph）。有CPU密集型的。一个场景可能在CPU使用率不超过30%的情况下，就已经出现大量异常的QPS。load很高，需要增加机器。

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

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

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

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

当总的机器数目有限的情况，如何分配不同场景之间的机器，最大化收益，如何实现从某些场景中拿一些资源去补充重要场景的运行。