映客高級技術總監黃繼：7天從開發到上線，雲上高效運維實踐與探索
- 2021 年 11 月 9 日
- 筆記
2021年10月22日，在雲棲大會的《雲上運維最佳實踐》分論壇，映客高級技術總監黃繼發表了主題為「7天從開發到上線，雲上高效運維實踐與探索」的演講，為大家闡述映客團隊如何在較短時間內快速完成業務的開發，同時還要保障業務上線後的穩定運行、快速擴展、訪問質量和數據化運營等經驗。
本文根據他的演講整理而成，主要分為三個部分：
一、映客業務的效率問題與挑戰。
二、應對思路與實踐探索。
三、未來方向與規劃。
圖：映客高級技術總監黃繼
映客業務的效率問題與挑戰
說到映客，在大部分人理解或認識里，映客就是一個直播的平台。但實際上，映客是有一系列泛娛樂化的各種APP，比如有在線相親、香港地區的電商直播、陌生人的音視頻社交等。截止到目前為止，映客大約有40個業務在線運營。
在映客內部，我們非常鼓勵去做新賽道探索和內部創業。所以，我們每年都還會有十多個新的業務被立項、開發和投入上線。在這個大的背景下，時間和效率對我們來說至關重要。
在時間短這個前提下，對我們主要造成的問題或者一些挑戰就來自於這三個方面：
1. 業務需快速做功能迭代。尤其在APP上線初期，有大量的業務需求和功能去完善，我們需要一個比較完善的工具平台和智能化體系。
2. 驗證周期短。在數據運營方面，大部分產品在上線之初就設計好了付費、盈利的模式。所以產品會在非常短的時間周期內進行驗證。只要驗證可行，就會馬上轉入流量推廣和增長獲客的階段。
3. 服務質量。因為我們業務驗證周期很短，在這個周期之內，很可能會遇到突發的用戶新增。所以我們希望所有的用戶，都有比較好的用戶體驗。這就要求在業務剛上線的初期，在穩定、訪問速度等方面，要達到成熟業務的標準。
在剛開始的時候，我們大部分產品的必要功能就很多，比如支付、審核、用戶觸達等。這些功能在初期就是必備功能，涉及到很多團隊，需要多方去溝通和對接；其次，內部的流程有時候也會影響工作效率；在服務質量方面和數據運營方面，初期沒有什麼投入，大家的精力基本都在功能上。
如果說把這些問題都拉到一個比較長的周期來看，其實不是太大的問題。但在我們的場景里，我們希望在業務上線的時候就已經解決了這些問題，或者能夠儘快解決這些問題。
我們的解決思路大致分為四個維度：
1. 敏捷，努力完善我運維體系和服務治理體系，從而加快內部的迭代效率；
2. 解耦，通過解耦讓業務更加的純粹，只需要關心自己的業務邏輯；
3. 復用，這麼多業務中有一些功能是相同的，把這些功能作為公共服務提供；
4. 場景化，比如說用戶註冊之後，會涉及到風控、審核、數據可視化和用戶觸達等。我們把部分能力做了整合，讓它在快速獲得這些能力。
我們給自己定了一些目標和口號，比如我們的目標是「711」，口號是「讓業務更專註業務」。「711」意思是7個雙端的研發可以在1周時間開發上線1個APP。具體實踐的過程是：
◾ 首先，提前做統一的資源管理；
◾ 其次，在內部所有的業務之間統一服務架構；
◾ 第三，做標準的公共服務組件；
◾ 最後，沉澱我們自己的業務場景和閉環。
應對思路與實踐探索
下圖是我們應對思路與實踐探索示意圖，底層主要是統一資源的管理，上面兩層是為服務端和客戶端提供的開發框架的服務組件，橫向部分是將第三方服務和我們自己內部的服務去做一些場景提煉和沉澱。
最早，我們先從統一資源管理開始做，其中公有雲也提供了一些管控的能力。但為什麼我們還要考慮自己來做呢？
1.多雲支持。這裡最早是為了解決服務質量，在發生故障時方便做熱備切換。
2.去差異化。如果雲擴展了，相互之間會有不同和差異。對於業務層，我們需要把這些差異做到屏蔽，讓他們覺得平滑和透明。
3.自有體系。在這個基礎上更容易建立自己的自有體系，包括運維自動化的體系和服務管理的體系。
4.成本管理。因為我們需要在很早階段就做更精細的成本管控，所以我們需要看APP的維度，去看大家的費用消耗或者資源使用情況。
上圖是當前所有的運維工具和平台的體系。右邊最下面是CloudAPI層，我們把所有公有雲提供的資源，只要能支持API接口的都做了接入。在這個基礎之上，按資源的分類去做相對應的管理工具和平台，包括安全組，因為它的變更頻率非常高，所以我們對安全組做了抽象和重新設計，還有一個對應的管理平台。這些資源一旦被開通和投入線上使用，都會和我們自己的服務樹做關聯綁定。
這棵服務樹就是右邊黑色的圖，在這個樹上按照產品、子系統、功能模塊進行業務拆分。因為這個樹上記錄了每個業務和資源的對應關係，所以服務樹和內部其他的系統進行關聯和聯動。
比如與監控系統聯動，可以實現監控自動地添加和刪除。這棵樹不但是運維管理的基礎視角，還是內部其他系統數據源。所以它的信息需要準確及時，不能是靜態或者手動回復。那麼我們如何動態維護和管理這棵樹呢？我們通過和上層服務治理結合的方式實現。
先介紹一下自動化運維里三個基本的概念。
◾ 首先是Service Tag，即微服務模塊。當它橫向排列展開時就是如圖的字符串。在這個字符串里包含了子系統的信息、服務系統的信息、模塊的名字。如果把它豎向排列，就和服務樹一樣，它很多時候可以通過這個Tag生成服務樹。
◾ 再往上是service Name，包含服務名字、子系統。這兩個有相似性，本質是一個東西，只是一長一短。長的這一塊更偏向資源和運維管理，短的這個更偏向服務應用。
◾ 再往上就是Appid，即業務的標識。Appid下關聯了很多業務屬性，比如業務的負責人，相關的業務屬性等。
這三個基礎的概念，底層有一個關聯的邏輯關係，可以梳理業務下面的服務，服務所關聯的資源。這三個是一一對應的關係。我們所有的自動化運維體系圍繞這三個來展開的。
具體運行的模式，這裡簡單跟大家介紹一下。如果創建了一個新的業務。它首先在映客雲平台上立項添加；然後生成和業務對應的屬性；其次，通過一些接口或者生成工單的形式通知運維平台做基礎資源的準備。
同時，研發可以開展代碼開發的工作。在代碼開發的同時，它需要先到KAE平台創建和生成serviceName和serviceTag的字符串。當這個業務在平台發佈線上之後，業務和資源的對應關係會自動生成關聯到樹上。基於服務樹，我們進一步做自動監控，基於KAE平台進一步做遠程配置、流量錄製。同時業務還會生成一些源數據給大數據做計算分析。生產數據也利用service和Appid信息去決定生產到什麼樣的隊列，去做一些隔離和優先級劃分等等，最後落地到大數據。
業務在最初創建時，會和我們的數據平台去做關聯。當源數據生成之後，對應的數據就能可視化，和APP相關的數據都會和映客雲做一個關聯。
為了讓所有業務都能遵守這樣的機制，我們提供了統一的一套開發框架。這套框架提供了一些能力，包括日誌、監控上報等基礎功能。圍繞這個框架，我們也做了周邊的腳手架，以便快速生成一個項目。對於整個框架依賴的公共資源，我們抽取出來進行集中的統一管理和運維。
下一階段做一些通用公共服務組件的提煉，包括短訊、推送、加解密、埋點等服務。這些都變成公共服務，並且儘可能讓它實現自助對接。我們在客戶端也同樣做了類似的事情，比如熱修復、網絡優選、通用埋點。我們都提供一個公共的能力。
包括對於一些第三方，我們也做了一些提煉。這個設計圖底層就是音視頻SDK所提供的能力，在高階應用接口這一層，我們按照房間操作和使用角度去提供接口。通過這樣的方式，我們去實現底層SDK接口快速切換，來做到對業務層更加透明。
在業務場景化這一塊，我們內部主要在使用的是用戶、金融、IM這三塊。比如用戶，我們對基本的註冊/登錄，風控、推廣投放和數據可視化能力進行了整合。
這些整合過的能力，我們儘可能讓它自助配置，自助的對接。我們現在設計的一個目標就是每個組件可以在30分鐘內完成接入，達到可連調的條件。
經過上面幾個階段的發展之後，我們主要的變化和收益在研發人員這邊。
一是他們可以跨業務的靈活遷移。比如說這個項目要去做了，它可以快速從其他產品里抽調人手。如果不做了，這些人可以快速分散到其他業務里；
二是他們更多時間是聚焦在業務邏輯上，所以可以降低一些經驗要求。在業務端，我們對業務可以減少開發的工作量；很多組件可以快速對接，我們目前大部分都可以做到30分鐘-1小時完成；
三是底層服務升級更加透明，而且這些服務有專人維護，更加成熟穩定，避免業務之間重複踩坑。最後是一些默認的功能整合。
我們整套體系從最初100%基於公有雲來去搭建和建設，某種程度上也符合最近比較流行的雲原生理念。在上圖，左邊是初期已經開始在用的一些服務，右邊是隨着現在公有雲產品越來越豐富和完善，我們也陸續用了更多的一些能力。大家在準備上雲，或者在雲上運維里，不可避免都會遇到類似這樣的問題，比如說雲的定位是什麼？雲上產品越來越豐富，到底直接使用還是考慮自研？雲需不需要去做混合雲，或者做多雲架構？我覺得這個需要根據業務和場景來做具體的分析和決策。
我個人認為這些問題在可控性、遷移性和低投入，這三個角度去尋找平衡。而這三個角度某種程度上點像一個不太嚴謹的CAP理論。只能佔有兩個，犧牲掉一個或者放棄掉其中一個。在映客最初的定位里，我們更多側重在可控性和可遷移性上。
未來方向與規劃
針對未來，我們要做的一些事情。
首先，持續建設多雲熱備架構，以及遷移能力的加強，這方面主要考慮是服務質量。隨着公有雲本身的穩定性和可用區域越來越多。這件事情變成一個重要，但不緊急的事情。但是對於一些大面積故障，或者區域性故障，我們仍然是不可接受的。
其次，中台化相關的能力，主要針對海外。因為我們越來越多的業務開始去探索海外市場。這一塊我們的積累沉澱還很少。
最後，更多的場景化。讓業務可以更簡單，比如客服或者智能投放的能力。
