十年三次重大架构升级，微博应对“极端热点”的进阶之路
“一个可靠的架构从来都不是设计出来的，而是逐步演进而来的。”这句话用来形容微博系统架构的改造历程再适合不过。
截至 2020 年 10 月，微博月活跃用户达 5.23 亿，作为当今中文社交媒体的头部品牌， 微博一直是社会热点事件传播的最主要平台。而热点事件往往具有不可预测性和突发性，10 分钟内可能带来流量的翻倍增长，甚至更大。如何快速应对突发流量的冲击，确保线上服务的稳定性，是极大的挑战。
过去几年，微博无数次遭遇突发热点事件带来的流量冲击，虽然刚开始确实暴露了不少稳定性问题，导致后来每次出现明星热点事件，就会有大批网友调侃“微博挂了吗”、“微博是不是又挂了”、“微博这次竟然没挂”等等。但与此同时，微博研发团队也在持续不断地“打怪升级”，微博背后的技术方案和系统架构经过多次调整优化，变得越来越稳定。2020 年疫情以来，微博出现多次整体流量翻 2 倍、甚至 3 倍的极端热点事件，最终都平稳度过。本文，我们有幸采访了新浪微博研发中心研发总监、微博后端架构多次升级的亲历者和负责人刘道儒，请他跟我们聊聊，围绕“极端热点”这个微博独有的场景，团队是如何展开架构改造和高可用保障工作的。
刘道儒在 2010 年加入微博，2011 年开始参与和负责微博核心系统的改造和优化工作。据他介绍，过去这十年间，微博总共经历了三次比较重大的后端架构升级。
分布式平台化架构（2011 年 -2014 年）：为应对极速增长的流量，研发团队将微博核心系统从 PHP 架构改造成平台化的 Java 架构，并构建了分布式缓存、千亿级存储、异地多活、监控、服务化等基础架构，改造完成后微博拥有了支撑亿级 DAU、千亿级存储的高可用架构。
弹性混合云架构（2015 年 -2019 年）：2015 年起微博流量持续增长且热点频发，流量随时都可能成倍增加。为在可控的成本下完成热点应对工作，微博研发团队构建了基于 Docker 和公有云的弹性混合云架构，从核心业务开始花了三四年的时间逐步推广到微博各个业务，最终让各主要业务都具备了极速扩容能力，最新的弹性扩容速度是 10 分钟 5000 台。同时，也完成了微博的热点联动机制和 Service Mesh 技术架构 WeiboMesh 的建设，并推广到了各业务。（延伸阅读：《从观望到落地：新浪微博 Service Mesh 自研实践全过程》）
智能云原生架构（2020 年至今）：随着弹性能力的提升，微博单个运维和 DBA 能保障的服务和资源规模大幅增加，微博 DBA 人均管理 1 万以上的资源端口，但随着架构复杂度不断提升，如何提供普遍的高品质的保障服务变成新的挑战。研发团队开始对数据库、缓存、消息队列等进行智能化和弹性调度改造，并完成了可将单位成本降低 50% 的基于阿里云高配神龙服务器的整租零售方案建设，同步也在将运维和 DBA 团队升级为 DevOps 团队。由于云原生架构的改造和建设工作量非常巨大，相关工作还在持续推进中。
除了微博核心系统，研发团队也配合搜索、热门微博、广告、直播、视频等业务进行了混合云和云原生架构升级改造，大幅提升了微博全站的热点和稳定性保障能力。
虽说成功的架构升级改造确实能够为企业带来不小的收益，但改造需要付出的代价同样不得不提前考量好。
在刘道儒看来，架构改造不仅消耗架构师团队大量的时间，也需要业务研发团队腾出很多时间和精力来支持，甚至会延缓业务研发速度，所以如果不是问题致命且有普遍性，或者能带来效率十倍以上提升，不要轻易展开一个大的架构改造项目。
由于架构升级的成本非常巨大，2～3 年的时间只能进行一项重大架构改造，选择某一个架构改造就要放弃其他所有可能的架构改造，这就要求所选的架构改造要具备独特性、技术领先性以及很强的扇出效应。
独特性是指架构改造解决的问题要有很强的差异性，如果独特性比较差，那么大家都能很快做到，架构改造的成果就会大打折扣。以微博为例，研发团队在选择架构改造方向时主要会围绕“极端热点”这个微博独特的场景来进行，包括做 Web 自动化扩缩容和数据库自动化扩缩容都是围绕这个场景来的，这样在这个场景下就很容易做到持续领先。
技术先进性则对技术品牌、招聘和研发竞争力非常有价值。而扇出效应则是指所选的方向要有以点带面的能力，比如微博借助领先的弹性能力改进了业务治理、上线发布、快速研发、压测、快速故障处置等方面的能力，借助云原生能力具备了产品化异地多活、资源云、整租零售、在离线整合等能力，这些能力交织在一起构成了一套完备的云原生基础架构体系。
刘道儒补充表示，为了进一步摊销架构改造的高成本，所选的架构改造方向要能进行产品化，能普遍支持公司的各种业务场景，只对某个业务场景有价值的方向不适合大规模来做。业务的故障和问题记录可以作为参考，看看所选的架构改造方向对过去一年的故障和问题的覆盖度有多少。优先选择高频的方向，一方面能解决很多具体问题，另一方面也更能获得业务的大力支持。
通过部署混合云架构、让业务具备弹性扩容能力，是微博面对频繁爆发的热点事件带来的突发流量时，解决内部资源冗余度不足问题的有力武器。
微博热点分为很多不同的类型，其中如地震、游戏类的热点主要冲击 Feed 流，而明星类的热点主要冲击热搜和热门微博流。热点的访问路径不同对应的技术链路也略有不同，但总的来说从网络入口、四七层、接入层到业务层、平台层、资源层，就像现实中的洪水洪峰一样，各层都会逐步承受流量洪峰。
差别在于不同层的扩容难易度、维持高冗余度的成本、最高峰值大小等。通常网络入口、四七层和接入层比较容易扩容，维持高冗余的成本也较低；而平台层由于服务器规模大维持高冗余度成本就很高，热搜、热门微博等业务流量涨的非常快、3 分钟流量就能翻 5～10 倍，资源层扩容慢需要持续维持高冗余度。另外，由于需要逐层逐业务地进行热点应对治理，暂未治理的系统或业务如果遇到热点承压就会比较大。
由于热点的业务链路和技术链路都很多样，不可能防住一两个点就高枕无忧，但所有系统和业务全部覆盖的服务器成本和改造的人力成本会非常高，这也是微博热点应对的挑战之处。
刘道儒表示，经过多年的实践和研发，最有效的手段还是对热点频发的业务和链路进行热点联动覆盖，量化流量并通过动态扩缩容维持服务冗余度，再对热点进行实时判断并联动扩容。具体来说，会有一个服务实时检测服务流量变化情况，如果流量快速增长并达到预定的一级热度阈值，检测服务就会对外广播一级热度消息。不同的服务和模块会根据不同级别的热度做出不同的反应，比如报警及通知模块会通过 IVR 电话、邮件、内网 IM 消息等告知开发、运维等同学进行应对。而各业务系统则会在收到消息后，根据各自预定的方案进行扩容、降级等操作。
同时，日常工作中让所有的业务均支持动态扩缩容，这样即使某个业务第一次遇到热点，也能快速扩容恢复服务。对于网络、专线等公共基础设施，则由基础架构团队持续监控并维持足够冗余度。
相比 5 年前，微博如今已经构建了完备的热点应对机制，建立了包括热度等级、烈度等级、热点预测与高冗余度保持、热点联动扩容、热点联动动员等机制，能够在 2 分钟内发现热点并进行体系的降级、扩容等联动应对，具备 7*24 小时 10 分钟 5000 台弹性服务器的极速弹性扩容能力，各核心业务均纳入到热点联动范围，并建立了涵盖四七层、专线等全链路基础设施冗余度监控与保持机制。
2020 年疫情以来，微博出现多次整体流量翻 2 倍、甚至 3 倍的极端热点事件，热点联动机制均很好地保障了热点发生时的全站稳定性，单次最大弹性扩容服务器达数万台。
除了极具挑战的突发热点场景，微博系统架构的可靠性保障还面临来自其他方面的挑战，异地多活就是其中之一。
微博早在十年前就开始尝试异地多活部署，而这项工作一直持续了十年之久。
2010 年 -2014 年，微博研发团队摸索并构建了初步的异地多活技术体系，并综合各种因素最终采取了核心业务同城多活的架构，这期间团队也走了一些弯路。最开始团队选择了基于 MySQL 触发器的方案，后来遇到从库延迟和消息到达无序等问题导致第一次方案失败；2012 年参考雅虎的方案又研发了微博多机房消息分发服务 wmb，解决了异地消息同步的问题，微博核心系统实现了北京 - 广州异地双活架构；但到了 2014 年，随着微博业务变得愈加复杂，普遍的异地多活成本已经非常巨大，微博核心系统撤离了广州退回到北京同城双活架构。直到后来有了混合云架构之后，才又变成同城多活架构。
2015 年以来，微博研发团队逐步构建了弹性混合云体系、WeiboMesh 体系、统一运维平台、数据备份与恢复平台、指标治理与 AIOps 体系、资源云体系、整租零售技术等一系列的前置技术体系，逐步统一了基础架构体系。如今团队正在推进 5 分钟 8 万台服务器（Pod）的弹性能力、10 分钟百 T 级数据传输与恢复能力、跨语言智能服务治理、数据库弹性扩缩容等领先的技术和架构能力，进而让业务可以低感知甚至无感知地支持异地多活。到 2020 年底，随着微博云原生技术和资源云技术的发展，微博终于具备了全站范围低成本做异地多活的技术能力。
在刘道儒看来，技术发展到今天，异地多活已经不仅仅是一个技术问题，更多是成本与容灾能力的平衡。异地多活不仅会大幅增加数据库、服务器等成本，而且新业务的研发、老业务的改造、基础设施建设等都要增加异地多活的支持。如果是远距离的异地多活，不仅核心业务要做异地多活，所有相关的业务都要做异地多活，相关的成本会呈数量级增加。
由于异地多活需要提高数据库等资源的冗余度与成本，微博研发团队目前在重点建设 1 小时 1 万台服务器的快速迁移和异地重建能力（延伸阅读：《业界前所未有：10 分钟部署十万量级资源、1 小时完成微博后端异地重建》）。
除了基础架构部主导的整体架构、基础设施等层面的建设，微博的故障响应定级机制、服务 SLA 保障、重大事件应急演练、重大事件职守与保障等制度和机制在保障微博整体系统高可用上同样发挥着重要作用。
此外，作为最早的移动互联网产品之一，微博已经经过十多年的迭代，拥有众多业务线和各种新老服务，众多的老服务和老资源如何维护和改造也是一个很大的挑战。为此，微博研发团队构建了 WeiboMesh 架构和统一运维平台以实现新老架构的跨语言标准化治理，并组建了专门的架构改造团队帮助业务团队进行架构改造与升级。
虽然微博核心系统采用的是 Java 语言，但近年来随着广告和推荐体系的快速发展，C++ 语言架构在微博的应用场景越来越多，由于建设时间较短且研发团队分散等原因，C++ 技术体系的完备性难以满足业务需求。2020 年下半年以来，借着对推荐引擎进行升级重构的机会，微博组建了 C++ 架构师团队并完善了 C++ 体系的开发、架构、运维等体系，在今年 5 月份即将召开的 QCon 北京站上，这个重构项目的负责人马骎将会与大家分享相关经验。
当前整个基础架构和云原生体系都在蓬勃发展，AIOps、边缘计算、容器编排、云原生数据库等方向都发展得很迅速。
随着监控体系的完善和大数据技术的发展，AIOps 能够让基础设施治理更智能，大幅提升问题发现、故障定位、流量预测、服务治理等的效率。边缘计算除了提供静态服务外，已经具备函数式动态服务能力，并将很快具备普遍的动态服务能力，届时与 5G 技术结合，用户在毫秒级即可获得强大的动态计算能力。容器编排则可以对资源进行全局错峰调度，对 Web、数据库、大数据等资源统一调度合理调配，大幅提升资源整体的利用率。云原生数据库则能够让数据库的自动化治理程度不断提升，数据库的自动分库分表、自动扩缩容、自动迁移等能力将很快变成现实。
在刘道儒看来，IT 领域层出不穷的新技术和新解决方案是值得研发人员庆幸的。这些新技术、新解决方案背后是旺盛的、未能充分满足的且充满挑战的需求，它们也代表一波新的技术浪潮，新技术浪潮中会有巨大的红利，这些红利不仅包括效率或成本的大幅优化，也有利于研发人员的晋升和研发团队的发展。
不过他也表示，如果某项技术连续几年都很热，说明这项技术还在发展中、还不够成熟，还有一些关键难点未能攻克，不能普遍采用。这个时候更适合技术实力强大，且场景特别契合的公司和团队先做尝试，在部分场景落地并率先抢到红利。
任何新的先进技术在带来便利和收益的同时，也会带来新的挑战。只有及时进行组织和系统的调整才能更快地掌控新的技术体系。
从好的一面来看，云原生浪潮大大加快了基础架构体系的自动化和智能化演进速度，传统对业务的人工运维和保障工作大幅减少，基础设施的研发和保障工作大幅增加，需要基础架构团队在人员构成上不断演进，需要更多综合能力强的架构师，也需要更多的 DevOps。云原生的浪潮会大幅提升系统稳定性和治理水平，并大幅节省成本，工程师和架构师的工作会获得更多认可。
但与此同时，在云原生技术完全成熟之前，云原生架构的风险比之前更大了。以前很多系统都是独立的，很多操作都是手动的，问题很多但很少同时出现；而云原生之后，由于有大量的中心节点、中心系统的存在，以及大量的自动化工作，平常的问题会少很多，但全局性故障的风险却大了很多。针对新的可靠性挑战，刘道儒建议可以围绕中心系统等建立健全监控和故障恢复体系，并确保所有自动化的操作都能手工干预，同时也要定期进行灾备演练。
在技术路线和架构选择上，刘道儒一直认为适合自己业务的技术才是好技术，研发团队要依据业务的特点选择自己的技术路线，而不是盲目跟风。
以微博为例，2015 年微博在做 Docker 编排技术选型时，由于当时的运维同学更熟悉和习惯用 IP 方式管理和调度资源，就放弃了 Swarm 的编排方案，也没采用当时已开始火爆的 K8s 编排方案，直到 2020 年微博需要对高配服务器进行资源切割调度时才转向 K8s 方案，这帮助团队快速实现了 Docker 在微博的落地和广泛使用。在 2016 年的时候，微博更多是一种“保守主义”和“实用主义”的架构思路，当时团队比较小研发能力弱，系统的缺陷和挑战也很多，保守主义是种不错的防御策略。而到了今天，微博已经有成规模的架构师团队，系统和技术体系也相对健全，抢占新技术制高点开始变成重点。当下，微博的研发团队会更多对新技术方向进行跟踪和终局预判，并与各业务线的需求和问题匹配，从而持续修正研发规划。对没有前途或者微博没有竞争力的方向尽早放弃，但对新的战略性方向会更加激进地投入和尝试，从而用先进的技术来赋能业务发展。
在混合云和云原生技术快速发展的当下，刘道儒对于后端架构技术选型也有一些新的思考。首先要看哪些是云厂商擅长做的，如果云解决方案的成本和效率远超过自研，那么直接用云厂商的解决方案是不错的选择。如果担心被云厂商绑死，可以同时选择两个或多个云厂商的服务。
其次要根据自己公司的业务特点选择适合的技术路线和架构战略，这个技术路线一定要匹配自己的独特业务场景，才能有竞争力。然后要在相关点上持续建设，该自研的一定要自研，该用新技术的时候一定不要保守，只有新技术才有大的红利。
最后对于云厂商未覆盖、也不在自己技术路线上的场景和需求，可以直接借鉴业界的成熟解决方案，够用就好，要把精力聚焦在自己的技术路线上。当然如果所在公司财大气粗，对基础设施投入特别充裕，可以选多条技术路线同时建设，但不建议全面铺开，毕竟投入再大也很难匹敌头部云厂商的投入和规模。
5 月 29-31 日，QCon 全球软件开发大会将在北京举办。大会汇聚 150+ 位演讲嘉宾，同时设立 29 个热点技术专场包括 Serverless、Flutter、DDD、音视频、云原生、智能金融、大数据、数字化转型、人工智能等，内容源于实践并面向社区，点击【阅读原文】了解更多。
五一特惠购票活动现已开启，团购最高立减 2840 元。活动截至 5 月 5 日，详询票务小姐姐 Doris：17310043226（电话同微信）
点个在看少个 bug👇