<返回更多

抗下所有热搜!微博亿级用户高可用架构体系建设

2023-08-31  dbaplus社群  
加入收藏

作者介绍

李庆丰,新浪微博研发中心高级总监。负责微博基础架构和流媒体等研发方向,在高可用架构、视频、直播等技术方向有丰富的研发实战及管理经验,同时作为微博技术新兵训练营负责人,主导技术新人技术融入提升培训体系。技术社区的拥护者,多次担任业界前沿技术大会的讲师及出品人。

分享概要

一、微博的业务场景和挑战

二、如何构建高可用架构体系

三、新的探索与展望

一、微博的业务场景和挑战

微博是2009年上线的一款社交媒体平台。刚开始微博的功能比较简单,就是用户关注了一些其他微博账号,就可以在自己的信息流里看到相关用户的动态微博。

为了满足不同用户的实际需求,微博的功能也变得越来越丰富,出现了多种信息流机制,比如基于关注关系进行信息分发的关注流、基于用户兴趣进行信息分发的推荐流,还有发现页中大家都很关注的热搜板块等。

有人把微博比喻为一个大广场,每当有社会热点事件出现,首先都会在微博上发酵,然后用户都集中来微博上关注事情进展,进行相关的热议,因此也给技术架构带来巨大的挑战。

2023年第一季度财报显示:微博活跃用户MAU5.93亿,DAU2.55亿。如此大的用户量,对技术架构就是一个不小的挑战,微博用户每天发布微博、评论、点赞等可以达到亿级规模,每天新增的订阅关注也在千万级规模。

用户规模大,首先要具备海量数据存储能力,同时作为用户日常的高频应用,也要求具备一定的容灾能力。所以在谈到微博的高可用挑战的时候,首先要关注的就是微博在什么情况下流量高、挑战大。总结下来,微博有4个典型的流量场景:

前三个场景是可以预期的,可以提前准备,而突发热点场景是不可预知的,且往往流量峰值非常高。

因此,从微博的业务情况和场景上看,高可用架构的挑战可以归纳出四个主要问题:

微博从刚上线时的几百万用户到现在几亿用户量,博文内容数据也在不断累积,数据量和存储压力越来越大;同时,随着用户规模增大,并发用户请求量也会增大。

接口性能问题,不仅会影响用户消费微博信息流的体验,还会增加资源成本。

就是边缘业务功能有问题,影响了核心功能,这是不能接受的。

近几年也经常听说机房或专线故障导致某些服务不可用情况,作为用户高频使用的App,需要有一定的容灾能力。

二、构建高可用架构体系

针对上面提到的问题和挑战,对应的解决方案如下:

当然,解决问题最重要的一步是能够提前感知和发现问题,因此需要有比较完备的监控体系,这就组成了我们的高可用架构体系(如下图所示)。

下面我们谈谈各个模块的具体技术架构方案:

1、容量问题

建设海量数据存储架构要关注四个方面:首先是容量评估,根据业务规模和场景确定存储容量和请求的读写比例和规模,接着就可以进行存储组件选型MySQLredis等),然后就需要根据实际压测数据,确定相关的容量安全阈值和请求量安全阈值,同时增加相关监控和报警,最后还要做好容量的可扩展预案,一旦存储容量或请求容量达到安全阈值,能从容按照预案应对。

存储容量的可扩展预案,需要提前做好三方面的准备:

微博场景已经有十几年的历程,博文内容存储量会随着时间不断增多,因为内容存储按时间维度进行垂直拆分,每隔一段时间,就可以自然地增加新的数据库实例,不断扩展整体存储容量。

2、性能问题

性能问题的主要应对方式是建设分布式缓存架构,也包含四个方面的建设。首先是容量评估(对应缓存要缓存什么数据,缓存数据有多大规模,增长趋势如何等),有了这些评估情况,就可以进行缓存组件选型(本地缓存LocalCache还是分布式缓存,分布式缓存常见的还有memcached或redis等),原则上,如果缓存数据不多,能使用LocalCache搞定的就尽量用LocalCache,会相对简单。

与此同时,因为互联网产品用户规模大,需要缓存的数据多,大部分情况都要用分布式缓存就来解决,所以缓存组件也需要建立性能基准,确定请求安全阈值,建立监控和报警机制,最后也要提前做好缓存容量可扩展预案。

缓存容量的可扩展和保障预案主要从下面三个方面准备:

因本地缓存机制简单高效、性能好,所以要优先使用本地缓存LocalCache;如果本地缓存放不下,就要使用分布式缓存,使用sharding分片把数据按指定hash规则放到对应缓存实例中;同时还需要考虑缓存高可用的问题,因为一旦缓存出了故障,就会有大量请求直接穿透数据库,可能会直接把对应数据库实例打挂,造成服务雪崩,一般预防措施是采用Master/Slave的主从模式

3、依赖问题

系统一般都会有核心和非核心功能,它们之间会有调用关系,也就是有依赖关系。通常情况下,这种调用依赖会加上超时控制和重试机制,尽量降低依赖的影响。

同时,在核心功能内部,也会有核心服务模块和非核心服务模块、核心资源和非核心资源;因为这些服务模块在一个JVM(以JAVA环境为例)或容器里,在运行环境中共享cpu、内存、磁盘,所以它们之间的很难避免互相影响。

基于这种情况,我们通常会想到微服务架构。微服务架构在2012、2013年的时候就非常火,好的微服务架构要求实现松耦合、高内聚。

通过微服务的理念,把服务模块拆得足够细,再加上超时控制和容错机制,相互之间的依赖会变轻量,但同时会带来另一个问题——服务性能会变差

通常HTTP调用相比JVM内部的进程调用耗时会慢很多,所以我们又引入了RPC调用方式来解决服务性能的问题。RPC的调用方式是在调用方和被调用方之间建立长连接通道,相比HTTP调用,省去了域名解析、握手建连流程,调用效率会高很多。

微博内部服务使用了php、GO、Java等不同的开发语言,为了能让这些服务间实现高效的RPC调用,我们在2014年自研了跨语言RPC服务Motan,并于内部广泛使用。目前这个RPC框架是已开源,已有5000+ star,感兴趣的同学可以去了解和共同建设。Github地址:https://github.com/weibocom/motan

2017年左右出现了ServiceMesh技术,这是对微服务和RPC技术的一次理念升级。

因微博场景需要解决跨语言的问题,所以很早就在motan RPC框架基础上,把服务治理能力抽象到一个Agent中,然后部署上下层成为基础设施组件的一部分,这和业界ServiceMesh的部分理念不谋而合。

紧接着,我们在Motan框架基础上建设了WeiboMesh服务组件。区别于原来的微服务,我们无需业务关心通用服务治理能力下层的基础设施层,只要用了WeiboMesh,自然就具备了相关的通用服务治理能力,业务在调用接口的时候,就感觉在调用本地服务接口一样方便。

下图所示为WeiboMesh架构。我们把WeiboMesh服务直接打到基础镜像里,这样在业务部署服务时,自然就有了服务网格的基础通信能力、服务治理能力,业务间通过服务网格的通信基础走长连接通道,更加方便高效。

WeiboMesh的使用主要分成两方面:一方面是服务间的调用(ServiceMesh);另一方面是资源调用(DataMesh)。

资源调用DataMesh对性能要求会更高一些,有了服务网格模式后,我们就能更好地监控到所有业务的资源调用情况,方便进行相关调用管理,比如资源流量调用等。有了这些监控数据和调度手段,就能够在全站建立联动策略和故障容灾体系。

目前为止,我们通过微服务架构解决了服务依赖问题、通过Motan RPC调用解决了调用性能问题、通过ServiceMesh解决了服务治理通用化问题。但微服务还带来了一个问题——运维复杂度问题。

如上图所示,运维复杂度取决于两个因素:

所以,微服务拆分之后,即使集群还是同样的服务器规模,但是服务种类大幅增加了,运维复杂度也大幅增加了。

在2014年左右,Docker容器化技术正好出现了,其可以实现用非常小的成本解决运维复杂度的问题,微博作为国内最早一批大规模应用容器化技术的团队,也享受着这一新技术的红利。

Docker容器化技术的优势是可以隔离环境差异、实现统一的部署方式,同时还没有太多额外消耗。统一部署方面,我们通过统一基础镜像的方式,解决组件和版本依赖问题。

如微博春晚扩容场景。因之前运维复杂度高,春节需要提前一个月准备采购机器和版本环境,不同服务还要检查相关差异,而在2014年春节的时候,我们首次大规模应用容器化技术进行春晚抗峰扩容,利用容器化技术屏蔽系统环境和版本差异,扩容准备时间大幅缩短,很好地解决了微服务带来的运维复杂度问题。

同时,伴随着现在公有云厂商的出现,我们又有了新的想法。回顾微博4种典型流量场景,微博的流量高峰和低谷都非常明显,如果按照高峰来部署服务器,资源成本会非常高,因此在运维效率得到一定的提升之后,我们只需部署基础流量的服务器资源,出现流量高峰的时候再从公有云临时借用一部分服务器,流量高峰过去后再归还,这样的策略大幅降低服务器成本。

基于以上思路,我们通过容器化技术+公有云技术,并通过容器化技术屏蔽我们本地服务器和公有云服务器的环境差异,建设了微博的混合云架构。

混合云架构让微博可以日常部署基础的服务器资源,在各种流量高峰场景,还可以快速从公有云临时借服务器部署,极大地降低服务运维资源成本。特别是在微博的突发热点场景下,依托混合云技术的动态扩缩容能力,让我们可以用相对较小的成本,很好地应对微博突发热点流量。

4、容灾问题

多机房部署是大型服务必须考虑的事情,因此机房容灾的重要性在这几年特别突出。有些公司因机房问题导致的故障甚至还上了热搜,还因此受到了处罚,所以基础运维负责人要尤为重视容灾问题。

说到多机房容灾架构,我们一定首先要了解一个古老而重要的理论——CAP理论(就是一致性、可用性、分区容忍性,同一时间场景只能满足其二),对于社交场景一般是舍弃一致性,把一致性从强一致性降为最终一致性。

上图是微博的简化版多机房架构,这个架构主要解决三个问题:

在这样的架构下 ,即使某一机房出现问题,机房内部还能形成自运行生态,从而保障服务可用。

微博的机房较为分散,把几个相近的机房称为一个可用区,最终微博形成的是:三可用区+公有云架构。在可用区内部,服务和资源依赖形成闭环,同时不能强依赖可用区外的服务和资源,核心服务采用多可用区部署;同时依托混合云架构,让每个可用区可独立通过公有云随时进行快速扩容;最终还要建立流量调用机制,并定期进行相关场景的容灾演练。

5、监控体系、服务治理SLA体系

探讨四大问题后,还需要探讨监控体系、服务治理SLA体系问题。服务监控是整个高可用体系的眼睛,能够及时发现问题并制定预案,服务治理也已完全融入ServiceMesh中,SLA体系作为重要的量化指标,对确保上下游建立良好默契、提高解决问题的效率有着重要作用。

高可用架构体系易于搭建,难在维护。随着日常需求的不断上线变更,系统架构也在不断变化,原来的容灾预案也可能会受影响而失效。因此,多机房架构需要持续地积累和传承,最终把这个技术经验转化为基础组件,形成平台的技术体系。

有了平台的技术体系,系统的可用性就无需过度依赖人的因素,只需服务部署在这个技术体系上,海量数据存储、分布式缓存架构、混合云体系能力都可以浑然天成。

三、新的探索与展望

微博一直在建设PAAS平台,未来,我们希望把平台积累的技术经验、技术组件集成到这个PAAS平台上,业务开发同学把功能开发完成后,只要在git提交,就能自动进行CI/CD流程、进行服务部署。

微博PAAS还以混合云技术为基础,实现服务资源的动态扩缩容能力,通过容器化技术和K8s技术,管理并标准化服务Node节点,通过ServiceMesh和DataMesh组件,管理服务间调用和资源调用,包括继承服务治理能力。通过Paaslet来进行资源的隔离和优先级调度,实现多类型服务混合部署,提升资源利用率。所有部署在PAAS平台上的服务,都可以得到runtime的实时监测,可以及时发现服务运行时异常、保障服务稳定。

随着AIGC的兴起,我们也在积极探索AIGC代码生成和异常监测方案,目前我们开发了WeCode组件,从代码开发层面提升代码质量保障服务稳定。

微博PAAS平台建设方面已初具规模,也还在不断完善,后续有机会再和大家分享。

关键词:架构体系      点击(23)
声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多架构体系相关>>>