快手架构师：3亿日活的快手微服务架构实践

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

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

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

快手系统架构遇到的挑战

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

快手的微服务架构的治理

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

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

跨数据中心的路由管理

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

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

有状态服务管理

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

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

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

一个典型案例，快手的私信服务，可以理解为是一个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进行了改造、并针对消费者进行了智能限速等。

后续计划：

第一点，由于机房的限制，面临无法集群内扩容的问题。如果搭建新集群，势必会带来大量的业务迁移过程，这会搞得大家都很痛苦。所以，解决的思路是，是否可以建设支持跨IDC的统一大集群的方案。

第二点，随着业务规模越来越大，目前controller存在一系列的性能问题。极端情况下，会影响系统稳定。接下来会对这块进行一系列优化。

第三点，部分业务线有对事物功能的诉求，也会参考高版本的设计，将这个功能增加进来。

第四点，机器的磁盘会出现“半死不活”的情况，这段时间请求会卡死，造成业务的不稳定。要想办法把这种情况解决掉。

本文内容小结

快手系统架构遇到的挑战。把海量视频精准的分发给用户、系统高可用、支持多开发语言大型微服务集群的治理。

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

快手的微服务架构的治理。服务治理平台自身的可用性、跨数据中心的路由管理、有状态服务管理、复杂服务网络的监控。

快手的大数据存储架构。HDFS/HBase服务主要的改进包括：单点故障快速恢复、读写性能优化、服务分级保障与回退等待、服务柔性可用、fastfail、QPS限流、扩展性改进等。

快手的Kafka集群应用实践。平滑扩容功能、数据Mirror服务做了集群化建设、做了资源隔离和cache 改造、智能限速等。

作者简介：K，知名电商公司技术老K级人物。文出过畅销书，武做过CTO，若不是生活所迫，谁愿意一身才华。

如果觉得本文对您有帮助，请点在看、分享朋友圈，感谢您的支持！

声明：本文来自“技术领导力”公众号。

快手架构师：3亿日活的快手微服务架构实践相关推荐

首席架构师推荐：史上最全微服务架构简史详解！
本文将介绍微服务架构和相关的组件,介绍他们是什么以及为什么要使用微服务架构和这些组件.本文侧重于简明地表达微服务架构的全局图景,因此不会涉及具体如何使用组件等细节. 要理解微服务,首先要先理解不是微服 ...
听听八年阿里架构师怎样讲述Dubbo和Spring Cloud微服务架构
微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业 ...
听听八年阿里架构师怎样讲述Dubbo和Spring Cloud微服务架构吧
微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业 ...
快手架构师：3亿日活的快手微服务架构实践！8页ppt分享
点击"技术领导力"关注∆ 每天早上8:30推送作者| Mr.K 编辑| Emma 来源| 技术领导力(ID:jishulingdaoli) 本文整理了,快手基础平台架构师曹 ...
从 0 到 1 实现支撑百亿级请求量的微服务架构演化
过去几年,架构领域最火的方向之一莫过于微服务.实践微服务的好处显而易见,比如其本身所具备的可扩展性.易维护性.独立自治.故障和资源隔离等诸多特性,可以大大提高产品研发效率.同时,基于微服务架构设计风格 ...
【系统架构设计师】软考高级职称，一次通过，倾尽所有，2016年下半年系统架构设计师考试论文真题（论微服务架构及其应用）
[系统架构设计师]软考高级职称,一次通过,倾尽所有,看完这篇就够了,学习方法和技巧这里全都有. 2016年下半年系统架构设计师考试论文真题(论微服务架构及其应用) 论微服务架构及其应用近年来,随着互 ...
创建微服务架构的步骤_如何快速搭建一个微服务架构？
原标题:如何快速搭建一个微服务架构? 微服务火了很久,但网上很少有文章能做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务 ...
Re：从0开始的微服务架构：（二）如何快速体验微服务架构？
记得好久之前看到一个大牛说过:如果单体架构都搞不好,就别搞微服务架构.乍一看,这句很有道理,后来发现这句话是不太对的,因为微服务架构的目的就是为了降低系统的复杂性,所以微服务架构应该比单体架构更简单 ...
《微服务架构设计模式》读书笔记 | 第9章微服务架构中的测试策略（上）
第9章微服务架构中的测试策略(上) 前言 1. 微服务架构中的测试策略概述 1.1 编写自动化测试 1.2 使用模拟和桩进行测试 1.3 使用范围对测试进行分类 1.4 使用测试象限对测试进行分类 ...

快手架构师：3亿日活的快手微服务架构实践

快手架构师：3亿日活的快手微服务架构实践相关推荐

最新文章

热门文章