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

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

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

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

從團隊來看，CNCF提出了Cloud Native的特征和目標，Gartner也同樣做出了重要的規(guī)范。 1.2對云原生的定義和要求

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

整個云原生，我們認為應(yīng)該分成三大部分?；诳低?，組織決定其所成就的業(yè)務(wù)。對實踐云原生而言，組織的變化最能使我們感同身受，尤其是對每一個人的能力要求發(fā)生了非常明顯的變化。例如，對研發(fā)人員不再像以前傳統(tǒng)模式下的要求，即實現(xiàn)需求就可以；現(xiàn)在，從前端需求討論，到需求分析，再到開發(fā)、參與測試、參與灰度的過程，最后到上線以及在線上運行的情況，包括監(jiān)控、告警等，都需要端到端的關(guān)注。所以，對研發(fā)團隊人員技能的要求提高了。 今天，我重點和大家分享的是關(guān)于云原生的架構(gòu)和工程方面。各個公司根據(jù)不同的業(yè)務(wù)，都會涉及到這兩個方面，所以更有參考價值。架構(gòu)方面的核心是微服務(wù)架構(gòu)，其后還有彈性伸縮和分布式等特征；工程能力有DevOps、持續(xù)交付、灰度上線等。最終的目標是讓云應(yīng)用能夠快速高效地部署和規(guī)?；?，以及實現(xiàn)整個服務(wù)的高可用性。這是云原生的整體概略，下面我將圍繞架構(gòu)和工程兩個方面和大家展開分享。 2 Cloud Native的基本特征和架構(gòu) 2.1微服務(wù)架構(gòu)的定義及優(yōu)勢

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

既然微服務(wù)如此重要，我們就來進一步對比微服務(wù)架構(gòu)和傳統(tǒng)架構(gòu)。傳統(tǒng)單體架構(gòu)的軟件是按模塊劃分的，一個復雜的系統(tǒng)可能會劃分幾十個甚至更多的模塊，每個模塊完成一定的功能，模塊之間可能是內(nèi)部代碼級的接口調(diào)用或本地API調(diào)用。可以看出，在架構(gòu)簡單或系統(tǒng)功能單一的情況下，單體軟件在初始階段效率可能更高，因為整個系統(tǒng)使用一套代碼，在部署和靜態(tài)檢查時更容易管理，且內(nèi)存是共享的，可以調(diào)用，時延更低，這是它的好處。如果云原生下的所有功能點全部通過微服務(wù)化的API調(diào)用，調(diào)用之間就會造成時延。 那么微服務(wù)架構(gòu)有什么好處呢？進程隔離，代碼之間徹底解耦，即各微服務(wù)可以單獨演化和發(fā)展。對比傳統(tǒng)的單體架構(gòu)，其在設(shè)計上肯定想要解耦使模塊功能獨立，但在架構(gòu)演進的過程中，開發(fā)人員難免把控不力，導致耦合越來越不清晰，同時每個模塊的變動都會涉及到其他模塊的升級變更，甚至影響到技術(shù)棧發(fā)展。一個模塊的重構(gòu)會對另一個模塊產(chǎn)生影響，導致整個系統(tǒng)的演進變得異常困難。但是，在服務(wù)化架構(gòu)下，以上問題都能迎刃而解。每個服務(wù)之間通過API協(xié)作完成，更加靈活高效。隨著系統(tǒng)規(guī)模的擴大，效率也不會降低，可用性和開發(fā)效率等方面也能得到保證。 2.3充分利用云基礎(chǔ)設(shè)施及平臺服務(wù)

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

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

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

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

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

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

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

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

云原生是一系列云上經(jīng)驗的總結(jié)，在實施過程中，沒有把所有經(jīng)驗全都實踐一遍的必要，只需引用業(yè)務(wù)所需的實踐即可。重要的是經(jīng)驗的價值。 3.2架構(gòu)-微服務(wù)架構(gòu) 我們對微服務(wù)架構(gòu)也做了總結(jié)，從服務(wù)發(fā)現(xiàn)、服務(wù)注冊、到服務(wù)劃分和部署等，各模式都有統(tǒng)一的要求。包括可用性、自動化運維等等，在這里就不詳細展開了。 我們對比一下左右兩張圖。左圖是業(yè)務(wù)剛剛構(gòu)建之初的微服務(wù)架構(gòu)，當時對云原生的了解并未深入，業(yè)務(wù)邏輯相對比較簡單。大概一年之后，我們發(fā)現(xiàn)以前的業(yè)務(wù)架構(gòu)出現(xiàn)了問題。第一，開發(fā)效率越來越低，由于一個服務(wù)的開發(fā)經(jīng)常會涉及到其他服務(wù)，并且需要頻繁變更，導致一個需求需要很長時間的開發(fā)才能上線，客戶響應(yīng)時間明顯變低；第二，測試越來越困難，架構(gòu)出現(xiàn)腐化，代碼出現(xiàn)壞味道?；诙喾N方式判斷，我們認為需要重構(gòu)架構(gòu)。

現(xiàn)在看向右圖，將之前的VodManager微服務(wù)拆分為4、5個服務(wù)，每一個服務(wù)的功能邏輯都是相對獨立的，一個需求的開發(fā)只會落到一、兩個服務(wù)里，測試變得簡單，開發(fā)也更加高效。我認為，微服務(wù)劃分是動態(tài)的，沒有一個理想的架構(gòu)和劃分方法，只有一些指導的原則，這些原則就是我們之前所講到的，這里就不贅述了。需要根據(jù)任務(wù)場景、以及系統(tǒng)業(yè)務(wù)復雜度、用戶數(shù)量和具體要求等方面統(tǒng)一看待，有問題就進行重構(gòu)，沒有問題就盡可能簡單化。這是我們在微服務(wù)架構(gòu)重構(gòu)方面的一些實踐。 再強調(diào)一點，這里的微服務(wù)架構(gòu)并不能一次性變更到位，而是一個逐漸演進的過程。可能本周拆分出一個微服務(wù)，下周又拆分出一個微服務(wù)；并不能提前限定時間進行拆分，然后一次性上線。我認為原因主要是基于質(zhì)量上的考慮，如果突然重構(gòu)全部架構(gòu)，可能會涉及幾十甚至更多代碼同時上線，質(zhì)量是很難保證的。每次變更一個微服務(wù)，就會有一個灰度過程，從而保護客戶服務(wù)的可用性。目前，整個云視頻業(yè)務(wù)，我們的服務(wù)個數(shù)大概有2百個，人均一個或一個多一點的規(guī)模，都有對外API接口，接口數(shù)量約2千個。并不是說越多越好，以上內(nèi)容僅給大家做一個參考。 3.3RTC用戶接入微服務(wù)容器化實踐

我們認為在云服務(wù)上必須要做容器化，因為各微服務(wù)之間是相互獨立的，而且應(yīng)該設(shè)計為無狀態(tài)，隨時可以被銷毀。上圖是我們實時性視頻的一個微服務(wù)，目前已經(jīng)商用了，其中一個案例可以和大家分享一下。所有微服務(wù)全部容器化，因為任何一個實例都可以被銷毀，如果出現(xiàn)變更或是業(yè)務(wù)量上升，隨意拉起一個微服務(wù)，其他微服務(wù)仍能正常工作。在這里重述一點，進行對外服務(wù)的微服務(wù)，我們建議首先通過域名調(diào)度，不要通過IP，因為可能會有多Region的情況。大家都明白，如果一個Region出了問題，域名還能解析到另一個Region上去。對于對外呈現(xiàn)解析的IP，首先它應(yīng)該是一個EIP，且需要有主備，不能是單一的IP。因為EIP可以對應(yīng)后面多個IP地址，可以保證任何一個IP或者主機出了問題，都不會都整體服務(wù)產(chǎn)生影響。這是對對外服務(wù)微服務(wù)的一個考慮。 另外，所有微服務(wù)之間都不能直接調(diào)用，都應(yīng)該通過服務(wù)網(wǎng)格的方式調(diào)用。目前華為云上比較成熟的是CSE，該方式經(jīng)過了大規(guī)模的考驗。比較新的方式有Istio，這兩年逐漸開始使用，服務(wù)線數(shù)量增加較快。我們的整個云視頻板塊Docker（容器）的數(shù)量最高峰的時候達到了好幾千個。 3.4使用容器化的收益

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

剛剛也提到，彈性伸縮在云原生里是很重要的一部分，因為它切實影響到可用性和成本。視頻中的彈性伸縮主要考慮什么問題呢？首先，"彈"，我認為是沒有問題的，上面的配置圖隱去了數(shù)據(jù)。使用起來很簡單，根據(jù)事件驅(qū)動，如內(nèi)存、網(wǎng)絡(luò)、業(yè)務(wù)量等，當達到某一特定值時，相應(yīng)地彈出多少個實例，彈出速度非常快，基本可達到秒級彈出。所以，“彈”的方面是沒有問題的。但是，對于視頻業(yè)務(wù)而言，“縮”也非常重要。那么，“縮”具體會遇到什么問題呢？視頻包括直播、會議、RTC等業(yè)務(wù)，對實時性的要求非常高。比如，在某一個實例上，有1000個用戶同時在觀看，其中有800個已經(jīng)下線，只有200個占用了一個實例，此時應(yīng)該怎么辦呢？我們的做法有兩種，一種方式是，在新業(yè)務(wù)的調(diào)度上，基于部分指定的容器優(yōu)先預(yù)調(diào)這些業(yè)務(wù)，尤其在業(yè)務(wù)規(guī)模的下降期，根據(jù)業(yè)務(wù)的情況，可能要留出半小時到一小時不等的時間進行收縮。對于實在很小的業(yè)務(wù)，怎樣把直播遷移到另一個容器當中去，而且對用戶的觀看體驗沒有任何影響。這才是彈性伸縮實踐中，云視頻業(yè)務(wù)做到“縮”的時候很重要的一點。 左下角的圖展示的是24小時內(nèi)高峰期和低峰期的資源利用率。本來，高峰期和低峰期的峰值有10倍甚至百倍之差，但CPU資源的利用率還算平穩(wěn)，并未出現(xiàn)大起大落。這就是彈性伸縮所需要做到的一個能力。 3.6云視頻統(tǒng)一OPS平臺

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

OPS平臺依賴大量的數(shù)據(jù)，尤其是日志的數(shù)據(jù)，因為問題的定位定界、故障，告警等，全部分析都依賴于這些數(shù)據(jù)。在云服務(wù)下，整個運維的架構(gòu)非常重要。對于云視頻板塊，我向大家展示一下我們的過程，供各位借鑒。 針對數(shù)據(jù)采集上報，需要考慮本地冗余，不能直接上報，在失敗之后就丟掉。而且考慮成本，并不會預(yù)留很大的數(shù)據(jù)通道供使用，所以本地需要有緩存能力，以及上報失敗后重復上報的能力。對于數(shù)據(jù)接入，我們采用Kafka對數(shù)據(jù)進行二次匯聚，因為原始數(shù)據(jù)過大，對其分析、存儲、查詢等規(guī)模上都無法滿足。目前，每天的日志量可達數(shù)百T，而且不能長久存儲。我認為，運維架構(gòu)可以不斷演進。我們的運維架構(gòu)起初設(shè)計出來時，比現(xiàn)在的要簡單很多，而上圖的架構(gòu)是我們研究至今的情況。大家在構(gòu)建日志系統(tǒng)或運維系統(tǒng)時，需要著重考慮以下兩點：1、日志上報實時性。日志如同神經(jīng)表現(xiàn)，快速獲得日志，就能快速了解系統(tǒng)中存在的問題并解決。實時性是一個挑戰(zhàn)，當然這也和成本掛鉤。2、日志實時數(shù)據(jù)。包括數(shù)據(jù)的匯聚、分析、展示。 3.8工程能力-服務(wù)自治

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

灰度發(fā)布也是云服務(wù)核心的一部分，服務(wù)上線、開發(fā)過程質(zhì)量的基本保障，目前主要使用灰度發(fā)布?；叶确绞娇苫诹髁?、內(nèi)容、域名、特性等，與開發(fā)特性相關(guān)，在腳本里便捷地更改后就實現(xiàn)快速發(fā)布。每種發(fā)布都有驗證，驗證可以是自動的撥測用例、人工撥測，還能與客戶共同測試。 3.10架構(gòu)-分布式&高可用

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

原文標題：華為云視頻Cloud Native架構(gòu)設(shè)計與工程實踐

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責任編輯：haq