QQ瀏覽器信息流雲原生應用之路

背景

QQ 瀏覽器信息流（QB）推薦架構支撐了 QQ 瀏覽器、快報主 feeds 場景、浮層等信息流卡片實時推薦的能力，架構上不只僅要支持多業務、多產品，如 QB 、快報、外部合做等，並且須要可以快速支持各類類型場景的能力，如主 TL 、浮層，且可以快速擴展支持垂直頻道和 APP 。那麼信息流推薦架構須要作到靈活模塊化，水平易擴展。mysql

爲了作到海量級實時精準推薦，信息流推薦架構劃分爲了四層：展控層、排序層（精排/粗排）、召回層、索引層，並提供實時級用戶畫像模型打分模塊和特徵系統，進行實時的用戶/物品特徵累積，實時反饋給推薦鏈路進行千萬級索引文章/視頻的篩選和精準推薦。具體的架構模塊圖以下所示：git

能夠看到，推薦架構容納的模塊之多，支持的業務形式之多，並且須要支撐億級用戶規模和百億特徵規模，那麼須要更好的技術架構體系對於如此龐大的架構服務和存儲去進行開發、擴展、管理、維護等。redis

挑戰

挑戰一：實時性

（1）特徵實時更新sql

（2）模型在線實時學習數據庫

挑戰二：超大規模

（1）用戶量級：億級用戶編程

（2）特徵規模大：百億特徵、千億參數（無量）後端

（3）樣本龐大：精排樣本每日樣本近百TB瀏覽器

挑戰三：高性能

（1）全鏈路耗時達到業界領先水平。緩存

解決方案

雖然推薦系統模塊功能衆多，是一個較爲龐大系統，但咱們以微服務的方式對推薦系統進行拆分。把一個龐大的系統劃分爲成千上萬個微服務模塊，每一個微服務只負責相對獨立的功能，並以遠程 RPC 的接口方式提供服務，模塊之間能夠相互調用，從而造成了一個複雜的調用關係網，總體上就組成了一個龐大的推薦系統。微服務化之後，再結合雲原生的相關技術架構體系保證雲原生應用的穩定性，並提高資源的利用率和研發效率。安全

容器化

在雲計算 1.0 的時代裏，業界經過虛擬化的方式從硬件級分離應用程序，而容器的出現，標誌着雲計算 2.0 時代的到來，這個階段應用是經過容器化的手段從操做系統級別分離應用程序。

在容器化的時代中， Docker 的出現使得隔離的開發測試環境和持續集成環境成爲普遍實踐，而 K8s 則讓容器應用進入了大規模工業生產的時期。集羣也可以最大程度地發揮發揮容器的良好隔離、資源分配與編排管理的能力。容器化後給企業帶來的最大價值是人力和機器成本的節約。下圖則從穩定性、可擴展性、資源利用率三大維度上對比了虛擬化和容器化的區別。

雲原生時代

雲原生（Cloud Native）這個概念最先是由 Pivotal 公司的 Matt Stine 提出的。並隨着時間的推移，雲原生的概念也不斷在更新迭代，雲原生架構已經成爲互聯網行業的技術熱門，國內外各大廠都開始推動公司業務朝着雲原生的方向進行演變，並在很大程度上推進了 IT 成本的下降和企業的發展。

雲原生架構體系簡介

雲原生是一種技術架構體系和方法論，它包容了容器化、持續交付、 DevOps 和微服務等概念。容器化是微服務的最佳載體，持續交付可頻繁快速交付降低低質量風險， DevOps 將發佈部署自動化化，微服務則是核心地可被獨立部署、更新、 scale 和重啓。

CNCF 雲原生計算基金會，在 CNCF 全景圖中列舉了和雲原生相關的產品及服務的完整名單，這1381個項目共同構成了恢弘龐大的雲原生世界。整個全景圖按照功能分爲29個模塊，分別歸屬於9種大的類別

應用定義與開發（App Definition and Development）
編排與管理（Orchestration and Management）
運行時（Runtime）
配置（Provsioning）
平臺（Platform）
可觀察性與分析（Observability and Analysis）
無服務（Serverless）

（原圖連接：docimg7.docs.qq.com/image/0jAMP…

QB 雲原生架構體系

下圖爲 QB 信息流推薦架構的總體雲原生架構體系。 DevOps 承載了代碼/發佈/構建管理、流水線、自動部署、監控、CI/CD、集成測試等能力，測試平臺負責壓力測試/接口測試/集成測試/故障分析演練等職責，微服務框架經過服務發現/路由、負載均衡、動態配置等功能提供便捷有效而穩定的服務鏈路能力，雲平臺管理的 redis 、 mysql 、 mq 、 flink 等數據存儲維護了業務的數據統一安全的管理和備份，容器服務基於集羣/容器/鏡像/存儲管理提供無狀態可自動調節和平行擴展的能力，使得機器資源的利用率達到極優，而平常的鏈路排查和部署維護則經過配置/日誌管理和監控告警等串聯和及時響應。

在技術選型上， QB 信息流推薦架構在編排和管理上選擇了北極星和 trpc 框架，基礎配置管理上選擇了 rainbow 平臺，服務部署管理平臺選擇了123平臺，染色監控方面選擇了天機閣和007。

DevOps

QB 信息流推薦架構服務遷移至 trpc 框架和123平臺。123平臺是通用的研發和運營的開放式 DevOps 平臺，支持插件式擴展定製業務特性需求。經過123平臺可進行自動化服務部署和運維，合理分配服務容器資源配比充分提高資源池利用率，也經過不一樣服務部署環境（正式/測試等）的隔離，可以穩定安全地進行新版本部署和發佈。

在 CI/CD 上，選型了藍盾流水線嚴格規範了 git 提交的代碼風格/規範/質量/提交日誌規範等，並經過編譯構建和單測用例經過率/覆蓋率嚴格保障 MR 分支和默認主線分支代碼的可用性和穩定性，同時也經過構建流水線統一規範構建和鏡像發佈，從而保障在頻繁持續交付過程當中有較高的服務和代碼質量。

可觀測性和分析

龐大的業務技術架構下，因爲容納的業務服務模塊多且繁雜，鏈路之長，更不乏業務間合做的場景，故而一旦須要去把控服務鏈路的穩定性或者是追查問題時，缺少可觀測性的手段的狀況下將會變得複雜且費時費力。在可觀測性的組件上，咱們選擇的是天機閣。天機閣旨在解決上述的問題和難點：故障定位難、鏈路梳理難、性能分析難。它經過 Log 、 Trace 、 Metric 三個維度相輔相成地去給予多方位的監控和串聯。經過天機閣，咱們可快速地染色和排查定位鏈路問題，也能夠進行服務的流量分析和性能分析。

配置管理

服務配置管理平臺須要可以作到的是配置同步、版本管理、權限管理等幾個要素。基於上述理由，且trpc框架也支持了七彩石插件，故而咱們選型的是七彩石 rainbow 做爲服務配置的管理平臺。

雲原生應用

傳統應用 VS 雲原生應用概述

傳統應用和雲原生應用有什麼區別？主要體如今幾個方面：研發模式、架構設計、部署方式、運維方式。在部署、運維方式上，雲原生應用都是自動化的。

傳統應用

傳統應用通常擁有較長的生命週期，並常常被構建成緊密耦合的單體式應用。它們符合定義時制定的的相關規範，可是這些規範制定的時間一般遠早於應用的交付時間。業務運營所需的不少基礎性應用在設計時都不曾考慮提供數字化體驗。

傳統應用的開發方案大部分都屬於瀑布式和漸進式，不只時間跨度長，並且直到近期才實現了半敏捷性。應用歷經開發、測試、安全合規監管、部署和管理階段，這些階段被分隔成了不一樣的功能領域，每一個領域都由不一樣的團隊負責、發揮着不一樣的做用、肩負着不一樣的職責，且各方間均經過線性流程來溝通。

對於大多數傳統應用來講，基礎架構會針對應用所需的峯值容量預先進行置備；還會經過縱向擴展來提升服務器的硬件的相關性能。

雲原生應用

因爲雲原生應用很是注重研發與交付的效率，信息流業務對此也有着迫切的需求。所以，在開發時須要實施更加敏捷且基於服務和 API 的方案和持續交付策略。開發時從針對服務器的眼光轉爲以容器爲中心的模式。開發方案從單一緊密的應用，轉變成鬆散耦合的服務形式，更增強調應用間接口的通訊。服務交付週期一般變的更短，須要持續地迭代交付。而這些方案可否成功實施又取決於如下幾點：開發和交付團隊間的 DevOps 協做；模塊化程度更高的架構；可以按需橫向擴展、支持多種環境並實現應用可移植性的靈活基礎架構。

雲原生應用開發範式

既然雲原生應用有諸多的好處，那咱們在開發雲原生應用須要關注那些點呢？如下會從微服務、名字服務、數據管理、配置管理和日誌管理五方面進行介紹。

微服務

微服務架構是以一組小型服務的方式來開發一個獨立的應用系統，每一個服務都以一個獨立進程的方式運行，每一個服務與其餘服務使用輕量級通訊機制。這些服務是圍繞業務功能構建的，能夠經過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理能力，也能夠採用不一樣的編程語言和數據庫，實現去中心化的服務管理。微服務的關鍵詞：加速交付準備，高度可擴展，出色的彈性，易於部署，易於訪問，更加開放。

爲何要切換成微服務的架構設計？信息流傳統的推薦架構，是以服務器爲核心而搭建的。傳統架構中，精排、粗排、展控等模塊部署在同一物理機，這樣就會面臨着可能物理機器掛了，致使相關的系統整個不可用。運維過程針對單機性能不足的狀況，只能運維同窗手動對單機容量進行調整。微服務強調的是低耦合+高內聚特性。經過將信息流業務的切分紅一個個完整、獨立的微服務，每一個服務能夠做爲獨立組件升級、灰度或複用等，對整個大應用的影響也較小，每一個服務能夠由專門的組織來單獨完成，依賴方只要定好輸入和輸出口便可徹底開發，甚至整個團隊的組織架構也會更精簡，所以溝通成本低、效率高。

業務實際在遷微服務過程當中，遇到的問題和思惟的轉變：

版本管理以及一份基準代碼，多份部署

信息流業務歷史存量代碼與資源存放於集中式版本控制 svn 上單一路徑管理，中央服務器沒有作備份的狀況下，可能出現數據丟失的情形。爲了應對以後遷移微服務和多人協做開發的大勢。引入了 git 版本控制工具，提升了並行開發的生產效率。每個服務共享一份基準代碼，可是能夠存在多份部署。一般會將服務的不一樣版本分別部署在123平臺提供的不一樣發佈環境，以期測試驗證和灰度驗證的效果。

編譯、發佈系統

採用分佈式編譯系統加速對源碼的編譯。123服務運營平臺支持各個團隊自定義各自的編譯、運行鏡像，知足各類豐富的自定義化需求。同時能夠記錄編譯及發佈的相關歷史，達到隨時能夠追溯各個歷史版本的效果。

顯式聲明依賴關係以及依賴管理

將業務中的單體應用切分紅了各個微服務。維護服務間編譯的依賴關係，保證服務依賴關係清晰就成了重中之重。業務首先將應用，按照功能與模塊劃分紅粒度更爲細緻的微服務，而且劃分到不一樣 git 倉庫管理。在服務鬆耦合的基礎上，引入了模塊依賴管理工具，如 bazel 、 maven 、 go modules 等。經過先進的生產力工具，構造更爲清晰的依賴關係，也解決了歷史應用各類協議版本不一致引起的各類問題。

進程與併發性

開發、運維同窗將思惟轉化爲進程模型來設計應用架構。分配任務給不一樣的進程類型，如服務中的 Web 、 Worker 進程。考慮將進程設計成無狀態，無共享的模式。應用就能夠經過複製其進程來擴容。構造無狀態應用還讓進程可在不一樣的計算基礎架構之間移植。設計思惟逐漸向分佈式靠攏，這樣在整個系統急需水平擴展時，能夠添加更多進程解決燃眉之急。

名字服務

服務發現的概念是隨着計算機體系結構的發展而演變的概念。網絡時代初期，不一樣的計算機須要相互定位，這是經過一個全球文本文件 HOSTS.TXT 完成的。由於不常常添加新主機，因此手動維護文件的地址列表。隨着互聯網的發展，主機的增長速度愈來愈快，須要一個自動化，可擴展性的更強系統，從而致使了 DNS 的發明和普遍採用。

服務發現通常是由三個模塊組成，主控、客戶端、服務端，其中服務端會把當前的結點信息註冊到主控，當客戶端須要調用服務端時，則從主控獲取到服務端的結點信息或者從已經緩存的數據中拿到服務端的信息，而後進行調用，其關係以下圖所示：

如今，微服務架構正在推進服務發現的不斷髮展。隨着容器化平臺或雲平臺的不斷普及，基於平臺的微服務架構部署，服務的生命週期以秒和分鐘來衡量。同時，由於微服務的自動擴展、故障和發佈升級，致使微服務具備動態變化的地址列表，微服務的靈活性再次推進了服務發現技術的發展。如今基於容器化平臺或雲平臺的微服務應用程序，須要解決服務地址動態變化的問題。騰訊內部也提供了衆多優秀的平臺和組件以供選擇，如 cl5 / l5 /北極星（ Polaris ）等。如下是傳統應用和雲原生引用在名字服務上的異同：

業務實際在切換名字服務過程當中，遇到的問題和思惟的轉變：

端口綁定

在非雲環境中，一般將 Web 應用編寫爲在應用容器中運行。相比之下，雲原生應用不依賴於外部應用容器。相反，它們會將 Web 服務器庫打包爲應用自己的一部分。互聯網應用能夠經過端口綁定來提供服務並隨時監聽全部發送至該端口的請求。123平臺上接入的服務，會自動對接北極星名字服務。123平臺中的每個服務，都會被北極星經過該服務名能夠解析出具體的實例（表明一個 ip port 以及相關配置信息）。在服務下線或者變動時，採用名字服務的方式，每每能減小不少人力成本。

數據管理

互聯網業務也包括信息流業務，由於數據的量級以及對存取速度要求的不一樣，免不了使用各式各樣的存儲系統。隨着雲原生的推廣，傳統的數據管理方式也在逐步向雲存儲轉變。以常見的 NoSql 組件 redis ，以及關係型數據庫 mysql 爲例，也經歷了單機本地存儲，集羣存儲以及上雲的變遷。

相對於傳統數據管理方式，雲原生數據管理有如下幾個特色：

分佈式

用戶的存儲分佈在多臺機器上，完全擺脫單機容量和資源限制。

高可用性

每一個實例均提供主從熱備，宕機自動監測，自動容災。

高可靠性

數據持久化存儲，可提供冷備和自助回檔。

彈性擴容

集羣版存儲每每支持單實例無上限擴容。在擴容過程當中不中斷服務，真正作到用戶無感知。

完善的監控

能提供完整的運營系統，主要包括實時流量、特性的監控以及告警。實時監控各項組件指標，針對閾值配置告警。

如下是分佈式存儲的監控圖

配置管理

信息流業務的推薦系統被劃分爲成千上萬個微服務模塊，其中每一個服務在123運營平臺上又被部署到多個環境中。傳統文件配置管理的方式，存在着比較大的侷限性，雲原生的配置管理系統應運而生。

業務實際在切換配置管理系統過程當中，遇到的問題和思惟的轉變：

在環境中存儲配置

信息流業務使用七彩石 rainbow 系統做爲配置管理核心系統。在123平臺中，七彩石以插件化的形式存在。業務的配置在不一樣環境下（如預發佈、正式環境）仍是有差距的，七彩石以及123平臺能夠針對環境作不一樣隔離，能夠知足業務的需求。

環境等價

不一樣環境的配置會存在差別，而應用要想作到持續部署，保證系統穩定，就得作到配置文件間差別儘量少。從信息流業務自身出發，經過引入 DevOps ，縮短部署上線的時間，作到儘量由開發的同窗來修改配置文件，這樣的舉措是值得的。

日誌管理

傳統的日誌管理形式，日誌以存儲在 Web Server 本地文件形式而存在，單機存儲日誌文件存在單機容量的侷限。業務開發及運維同窗，須要分析數據時，每每只能登陸到特定機器才能看到特定的日誌。不能總覽事件觸發的鏈路，及其餘相關模塊的日誌。

在雲原生的日誌管理流程下，服務的日誌應該是事件流的彙總。日誌採集系統將全部運行中進程和後端服務的輸出流按照時間順序收集起來。日誌是以流水的形式追加到所屬的日誌文件後，開發及運維能夠實時在終端跟蹤標準輸出流的狀況。再輔以日誌採集跟蹤組件，便可完整地追蹤事件發生流程相關模塊產生的染色日誌。信息流業務目前是經過鷹眼日誌系統，來分析業務生命週期中的各類可能遇到的問題。

業務實際在切換日誌系統過程當中，遇到的問題和思惟的轉變：

集中式遠程日誌中心
集中收集，統一管理
方便快捷的日誌分析能力

資源利用率優化

業務使用了 Docker 、 K8s 等技術後，從理論上來講能夠有效地提高資源利用率，但在複雜的業務架構下，微服務數量膨脹，大部分業務應用仍是存在資源利用率低的問題，究其緣由主要是工具平臺不夠完善、業務的獨有資源使用方式不一樣，那如何提高資源的利用率是雲原生架構體系的一個重要命題。

資源浪費場景

考慮到資源浪費，首先咱們來分析下業務中常見的資源使用方式，從這些場景中能夠找到一些優化的方向。

索取大於使用

業務應用在實際的使用過程當中，存在資源預留大量浪費的問題，好比服務實際運行須要1核 CPU ，服務負責人對應用使用的內存沒有估算到位，爲了讓應用能穩定地運行，服務負責人會申請過多資源，好比4核 CPU ，避免後面服務在運行的過程當中出現問題。這勢必會形成較大的資源浪費。以下圖所示，CPU 使用率只有1%-1.5%左右。

波峯波谷現象

大多數業務存在波峯波谷現象，好比咱們的業務中，中午餐後、晚上睡前的時間段存在一個波峯，這段時間用戶有跟多的空閒時間來消費信息流。而凌晨時間用戶在休息，則出現了波谷。以下圖所示，晚上10-11點左右出現了一個波峯。

應用資源使用差別

不一樣的業務應用在不一樣的時段使用的資源存在較大的差別，在信息流業務中較爲明顯，在線業務白天負載較高，對時延也要求較高，而離線計算業務在凌晨負載較高，對時延要求相對較低。

優化方案

針對以上提到的資源浪費場景，咱們能夠採用手動、自動的方式進行資源利用率調優，好比針對索取大於使用的場景能夠採用手動的方式進行調優，把多申請的資源從新按照真實的使用狀況進行縮容，但這種操做方式很大程度上依賴開發的能力和意願，在實際的操做過程當中難以落地，因此須要採用自動的方式進行優化，儘量少地依賴開發者。自動的方式有如下幾種：

根據 HPA 、 CA 等參數彈性伸縮
調度， K8s 提供資源分配機制，自動找到合適的節點
在線、離線業務混合部署

這些自動的能力在TKE上都支持，詳細操做能夠查閱TKE的相關文檔。

監控

雖然自動的擴容、縮容能力能有效地調度資源，使得資源的利用率有所提高，但對於整個業務的資源使用狀況還須要有相應的監控，如下是咱們業務部分的監控模塊，經過這些監控數據能夠快速找出優化的方向。

總體資源概況

業務應用擴縮容閾值

模塊資源利用率排行榜

後記

雲原生架構體系是一個龐大的技術體系，在各個技術方向上都有相關研究或成熟組件，公司也有 Oteam 在相關領域進行共建，做爲業務更多的是須要藉助平臺、 Oteam 的能力進行整合，站在巨人的肩膀上才能飛得更高。最後感謝公司在雲原生各個技術領域上作出貢獻的團隊和我的。

參考文檔

雲原生應用之路：www.sohu.com/a/211846555…

12-factors：12factor.net/zh_cn/