百萬(wàn)在線直播互動(dòng)平臺(tái)基于docker的微服務(wù)架構(gòu)實(shí)踐

原創(chuàng)
作者：溫情 2018-05-04 10:04:47

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

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

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

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

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

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

微博直播互動(dòng)平臺(tái)的背景與挑戰(zhàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架構(gòu)選型

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

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

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

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

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

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

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

微服務(wù)化難題

微服務(wù)的引入也帶來(lái)一些新的問(wèn)題：

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

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

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

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

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

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

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

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

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

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

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

• 我們?cè)谠O(shè)計(jì)時(shí)會(huì)希望 Push Service 盡量簡(jiǎn)單，并讓它對(duì)資源減少依賴。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而對(duì)于 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é)起來(lái)，微服務(wù)解決了如下四方面的問(wèn)題：

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

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

微博直播互動(dòng)平臺(tái)的彈性擴(kuò)縮容

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

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

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

因此我們采用了快速?gòu)椥詳U(kuò)縮容的應(yīng)對(duì)策略，即利用公有云端的各種快速?gòu)椥陨炜s的資源服務(wù)。

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

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

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

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

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

同時(shí)由于它省去了各種路由的開(kāi)銷，因此會(huì)比 Bridge 模式更快。

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

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

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

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

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

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

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

業(yè)務(wù) C 會(huì)因?yàn)榉逯盗髁慷暾?qǐng)池中的 3 臺(tái)服務(wù)器，而在業(yè)務(wù)空閑時(shí)則將資源歸還到池中。如此，我們可以自由地在私有云和共有云上實(shí)現(xiàn)快速擴(kuò)容，即為“雙云擴(kuò)”。

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

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

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

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

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

• 業(yè)務(wù)性能指標(biāo)，不同的業(yè)務(wù)之間會(huì)存在著差異，有的 API 服務(wù)能夠支撐 1000 個(gè) QPS(Query Per Second)，而有的卻只能支撐 200 個(gè)。因此根據(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ò)容。

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

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

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

就 Push Service 的指標(biāo)監(jiān)控而言，我們?cè)趬毫y(cè)試時(shí)所監(jiān)控的業(yè)務(wù)性能包括：

• 用戶數(shù)據(jù)的長(zhǎng)連數(shù)。因?yàn)閱闻_(tái)機(jī)器可能會(huì)撐起幾千個(gè)用戶長(zhǎng)連數(shù)。
• 消息推送量。在某些的業(yè)務(wù)場(chǎng)景中，可能長(zhǎng)連數(shù)并不多，但是其消息推送量卻非常大。因此我們需要從不同的維度實(shí)施監(jiān)控。

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

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

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

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

總結(jié)起來(lái)，我們?cè)趶椥詳U(kuò)縮容方面實(shí)現(xiàn)了如下三點(diǎn)：

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

典型案例分享

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

未實(shí)現(xiàn)自動(dòng)化擴(kuò)縮容時(shí)，我們?cè)鲞^(guò)對(duì)神州飛船回收的直播。由于發(fā)生在凌晨 3 點(diǎn)多、且各方人員并未被通知到，因此我們?cè)诓磺宄?huì)有多少觀看流量的情況下采用了全量 Push。

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

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

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

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

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

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

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

本文標(biāo)題：百萬(wàn)在線直播互動(dòng)平臺(tái)基于Docker的微服務(wù)架構(gòu)實(shí)踐
轉(zhuǎn)載來(lái)于：http://www.5511xx.com/article/dhdcosj.html