快手服務治理平台 KESS 的設計理念和實戰

如今快手有 80 億條海量短視頻，1.5 億的日活，每天仍然有超過 1500 萬條以上的新增短視頻。如何根據用戶的個性化需要，把海量視頻精準的分發給用戶，讓有戶得到獨特的體驗，感受科技帶來的幸福感，這是一個複雜的技術問題。快手的用戶界面非常簡潔，在簡潔介面背後是非常複雜的一套後端系統。

以下內容是快手科技基礎平台架構師曹福祥在 2018 北京 ArchSummit 全球架構師峰會快手科技技術專題中分享，快手服務治理平台 KESS 的設計理念和實戰。

快手服務架構和服務化背景

快手的公司使命是用科技提升每一個人獨特的幸福感，這其中就包括讓每一個普通人都有機會被世界所看到，以及看到更廣闊的世界。這裡需要解決一個問題，如何讓所有視頻都有機會被看到，同時也不能讓低質量或者用戶不感興趣的視頻影響用戶的體驗，換句話說，如何解決十億級長尾視頻的高效分發。

為了解決這個問題，快手採用了獨特的技術架構，一是前端入口非常簡潔，關注、發現、同城三個 Tab，二是極其複雜的後端架構，通過 AI 和大數據技術實現視頻內容理解和個性化推薦，從而解決內容分發的問題。

快手的後端服務架構包含多個業務模塊，比如視頻處理、推薦、廣告、消息系統等，每一個模塊都可能由成百上千的微服務組成。這是一個非常複雜的微服務網路，並且其規模也隨著用戶規模和開發團隊擴張而增長。如何在保障整體服務質量的同時，還能保證新業務的開發效率和質量，需要一個統一的服務治理方案，來解決微服務開發運維過程中的各類問題。

服務治理平台方案選型

這裡列出了服務治理的幾個基本要求。首先要有完善的基礎平台和組件，包括配置中心，服務發現、監控平台，以及服務開發框架。第二，支持多語言，因為快手的業務特點，主要使用的語言有 Java 和 C ，還有少量業務會使用 Node.js、Python。第三，高可用、高可伸縮性。第四，快手的服務原來主要部署在物理機和虛擬機上，現在又增加了容器化部署平台，需要兼容所有的部署平台。

除此之外，還有幾個核心痛點，第一，服務治理平台自身的可用性要達到足夠高。第二，要支持跨數據中心的路由管理。第三，有狀態服務管理，這部分在大部分常見方案中支持不多，後面詳述。第四，複雜服務調用網路上的質量監控。

這是四個核心痛點，加上前面的四個基本要求，根據這些依據來做服務選型。

首先快手調研了一些開源的方案，看看是否可以做一些定製化的開發，這樣做的優點是有大量的業界經驗可以借鑒，可以少踩坑，前提是改造成本不能太高。

常見的開源方案有很多，為了方便比較，快手把常見的服務治理方案從需求出發做了一個簡單的分類。

第一類是簡單的基於分散式協調系統的方案，比如基於 Zookeeper 的臨時節點來做。這類方案缺點比較明顯，之前 Netflix 和阿里都有專題文章分析了這類方案的弊端，從 CAP 理論的觀點來講，配置中心和服務發現需要盡量高的可用性和分區容忍度，一致性要求相對較低，一般認為最終一致即可。這與 Zookeeper 的設計模型有一定的偏差。

第二類是服務發現和配置管理中心方案。比如國內很多公司使用的 Consul，以及今年阿里剛剛開源的 Nacos。

第三類是集成服務治理的單語言 RPC 框架，比如說 Spring Cloud，還有 Dubbo。

第四類是集成服務治理的多語言 RPC 框架，比如騰訊 2017 年開源的 Tars。

第五類是容器化的平台。Kubernetes 和 Istio。前者是大家比較熟悉的一個容器化管理平台。Istio 是基於 Kubernetes 的一個 service match 實現，今年 7 月剛剛發布了第一個正式版本。

這些方案，有的在基礎需求上有所欠缺，比如說不支持多語言或者缺少一些組件；還有一些在核心痛點上沒有足夠的支持。比如，服務治理平台本身的可用性，需要從底層做大量的改造，開發成本非常高。

經過調研，快手決定自研，自研除去解決基本需求和核心痛點之外，還有一個附帶的好處，能夠快速迭代，能夠在業務發展非常快的情況下，快速跟進業務提出的各種需求。

痛點分析和設計理念

下面分析一下四個核心痛點，它們從何而來的，自研的 KESS 平台又是如何解決這些問題的？

痛點一：服務治理平台自身的可用性。服務治理平台非常基礎，一些公司把它稱為元服務，即服務之服務，它的可用性決定了業務服務可用性的天花板。首先看一下 KESS 的多數據中心的架構。

快手有國際化業務，把相對獨立的國家和地區稱作 division。比如圖中 central division 是指國內的，另外還有韓國、印度等。在每一個 division 內部會有多個數據中心。其中有一個是主數據中心，其他的是從數據中心。KESS 負責從主數據中心到從數據中心的數據同步。主數據中心是全局配置唯一的可寫入端。一旦主數據中心發生了災難，可以將另一個可用的數據中心切換為主，在較短時間內恢復功能。這裡比較核心的一個高可用設計，在於它的配置分發部分。

上圖展示了主從兩個數據中心的情況。底層的存儲雖然使用了 ZK，但使用方式非常節制，僅僅把 ZK 當做一個小數據量的 KV 存儲，由上層來處理多個機房之間的數據同步。並且不依賴於 ZK 的通知機制，採用既推又拉的方式去同步數據。事實上，可以把 ZK 換成任何能夠滿足要求的存儲系統，包括 MySQL。

在底層的存儲之上，設計了一個配置同步協議，這個協議里定義了一個最小同步單元，其中所有配置項的修改是原子可見的，整體上滿足 BASE 原則，即基本可用，軟狀態，最終一致性。

Mandator 是每個數據中心的協調模塊，是主從熱備的，負責數據同步。每一個機器上還會運行一個 Agent，Agent 負責同步數據到本地的文件系統和共享內存中。SDK 定期掃描本地緩存，獲取數據更新。

這裡，第一解決了多數據中心數據同步的問題，第二實現多層的緩存以及持久化，第三，任何一個模塊如果出現了故障，有備用的模塊，如果沒有備用模塊，也有一個緩存，保證它的讀可用性。

在配置分發之上建設了服務發現機制，在設計中也包含了一些中間緩存來確保某些模塊暫時失效時，業務的無感知。

痛點二：跨數據中心的路由管理

對於多數據中心部署的服務，通常是需要就近訪問的，一方面能保證低延遲，另一方面也能減少專線故障對可用性的影響。但也有一些例外，比如說機器資源可能不均衡。在快手，因為業務規模擴張太快，經常出現某個數據中心機器資源緊張的情況。一些服務在特定數據中心沒有機器可以部署，就近訪問就會失敗。另外，在節假日，用戶訪問量通常會增長，需要提前估算流量安排機器擴容，但估算可能會不足。

再一個，下游業務可能會發生故障，這個時候需要把原來就近訪問的請求分發到其他可用的數據中心去。所以我們提供了這樣的功能，在正常的情況下都是就近訪問的，但是遇到突發情況，能夠快速把某個服務的流量按比例調度到其他數據中心去。

痛點三：有狀態服務管理

有狀態服務管理是較少提到的話題，因為它比較複雜，一般在業務架構設計中是要盡量避開的。為什麼快手需要有狀態服務，主要分為兩種情況，一是在特定的領域存在有狀態服務的開發需求，比如高並發的消息服務、推薦系統、多媒體數據理解等。二是業務服務無狀態，實際上是把狀態交給了分散式存儲。當業務規模不斷擴大的情況下，已有的分散式存儲方案可能不是特別適用，需要做定製化開發。

一個典型案例，快手的私信服務，可以理解為是一個 IM 服務。這個服務管理了用戶手機和快手服務之間的長連接。長連接就是一個狀態，長連接建立好之後還會有一個用戶會話數據，這也是狀態。一旦服務重啟，這些狀態就會丟失，用戶就會掉線，雖然可以在客戶端做一些 cover，但不是特別理想。

所以把這個狀態和業務邏輯做了解耦。一是把長連接的管理拆分為一個服務，它邏輯非常簡單，非常穩定，很長時間都不需要去更新它。二是把業務邏輯做成一個無狀態的模塊，它更新比較快，但是重啟也不會導致用戶掉線。三是開發了一個 Crux 服務存儲會話數據。它是持久化的，支持多地多活，能支撐千萬級的讀寫 QPS。為此我們犧牲了寫讀一致性，寫入之後可以容忍在十毫秒之內讀到即可。它是一個非常定製化的分散式存儲服務。Crux 服務目前支撐了主 APP 的私信服務，同時有千萬級用戶在線，1.5 億的日活。

對於 Crux 這樣的有狀態服務的開發，有一些共通的做法。首先要對這個數據做分片，讓它可以伸縮；然後需要主從多副本，能夠支持自動 Failover。還要支持平滑擴縮容。以及對於快手來講，一定要支持多數據中心。KESS 將這些業務無關的邏輯抽象為一個統一的有狀態服務管理模型：預分片、自動平衡以及狀態遷移，來幫助用戶簡化有狀態服務的開發。

痛點四：複雜服務網路的監控

在複雜服務調用網路上的質量監控，主要有如下一些需求：

服務依賴梳理，在做服務改造或者容量預估時，需要了解上下游的情況。

如何監控服務整體質量指標，而不是單機指標？

出了故障，怎麼定位？

為了解決這些問題，我們開發了 RPC Monitor 監控系統，它主要有以下幾個核心功能。

能夠實時的查看整體服務的可用性。

對可用性做多維的分析。比如除了實例維度之外，還要能夠對機房維度、錯誤類型維度、主被調的不同維度來做分析，幫助快速定位問題。

調用鏈分析。比如上圖是現實當中某一個服務上下游的情況，其中紅色的小點代表微服務，背後可能有成百上千的實例，線條代表調用關係，線條的顏色代表調用的成功率。

報警功能。上圖右側是一個手機報警頁面。從圖中我們可以看到成功率曲線的陡降很可能是跟 QPS 上漲有關。工程師也可以通過下面的圖表和鏈接去查看更多維度的信息來判定問題根源。

痛點分析和設計理念

KESS 的整體架構

上圖是 KESS 平台整體的架構。KESS 目前在快手得到了廣泛的應用。目前 KESS 上管理了幾千個微服務，幾萬台伺服器，在四個國家和地區都有部署，分布在十多個數據中心。

平台的整體可用性是 99.997%，之前發生過一次 Zookeeper BUG 導致的故障，寫可用性受到了影響。

跨數據中心的路由管理功能在快手內部每個月大概有一百多次的使用。RPC Monitor 每天會發出幾百個報警信息，發現並定位了後端工程方面幾乎 100% 的故障。

關於未來計劃

目前快手有更多的新語言開發者加入，需要服務平台繼續支持更多的編程語言。服務網格是業內比較關注的領域，它能有效地提高工程師的開發效率，目前我們也在探索其結合方式。再有，多數據中心給業務架構設計增加了很多複雜性，我們希望能在基礎平台的層面做更多的適配，簡化業務設計開發的負擔。

嘉賓介紹：

曹福祥，快手基礎平台架構師，快手服務治理平台技術負責人，快手技術培訓資深講師，擅長分散式系統、大數據、微服務框架等技術領域。曾經在網易、微軟、小米負責基礎架構相關工作。

企業組織架構調整，對於技術團隊和技術人有什麼正面和負面的影響？7 月 12 日深圳 ArchSummit 全球架構師峰會，將邀請業界專家來解答。此外其他專題涵蓋微服務、金融架構、數據處理、小程序、DDD 等專題。邀請 Apple、Google、阿里、百度等公司的技術專家來分享。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！