正文字?jǐn)?shù)：7544 ?閱讀時(shí)長(zhǎng)：11分鐘

隨著云基礎(chǔ)設(shè)施服務(wù)以及邊緣計(jì)算技術(shù)的發(fā)展，Cloud Native，即云原生，架構(gòu)理念和研發(fā)也越來(lái)越普及。從傳統(tǒng)軟件架構(gòu)，到云原生軟件架構(gòu)的轉(zhuǎn)變，還需要經(jīng)歷一段時(shí)間才能逐漸走向成熟。今天的分享，我們邀請(qǐng)到了華為云直播的段亮老師，從經(jīng)驗(yàn)和教訓(xùn)的角度，詳細(xì)介紹華為云視頻在Cloud Native的轉(zhuǎn)型實(shí)踐中遇到的問題、挑戰(zhàn)以及解決之道。

作者 /?段亮

整理 / LiveVideoStack

大家好，很高興能有機(jī)會(huì)和大家去分享華為在云視頻Cloud Native（云原生）實(shí)踐過程中的一些經(jīng)驗(yàn)。

我的分享主要分為三個(gè)部分：前兩個(gè)部分和大家一起回顧關(guān)于Cloud Native本身具有哪些的特征以及架構(gòu)；第三部分是我重點(diǎn)想和大家分享的，即我們的云視頻業(yè)務(wù)在探索和實(shí)踐Cloud Native的過程當(dāng)中具體是怎么做的，以及遇到了哪些問題，希望本次分享能夠?qū)ο胍蛘哒谑褂迷圃男』锇閹?lái)幫助。

1

Cloud Native的前世今生

1.1 業(yè)界對(duì)Cloud Native的描述

我們先來(lái)回顧一下，在2010年，Paul（Paul Fremantle）提出了云原生的概念，起初只提出了關(guān)于彈性、分布式、多租戶等基本特征；隨著實(shí)踐和發(fā)展，Adrian（Adrian Cockcroft，2013）和Matt（Matt Stine，2015）相繼對(duì)關(guān)鍵特征進(jìn)行完善，逐漸提出了反脆弱性、DevOps、持續(xù)交付等更新的認(rèn)識(shí)。這就是Cloud Native最初的發(fā)展。

從團(tuán)隊(duì)來(lái)看，CNCF提出了Cloud Native的特征和目標(biāo)，Gartner也同樣做出了重要的規(guī)范。

1.2?對(duì)云原生的定義和要求

華為公司早在2016、17年，就開始通過內(nèi)部發(fā)文的方式，統(tǒng)一云原生定義并規(guī)范語(yǔ)言，便于各部分和業(yè)務(wù)之間對(duì)齊語(yǔ)言，包括（微）服務(wù)化、彈性伸縮、分布式等，同時(shí)對(duì)這些關(guān)鍵特征的定義和范圍，也都做了非常詳細(xì)的規(guī)范。

1.3?Cloud Native定義及關(guān)鍵特征

整個(gè)云原生，我們認(rèn)為應(yīng)該分成三大部分。基于康威定律，組織決定其所成就的業(yè)務(wù)。對(duì)實(shí)踐云原生而言，組織的變化最能使我們感同身受，尤其是對(duì)每一個(gè)人的能力要求發(fā)生了非常明顯的變化。例如，對(duì)研發(fā)人員不再像以前傳統(tǒng)模式下的要求，即實(shí)現(xiàn)需求就可以；現(xiàn)在，從前端需求討論，到需求分析，再到開發(fā)、參與測(cè)試、參與灰度的過程，最后到上線以及在線上運(yùn)行的情況，包括監(jiān)控、告警等，都需要端到端的關(guān)注。所以，對(duì)研發(fā)團(tuán)隊(duì)人員技能的要求提高了。

今天，我重點(diǎn)和大家分享的是關(guān)于云原生的架構(gòu)和工程方面。各個(gè)公司根據(jù)不同的業(yè)務(wù)，都會(huì)涉及到這兩個(gè)方面，所以更有參考價(jià)值。架構(gòu)方面的核心是微服務(wù)架構(gòu)，其后還有彈性伸縮和分布式等特征；工程能力有DevOps、持續(xù)交付、灰度上線等。最終的目標(biāo)是讓云應(yīng)用能夠快速高效地部署和規(guī)模化，以及實(shí)現(xiàn)整個(gè)服務(wù)的高可用性。這是云原生的整體概略，下面我將圍繞架構(gòu)和工程兩個(gè)方面和大家展開分享。

2

Cloud Native的基本特征和架構(gòu)

2.1?微服務(wù)架構(gòu)的定義及優(yōu)勢(shì)

云原生的架構(gòu)，最核心的部分是微服務(wù)架構(gòu)。微服務(wù)的首要特征是高內(nèi)聚、功能單一，最好的狀態(tài)是一個(gè)微服務(wù)只做一件事情，并且各微服務(wù)之間通過進(jìn)程隔離、獨(dú)立代碼庫(kù)等，使得每個(gè)微服務(wù)都可以單獨(dú)測(cè)試、部署和升級(jí)。這樣，單個(gè)微服務(wù)規(guī)模較小，可以做到靈活使用且易于管理。實(shí)現(xiàn)微服務(wù)化后，整個(gè)云原生的交付和小團(tuán)隊(duì)溝通都能快速進(jìn)行，因?yàn)槲⒎?wù)之間使用API（應(yīng)用程序編程接口）通信，沒有了開發(fā)語(yǔ)言的限制，小團(tuán)隊(duì)溝通會(huì)更簡(jiǎn)單、順暢。任何一個(gè)功能點(diǎn)或微服務(wù)出現(xiàn)問題，其故障影響范圍只存在于本服務(wù)器內(nèi)部，這樣可以提升微服務(wù)整體的高可用性，且每個(gè)微服務(wù)都能單獨(dú)演化。

2.2?傳統(tǒng)軟件架構(gòu)與微服務(wù)架構(gòu)對(duì)比

既然微服務(wù)如此重要，我們就來(lái)進(jìn)一步對(duì)比微服務(wù)架構(gòu)和傳統(tǒng)架構(gòu)。傳統(tǒng)單體架構(gòu)的軟件是按模塊劃分的，一個(gè)復(fù)雜的系統(tǒng)可能會(huì)劃分幾十個(gè)甚至更多的模塊，每個(gè)模塊完成一定的功能，模塊之間可能是內(nèi)部代碼級(jí)的接口調(diào)用或本地API調(diào)用。可以看出，在架構(gòu)簡(jiǎn)單或系統(tǒng)功能單一的情況下，單體軟件在初始階段效率可能更高，因?yàn)檎麄€(gè)系統(tǒng)使用一套代碼，在部署和靜態(tài)檢查時(shí)更容易管理，且內(nèi)存是共享的，可以調(diào)用，時(shí)延更低，這是它的好處。如果云原生下的所有功能點(diǎn)全部通過微服務(wù)化的API調(diào)用，調(diào)用之間就會(huì)造成時(shí)延。

那么微服務(wù)架構(gòu)有什么好處呢？進(jìn)程隔離，代碼之間徹底解耦，即各微服務(wù)可以單獨(dú)演化和發(fā)展。對(duì)比傳統(tǒng)的單體架構(gòu)，其在設(shè)計(jì)上肯定想要解耦使模塊功能獨(dú)立，但在架構(gòu)演進(jìn)的過程中，開發(fā)人員難免把控不力，導(dǎo)致耦合越來(lái)越不清晰，同時(shí)每個(gè)模塊的變動(dòng)都會(huì)涉及到其他模塊的升級(jí)變更，甚至影響到技術(shù)棧發(fā)展。一個(gè)模塊的重構(gòu)會(huì)對(duì)另一個(gè)模塊產(chǎn)生影響，導(dǎo)致整個(gè)系統(tǒng)的演進(jìn)變得異常困難。但是，在服務(wù)化架構(gòu)下，以上問題都能迎刃而解。每個(gè)服務(wù)之間通過API協(xié)作完成，更加靈活高效。隨著系統(tǒng)規(guī)模的擴(kuò)大，效率也不會(huì)降低，可用性和開發(fā)效率等方面也能得到保證。

2.3?充分利用云基礎(chǔ)設(shè)施及平臺(tái)服務(wù)

在充分使用云基礎(chǔ)設(shè)施及平臺(tái)服務(wù)方面，我們的架構(gòu)師和設(shè)計(jì)人員的思路也發(fā)生了較大變化。云原生軟件構(gòu)建在整個(gè)云的基礎(chǔ)上，云包括計(jì)算資源、網(wǎng)絡(luò)資源、存儲(chǔ)資源、消息隊(duì)列等，優(yōu)先使用云服務(wù)上已有的資源，而這些資源通過編排的方式調(diào)用，便于實(shí)現(xiàn)整個(gè)系統(tǒng)的可用性。也就是說，每個(gè)服務(wù)、每個(gè)應(yīng)用，僅需關(guān)注自己需要實(shí)現(xiàn)的部分，而不是實(shí)現(xiàn)每一個(gè)功能。在單體架構(gòu)下，較常規(guī)的情況是：需要某一特性，就找到一個(gè)開源的代碼、軟件或模塊拿來(lái)使用，這種方式是不可取的。在云原生下，通過調(diào)用其他服務(wù)來(lái)實(shí)現(xiàn)會(huì)更聚焦和高效。

2.4?彈性伸縮

彈性伸縮也是云原生的精髓，主要需要解決兩個(gè)問題：一是“伸”，二是“縮”。對(duì)于視頻業(yè)務(wù)而言，其規(guī)模往往是不可控制的。若主播在直播時(shí)產(chǎn)生一個(gè)爆點(diǎn)，大量用戶涌入，導(dǎo)致業(yè)務(wù)量陡增。這時(shí)，我們的服務(wù)需要能夠自動(dòng)拓展資源，如果等到業(yè)務(wù)人員接收到高負(fù)荷提醒后，再主動(dòng)升級(jí)變更擴(kuò)展資源，可能會(huì)來(lái)不及。以上是彈性伸縮中“伸”的部分，而“縮”的必要性主要基于成本。我們知道，視頻每天都會(huì)有一個(gè)高峰期，比如，教育類的視頻服務(wù)會(huì)在早上上課的時(shí)間達(dá)到高峰期，而游戲類的直播視頻在晚上8點(diǎn)到10點(diǎn)是高峰期。高峰期相對(duì)于低峰期，其業(yè)務(wù)規(guī)模相差十倍甚至百倍以上，若資源不會(huì)自動(dòng)開放，在空閑期間就會(huì)造成資源浪費(fèi)。“縮”就可把資源釋放出來(lái)，提供給其他服務(wù)使用。

2.5 分布式

分布式是云原生的一個(gè)核心理念，主要用于提高可用性。分布式分為三個(gè)部分：其一，應(yīng)用分布式，分布在多AZ（可用區(qū)）和多Region（區(qū)域）上。如果出現(xiàn)一個(gè)故障，不至于影響到其他方面。例如，一個(gè)城市的電力系統(tǒng)故障，或者某條光纖被挖斷了，也不至于影響到整體服務(wù)的可用性。其二，數(shù)據(jù)分布式。各城市之間，重要的數(shù)據(jù)需要做到跨Region和跨AZ的同步部署和存儲(chǔ)。其三，跨可用區(qū)的部署以及整體的調(diào)度。用我們今天的分享舉例，整個(gè)媒體處理分布在各個(gè)不同的Region上，假設(shè)某個(gè)城市的光纖出了問題，也不會(huì)影響整個(gè)直播的過程和質(zhì)量。這就是分布式帶來(lái)的好處。

2.6?高可用

在云原生下，可用性和傳統(tǒng)模式有著本質(zhì)的區(qū)別，在設(shè)計(jì)思路上就全然不同，云原生是基于不可靠、可拋棄的資源設(shè)計(jì)反脆弱性的系統(tǒng)。舉例說明：在沙漠上建一座牢固的大樓，應(yīng)該怎么建？我們不能因?yàn)樯车夭环€(wěn)固，在其上建造出的樓也不穩(wěn)定。云原生的系統(tǒng)設(shè)計(jì)，并沒有假設(shè)系統(tǒng)下的資源是穩(wěn)定的，實(shí)際上所有資源都可能出故障。那么，系統(tǒng)的反脆弱性具體應(yīng)該怎么設(shè)計(jì)？這才是我們?cè)圃O(shè)計(jì)的精髓之一。

2.7?認(rèn)可失敗的設(shè)計(jì)

在傳統(tǒng)方式上，我們總是在安全、可用等方面下大功夫，希望把系統(tǒng)中的bug和故障全部清除掉，不留任何隱患，這種思路是沒有錯(cuò)的。但是，隨著云上系統(tǒng)規(guī)模越來(lái)越大，云服務(wù)越來(lái)越多，想要清除所有的bug幾乎是不可能完成的任務(wù)。在設(shè)計(jì)上，我們應(yīng)該承認(rèn)失效是時(shí)常發(fā)生的。同時(shí)，需要考慮的是，如何在系統(tǒng)或者某個(gè)功能失效的前提下，業(yè)務(wù)還能正常運(yùn)行。如，在某一微服務(wù)出現(xiàn)故障之后，如何快速發(fā)現(xiàn)并自我隔離，從而消除其對(duì)整個(gè)系統(tǒng)的影響；甚至，在整個(gè)可用區(qū)和核心服務(wù)出現(xiàn)故障時(shí)，怎樣對(duì)服務(wù)進(jìn)行降級(jí)，而不是任由整個(gè)服務(wù)癱瘓。比如，系統(tǒng)中有10個(gè)業(yè)務(wù)，現(xiàn)在出現(xiàn)一個(gè)故障，導(dǎo)致3個(gè)業(yè)務(wù)不可用，那么另外7個(gè)業(yè)務(wù)是否能繼續(xù)服務(wù)？這是在云原生下設(shè)計(jì)系統(tǒng)的一個(gè)核心理念。

2.8?自動(dòng)化運(yùn)維——基于數(shù)據(jù)分析的全方位故障監(jiān)控

目前，云原生下的微服務(wù)數(shù)量較多，大部分情況下，如果系統(tǒng)規(guī)模中等，微服務(wù)數(shù)量是幾十上百甚至更多，若采用人工運(yùn)維的方式幾乎是不可能的。每個(gè)微服務(wù)的運(yùn)行狀態(tài)都是非常復(fù)雜的，且各微服務(wù)之間也會(huì)產(chǎn)生各種復(fù)雜的關(guān)系。若僅從最上層的客戶黃金指標(biāo)來(lái)判斷系統(tǒng)的運(yùn)行狀況，那最終出現(xiàn)問題時(shí)，事態(tài)可能已經(jīng)很嚴(yán)重了。所以從開發(fā)、部署、升級(jí)、問題定位等各方面來(lái)看，自動(dòng)化運(yùn)維都是云原生下非常重要的一環(huán)。

2.9?灰度發(fā)布

灰度發(fā)布也是整個(gè)云原生核心的一部分。我們的系統(tǒng)一直處于開發(fā)當(dāng)中，如果沒有灰度發(fā)布，如何變更一直在開發(fā)中的系統(tǒng)？打個(gè)比方，一架飛機(jī)在高空飛行，不能等飛機(jī)落地之后再更換發(fā)動(dòng)機(jī)。同理，如果我是一名客戶，想讓系統(tǒng)停下再去變更，也是不可能執(zhí)行的。那么，如何在變更的同時(shí)保證所有的業(yè)務(wù)可用，并且保證系統(tǒng)能夠穩(wěn)步向前發(fā)展，這其中有著非常大的挑戰(zhàn)。灰度發(fā)布是目前應(yīng)用較廣泛的方式，其他還有滾動(dòng)發(fā)布、藍(lán)綠發(fā)布等方式，其中藍(lán)綠發(fā)布會(huì)造成資源浪費(fèi)。灰度發(fā)布是目前常用的一種方式，通過灰度升級(jí)，逐漸擴(kuò)大灰度范圍，從而保證整個(gè)服務(wù)的可用性，中途若出現(xiàn)問題則快速回滾。

3

華為云視頻Cloud Native實(shí)踐

下面和大家分享我們的云視頻業(yè)務(wù)在實(shí)踐云原生的過程中的一些經(jīng)驗(yàn)和教訓(xùn)。

3.1?Cloud Native架構(gòu)能力

華為云不但統(tǒng)一了云原生的定義和語(yǔ)言，同時(shí)還對(duì)多個(gè)云原生項(xiàng)目進(jìn)行了總結(jié)，包括內(nèi)部的架構(gòu)設(shè)計(jì)指南，即云原生的架構(gòu)具體應(yīng)該如何設(shè)計(jì)，其中還包括一些優(yōu)秀案例。對(duì)于不同的場(chǎng)景和模式，我們構(gòu)建了架構(gòu)模式庫(kù)，在設(shè)計(jì)過程中，可以直接參考模式庫(kù)，方便高效、高質(zhì)地完成架構(gòu)設(shè)計(jì)。對(duì)整個(gè)云原生，我們也進(jìn)行了全面、規(guī)范的體系建設(shè)，各服務(wù)間的Console、風(fēng)格，包括如何鑒權(quán)、AKI網(wǎng)關(guān)如何對(duì)接、接口風(fēng)格等，都有統(tǒng)一的規(guī)范。最后一點(diǎn)很關(guān)鍵，針對(duì)各業(yè)務(wù)的云原生研發(fā)成熟度，在工具中設(shè)立云原生架構(gòu)評(píng)價(jià)標(biāo)準(zhǔn)，提供數(shù)值打分。這樣，包括云視頻在內(nèi)的每一個(gè)業(yè)務(wù)，都可以衡量其當(dāng)前狀態(tài)與理想狀態(tài)之間的差距，并且知曉待改進(jìn)的方面在哪里。

云原生是一系列云上經(jīng)驗(yàn)的總結(jié)，在實(shí)施過程中，沒有把所有經(jīng)驗(yàn)全都實(shí)踐一遍的必要，只需引用業(yè)務(wù)所需的實(shí)踐即可。重要的是經(jīng)驗(yàn)的價(jià)值。

3.2?架構(gòu)-微服務(wù)架構(gòu)

我們對(duì)微服務(wù)架構(gòu)也做了總結(jié)，從服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)、到服務(wù)劃分和部署等，各模式都有統(tǒng)一的要求。包括可用性、自動(dòng)化運(yùn)維等等，在這里就不詳細(xì)展開了。

我們對(duì)比一下左右兩張圖。左圖是業(yè)務(wù)剛剛構(gòu)建之初的微服務(wù)架構(gòu)，當(dāng)時(shí)對(duì)云原生的了解并未深入，業(yè)務(wù)邏輯相對(duì)比較簡(jiǎn)單。大概一年之后，我們發(fā)現(xiàn)以前的業(yè)務(wù)架構(gòu)出現(xiàn)了問題。第一，開發(fā)效率越來(lái)越低，由于一個(gè)服務(wù)的開發(fā)經(jīng)常會(huì)涉及到其他服務(wù)，并且需要頻繁變更，導(dǎo)致一個(gè)需求需要很長(zhǎng)時(shí)間的開發(fā)才能上線，客戶響應(yīng)時(shí)間明顯變低；第二，測(cè)試越來(lái)越困難，架構(gòu)出現(xiàn)腐化，代碼出現(xiàn)壞味道。基于多種方式判斷，我們認(rèn)為需要重構(gòu)架構(gòu)。現(xiàn)在看向右圖，將之前的VodManager微服務(wù)拆分為4、5個(gè)服務(wù)，每一個(gè)服務(wù)的功能邏輯都是相對(duì)獨(dú)立的，一個(gè)需求的開發(fā)只會(huì)落到一、兩個(gè)服務(wù)里，測(cè)試變得簡(jiǎn)單，開發(fā)也更加高效。我認(rèn)為，微服務(wù)劃分是動(dòng)態(tài)的，沒有一個(gè)理想的架構(gòu)和劃分方法，只有一些指導(dǎo)的原則，這些原則就是我們之前所講到的，這里就不贅述了。需要根據(jù)任務(wù)場(chǎng)景、以及系統(tǒng)業(yè)務(wù)復(fù)雜度、用戶數(shù)量和具體要求等方面統(tǒng)一看待，有問題就進(jìn)行重構(gòu)，沒有問題就盡可能簡(jiǎn)單化。這是我們?cè)谖⒎?wù)架構(gòu)重構(gòu)方面的一些實(shí)踐。

再?gòu)?qiáng)調(diào)一點(diǎn)，這里的微服務(wù)架構(gòu)并不能一次性變更到位，而是一個(gè)逐漸演進(jìn)的過程。可能本周拆分出一個(gè)微服務(wù)，下周又拆分出一個(gè)微服務(wù)；并不能提前限定時(shí)間進(jìn)行拆分，然后一次性上線。我認(rèn)為原因主要是基于質(zhì)量上的考慮，如果突然重構(gòu)全部架構(gòu)，可能會(huì)涉及幾十甚至更多代碼同時(shí)上線，質(zhì)量是很難保證的。每次變更一個(gè)微服務(wù)，就會(huì)有一個(gè)灰度過程，從而保護(hù)客戶服務(wù)的可用性。目前，整個(gè)云視頻業(yè)務(wù)，我們的服務(wù)個(gè)數(shù)大概有2百個(gè)，人均一個(gè)或一個(gè)多一點(diǎn)的規(guī)模，都有對(duì)外API接口，接口數(shù)量約2千個(gè)。并不是說越多越好，以上內(nèi)容僅給大家做一個(gè)參考。

3.3?RTC用戶接入微服務(wù)容器化實(shí)踐

我們認(rèn)為在云服務(wù)上必須要做容器化，因?yàn)楦魑⒎?wù)之間是相互獨(dú)立的，而且應(yīng)該設(shè)計(jì)為無(wú)狀態(tài)，隨時(shí)可以被銷毀。上圖是我們實(shí)時(shí)性視頻的一個(gè)微服務(wù)，目前已經(jīng)商用了，其中一個(gè)案例可以和大家分享一下。所有微服務(wù)全部容器化，因?yàn)槿魏我粋€(gè)實(shí)例都可以被銷毀，如果出現(xiàn)變更或是業(yè)務(wù)量上升，隨意拉起一個(gè)微服務(wù)，其他微服務(wù)仍能正常工作。在這里重述一點(diǎn)，進(jìn)行對(duì)外服務(wù)的微服務(wù)，我們建議首先通過域名調(diào)度，不要通過IP，因?yàn)榭赡軙?huì)有多Region的情況。大家都明白，如果一個(gè)Region出了問題，域名還能解析到另一個(gè)Region上去。對(duì)于對(duì)外呈現(xiàn)解析的IP，首先它應(yīng)該是一個(gè)EIP，且需要有主備，不能是單一的IP。因?yàn)镋IP可以對(duì)應(yīng)后面多個(gè)IP地址，可以保證任何一個(gè)IP或者主機(jī)出了問題，都不會(huì)都整體服務(wù)產(chǎn)生影響。這是對(duì)對(duì)外服務(wù)微服務(wù)的一個(gè)考慮。

另外，所有微服務(wù)之間都不能直接調(diào)用，都應(yīng)該通過服務(wù)網(wǎng)格的方式調(diào)用。目前華為云上比較成熟的是CSE，該方式經(jīng)過了大規(guī)模的考驗(yàn)。比較新的方式有Istio，這兩年逐漸開始使用，服務(wù)線數(shù)量增加較快。我們的整個(gè)云視頻板塊Docker（容器）的數(shù)量最高峰的時(shí)候達(dá)到了好幾千個(gè)。

3.4?使用容器化的收益

這里通過我們自己遇到的一些情況，特別講解一下容器化的好處。最開始我們并沒有采用容器化的方式，后來(lái)發(fā)現(xiàn)通過容器化，資源利用率明顯下降，因?yàn)閺椥陨炜s做的比較容易；另一點(diǎn)是快速啟停，我們現(xiàn)在用容器基本可以達(dá)到秒級(jí)重啟，如果需要就可以秒級(jí)彈出、秒級(jí)部署，而且各個(gè)服務(wù)之間的遷移、依賴關(guān)系、解耦、服務(wù)打包等各方面操作都很迅速。我們現(xiàn)在代碼的升級(jí)、變更、流水線等等都是和容器化綁定的。以上是我們關(guān)于容器化的實(shí)踐。

3.5?實(shí)時(shí)轉(zhuǎn)碼服務(wù)的彈性伸縮實(shí)踐

剛剛也提到，彈性伸縮在云原生里是很重要的一部分，因?yàn)樗袑?shí)影響到可用性和成本。視頻中的彈性伸縮主要考慮什么問題呢？首先，"彈"，我認(rèn)為是沒有問題的，上面的配置圖隱去了數(shù)據(jù)。使用起來(lái)很簡(jiǎn)單，根據(jù)事件驅(qū)動(dòng)，如內(nèi)存、網(wǎng)絡(luò)、業(yè)務(wù)量等，當(dāng)達(dá)到某一特定值時(shí)，相應(yīng)地彈出多少個(gè)實(shí)例，彈出速度非常快，基本可達(dá)到秒級(jí)彈出。所以，“彈”的方面是沒有問題的。但是，對(duì)于視頻業(yè)務(wù)而言，“縮”也非常重要。那么，“縮”具體會(huì)遇到什么問題呢？視頻包括直播、會(huì)議、RTC等業(yè)務(wù)，對(duì)實(shí)時(shí)性的要求非常高。比如，在某一個(gè)實(shí)例上，有1000個(gè)用戶同時(shí)在觀看，其中有800個(gè)已經(jīng)下線，只有200個(gè)占用了一個(gè)實(shí)例，此時(shí)應(yīng)該怎么辦呢？我們的做法有兩種，一種方式是，在新業(yè)務(wù)的調(diào)度上，基于部分指定的容器優(yōu)先預(yù)調(diào)這些業(yè)務(wù)，尤其在業(yè)務(wù)規(guī)模的下降期，根據(jù)業(yè)務(wù)的情況，可能要留出半小時(shí)到一小時(shí)不等的時(shí)間進(jìn)行收縮。對(duì)于實(shí)在很小的業(yè)務(wù)，怎樣把直播遷移到另一個(gè)容器當(dāng)中去，而且對(duì)用戶的觀看體驗(yàn)沒有任何影響。這才是彈性伸縮實(shí)踐中，云視頻業(yè)務(wù)做到“縮”的時(shí)候很重要的一點(diǎn)。

左下角的圖展示的是24小時(shí)內(nèi)高峰期和低峰期的資源利用率。本來(lái)，高峰期和低峰期的峰值有10倍甚至百倍之差，但CPU資源的利用率還算平穩(wěn)，并未出現(xiàn)大起大落。這就是彈性伸縮所需要做到的一個(gè)能力。

3.6?云視頻統(tǒng)一OPS平臺(tái)

云服務(wù)上沒有OPS，相當(dāng)于人沒有眼睛。操作每一塊業(yè)務(wù)，可視化每一項(xiàng)服務(wù)，出了問題之后快速定位，OPS都是核心能力。業(yè)務(wù)監(jiān)控、配置、調(diào)用鏈、日志規(guī)模分析等都能在OPS里很好地體現(xiàn)。這一部分與業(yè)務(wù)相關(guān)性較強(qiáng)，所以只展示了云視頻能力，包括故障的定位定界、運(yùn)營(yíng)、管理、配置等都是必須的。

3.7?云視頻監(jiān)控運(yùn)維系統(tǒng)架構(gòu)

OPS平臺(tái)依賴大量的數(shù)據(jù)，尤其是日志的數(shù)據(jù)，因?yàn)閱栴}的定位定界、故障，告警等，全部分析都依賴于這些數(shù)據(jù)。在云服務(wù)下，整個(gè)運(yùn)維的架構(gòu)非常重要。對(duì)于云視頻板塊，我向大家展示一下我們的過程，供各位借鑒。

針對(duì)數(shù)據(jù)采集上報(bào)，需要考慮本地冗余，不能直接上報(bào)，在失敗之后就丟掉。而且考慮成本，并不會(huì)預(yù)留很大的數(shù)據(jù)通道供使用，所以本地需要有緩存能力，以及上報(bào)失敗后重復(fù)上報(bào)的能力。對(duì)于數(shù)據(jù)接入，我們采用Kafka對(duì)數(shù)據(jù)進(jìn)行二次匯聚，因?yàn)樵紨?shù)據(jù)過大，對(duì)其分析、存儲(chǔ)、查詢等規(guī)模上都無(wú)法滿足。目前，每天的日志量可達(dá)數(shù)百T，而且不能長(zhǎng)久存儲(chǔ)。我認(rèn)為，運(yùn)維架構(gòu)可以不斷演進(jìn)。我們的運(yùn)維架構(gòu)起初設(shè)計(jì)出來(lái)時(shí)，比現(xiàn)在的要簡(jiǎn)單很多，而上圖的架構(gòu)是我們研究至今的情況。大家在構(gòu)建日志系統(tǒng)或運(yùn)維系統(tǒng)時(shí)，需要著重考慮以下兩點(diǎn)：1、日志上報(bào)實(shí)時(shí)性。日志如同神經(jīng)表現(xiàn)，快速獲得日志，就能快速了解系統(tǒng)中存在的問題并解決。實(shí)時(shí)性是一個(gè)挑戰(zhàn)，當(dāng)然這也和成本掛鉤。2、日志實(shí)時(shí)數(shù)據(jù)。包括數(shù)據(jù)的匯聚、分析、展示。

3.8?工程能力-服務(wù)自治

前面提到在微服務(wù)架構(gòu)下，會(huì)存在很多個(gè)擁有單獨(dú)代碼庫(kù)的微服務(wù)，其相對(duì)單體軟件而言更加獨(dú)立，但隨之而來(lái)的問題是——管理。每一個(gè)微服務(wù)都需要人工部署，而且頻度很高，幾乎不可能實(shí)現(xiàn)。所以工程能力的工具化、自動(dòng)化，且能夠?qū)崿F(xiàn)服務(wù)自治是云原生中非常重要的一部分，需要在最初時(shí)就開始構(gòu)建。從開發(fā)人員寫完代碼到上線，需要經(jīng)歷哪些步驟？從第一幅圖中可以看到，包括開發(fā)代碼、靜態(tài)檢查、合規(guī)掃描、Alpha測(cè)試、Gamma測(cè)試、自動(dòng)部署、灰度發(fā)布、在線測(cè)試等。雖然，開發(fā)一個(gè)功能可能只需要30-50行代碼，但一套流程全靠人工幾乎是不可能完成的。但是，在工具化之后，只需在本地開放代碼并測(cè)試后一鍵提交，整個(gè)過程只在部署環(huán)節(jié)需要人工確認(rèn)，其他步驟可以全部通過工具化自動(dòng)完成，從而實(shí)現(xiàn)一人運(yùn)維多個(gè)微服務(wù)。目前，我們的團(tuán)隊(duì)每月大約有500多次變更，一年達(dá)數(shù)千次變更。按照業(yè)務(wù)發(fā)展，并且視頻領(lǐng)域更加活躍，包括RTC等業(yè)務(wù)場(chǎng)景，明年的變更次數(shù)一定會(huì)更多，所以服務(wù)自治非常重要。

3.9?功能能力-灰度發(fā)布

灰度發(fā)布也是云服務(wù)核心的一部分，服務(wù)上線、開發(fā)過程質(zhì)量的基本保障，目前主要使用灰度發(fā)布。灰度方式可基于流量、內(nèi)容、域名、特性等，與開發(fā)特性相關(guān)，在腳本里便捷地更改后就實(shí)現(xiàn)快速發(fā)布。每種發(fā)布都有驗(yàn)證，驗(yàn)證可以是自動(dòng)的撥測(cè)用例、人工撥測(cè)，還能與客戶共同測(cè)試。

3.10?架構(gòu)-分布式&高可用

前面所講內(nèi)容，除了提升效率和降低成本之外，最核心的一點(diǎn)是云服務(wù)的可用性。云服務(wù)可用性是對(duì)客戶的服務(wù)承諾，出了問題，不僅是賠款，更嚴(yán)重的是影響品牌信譽(yù)。那么如何做到可用性？總結(jié)如下：基于認(rèn)可失敗的理念設(shè)計(jì)，能夠?qū)κ〉臉I(yè)務(wù)進(jìn)行降級(jí)；同時(shí)對(duì)于底層資源做到多AZ，這樣一個(gè)城市的機(jī)房出問題時(shí)，不會(huì)影響整體服務(wù)，多Region相互容災(zāi)，最后實(shí)現(xiàn)整體的可用性。但是可用性只能做到盡可能高，不能做到百分之百，整個(gè)過程還需要大家共同探索。上圖展示了一個(gè)比較嚴(yán)重的事件：某個(gè)Region區(qū)底層的所有資源幾乎都不可用了，圖中紅線顯示的是我們的業(yè)務(wù)，幾乎沒有受到任何影響。在保證業(yè)務(wù)不受影響的前提下提高服務(wù)可用性，應(yīng)該是我們共同的愿望。

LiveVideoStackCon 2021 ShangHai

我們準(zhǔn)備好全新的內(nèi)容

在上海歡迎您的到來(lái)

LiveVideoStackCon 2021?上海站

北京時(shí)間：2021年4月16日-4月17日

點(diǎn)擊【閱讀原文】了解大會(huì)詳情

總結(jié)

以上是生活随笔為你收集整理的华为云视频Cloud Native架构设计与工程实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。