本文來自愛奇藝研究員在 ArchSummit 全球架構師峰會上的演講整理,將為大家分享愛奇藝打造移動中臺的過程。愛奇藝移動中臺的建設過程可分為元件解耦、元件定製化和平臺化，未來會利用平臺發現、沉澱和複用的能力，對外提供 SaaS 服務。1中臺的定義和意義
首先我們來看一下中臺的定義，其實中臺來源於前臺，它更多的是為前臺的創新，還有快速迭代服務。所以說中臺是位於前臺和後臺之間的一層。相對於前臺來講，它比前臺要更穩定；相對於後臺來講，它比後臺要更加靈活。中臺的意義在於企業級能力複用平臺：
“企業級”定義了中臺的邊界跟範圍“能力”定義了中臺的主要承載物件“複用”的話，定義了中臺的核心價值“平臺“是我們中臺的主要表現形式2愛奇藝 App 中臺
除了愛奇藝 App，愛奇藝也通過內容孵化出一些其他的產品App，比如像愛奇藝漫畫、愛奇藝知識等。
既然有了這麼多的產品，那麼就有了建立愛奇藝 App 中臺的必要性。主要從三方面考慮，專業深度、人力資源、使用者體驗。
這個是愛奇藝中臺演進歷程。在 2018 年以前，當時愛奇藝的四大 App 基本上就是一套程式碼，同一個工程。後來每一個 App 都成立了一個單獨的團隊，我們把程式碼還有開發資源完全的隔離開，並且在這個過程中，將通用的元件給拆分出來。這個時候開始做大量的解耦工作。然後在 2019 年，一邊做解耦，一邊在搭建愛奇藝 App 中臺。
在未來，除了要服務好公司內部的各種業務，還有對外提供 SaaS 服務，特別是愛奇藝的一些合資的子公司，也要為他們做好支撐。
談到解耦，就不得不提一個迭代效率的問題。一個團隊規模基本上決定了一個迭代效率的瓶頸。
對於一個 10 人以下的小型團隊來講，這時候更多講究的是團隊成員的獨當一面，基本上就奉行“拿來主義”。然後到了一箇中型團隊，一個人英雄主義承擔不了這麼大規模的東西。所以這時候就強調一種元件化解耦模組化，讓大家專注在自己能做的事情上面。這個時候強調的是邊界弱耦合的元件化。接下來到了一個大型團隊，這時候除了元件化之外，還強調業務之間的並行迭代能力。但是隨著工程規模的成長，元件化拆分的改造成本會呈指數性增長。愛奇藝在 2018 年開始就投入了大量的人力和物力去做各種解耦的事情。所以特別提個經驗教訓，小團隊的時候，能夠解耦的儘早解耦。
愛奇藝 APP 中臺效果，跟中臺合作最緊密的極速版和國際版就有這樣的反饋，“從人力資本上是巨大節約，參考基線 100 開發 + 規模，極速版和國際版同等功能只有 20 開發規模；同時中臺也能將技術做深做細；開發經驗和流程也能共享”。
這個是中臺的架構圖，底層是中臺門戶。因為所謂的中臺化就是企業級能力複用平臺，所以中臺化就是通過平臺化去發現、沉澱跟複用企業級能力。所以最重要的首先是打造一箇中臺門戶，提供統一接入、統一門戶、統一賬號、許可權和文件的事情。上面是移動開發基礎框架，提供從開發、測試到運營的一站式解決方案，包括一些框架元件、業務元件、基礎元件，還有後臺的一些元件服務；還有高可用高效能的平臺，釋出運營平臺，研發支撐平臺等。最上層就是支撐各個業務 App。
首先就是最底層的中臺門戶 QMAS，它的全稱叫 QIYI Mobile Application Studio。當時做這個平臺之前，收集了各種反饋，特別是新 App 的反饋。對於新 App 來講，首先反應就是開發一個新的 App，冷啟動的時間特別長，公司到底有哪些後臺服務？有哪些 SDK？文件在什麼地方？通通都不知道，遇到了很多問題。
曾經有團隊反饋，他們一個 App 從立項到正式上線花了大概三個月時間，大量的時間花在尋找各種文件上，以及找各崗位幫忙對接的事情上。愛奇藝 App 裡面 APM 日活資料，竟然連公司的前臺都有許可權看。每次搭建一個新系統，都要搭建一套自己的許可權管理管控，甚至每一個系統之間定義的產品線都是不一樣的。繁冗的事情很多，根本沒時間做資料沉澱。針對上面提到的情況，開發了我們自己的中臺叫 QMAS。平臺整合有三方面優勢，第一：一站式服務接入，提供一些工單許可權申請。第二：統一的決策管控，各平臺不會存在角色之間互相不一致的情況。第三：一站式瀏覽體驗，儘量抹平各個平臺存量差異，然後直接在 QMAS 上進行增量平臺開發。
舉一個例子，以前一個推送平臺的申請，大概要兩週左右。建立一個申請，然後給各個公司的商務做審批，再發給愛奇藝的推送，愛奇藝的訊息系統再確認。這些都需要郵件來往，非常麻煩。現在直接在 QMAS 上一鍵申請就好了，接入效率大幅提升，且資訊得到沉澱，還能複用 QMAS 的許可權申請。
平臺運營
關於釋出運營，這裡著重介紹兩個平臺，一個是互動平臺，一個是使用者行為平臺。以互動劇《他的微笑》為例。這裡面提到一個分支劇情，你可以進行選擇，像遊戲一樣。愛奇藝已經有好幾部這種互動劇了。跟傳統的一條故事線相比，我們提供一些分支劇情。甚至有些綜藝頻道，能夠進行一些視角切換，比如說不同的導師的視角來看舞臺。還可以提供一些豎屏的小視訊互動。
IVOS 應用場景，第 1 個平臺主要是給運營平臺做一些配置策略和場景。還提供一些非劇情類的互動、氣泡廣告，這些都能做互動。第 2 個是互動製作平臺。
另外搭建了一個叫做使用者行為分析的平臺，可以看到每一個場景，每個頁面的流量是從哪裡過來的，這個主要是給產品同學用，能看到使用者行為路徑大資料的視覺化分析，能夠知道使用者的轉換留存的原因，輔助實現業務的快速增長。
研發支撐
看一下研發支撐部分。這是最近剛成立的 10 人的虛擬小團隊，在打造愛奇藝 CI/CD 研發中臺，主要囊括專案管理平臺，打包平臺上線，還有版本管理以及渠道管理和運維管理運維平臺。這是面向整個公司做的，另外也會監控整個流水線，還有各個後臺的平臺穩定性，伺服器日誌等。
SDK 對於移動中臺來說是非常重要的，所以在 QMAS 搭建了一個 SDK 管理平臺，就是為提供方和接入方搭建了一個橋樑：
對提供方來講，可以非常方便的去建立釋出，以及做一些成員管理。甚至測試可以針對 SDK 做一些預釋出的測試。對接入方來講，可以非常方便的看到移動中臺到底有哪些 SDK，哪個 SDK 具體什麼作用。並且可以通過內部 IM 系統，直接找到對應的功能。其次是搭建了一個移動 App 腳手架，將常用的一些功能、業務元件、基礎組建、後臺服務都陳列在腳手架上。腳手架有三大好處：提升開發效率，避免踩過的一些典型坑，以及為 App 建立一個一致的基礎設施，方便做跨 App 的功能性升級。在新 App 已實驗過，大幅提升了開發效率。
腳手架使用姿勢也比較簡單，首先是把程式碼拉下來，在 QMAS 上把各種後臺申請下來之後，儲存在基層配置裡，之後基本上就能跑起一個可執行的 App 了，然後在上面再進行自己的業務開發。我們測出來一個新 App 的建立，大概從兩個月左右縮短到兩週，因為以前的很多繁冗的操作都不需要了。
接下來講一下框架元件，大家知道移動應用的一個技術躍遷，從傳統的 Web 開發，到開發獨立 App，可以看到各種各樣跨平臺框架都出來了，所以大家希望一套程式碼實現在多個平臺上，這時候就是所謂的分久必合的時代。特別是 5G、IoT 時代的到來，這個時候甚至可能要提供跨終端開發，這就叫分分合合時代。
當然我們現在處於跨平臺時代，所以愛奇藝中臺也沉澱了非常多的動態化框架，其他 App 想用都是比較方便的。H5、小程式、小遊戲，還有最近的 Facebook RN，還有自己開發的一些外掛化熱修復框架，以及 Flutter。
這裡重點介紹一下 Qigsaw 框架。Google 開源 Google APP bundles 之後，我們看到一絲曙光，就是可以複用 APP Bundles。Google 將他的一些元件外掛放在 Google Play Store 上面，然後底層的 runtime 負責合併和載入。
而我們要做的事情，就將它的 runtime 替換成 Fake 的一套，保證 runtime 介面是完全一樣的，用愛奇藝的 CDN 替換 Google Player。原理就是基於 Google 一些原生的 App Bundles 工具鏈，山寨 Play Core Library，直接複用到原生的一些開發工具類和文件，開發體驗非常好，穩定性非常高，我們只有一處 Hook，從 4.0 開始就支援了。另外就是國內國際雙軌制可以做無縫切換，對於國內的開發來講，它只用 Qigsaw 開發框架就好了，而對於國外的使用者來講，直接用 App 的開發環境就好了。開源地址：https://github.com/iqiyi/Qigsaw
目前已經在非常多的 App 落地如愛奇藝極速版、隨刻、快手等，崩潰率在愛奇藝上幾乎為 0，啟動成功率在 99.5% 左右。
高可用高效能
講完了框架元件的話，接下來看一下高可用高效能。提到高可用高效能、高穩定性，首先想到的可能就是 APM。APM 現在提供了這麼多功能，從崩潰異常和使用者互動，網路熱修復，使用者除錯，以及幀率、ANR 等。APM 對後臺提供實時性、大資料、全覆蓋，還有很多維度的支撐。
通過對一些裝置進行資料採集，經過 CDN 和 QLB 的 Balance，然後再到 Nginx，最後收集到 HBase 和 ES 裡面。經過符號解析，到前端展示。一旦報警，通過內部 IM 或者郵件進行通知。
除了 APM，我們成立了一個虛擬團隊，在打造一個全鏈路的監控平臺，主要作用就是通過統一的投遞規範，然後收集整個端到端的日誌、鏈路資料，實現鏈路視覺化。可以非常方便的看到鏈路瓶頸，進而做一些可優化的事情。另外可以做監控報警，實現故障快速定位。目標是線上定位問題的效率能夠縮短至 20 分鐘。
除了全鏈路監控，我們打造了一個移動日誌平臺，實時記錄一些重要的日誌，當觸發一些異常場景，會自動把它上傳。
最後再講一下無線網路基礎元件，包括閘道器和 HTTPDNS。從有線網路進入到無線網路之後，因為有些網路相對於無線網路，他的拓樸結構變得複雜了很多，多了無線基站，核心網路等。所以這個時候會出現很多問題，比如使用者說網路太卡了，頁面打不開，然後又有各種植入廣告。然後 DNS 資訊的話，各種運營商的 DNS 又不靠譜，他們 TTL 甚至一個月之後才生效。還有使用者可能被排程錯誤，武漢使用者可能被排程到北京的機房去。
針對這些問題，我們提供了一些 HTTPDNS 的閘道器方案。當然還有一些小的像客戶端的一些複合連線等。然後 DNS 主要是起到一個防劫持，另外一個是做容災的作用。特別是後臺出了問題，我們可以及時的做一些更新排程，由於離使用者側比較近，所以排程會比較及時。
還有就是提供了一個閘道器方案，是一個自定義的 Protobuf 協議，好處有 4 點：
沒有 SSL 消耗，像 iOS 必須使用 HTTPS，有閘道器自定協議的話，可以繞開限制；劫持成本比較高，因為是自定義的協議；提供一個比較穩定的長連線系統；節省建連時間，因為是一個穩定的長連，所以 TCP 的三次握手基本上不需要，可以作為一個域名的收斂方案。大家所有的網路連線，從原來的連線各種各樣的業務後臺，到現在直接連一個通用閘道器代理，幫你做域名轉發的事情。可以說，中臺是一種技術趨勢，但並不適用於所有公司、所有技術團隊。而作為架構師，技術管理者，是有必要了解中臺的技術思路的，不管是資料中臺，還是業務中臺，或者是移動中臺，其思想是可以變通應用在各個領域的。
也許你還想了解2020愛奇藝卡通人物檢測識別挑戰賽！