一種第三方模塊適配接入視聽媒體內容資源服務平臺的技術研究

付 坤 鄧成勝 倪業鵬

（中國傳媒大學 數據科學與智能媒體學院，北京 100000）

1.研究背景

在“互聯網+”的技術和業務創新大潮下，傳統廣電需要吸納云計算和云原生技術，以及其底層所支撐的微服務技術。[1]與傳統技術架構相比，基于微服務技術架構的視聽媒體內容資源服務平臺具有明顯優勢，但也由于需要接入大量第三方微服務模塊，平臺存在著諸多問題，如：第三方微服務模塊接口不規范、存在安全隱患、效率低下等問題；微服務架構系統和傳統架構系統形成生態隔閡，不同架構的系統不能互用；微服務模塊開發語言多樣繁雜，導致系統的維護成本增加，不利于行業發展等問題。[2]

針對上述問題，本文提出了一種第三方模塊適配接入視聽媒體內容資源服務平臺的技術方案，為視聽媒體微服務生態建設發展提供了一條新的思路：將第三方模塊（即除原生開發團隊開發的功能模塊以外，其他團隊開發的微服務模塊或非微服務模塊）通過該技術進行適配接入之后，與原生平臺相連，將第三方模塊部署到原生平臺上，以拓展平臺的功能，進而形成視聽媒體微服務生態系統。[3-4]

2.整體解決方案

在計算網絡技術的不斷發展和普及下，軟件體系架構在信息系統的整體設計中愈發重要，傳統單體架構設計模式具有耦合度高、業務模塊復用性差等問題，無法滿足現代用戶的使用需求。為了解決第三方模塊適配接入尤其是單體架構應用適配接入的問題，本文提出第三方模塊適配接入技術整體解決方案，如圖1所示，該方案使用一種基于容器的微服務架構，通過使用容器技術保證第三方模塊的可用性，提高適配接入效率。[5]

圖1 第三方適配接入技術整體解決方案

通過對國內外相關技術進行調研，參考視聽媒體微服務架構（MMA），提出基于容器的微服務技術棧，明確容器和鏡像倉庫是第三方模塊適配接入的基礎。依據視聽媒體七大功能子域劃分，研究視聽媒體業務微服務業務功能拆分方法和原則，為第三方模塊開發團隊提供指導，制定通用API接口規范。[6]根據通用API接口規范，規范指導第三方模塊開發團隊進行微服務模塊接口設計，為平臺和復雜微服務接口提供統一交互界面。研究微服務模塊鏡像制作技術，指導第三方模塊開發團隊打包微服務模塊代碼和運行環境并上載至平臺鏡像倉庫，使微服務可以跨平臺部署上線運行。[7]

視聽媒體微服務第三方模塊適配接入技術整體解決方案，可以分為如下步驟。

2.1 業務的微服務化

通過對視聽媒體業務和數據流，代碼邏輯的提取，結合7大域340多個微服務劃分，將原有的業務按需拆分成獨立的、適合系統的微服務架構。[8-9]

2.2 微服務接口設計

模塊拆分完成后，在業務系統背景下，根據微服務模塊的功能和特性進行接口設計。指導接入方修改原有的單體應用結構或者不符合規則的接口，按照商議好的原則進行新的接口代碼實現。[10]

2.3 微服務鏡像打包封裝

第三方開發團隊本地自測完新的代碼后，將第三方模塊的代碼和環境通過本方案提供的方法，創建對應的鏡像打包封裝，并在通過鑒權等一系列認證后，準入到鏡像倉庫中。

根據以上解決方案，本技術研究內容主要分為三個部分。

首先容器是微服務的載體[11]，通過鏡像封裝技術可以把微服務架構的第三方模塊打包后上載到鏡像倉庫，方便部署，因此第一部分研究內容為基于容器的微服務平臺，主要研究適合第三方模塊適配接入的技術棧。

其次對于單體架構的第三方模塊，需要進行微服務化，微服務化主要包括服務拆分和接口設計，因此第二部分研究內容為單體架構第三方模塊的微服務化。

對于微服務化后的第三方模塊，需要以容器的方式，進行鏡像封裝，封裝后的鏡像可以屏蔽底層技術差異，在上載到鏡像倉庫后，模塊可以跨平臺運行，因此第三部分研究內容為第三方微服務模塊鏡像封裝技術。[12]

以上三部分內容即完成了視聽媒體微服務第三方模塊適配接入技術研究，使單體架構或微服務化的第三方模塊平滑接入平臺。

3.基于容器的微服務平臺技術棧

根據對視聽媒體微服務架構（MMA）和容器等技術的理解，本文提出了一種基于容器的微服務平臺技術棧，為視聽媒體內容資源服務平臺建設提供參考。根據研究，目前只有基于容器的微服務技術?？梢员ＷC第三方模塊的適配接入，技術棧的具體方案如圖2所示。

圖2 基于容器的微服務技術棧

整個平臺分為兩層，底層同樣為IaaS層，可以是虛擬機或物理機，容器無須關心底層資源的實現形式。中間為CaaS層，主要提供容器級別的服務。CaaS中包含了Docker、k8s和Istio，分別對應容器生命周期管理，容器治理、微服務治理。該技術棧符合視聽媒體微服務架構的特性需求，同時提供容器相關的服務，為第三方模塊適配接入奠定基礎。

4.單體架構第三方模塊微服務化

4.1 數據拆分方法

本文主要采取的數據拆分方法為優化的數據流驅動的拆分方法。具體拆分方法如圖3所示：

圖3 第三方模塊拆分流程

①需求分析。由需求分析人員對待拆分的軟件系統需求進行分析。根據系統用例或自然語言描述的業務邏輯，識別領域上下文和實體，為數據流圖的構建做準備。

②精簡數據流圖構建。基于第①步中的用例和業務邏輯分析，由數據分析人員手動構建詳細版本的分層數據流圖和精簡的數據流圖。詳細版本的數據流圖構建需要遵循方法預設的分解規則，精簡數據流圖所構造的僅關注操作與相關數據存儲之間的關系，排除了諸如外部實體以及數據流傳輸的具體數據之類的無關信息。[13]

③可拆分數據流圖構建。從精簡化數據流圖中提取操作和數據存儲之間數據交互信息，將精簡數據流圖通過算法自動轉化可拆分的數據流圖。之所以關注操作和數據存儲之間的數據交互，目的是避免數據存儲在拆分過程中被分到不同的微服務中，這樣可以保證在減小微服務粒度的同時，盡可能減少不必要的數據一致性的問題。[14-15]

④候選微服務識別。對第③步導出的可拆分的數據流圖，通過設計的算法進行拆分，具體是對同一數據存儲的相關操作進行聚合，然后對出現重復操作的聚合結果進行合并，合并后的結果作為候選微服務。[16]

4.2 微服務劃分算法優化

4.2.1 基于最小生成樹的拆分[17]

本文實現了基于最小生成樹的算法來完成業務操作的聚類拆分，該算法依賴的參數是根據收集的操作間的數據流信息生成的帶權圖G、預期的微服務個數m 和每個微服務的類個數閾值n。其中，圖G的結點表示的是類級別的業務操作；邊權重表示的是操作結點之間的交互頻率，邊權重值越大，表示操作之間的交互越頻繁，耦合程度越高，即越傾向于被分到同一個微服務中。該階段算法的基本原理是：首先，通過Kruskal 算法生成圖G的最小生成樹MST；然后對最小生成樹的邊權重進行分析和刪除，以實現圖的拆分。由于G1 的邊權重越大表示結點間的距離越近，因此在計算最小生成樹之前需要對邊權重值取倒數；所生成的MST中包含了關系最為緊密的業務操作結點和邊，對MST 涉及的邊權重值進行排序和反轉操作，依次刪除權重值越高的邊來實現耦合度較低的業務操作的拆分，并通過深度優先搜索算法（Depth-First-Search，簡稱DFS）遍歷剩余邊組成的子圖。本文通過預期的微服務個數和每個微服務類個數閾值這兩個參數作為算法的終止條件，不同的參數設置可以產生不同的微服務化拆分結果，用戶可以根據自己的需求進行設置，一定程度上保證了方法在使用過程中的靈活性。

4.2.2 基于K-means 的數據庫表拆分[18]

Database per Service 原則倡導每個服務維護自己的數據庫，其他的微服務通過向外暴露的接口來訪問服務私有的數據，因此在向微服務架構遷移時，需要對數據庫表進行拆分?，F有的方法中涉及了數據庫表的拆分，但與業務操作拆分類似，其僅考慮了操作與數據存儲之間有無數據交互關系，使用預先定義的簡單規則來實現拆分；其他工作集中在通過設計階段數據庫實體的結構分析以及其被系統訪問的特征來進行拆分。然而一般情況下，單體系統，尤其是復雜單體系統中使用的集中式數據庫中，數據庫表之間存在耦合和粘連性，設計階段單一特征分析和簡單的規則無法全面解決該問題，有可能會造成拆分的粒度過細或過粗，從而導致后期微服務之間的頻繁交互而影響性能。

本文在前一階段業務拆分結果的基礎上，依據收集的類級別的業務操作與數據存儲之間的交互關系來分析其在運行時對數據的訪問特征，通過K-means 算法來實現數據庫表的有效拆分。K-means 算法依賴的參數是上一階段聚類產生的業務操作集合為結點、集合中操作與數據庫表交互關系為邊所生成的帶權圖G，以及根據數據庫實體關系分析初步設定的數據庫表中心點集合。具體實現過程中，由于操作對數據的訪問頻率越高同樣代表其之間的關系越緊密，因此以圖G邊權重值倒數計算結點到中心點的Dijkstra 最短路徑，將結點放到與之路徑最短的中心結點簇中；然后在每個中心點的簇中選出結點度最大的結點為該簇的中心點，直至中心點不再發生變化或迭代次數為0；最后輸出中心點與其簇中結點，其代表了包含數據庫表的微服務候選集。

4.3 第三方模塊通用接口設計規范

視聽媒體業務被拆分成7大域，340多個微服務，這些微服務功能各不相同，本文結合面向對象編程和操作系統函數的設計思想，提出視聽媒體微服務標準化接口設計方案如下。

（1）所有接口都按照RESTful API風格設計，通過HTTP協議調用。

（2）所有微服務都按照以下8個接口封裝其功能：

①創建服務。根據用戶需求創建服務，服務承載著用戶私有的一些使用設置，這些設置是一直存儲，不會隨著服務的關閉而重置（保存的信息可以是個性化場景配置，也可以是特定的素材），創建服務返回唯一的服務ID作為服務的標識。

②打開（運行）服務。給指定的服務申請對應的IT資源運行，進入可工作狀態。接口參數可以按需加上回調url，當服務運行過程中有需要通知業務方的可以通過此url進行，比如通知服務運行后的結果。打開（運行）服務返回服務當次運行期間有效憑證。

③關閉服務（可選）。服務當次使用結束，可以關閉服務來釋放計算資源，減少資源的浪費。有些服務會自動關閉，不需要實現主動。

④獲取服務信息。包括服務名稱、當前運行狀態（關閉、啟動中的百分比、運行中）、資源占用情況（CPU、內存、IO等運行時狀態）等。

⑤銷毀/刪除服務。不再需要使用的服務可以刪除，個性化配置將丟失。

⑥更新服務信息（可選）。服務創建完成后，可以修改創建時候提交的信息，如服務名稱等。

⑦獲取服務列表（可選）?？梢垣@取某個用戶下面的所有服務列表，包括簡單的信息。

⑧服務設置（可選）。有些服務可以通過API方式設置，服務設置提供了默認設置不滿足用戶需求的情況下，高級用戶自行設置服務參數的接口。

該方案只需要對開發好的服務接口做簡單的二次封裝，功能邊界清晰，開發成本低，易于實現。以上接口可以滿足大部分微服務功能的表達，同時接口設計屏蔽微服務的具體功能，只考慮服務、用戶和平臺三者的關系進行抽象，降低平臺管理復雜度，減輕用戶學習成本。

5.微服務模塊鏡像制作技術

容器云平臺支持的兩種鏡像構建的方式，如圖4所示。

圖4 鏡像構建的兩種方式

其中自動構建可以根據用戶選擇的基礎鏡像，配置啟動命令、環境變量、服務端口等相關參數后，后臺會根據配置的參數生成Docker file文件，然后通過調用Docker API構建鏡像，并上傳到鏡像倉庫。

手動構建根據選擇基礎鏡像創建容器，并提供SSH服務以及映射相關的服務端口，用戶通過SSH登錄容器后，修改配置文件，添加、刪除文件等，且可以通過服務端口驗證修改的情況，確認無誤，并在容器云平臺提交后，容器云平臺會自動生成鏡像并提交到倉庫。容器云平臺會記錄每個用戶的構建記錄，通過云平臺可以檢索追蹤歷史構建記錄，便于審計和分析。通過容器云平臺的鏡像管理控制臺，可以瀏覽當前所有鏡像，并支持多維度排序，比如按鏡像名、用戶名、構建時間等進行排序。同時支持在每個鏡像的詳情頁，對鏡像的Logo、功能描述、應用程序端口、啟動命令、環境變量、存儲路徑等進行重新編輯。也支持鏡像使用頻次的統計等數據的統計。對于已經部署的鏡像，可以通過重新部署選擇低版本的鏡像進行回滾，這是在發布應用的時候經常使用的操作。構建成功對應服務的鏡像后，在自己的Docker中運行該鏡像即可實現服務的部署，然后通過k8s等對Docker進行管理即可對服務進行操作。

6.總結與展望

視聽媒體微服務第三方模塊適配接入技術旨在拓展視聽媒體微服務平臺功能，規范微服務化劃分原則，針對API網關的設計提出統一標準，實現除原生團隊以外的第三方模塊平滑接入到微服務平臺，快速建立視聽媒體微服務生態。

本文給出了對單體架構進行拆分、接口設計、容器化鏡像制作的全流程解決方案。視聽媒體微服務第三方模塊適配接入技術有助于提升視聽媒體微服務平臺擴展性，增加平臺功能，加速內容制作、提高內容質量。將第三方模塊接入平臺可以快速形成視聽媒體制作生態，促進視聽媒體行業發展。

隨著研究內容的不斷深入與細化，本文將選取不同的第三方模塊進行試驗驗證。在試驗驗證的基礎上，通過不斷優化視聽媒體微服務第三方模塊適配接入技術，實現視聽媒體微服務第三方模塊適配接入解決方案，為形成第三方微服務模塊接入測試技術規范打下基礎。