【51CTO.com原創(chuàng)稿件】本文從具體的項目實例出發(fā)和大家討論如何從無到有地去搭建一個能夠快速伸縮的微服務(wù)架構(gòu)。

2017 年 12 月 1 日-2 日，由 51CTO 主辦的 WOTD 全球軟件開發(fā)技術(shù)峰會在深圳中州萬豪酒店隆重舉行。

本次峰會以軟件開發(fā)為主題，新浪微博研發(fā)中心平臺高級系統(tǒng)研發(fā)工程師溫情在微服務(wù)與容器技術(shù)專場帶來了主題為“基于 Docker 的微博直播互動微服務(wù)架構(gòu)”的精彩演講。

本文將圍繞以下主題，探討直播互動的微服務(wù)架構(gòu)設(shè)計：

• 針對現(xiàn)在非?；馃岬闹辈鼍埃绾卧O(shè)計一個穩(wěn)定的消息互動系統(tǒng)，以支持***消息的互動分發(fā)。
• 在服務(wù)越來越復(fù)雜的情況下，如何對系統(tǒng)進(jìn)行合理地組件化拆分，進(jìn)而實現(xiàn)以微服務(wù)的方式進(jìn)行獨(dú)立部署和升級。
• 在混合云的體系下，如何充分利用 Docker 技術(shù)和公有云的彈性特性，設(shè)計一個基于混合云的彈性化的架構(gòu)，以實現(xiàn)在流量突增且無人看守的情況下，自動完成服務(wù)的彈性伸縮。

微博直播互動平臺的背景與挑戰(zhàn)

2017 年可謂直播大年，新浪微博在自己的 App 推出了直播服務(wù)，同時也打通了與淘寶、一直播、紅豆等平臺的互動。

從技術(shù)上說，直播一般分為兩個部分：

• 視頻流，包括流媒體的傳輸部分。
• 直播互動，包括評論、點(diǎn)贊、送禮等其他部分。

直播的特點(diǎn)是：由于房間里人數(shù)眾多，直播平臺需要能夠支持百萬用戶同時在線的場景。

微博直播平臺特點(diǎn)

直播互動系統(tǒng)的基本模型是一個消息轉(zhuǎn)發(fā)的系統(tǒng)，即某個用戶發(fā)送一條消息，其他用戶收到該消息，并執(zhí)行相應(yīng)的存儲。

消息系統(tǒng)一般具備三個基本的評判標(biāo)準(zhǔn)：實時性、可靠性、和一致性。對于直播這種消息系統(tǒng)而言，它對于可靠性和一致性的要求并不高，而對實時性的要求卻非常高。

如果用戶給主播送完禮物 10 秒鐘或者 1 分鐘之后，主播才能收到并回復(fù)。這是不可接受的。因此我們需要具有“秒級”的實時性。

微博直播互動的特點(diǎn)：

• 平時的流量不太大，但是當(dāng)訪問多的時候流量會產(chǎn)生明顯的猛增。
• 流量的激增表現(xiàn)在消息推送量的巨大。一般可以達(dá)到每秒千萬條消息推送。
• 對于一般短連接的請求而言，用戶為了進(jìn)入界面僅發(fā)送一次請求，后續(xù)通常不再產(chǎn)生其他操作，因此服務(wù)器端的壓力不太大。

而直播互動場景則不同，在用戶加入房間之后，就算不做任何操作，也會收到一大堆的推送。這種實時性高的推送方式會給服務(wù)器造成持續(xù)的壓力。

微博直播平臺面臨的挑戰(zhàn)

由于用戶對直播的需求量大，且玩法多樣，我們面臨了來自三個方面的挑戰(zhàn)：

• 如何快速迭代并快速地響應(yīng)需求，這是對業(yè)務(wù)以及系統(tǒng)的衡量標(biāo)準(zhǔn)。
• 如何應(yīng)對全量 Push 所引發(fā)的流量峰值。
• 如何實現(xiàn)成本***化，即如何運(yùn)用有限的資源應(yīng)對波峰波谷的交替。

微博直播互動平臺微服務(wù)架構(gòu)演進(jìn)

針對上述三大挑戰(zhàn)，我們自己搭建了直播互動的微服務(wù)架構(gòu)。上圖是直播互動的架構(gòu)圖，我們對業(yè)務(wù)層進(jìn)行了模塊化的劃分，包括發(fā)現(xiàn)服務(wù)、三方平臺服務(wù)、推送服務(wù)等各種微服務(wù)。

架構(gòu)選型

在架構(gòu)選型方面，我們先來看傳統(tǒng)的單體模式。單體適用于許多場景，特別適合于敏捷開發(fā)。

由于微博互動的流量龐大，且系統(tǒng)相對復(fù)雜，因此會面臨如下問題：

• 上線成本高，迭代速度慢。單體模式是將所有的服務(wù)集中在一塊兒，實現(xiàn)一起部署和一起上/下線。因此任何一次細(xì)微的改動，都需要我們重新“上線”。
• 而為了掃清可能出現(xiàn)的服務(wù)問題，我們一般會進(jìn)行全量回歸測試。可見這種緩慢的迭代速度是我們所無法接受的。
• 可伸縮性差。在服務(wù)進(jìn)行水平擴(kuò)展時，隨著服務(wù)增多，Redis 和 DB 的連接數(shù)也會逐步增多，而每個資源都有一定的連接數(shù)瓶頸，當(dāng)服務(wù)增長到一定數(shù)量之后，則會導(dǎo)致服務(wù)無法進(jìn)一步地水平擴(kuò)展。

魯棒性差。系統(tǒng)中任何一處的 Bug，都會導(dǎo)致其他的服務(wù)，甚至是整個服務(wù)的癱瘓。

而微服務(wù)與單體之間的區(qū)別在于：微服務(wù)會將一些共同功能予以拆分，并且在拆分的基礎(chǔ)上，每個模塊都能維護(hù)自己的 DB 與資源。

因此微服務(wù)的好處體現(xiàn)在：

• 每個服務(wù)都被獨(dú)立地開發(fā)和部署，迭代速度明顯提高。我們不必測試全部，只需測試自己所開發(fā)的服務(wù)便可。
• 單個服務(wù)所依賴的資源變少，且擴(kuò)容的速度明顯提高。特別是對于一些輕量級的服務(wù)，我們能夠保證在 30～40 秒內(nèi)，完成擴(kuò)容并啟動。
• 通過 RDC 或者相關(guān)的調(diào)用，移除一些推送服務(wù)對于 DB 和 Redis 的直接依賴，從而解決連接數(shù)的問題。
• 將各個服務(wù)獨(dú)立進(jìn)行部署，從而避免了那些無關(guān)聯(lián)的服務(wù)問題所引起的整體宕機(jī)，將 Bug 限定在單個模塊中。

微服務(wù)化難題

微服務(wù)的引入也帶來一些新的問題：

• 以前在單體模式中，我們將各個模塊雜糅在一起，不必詳細(xì)考慮。如今采用微服務(wù)了，應(yīng)當(dāng)如何進(jìn)行合理的拆分呢？
• 以前只是本地調(diào)用，現(xiàn)在改成了微服務(wù)，它們將如何通信？如何考慮網(wǎng)絡(luò)開銷呢？
• 在服務(wù)部署之后，微服務(wù)如何去發(fā)現(xiàn)問題呢？

難題一：服務(wù)拆分

對于微服務(wù)的拆分，大家最為關(guān)心的問題是拆分的力度。我們采取了如下簡單的方式，大家可以在自己的項目中稍做借鑒：

• 不知如何拆分時，可“一刀兩斷”地直接拆分成核心和非核心服務(wù)。其好處是對服務(wù)做到相應(yīng)的隔離。

例如：在服務(wù)器不夠用時，我們只保護(hù)核心的服務(wù)，而非核心服務(wù)不會影響到核心服務(wù)。因此是一種根據(jù)業(yè)務(wù)重要性的拆分方式。

• 服務(wù)治理，可以隨時對非核心服務(wù)予以降級。我們讓有限的機(jī)器資源去支撐核心的服務(wù)。

完成了基礎(chǔ)拆分之后，我們就可以根據(jù)業(yè)務(wù)場景對核心服務(wù)進(jìn)行進(jìn)一步的拆分：

• 針對 Short Service，我們有一個叫做 Wesync 的私有協(xié)議解析。由于我們平時并不會修改其代碼，而且該協(xié)議的解析具有通用性，因此我們將其拆分出來單獨(dú)進(jìn)行部署。
• 我們將所有與業(yè)務(wù)相關(guān)的服務(wù)，如房間和消息等，全部放置在一個叫 Biz Service 的服務(wù)中進(jìn)行部署。這一部分的代碼量會非常大，但是代碼量并非服務(wù)是否拆分的衡量標(biāo)準(zhǔn)，由于其處理復(fù)雜業(yè)務(wù)的壓力并不大，因此可以將它們歸納到一起。
• 將 Push Service 這一推送服務(wù)進(jìn)行拆分，它可以維護(hù)與用戶之間的長連關(guān)系，從而保證消息推送的實時性。另外服務(wù)端“推”的方式會比用戶端“拉”的方式更具有實時性。

我們對于 Push Service 進(jìn)行拆分的原因在于：

• 由于消息的推送量巨大，Push Service 成為了整個服務(wù)的瓶頸點(diǎn)。假想在一個 10 萬人的房間中，如果 1 秒內(nèi)有 10 個人群發(fā)了消息到客戶端上，那么系統(tǒng)會產(chǎn)生 100 萬條每秒的推送量。

同理，如果房間里有 100 萬人，則會產(chǎn)生 1000 萬的推送量。可見該消息量的量級是非常大的，因此 Push Service 是我們需要頻繁擴(kuò)容的服務(wù)。

• 我們在設(shè)計時會希望 Push Service 盡量簡單，并讓它對資源減少依賴。

我們簡單地從業(yè)務(wù)角度對非核心服務(wù)進(jìn)行了如下拆分：

• Barrage Service：包括直播回訪功能和獲取歷史消息。
• Third Service：與三方平臺的接入服務(wù)。

我們來看 Barrage Service 的拆分原因：由于該服務(wù)是一種用來批量獲取歷史消息的對外暴露式服務(wù)，那么批量地獲取歷史消息必然會帶來大量的帶寬消耗。

因此，我們需要采取如下的優(yōu)化方式：

• 我們采用 Gzip 的壓縮技術(shù)對接口和返回的數(shù)據(jù)進(jìn)行壓縮，從而減緩對于帶寬的消耗。
• 充分利用 CPU 和其他硬件的性能。
• 增加多層緩存的策略，我們可以直接在本地 load，而不必去 DB 或 message cache 里 load，因此減少了與外界的交互。

如上圖所示，我們在進(jìn)行微服務(wù)化拆分之前，各個服務(wù)被雜亂無章地雜糅在一起，我們不得不一起部署。因此，我們根據(jù)各種策略，按照上述方法進(jìn)行了服務(wù)的拆分。

難題二：服務(wù)通信

同時我們也從同步與異步的角度，對服務(wù)之間的通信進(jìn)行了拆分：

• 同步操作：REST 的 API 方式+RPC 方式。
• 異步操作：主要圍繞的是消息隊列。

對于核心服務(wù)和非核心之間的通信交互，我們進(jìn)行了場景分析。如上圖所示，第三方服務(wù)（Third Service）包含兩個方面：

• 藍(lán)線部分表示第三方服務(wù)器推送（Push）消息到我們的系統(tǒng)。由于我們希望第三方來的消息能夠更為實時地（同步）展現(xiàn)到我們 App 的前端，因此采用的是 RPC 類型的 Push 方式。
• 紅線部分表示我們從微博 App 產(chǎn)生消息，然后對外傳遞給第三方服務(wù)器，讓他們以 Pull 的方式來獲取消息。由于我們不希望其他的服務(wù)、后面的服務(wù)、以及非核心服務(wù)影響到我們的核心服務(wù)功能，因此我們實現(xiàn)的是異步解耦，即采用 Queue 類型的 Pull 方式。

對于 Barrage Service，我們采取的是共享數(shù)據(jù)庫的方式。由于批量獲取回放消息是一項大量消息帶寬的服務(wù)，因此我們共用一個數(shù)據(jù)庫，通過直接從庫里 load，以保證系統(tǒng)資源的提供。

難題三：服務(wù)發(fā)現(xiàn)

對于 Push Service 類型的服務(wù)發(fā)現(xiàn)，我們棄用了以前掛在 DNS 處讓 DNS 做服務(wù)發(fā)現(xiàn)的方式，而是采用了自己寫的 Dispatch Service。

它的運(yùn)作機(jī)制是：

• 為了在用戶加入房間之前建立一個長連的過程，我們發(fā)送一個 Dispatch 與 Push Service 建立相應(yīng)的連接。一旦有消息產(chǎn)生，則通過 Push Service 進(jìn)行推送。
• Dispatch Service 可以動態(tài)地去根據(jù)用戶所屬的服務(wù)器和區(qū)域，按照策略就近做出相應(yīng)的選擇。
• 該策略可以支持 Push Service 的水平擴(kuò)容。即在擴(kuò)容之后，我們不再給老的 Push Service 推送流量，也不再返回相應(yīng)的 IP，而是把全部流量導(dǎo)入新的 Push Service。

而對于 RPC 類型的服務(wù)發(fā)現(xiàn)，我們采用典型的 SOA 架構(gòu)，包括：Registry 提供可用服務(wù)列表、Server 提供服務(wù)、Client 發(fā)現(xiàn)并使用服務(wù)。因此，我們采用的是 Motan RPC，以快速地響應(yīng)各種需求并完成發(fā)現(xiàn)。

微服務(wù)化總結(jié)

總結(jié)起來，微服務(wù)解決了如下四方面的問題：

• 獨(dú)立開發(fā)測試，加快了迭代的速度。
• 通過服務(wù)拆分，減少了無關(guān)聯(lián)服務(wù)之間的影響。
• 通過減少對資源的依賴，提高了服務(wù)擴(kuò)展的速度。
• 當(dāng)然也增加了服務(wù)的部署和運(yùn)維的難度。

既然采用了快速擴(kuò)容的框架，那么我們就需要運(yùn)維同學(xué)的參與和部署。下面來討論直播互動的彈性擴(kuò)縮容策略。

微博直播互動平臺的彈性擴(kuò)縮容

基于 Docker 的混合云架構(gòu)

由于對微博的使用是一個典型的流量激增場景，因此如果采用盲目購置服務(wù)器這一傳統(tǒng)的應(yīng)對方案的話，會造成整體負(fù)載飽和度的不均衡。

例如，大家一般在白天和半夜都不會去“刷微博”，服務(wù)器和網(wǎng)絡(luò)的利用率會比較低。只有在晚高峰出現(xiàn)時才會有爆炸式負(fù)載的產(chǎn)生。

因此我們采用了快速彈性擴(kuò)縮容的應(yīng)對策略，即利用公有云端的各種快速彈性伸縮的資源服務(wù)。

但是，由于之前的私有云環(huán)境是在我們自己完全掌控的范圍內(nèi)，而如今引入的公有云則帶來了環(huán)境上的差異性問題。于是我們參考業(yè)界的普遍方案，采用了 Docker。

Docker 的網(wǎng)絡(luò)模型選擇一般有 Bridge、Container 和 Host 等實現(xiàn)方式：

• 我們起初在測試環(huán)境中采用了 Docker 的默認(rèn)設(shè)置 Bridge 模式。
• Docker 在通過 Daemon 啟動時會有一個 Docker0 的虛擬以太網(wǎng)橋。
• Docker 的 Daemon 運(yùn)用 veth pair 技術(shù)進(jìn)行虛擬化，即在容器內(nèi)與宿主機(jī)之間建立虛擬網(wǎng)卡連接，而在容器外進(jìn)行相應(yīng)的消息轉(zhuǎn)發(fā)。
• 存在的問題：由于容器內(nèi)使用的是虛擬 IP 地址，我們就使用該虛擬 IP 注冊了 RPC 服務(wù)。但是在啟動之后，Client 端卻出現(xiàn)無法真正訪問到該虛擬IP。

因此我們采用了 Host 模式，即：

在 Host 模式下的同一個 eth0 可以被共用，因此各方能夠共享宿主機(jī)的網(wǎng)絡(luò)命名空間。

同時由于它省去了各種路由的開銷，因此會比 Bridge 模式更快。

可見，Docker 的優(yōu)點(diǎn)在于簡單輕便，非常適用于微博的應(yīng)用場景。另外，再加上公有云端的一些資源，共同構(gòu)成了基于 Docker 的混合云架構(gòu)，我們稱為 DockerDCP。

值得一提的是 DCP 已經(jīng)開源了，在 GitHub 上有一張 Open DCP 的服務(wù)圖，大家可以去搜索一下。

DCP 的作用是能夠在 10 分鐘之內(nèi)擴(kuò)容并部署 1000 臺機(jī)器，以應(yīng)對諸如“三大節(jié)日”的流量猛增。

因此，它每天都會有著 6000 億次 API 的調(diào)用，以及萬億次的 RPC 調(diào)用。

為了讓直播互動與 DCP 實現(xiàn)相關(guān)的自動化運(yùn)維部署與擴(kuò)縮容，我們每次都會將消息推送至 SLB（負(fù)載均衡），通過 Push Service 的推送服務(wù)來實現(xiàn)跨網(wǎng)服務(wù)的部署。

要想實現(xiàn)擴(kuò)容首先要獲知設(shè)備的來源。DCP 能夠幫助我們區(qū)分內(nèi)網(wǎng)和外網(wǎng)（公有云）不同的機(jī)器。

例如：內(nèi)網(wǎng)的三個業(yè)務(wù)方— A、B、C 都有自己的多臺服務(wù)器，而我們將它們設(shè)置為一個“共享池”。

業(yè)務(wù) C 會因為峰值流量而申請池中的 3 臺服務(wù)器，而在業(yè)務(wù)空閑時則將資源歸還到池中。如此，我們可以自由地在私有云和共有云上實現(xiàn)快速擴(kuò)容，即為“雙云擴(kuò)”。

自動化擴(kuò)縮容流程

我們直播互動的自動化擴(kuò)縮容流程大致分為：

• 制定監(jiān)控的指標(biāo)，即設(shè)定達(dá)到何種監(jiān)控指標(biāo)的閾值，才開始擴(kuò)容操作。一般是通過壓力測試來獲取到。
• 監(jiān)控指標(biāo)的采集，包括如何進(jìn)行采集，以及采集哪些指標(biāo)。
• 數(shù)據(jù)流轉(zhuǎn)到容量決策系統(tǒng)，以決定是否進(jìn)行擴(kuò)容。
• 一系列服務(wù)擴(kuò)容的標(biāo)準(zhǔn)流程，如上圖所示。

而縮容的流程與上述擴(kuò)容流程較為類似，在此就不贅述了。

對于上述提到的監(jiān)控指標(biāo)，我們分為兩大類：

• 業(yè)務(wù)性能指標(biāo)，不同的業(yè)務(wù)之間會存在著差異，有的 API 服務(wù)能夠支撐 1000 個 QPS(Query Per Second)，而有的卻只能支撐 200 個。因此根據(jù)業(yè)務(wù)的不同，我們所采集和監(jiān)控的性能指標(biāo)也不盡相同。
• 機(jī)器性能指標(biāo)，側(cè)重的是通用化的機(jī)器性能指標(biāo)，包括帶寬、PPS、CPU、性能、IOPS 等。只要發(fā)現(xiàn)哪一塊出現(xiàn)了瓶頸，就應(yīng)當(dāng)去盡快擴(kuò)容。

相對應(yīng)地，指定監(jiān)控指標(biāo)的流程為：對性能系統(tǒng)進(jìn)行相應(yīng)的壓力測試>發(fā)現(xiàn)服務(wù)的瓶頸點(diǎn)>對瓶頸點(diǎn)進(jìn)行分析>制定監(jiān)控的指標(biāo)。

如今我們也正在嘗試著通過機(jī)器學(xué)習(xí)來實現(xiàn)自動化監(jiān)控。我們一般會每周或是定時對各種服務(wù)進(jìn)行壓力測試，以及時地去發(fā)現(xiàn)服務(wù)的瓶頸。

由于新引入的機(jī)器可能會導(dǎo)致整體性能的不一致，而且隨著服務(wù)需求和代碼量的增多，整體服務(wù)的瓶頸點(diǎn)也可能會相應(yīng)地遷移到其他地方，因此我們通過進(jìn)化版的壓力測試，實現(xiàn)了對瓶頸點(diǎn)的實時把握。

就 Push Service 的指標(biāo)監(jiān)控而言，我們在壓力測試時所監(jiān)控的業(yè)務(wù)性能包括：

• 用戶數(shù)據(jù)的長連數(shù)。因為單臺機(jī)器可能會撐起幾千個用戶長連數(shù)。
• 消息推送量。在某些的業(yè)務(wù)場景中，可能長連數(shù)并不多，但是其消息推送量卻非常大。因此我們需要從不同的維度實施監(jiān)控。

而對于機(jī)器性能的指標(biāo)，同樣會包括帶寬、PPS、CPU、內(nèi)存、IOPS 等。

就監(jiān)控指標(biāo)的采集而言，我們分為兩個方面：

• 業(yè)務(wù)的性能指標(biāo)是由各個業(yè)務(wù)系統(tǒng)負(fù)責(zé)相應(yīng)的采集。
• 機(jī)器的性能指標(biāo)是由運(yùn)維監(jiān)控服務(wù)執(zhí)行統(tǒng)一的采集。

彈性擴(kuò)縮容總結(jié)

總結(jié)起來，我們在彈性擴(kuò)縮容方面實現(xiàn)了如下三點(diǎn)：

• 通過容器技術(shù) Docker 化的服務(wù)解決了環(huán)境差異性問題。既實現(xiàn)了更快速擴(kuò)縮容，又讓整個虛擬化更為標(biāo)準(zhǔn)。
• 通過混合云架構(gòu) DCP 解決了資源彈性伸縮的問題。
• 在架構(gòu)搭建之后，通過自動化擴(kuò)縮容實現(xiàn)了直播無人看守的場景。

典型案例分享

下面是在實現(xiàn)擴(kuò)縮容架構(gòu)之前與之后的兩個直播案例的對比。

未實現(xiàn)自動化擴(kuò)縮容時，我們曾做過對神州飛船回收的直播。由于發(fā)生在凌晨 3 點(diǎn)多、且各方人員并未被通知到，因此我們在不清楚會有多少觀看流量的情況下采用了全量 Push。

通過次日的事后分析，我們發(fā)現(xiàn)：服務(wù)的流量已觸及瓶頸點(diǎn)，出現(xiàn)了許多的報警，幸好有人員值班，所以并未出現(xiàn)故障。

從維護(hù)團(tuán)隊過于疲憊和服務(wù)保障的角度出發(fā)，我們決定開始著手實施自動化擴(kuò)縮容。

如上圖所示，這是我們在實現(xiàn)了自動化擴(kuò)縮容后的一次直播。左側(cè)圖中藍(lán)線的每一次波谷代表一次擴(kuò)容操作。

在波谷處于最小長連數(shù)時，由于自動擴(kuò)容出了一堆機(jī)器，因此那一時刻并無流量的進(jìn)入，連接數(shù)基本為零。

之后連接數(shù)隨即迅速上升，服務(wù)在 30 分鐘之內(nèi)做了 4 次快速自動擴(kuò)容。而這些自動化擴(kuò)容對于運(yùn)維人員來說都是透明的，只是在擴(kuò)縮容時會有郵件提醒而已。

[[228125]]

 

溫情，新浪微博高級系統(tǒng)研發(fā)工程師，從事微博視頻和通訊相關(guān)系統(tǒng)的研發(fā)。當(dāng)前負(fù)責(zé)微博直播消息互動系統(tǒng)的研發(fā)，推崇高可用，可彈性伸縮，低耦合的微服務(wù)架構(gòu)設(shè)計。技術(shù)上擅長消息通訊方向，針對系統(tǒng)應(yīng)對突增流量和高并發(fā)方面有豐富的實踐經(jīng)驗。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】