除夕作为中国人阖家团圆的传统佳节，具有不同寻常的意义。而春晚作为除夕夜的保留节目，每年都会吸引上亿用户同时在线收看。随着移动互联网的大规模普及，一边看春晚一边在社交平台上聊春晚，两微一屏（微博 + 微信 + 电视）已经是大家观看春晚的常规姿势了。
数据统计显示，2018 年除夕及春晚期间微博的活跃用户达到了 2.2 亿，又创造了历史新高。春晚会在短时间内召回大量平时不活跃的用户，给微博带来数倍于日常的流量。可以说春晚的服务保障堪比一场重大战役，需要调动各种资源并准备各种预案以应对。
过去的一年，微博业务高速发展，用户规模也随之快速扩张，在原有的核心业务首页信息流之外，又孕育出了热门兴趣流、微博热搜榜以及超级话题等新业务。
同时，今年微博成为春晚的独家社交媒体合作伙伴，主场人会现场口播微博集中国赞等活动，会在短时间内带来大量集中访问。
因此 2018 年春晚服务保障主要面临以下挑战：
-
重点防御目标不清晰。以往流量主要集中在首页信息流业务，但现在用户的访问分散在多个业务线，无法预测哪个业务是防御的重点。因此，各个业务线均需要做好防御准备。
-
基础设施压力大。由于微博多个业务线的流量相比于去年都有了很大的增长，为了应对春晚，需要扩容的机器也成倍的增加，给底层基础设施如网络设备、专线带宽以及混合云平台等都带来巨大的挑战。
-
服务治理效率要求高。由于微博业务繁多，调用链路长，任何一个用户服务，其背后都依赖着诸多服务，相互依赖。因此对服务治理的效率要求极高，需要在出现异常情况时，能够在分钟级别做出判断并干预。
为应对以上挑战，今年我们主要在混合云平台、全自动化扩缩容系统以及跨语言的服务治理平台等三个方向上进行建设，在今年春晚服务保障的过程中发挥了关键作用，下面将为大家逐一进行介绍。
上万节点小时级别完成部署
从 2015 年起，为了应对业务的高速发展，我们从传统的自建 IDC 开始拥抱混合云，逐步在阿里云上扩大业务部署，甚至像微博故事和视频等新业务全部部署在阿里云上，其部署架构如图 1 所示：
图 1 微博混合云部署架构
在引入阿里云之前，为应对三节，往往在十一之后，就需要根据业务的需要，评估应对春晚所需要的机器数量。然后经过成本评审，采购，上架，业务部署，整个周期长达三个月，给业务带来了沉重的负担。同时春晚过后，采购的机器又会冗余，带来了巨大的成本浪费。
而采用混合云架构之后，新扩容的机器从阿里云上申请即可，并且只需要在春晚前一天提前部署好，春晚过后即可进行缩容，整个使用周期不超过 1 天，不仅节省了成本，而且极大的减轻了春晚扩容给业务带来的负担。
而今年为应对春晚峰值流量的冲击，各个业务线申请扩容的机器规模达到了上万台，并且需要在小时级别部署完毕。为此我们主要做了以下几个工作来确保春晚扩容工作的顺利：
1. 高并发高可用的混合云平台。
由于使用阿里云的 API 创建机器有诸多限制，如单个可用区的可用节点有限、单个安全组的可用节点数有限以及单个 VSwitch 的 IP 数限制等。为此，我们在混合云平台 DCP 系统调用阿里云创建机器时，做了许多优化，诸如多可用区、多 VSwitch、多安全组自动切换等如图 2 所示，确保了在上千台规模的并发扩容时的成功率，经过我们的压测显示，15 分钟 1000 台规模，25 分钟 2000 台规模，成功率均保持在 99% 左右。
图 2. 混合云平台优化
2. 多轮扩容演练寻找瓶颈点。
业务采用混合云的架构，不可避免地会出现流量在内网 IDC 与阿里云 IDC 之间的穿透访问，因此对网络出口设备以及专线带宽的冗余要求极高。为此，我们联合微博多个业务线，通过实际模拟春晚规模的机器扩容，发现某个内网 IDC 的网络出口转发设备的带宽存在瓶颈。
为了减轻该出口转发设备的压力，一方面我们对全网流量进行了分析，绘制出流量拓扑图，从而定位了跨网穿透流量的来源，并进行优化，以减少跨网流量穿透。另一方面，在春晚流量高峰期间，临时暂停某些离线任务的数据传输，以给网络基础设施减轻压力。
除此之外，扩容上万台阿里云节点，对公司的 DNS 以及 LVS 等基础设施也带来了巨大的压力。通过实际的多业务方的联合并发扩容，发现混合云平台 DCP 依赖的阿里云 DNS 在扩容规模超过 1W 台时出现了性能瓶颈，于是通过扩容 DNS，及时得予以解决。
全自动化扩缩容
过去几年春晚服务保障，我们主要依靠定制的 dashboard 监控业务核心接口某些关键指标，如 QPS、AvgTime 等来判断业务是否健康。一个问题是，当业务规模变大，需要防御的规模也膨胀的很大，靠传统的人肉的方式已经无法运维。
为此，经过近一年的研发与业务实践，我们开发了一套通用的智能弹性调度系统，能实时监测业务的冗余度，并按需进行全自动化的扩缩容，无需人为干预。其主要设计思路如下：
1. 通用的业务冗余度评估公式
由于业务系统的多样性和业务架构的差异性，实时而通用的冗余度评估是一个巨大的技术挑战。由于各业务的访问模型差异巨大，我们依托各接口的耗时分布，建立了一套函数模型对访问压力进行了统一的量化处理，引入了 metric_qps 的概念来计算任意时刻单机的消耗，相比于传统的 QPS、AvgTime、CPU Load 等单一指标更准确。具体计算公式就是给处于不同区间内的调用加权求和，来拟合实际的单机消耗量，通过压测得出系统中单机最大容量，任意时刻系统的冗余度就是单机最大容量与实际单机消耗量之比。
2. 分级水位线机制
虽然有了系统的实时冗余度，但如何做决策是否进行扩缩容也是个难点。为此，我们在系统中引入了分级水位线的概念。具体来讲，就是划定三条线：安全线、警戒线和致命线。
在系统实时冗余度低于致命线时，需要进行扩容。在业务水位线低于警戒线并且关键业务指标有问题时，也需要进行扩容。在业务水位线一段时间内稳定在安全线以上时，可以逐步进行缩容。
如下图所示，以首页信息流业务为例，通过这套实时冗余度评估机制，就可以保持持续有一倍以上的冗余度，并精准的计算春晚期间剩余的冗余度情况，以便进行扩容、降级等应对。图 3. 智能弹性调度系统
跨语言服务化改造
正如图 1 所示的混合云架构，业务线之间的服务调用采用 HTTP 调用，通过 DNS 解析请求不同的机房，再经过 LVS 和 Nginx 的转发，流量才到达正在处理的业务节点。当需要做全链路扩容时，不仅需要扩容业务计算节点，还需要对 LVS、Nginx 进行评估扩容。这一点往往被许多业务团队所忽略，并且监控也不一定能覆盖到。
同时，在这个模式下进行流量切换、扩容计算节点时，都需要依靠传统的运维模式，变更 DNS、LVS、Ngnix 等，这就强依赖业务运维团队的治理水平，而开发缺乏对这一层的掌控能力。
为此，经过近一年的立项与研发，我们在原有内部 RPC 框架 Motan 的基础上进一步扩展，研发了一套跨语言的服务化体系，与当前大热的 service mesh 思路不谋而合，其改造思路如图 4 所示。
图 4. 跨语言服务化改造
其中 magent 的作用主要包括服务发现与注册、负载均衡、动态路由、双发熔断、metric 上报以及日志推送等，如图 5 所示。
图 5. magent 的功能
经过跨语言服务化改造后的混合云架构如图 6 所示：
图 6. 微服务化后的混合云架构
在这套微服务化框架的基础上搭建了统一服务治理平台如图 7 所示，具备服务自动扩缩容、自动切流量管理，手工扩缩容，手工切流量，降级等功能，使得业务经过服务化改造后自动接入服务治理平台，便可具备这些功能，极大的增强了业务的服务治理能力。
图 7. 统一服务治理平台
总结与展望
经过 2017 年近一年的建设，我们在混合云平台、全自动化扩缩容系统以及跨语言服务治理体系这三个方向上取得了巨大的突破，成功完成了春晚超过 1 万台的阿里云节点的 1 小时快速构建，根据统计，春晚当天阿里云弹性节点承担了系统超过 40% 以上的流量。春晚期间微博的多个业务线如首页信息流、热门微博以及搜索等业务的流量都达到了日常晚高峰的 2 倍及以上，通过自动化扩缩容系统以及服务治理平台始终保持业务处于稳定健康的状态。
同时，我们也遇到一些不小挑战。如在业务计算节点大规模扩张时，与底层资源的连接数膨胀较快，对 MySQL 等资源是巨大的挑战。为此，今年我们希望在资源服务化领域取得突破，以解决资源的连接数问题。除此之外，自建 IDC 的规模无法像公有云一样随时弹性扩展，而当前依赖的数据库资源等均部署在自建 IDC。随着在公有云上所部属的业务越来越多，流量占比越来越大的情况下，数据库上云也成了一个开始考虑的方向。
挑战与机遇并存，也期望有志之士能够加入微博 Feed 研发这个群体。在这里，不仅能掌握支撑上亿日活用户访问的 Feed 系统所必须的知识，还能同一批优秀的人合作，共同建设业界领先的基于核心 Feed 业务的混合云和服务治理技术体系。