转载

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

点击“ 技术领导力 ”关注 ∆ 每天早上8:30 推送

作者| Mr.K 编辑| Emma

来源| 技术领导力(ID：jishulingdaoli)

本文整理了，快手基础平台架构师曹福祥、大数据架构团队负责人赵健博，在技术大会上的分享，内容包括：快手微服务架构、大数据存储架构、 Kafka技术演进等。从完整的技术架构视角，为你拆解3亿日活的快手App架构实践，以下是正文。

快手DAU在2020年初已突破3亿，快手App内有近200亿条海量视频；2019年，有2.5亿人在快手平台发布作品，平台累计点赞超过3500亿次!

参与过大型互联网系统设计的朋友应该知道，这个级别数据量的视频上传和播放、上亿的用户同时在线访问，对系统架构的挑战有多大。

快手系统架构遇到的挑战

在业务上，如何根据用户的个性化需要，把海量视频精准的分发给用户，让有户得到独特的体验，感受科技带来的幸福感，这是一个复杂的技术问题。快手的用户界面非常简洁，在简洁接口背后是非常复杂的一套后端系统。

技术需要解决一个问题：如何让所有视频都有机会被看到，同时也不能让低质量或者用户不感兴趣的视频影响用户的体验，换句话说，如何解决十亿级长尾视频的高效分发。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

（本文所有图片来自@快手科技版权归原作者）

快手微服务要解决的8个问题

从用户体验来看，快手的前端入口非常简洁，关注、发现、同城三个Tab，背后是通过 AI 和大数据技术实现视频内容理解和个性化推荐，从而解决内容分发的问题。

快手的微服务架构是按业务模块划分的，比如视频处理、推荐、广告、消息系统等，每一个模块都可能由成百上千的微服务集群组成。

这是一个非常复杂的微服务网络，并且其规模也随着用户规模和开发团队扩张而增长。如何在保障整体服务质量的同时，还能保证新业务的开发效率和质量，需要一个统一的服务治理方案，来解决微服务开发运维过程中的各类问题。

总结下来，快手的微服务架构要解决8个问题：

第一，要有完善的基础平台和组件，包括配置中心，服务发现、监控平台，以及服务开发框架。

第二，要支持多种开发语言，因为快手的业务特点，主要使用的语言有 Java 和 C++，还有少量业务会使用 Node.js、Python。

第三，系统的高可用、高可伸缩性。

第四，要兼容容器化部署、物理机部署。

第五，服务治理平台自身的可用性要达到足够高。

第六，要支持跨数据中心的路由管理。

第七，对于有状态的服务的支持。

第八，复杂服务调用网络上的质量监控。

快手微服务治理平台KESS 的整体架构

快手的微服务治理平台KESS，管理了几千个微服务，几万台服务器，在四个国家和地区都有部署，分布在十多个数据中心。

平台的整体可用性是 99.997%，这已经是一个比较高的数字了。

跨数据中心的路由管理功能在快手内部每个月大概有一百多次的使用。RPC Monitor 每天会发出几百个报警信息，发现并定位了后端工程方面几乎 100% 的故障。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

快手的微服务架构的治理

服务治理平台自身的可用性。服务治理平台非常基础，一些公司把它称为元服务，即服务之服务，它的可用性决定了业务服务可用性的天花板。首先看一下 KESS 的多数据中心的架构。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

快手有国际化业务，把相对独立的国家和地区称作 division。比如图中 central division 是指国内的，另外还有韩国、印度等。在每一个 division 内部会有多个数据中心。其中有一个是主数据中心，其他的是从数据中心。KESS 负责从主数据中心到从数据中心的数据同步。主数据中心是全局配置唯一的可写入端。一旦主数据中心发生了灾难，可以将另一个可用的数据中心切换为主，在较短时间内恢复功能。这里比较核心的一个高可用设计，在于它的配置分发部分。

跨数据中心的路由管理

对于多数据中心部署的服务，通常是需要就近访问的，一方面能保证低延迟，另一方面也能减少专线故障对可用性的影响。

在快手，因为业务规模扩张太快，经常出现某个数据中心机器资源紧张的情况。一些服务在特定数据中心没有机器可以部署，就近访问就会失败。另外，在节假日，用户访问量通常会增长，需要提前估算流量安排机器扩容，但估算可能会不足。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

有状态服务管理

有状态服务管理是较少提到的话题，因为它比较复杂，一般在业务架构设计中是要尽量避开的。为什么快手需要有状态服务，主要分为两种情况：

一是在特定的领域存在有状态服务的开发需求，比如高并发的消息服务、推荐系统、多媒体数据理解等。

二是业务服务无状态，实际上是把状态交给了分布式存储。当业务规模不断扩大的情况下，已有的分布式存储方案可能不是特别适用，需要做定制化开发。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享

一个典型案例，快手的私信服务，可以理解为是一个 IM 服务。这个服务管理了用户手机和快手服务之间的长连接。长连接就是一个状态，长连接建立好之后还会有一个用户会话数据，这也是状态。一旦服务重启，这些状态就会丢失，用户就会掉线，虽然可以在客户端做一些 cover，但不是特别理想。

所以把这个状态和业务逻辑做了解耦。一是把长连接的管理拆分为一个服务，它逻辑非常简单，非常稳定，很长时间都不需要去更新它。二是把业务逻辑做成一个无状态的模块，它更新比较快，但是重启也不会导致用户掉线。三是开发了一个 Crux 服务存储会话数据。

它是持久化的，支持多地多活，能支撑千万级的读写 QPS。为此快手牺牲了写读一致性，写入之后可以容忍在十毫秒之内读到即可。它是一个非常定制化的分布式存储服务。Crux 服务目前支撑了主 APP 的私信服务，同时有千万级用户在线，3亿的日活。

复杂服务网络的监控

1、能够实时的查看整体服务的可用性。

2、对可用性做多维的分析。比如除了实例维度之外，还要能够对机房维度、错误类型维度、主被调的不同维度来做分析，帮助快速定位问题。

3、调用链分析。比如现实当中某一个服务上下游的情况，用红色的小点代表微服务，背后可能有成百上千的实例，线条代表调用关系，线条的颜色代表调用的成功率。

4、报警功能。支持手机报警，工程师也可以通过多维度的图表和链接去查看信息来判定问题根源。

快手的大数据存储架构

在存储服务上，HDFS/HBase 服务主要的改进包括：单点故障快速恢复、读写性能优化、服务分级保障与回退等待、服务柔性可用、fastfail、QPS 限流、扩展性改进等，此外我们还自研了位图数据库 BitBase，用于 UV 计算，留存计算等场景。简单介绍下 HDFS 服务分级保障能力，这个功能主要是面对离线场景的。在离线计算的场景下，集群整体业务负载基本上没有固定规律，因为个别大作业启动起来后，会直接造成 HDFS 主节点的满载，满载的主要表现是服务延迟升高，QPS 打平，RPC 服务请求堆积。一旦该现象出现在凌晨时段，将会影响核心链路数据的产出，造成故障。为了保障核心链路的生产的稳定，我们引入了优先级的概念，并连同计算资源调度服务一起，给核心作业（高优先级）提供计算与存储资源的整体保障。

在实现上，HDFS 主节点 RPC 服务采用多队列设计，将不同优先级的作业请求路由到不同队列，处理线程池线程按照不同比例从不同队列取请求进行处理，一旦高优先级队列请求出现高时延情况，则直接降低低优先级队列请求处理比例，将资源向高优先级队列倾斜，从而保障高优先级作业请求的延迟稳定。如果低优先级队列满，则反馈给客户端特殊信号，客户端进行 backoff 等待重试。由于核心作业相对稳定，负载也相对稳定，基本不会出现由于核心作业导致服务过载的情况。通过这个能力的控制，可以保障核心作业的数据产出延迟稳定，不受低优异常作业流量徒增的影响。

快手的Kafka集群应用实践

快手 Kafka 的技术演进过程，整体上说，包括 4 个阶段：

第一：为了支持业务的快速发展，做了多集群建设以及增加了 Kafka 平滑扩容功能；

第二，为了保障业务稳定，对 Kafka 的可用性进行了改造，经过改造，将由于单点宕机发现与恢复的时间从 91s 优化到 6s 左右，有 15 倍的提升；

第三，为了增加系统的可维护性以及提升读系统的运维效率，对数据 Mirror 服务做了集群化建设，并开发了资源管理平台；

第四，为了进一步提升 Kafka 的稳定性、性能，做了资源隔离、对 cache 进行了改造、并针对消费者进行了智能限速等。

快手架构师：3亿日活的快手微服务架构实践！8页ppt分享