如今快手有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監控系統，它主要有以下幾個核心功能。

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

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

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

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

KESS平臺應用現狀和未來的計劃

KESS的整體架構

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

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

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

關于未來計劃

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

嘉賓介紹：

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

總結

以上是生活随笔為你收集整理的快手服务治理平台KESS的设计理念和实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。