php构件微博技巧_扛下所有热搜微博亿级用户高可用架构体系培植

作者先容

李庆丰，新浪微博研发中央高等总监。
卖力微博根本架构和流媒体等研发方向，在高可用架构、视频、直播等技能方向有丰富的研发实战及管理履历，同时作为微博技能新兵演习营卖力人，主导技能新人技能融入提升培训体系。
技能社区的推戴者，多次担当业界前沿技能大会的讲师及出品人。

分享概要

一、微博的业务场景和寻衅

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

三、新的探索与展望

一、微博的业务场景和寻衅

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

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

有人把微博比喻为一个大广场，每当有社会热点事宜涌现，首先都会在微博上发酵，然后用户都集中来微博上关注事情进展，进行干系的热议，因此也给技能架构带来巨大的寻衅。

2023年第一季度财报显示：微博生动用户MAU5.93亿，DAU2.55亿。
如此大的用户量，对技能架构便是一个不小的寻衅，微博用户每天发布微博、评论、点赞等可以达到亿级规模，每天新增的订阅关注也在千万级规模。

用户规模大，首先要具备海量数据存储能力，同时作为用户日常的高频运用，也哀求具备一定的容灾能力。
以是在谈到微博的高可用寻衅的时候，首先要关注的便是微博在什么情形下流量高、寻衅大。
总结下来，微博有4个范例的流量场景：

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

因此，从微博的业务情形和场景上看，高可用架构的寻衅可以归纳出四个紧张问题：

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

性能问题：做事相应太慢，资源本钱太高

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

依赖问题：个别非核心资源拖去世全体做事

便是边缘业务功能有问题，影响了核心功能，这是不能接管的。

容灾问题：机房、专线故障导致做事不可用

近几年也常常听说机房或专线故障导致某些做事不可用情形，作为用户高频利用的APP，须要有一定的容灾能力。

二、构建高可用架构体系

针对上面提到的问题和寻衅，对应的办理方案如下：

当然，办理问题最主要的一步是能够提前感知和创造问题，因此须要有比较完备的监控体系，这就组成了我们的高可用架构体系（如下图所示）。

下面我们谈谈各个模块的详细技能架构方案：

1、容量问题

培植海量数据存储架构要关注四个方面：首先是容量评估，根据业务规模和场景确定存储容量和要求的读写比例和规模，接着就可以进行存储组件选型（MySQL、Redis等），然后就须要根据实际压测数据，确定干系的容量安全阈值和要求量安全阈值，同时增加干系监控和报警，末了还要做好容量的可扩展预案，一旦存储容量或要求容量达到安全阈值，能从容按照预案应对。

存储容量的可扩展预案，须要提前做好三方面的准备：

读写分离：特殊适宜读写比例失落衡的业务场景，方便将来针对性地进行容量扩展；水平拆分：能够把数据按hash存储到多个存储实例中，办理单机存储容量的瓶颈问题；垂直拆分：针对随着韶光会累积增加的内容存储场景，提前按韶光维度做好分库或分表，应对随着韶光累积引起的存储容量问题。

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

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理论（便是同等性、可用性、分区容忍性，同一韶光场景只能知足其二），对付社交场景一样平常是舍弃同等性，把同等性从强同等性降为终极同等性。

上图是微博的简化版多机房架构，这个架构紧张办理三个问题：

一是把数据的强同等性降为终极同等性，多个机房之间的终极数据是通过数据主从同步的办法实现的，以此来保障机房数据的终极同等性；二是通过自研的WMB总线做事，快速把进行机房间同步，保障机房间同步的高效、稳定、完全；三是通过缓存机制，保障用户履行看到不同机房间的内容，不过度依赖数据库同步。

在这样的架构下 ，纵然某一机房涌现问题，机房内部还能形成自运行生态，从而保障做事可用。

微博的机房较为分散，把几个附近的机房称为一个可用区，终极微博形成的是：三可用区+公有云架构。
在可用区内部，做事和资源依赖形成闭环，同时不能强依赖可用区外的做事和资源，核心做事采取多可用区支配；同时依托稠浊云架构，让每个可用区可独立通过公有云随时进行快速扩容；终极还要建立流量调用机制，并定期进行干系场景的容灾演习训练。

5、监控体系、做事管理SLA体系

磋商四大问题后，还须要磋商监控体系、做事管理SLA体系问题。
做事监控是全体高可用体系的眼睛，能够及时创造问题并制订预案，做事管理也已完备融入ServiceMesh中，SLA体系作为主要的量化指标，对确保高下游建立良好默契、提高办理问题的效率有着重要浸染。

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

有了平台的技能体系，系统的可用性就无需过度依赖人的成分，只需做事支配在这个技能体系上，海量数据存储、分布式缓存架构、稠浊云体系能力都可以浑然天成。

三、新的探索与展望

微博一贯在培植PAAS平台，未来，我们希望把平台积累的技能履历、技能组件集成到这个PAAS平台上，业务开拓同学把功能开拓完成后，只要在git提交，就能自动进行CI/CD流程、进行做事支配。

微博PAAS还以稠浊云技能为根本，实现做事资源的动态扩缩容能力，通过容器化技能和K8s技能，管理并标准化做事Node节点，通过ServiceMesh和DataMesh组件，管理做事间调用和资源调用，包括继续做事管理能力。
通过Paaslet来进行资源的隔离和优先级调度，实现多类型做事稠浊支配，提升资源利用率。
所有支配在PAAS平台上的做事，都可以得到runtime的实时监测，可以及时创造做事运行时非常、保障做事稳定。

随着AIGC的兴起，我们也在积极探索AIGC代码天生和非常监测方案，目前我们开拓了WeCode组件，从代码开拓层面提升代码质量保障做事稳定。

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

添加群秘dbayuqing备注0728获取本期PPT

直播预报丨业务驱动的微做事架构演进之路：以 DDD 为辅导思想

随着公司计策调度及业务快速发展、酒店业务侧发生巨大变革，酒店供应链技能侧于2022年初主动发起一次基于DDD思想的技能架构调度。
本次分享紧张想通过实际项目的案例，先容DDD详细的落地过程。
结合业务特性所总结的方法，期望能够给大家在基于DDD落地微做事项目时供应思路。