微博云原生运维如何快速应对热点流量峰值？

编者按：2021年10月22日，在云栖大会的《云上运维最佳实践》分论坛，微博研发中心基础平台负责人马朕发表了“快速应对热点流量峰值，微博云原生运维最佳实践”的主题演讲，和大家分享交流了微博云原生运维如何快速应对热点流量峰值，希望给有同类型业务场景的同行提供一种思考方式。

基于云原生实现快速扩容以应对流量高峰

关于热点的应对，我们经过了三个阶段：成本考虑弹性资源的需求，热点弹性数量的需求，热点弹性速度的需求。

第一个阶段，我们遇到的挑战是春晚项目。在使用阿里云之前，我们需要提前准备和购买机器设备。采购周期长，设备成本高。当时应用阿里云之后，我们可以从月级别保障的准备周期直接缩短到以周为单位。
第二阶段，需求主要来源于网友吃瓜。这个弹性需求我们主要针对数量需求，于是以周为单位开始朝着以分钟为单位来准备。

第三阶段，是我们对弹性速度有了需求。我们现在弹性峰值的速度越来越快，所以我们的准备时间也越来越少。于是我们就开始思考，弹性能力怎么能够进一步再提升。

实际应对时，我们要从以下四个方面来提升弹性能力：

吞吐率：提升了每分钟弹性的能力。
创建速度：当我们收到机器之后，把机器快速部署到线上，降低单台机器扩容完成耗时，从而节约更多资源和时间。
资源分配策略：要确保核心服务能够更快地分配到资源。
在离线整合：想办法对在线、离线业务做一些整合，进一步提升供给。

上图是我们使用阿里云闪电交付的情况。当应用闪电交付之后，比常规的ECS机器供给速度提升了3倍，达到了300%。但同时，我们的运维成本会有一些增加。

这是闪电交付的一些流程。因为这个成本比ECS略高一些，所以我们会在热点联动时才使用闪电交付，用来承载第一波峰值流量。

在之前应用的时候，机器每分钟的吞吐率可以达到1000台。而且它有一个主要功能，当我们的资源减去拉取镜像的时间，可以提供一个更快的保障。

当我们拿到机器之后，我们会降低整体的扩容耗时，同时做一些优化。主要有这4个方面的优化工作：并行化改造，合并冗余步骤，把核心和非核心链路进行隔离，非核心步骤进行异步化。

因为我们应用了ECI、闪电交付，所以现在我们在扛热点流量时，数量由最早5分钟2000台，到现在能够稳定在6分钟6000台以上；我们还将镜像仓库中的镜像，缓存至待创建的资源上，随着机器交付，镜像就已经准备就绪。除此之外，我们还做了RPC服务化和DCP管理平台，提升服务发现效率和业务性能；将PUSH热点联动，由ECS扩容优化为ECI+ECS双路扩容，从而进一步提升服务交付能力。

微博DCP混合云平台资源分配策略优化

下面介绍我们在拿到DCP混合云平台设备之后，如何做一些优化，从而尽快地提升扩容效率。

这是我们整个扩容流通图，我们的DCP混合云平台也遇到了挑战。因为涉及的业务方比较多，所以谁先提交，资源就会侧重分配给谁。当核心业务慢时，却没有保障。其次，基础环境的初始化耗时比较高，镜像拉取的失败率也比较高。

针对这些问题，我们分别做了优化，包括建立扩容的策略、优化扩容链路、通过混合云决策来建立决策支持体系、接入ECI和闪电交付等服务。

我们默认的分配策略，是一种公平调度，保证每个产品在提交申请之后，都能均衡分配资源。就像餐厅就餐，每桌都要轮着上菜。这是我们常规的一种状态。当热点来的时候，为了能够优先保证核心服务，我们建立了优先级的队列。

这个优先级的队列有一定的唯一性。因为在热点下发的时候，它是一波一波。各业务方在一起商讨制定自己的容量，制定自己的热点机器数量，定好模板以后，我们就确定好了队列。

当我们向云厂商申请完资源之后，就按照这个策略80%的优先级核心服务。同时，普通队列也能满足我们日常的一些需求。当优先级队列的固定数量完成之后，在完成承载第一波峰值流量的任务后，他们开始转为普通队列。

这是混合云平台一些决策支持的思考。我们核心模块要求全覆盖，并且每个核心模块都有自己的核心指标。因为核心指标和扩容相关，所以大家会结合自己的业务和资源使用情况，综合成自己的核心指标。
我们的DCP整体关注三个点：库存、提交数和冗余度。我们自己业务的核心模块关注的点有：已经提交数、扩容成功率和慢速比。慢速比是我们的一个核心指标，我们会根据它来判断是否扩容、是否缩容。如果扩容的失败率高，出现了问题，我们就用IVR动员，让人工介入处理。

这是我们的一些分配策略，做了一些离线整合的实践。当有些服务流量大的时候，我们就把离线的服务先下来，然后部署上核心服务，优先去扛第一波流量。同时，当离线的服务冗余度不足，我们用常规队列慢慢补充。

这是我们在离线整合功能的使用时间情况，我们内部管它叫极速扩容。这里显示了我们的服务下线、驱逐任务、停止容器和环境清理等时间，整体可以在热点流量来的时候形成双保险，从而作为峰值流量机器运行时的补充。

这是我们内部建立的一整套关于热点联动的体系。这一套体系相对健全，首先是热点的预警与发现，分为主动和被动：
在主动方面，我们会根据一些重点热点事件，比如春晚、体育赛事等，我们主动做一些准备。在容量里还有一个功能，即高水位判断。如果我们发现这个流量已经达到了日常的晚高峰，或者是超过一定的水位，我们可以打开高水位开关。系统里的容量会保持在一个充足的水位，当热点来的时候也会比较从容。

**其次，对于系统来说稍显被动。**我们会根据这个热点和运营合作，如果运营的同事觉得这个热点是一个比较爆的点，也可以同时触发扩容。如果运营在热点的文案里没有判断到问题，或者不好判断。我们会在PUSH的文案中进行截取。如果发现一些明星或者一些热点，我们也会触发扩容，为第一波的流量扛峰。

**第二部分是热点联动的应对。**我们内部通过IVR进行动员，通过热点联动机制，进行热点的扩容与降级。如果扩容之后流量未达到预期，会自动对资源回收。我们内部会把流量分成几个等级：一级热度到五级热度。随着级别越高，我们也会做一些预判，比如降低一些不影响服务的边缘功能，从而释放更多的可用资源。我们对每一次热点都进行记录和归档，方便未来进行复盘和技术上的建设。

**第三部分，关于技术工具的改进。**因为我们的服务关联很多部门，每个部门的业务模型都不相同。所以我们会进行全链路的压测系统。随着业务复杂度的变化，我们需要定时压测与评估，以便更新我们扩容的模板。同时在制度方面，我们会在公司内部形成虚拟小组，各业务方技术负责人参与其中，对我们的项目进行日常的制度建设。这是我们到目前为止，关于热点无状态的计算类资源，比较全的介绍。

在容量管理和提升利用率等方面开展实践

资源的利用率和成本控制一直是各公司关注的点。其中类型多样性、热点与容量规划、硬件这三点对我们影响比较大。类型多样性是指服务，无论是前端的计算资源，还是后端资源；我们的硬件也是不同的，各种厂商、各种配置；再加上我们对热点的常容量的规划；服务类型的多种多样就产生了一些冲击。

无论是自建机房还是云上，我们在阿里云上已经开始使用神龙，我们基于K8s自己来切割，对神龙进行一些混合的编排。我们会自研一些系统对它进行调度。我们使用CPU的密集型、IO密集型、内存密集型等，每一项密集型背后表示着其他资源利用率不高。所以我们从空间上进行混合的编排，时间上争取能够弹性调度。

每个服务流量都跟自己相关，比如常规业务有早晚峰值，超话服务在0点会签到等。我们根据业务的自画像，从这些角度进行不同的削峰填谷，包括内部一些离线服务。我们的一些前端类计算服务会有早晚峰值，我们在早晚峰值时把离线服务的机器挪到线上使用。到夜里，再把机器下线给计算资源使用，从而达到削峰平谷的目的。

我们的闪电交付和ECI主要是应对峰值流量时的动态扩容。在日常的时候，我们会根据成本做一些自动扩容。除此之外，我们针对自动流量也做了一些预警，可以做到10秒级动态流量追踪与预测。当流量来的时候，我们自动进行扩容。流量过去，我们自动进行缩容，极大地节约了成本。

关于有状态的服务，我们也有做一些建设和实践。我们把资源实例尽量小型化，建立数据的恢复中心。当流量来的时候，我们通过在多个机房节点拉取数据，快速地形成一种扩容，从而弥补前端类计算资源流量大、后端资源不足的情况。

最后，我们把降本增效策略分成了几大块：

我们针对不同的规格进行混合编排，把它分成24个pod，在每个pod里用自研的程序进行编排，从而提升它的整体利用率。
弹性调度与自动扩缩容也能进一步节约成本。
我们把大多数流量都用弹性方式处理，通过离线整合、削峰平谷的方式，把这些资源合理利用起来。
关于异地部署各厂商也都在做，因为外地的机房很便宜。厂商只需要在异地部署一整套服务，以弥补两地之间的延迟。最后是大型机，我们未来也会朝着这个方向继续建设。（完）

微博云原生运维最佳实践！