愛奇藝內容中臺之Serverless應用與實踐

　　本文從內容中臺角度出發，以圖片生產服務為切入點，結合對Serverless的理解，討論其應用場景落地與實踐。

　　 01 什麼是Serverless

　　Serverless，顧名思義，就是無伺服器，是一種按需提供後端服務的方法。Serverless提供程式允許使用者編寫和部署程式碼，而不必關心底層基礎結構。儘管稱為無伺服器，但仍使用物理伺服器，只是開發人員無需瞭解它們。總結下來，評判一個服務是否是Serverless的，最關鍵的一點是是否需要關心伺服器。下面我們舉個例子找找感覺。

　　比如CDN，我們把靜態資源釋出到 CDN 之後，就不需要關心 CDN 有多少個節點、節點如何分佈，也不需要關心它如何做負載均衡、如何實現網路加速。那它就是一個Serverless的服務。

　　我們似乎對Serverless找到了一些感覺，FaaS，BaaS又是什麼？他們和Serverless有什麼關係呢？

　　FaaS（Function as a service），函式即服務。FaaS顯然是Serverless的，但不能狹隘地認為Serverless=FaaS。舉個經典的例子，我們寫一段hello world程式碼並部署到FaaS平臺，不依賴任何後端服務。這種自嗨式的服務就是FaaS本尊。

　　BaaS（Backend as a service），後端即服務，代表了一些後端的雲服務，比如雲資料庫、物件儲存、訊息佇列等。我們在使用他們的時候，不需要關心他們是如何部署的，能抗住多大的併發。因此BaaS也是Serverless的實際的業務開發中，我們很少遇到單純的FaaS應用場景，通常需要依賴一些後端的服務，比如日誌服務、資料庫、快取、儲存等等。因此從技術角度講，Serverless=FaaS+BaaS。

　　

　　 02 內容中臺為什麼使用Serverless

　　開發人員的基本訴求

　　節約伺服器資源，實現降本增效。

　　快速迭代、極速部署，作為服務開發者，都希望可以把精力放到業務之上，減少CI/CD的投入。

　　HA、動態擴縮容，現在是微服務開發，服務拆分得越來越多，越來越細，如果每個服務都考慮HA、擴容的問題，意味著投入更多精力。

　　內容中臺屬性

　　從內容中臺角度講，通用服務可以更好地服務於業務，這也是中臺的戰略方向。通用服務建設的好壞，直接影響中臺建設質量。圖片生產服務目前在愛奇藝服務100多個業務方，因此服務的穩定性、HA、動態伸縮能力至關重要。這種前提下，減少定製化開發、部署，就能節約不少工作量。

　　圖片生產服務屬性

　　圖片生產的特點使得服務的拆分粒度更細，除了微服務之外，還需要提供上面提到的自嗨式FaaS服務，比如圖片的裁剪、縮放、打水印、生成二維碼服務。服務多且雜，亟需降低對服務的各種成本。

　　因此對內容中臺來講，這種細粒度的服務越多，使用Serverless帶來的收益就越大。

　　 03 圖片生產應用案例

　　自嗨型FaaS

　　這種服務只提供圖片處理的相關操作，主要服務於內部編輯，目的是提供同步的圖片製作工具。例如圖片合成、裁剪縮放、二維碼生成、視訊抽幀等等，目前總共提供了12+FaaS服務，應用於20+個業務場景。這些FaaS服務為編輯的線上工作提供了方便，將編輯線下的製作（如使用PS）遷移到線上。

　　

　　對於圖片生產開發人員來說，Serverless可以說最大程度降低了其工作成本，開發人員只需把精力專注在圖片的生產邏輯上面，之後只需簡單填寫一些服務名稱、資源配額、擴縮容策略，即可完成服務的部署。

　　此外，Serverless為我們提供了一種更加精細化拆分服務及功能再組合的理念，此前我們為了部署方便，將這些圖片處理服務打包在一起部署一個大服務，每個子服務的變更都需要一次完整的部署，並且在資源控制方面也無法做到精細化，畢竟每種圖片FaaS服務對資源的消耗還是不同的。

　　同步FaaS+BaaS

　　在自嗨型FaaS的基礎上，增加了BaaS服務的依賴。例如圖片同步生產服務，這個服務將處理完的圖片，上傳至雲端儲存，並呼叫第三方API分發至CDN。分發至CDN的圖片，需要統一規格（格式、質量因子等）進行處理，以減少頻寬使用，提升端載入圖片的速度。服務雖然經過了三個步驟，但總體還算輕量，非常適合CMS圖片上傳這種需要快速生產的應用場景。

　　

　　非同步事件驅動

　　前兩種應用，依賴使用方的呼叫。但有些業務場景可能會帶來不便，比如有很多使用者上傳圖片的場景。按照傳統流程來看，業務除了將圖片上傳至雲端儲存，還需要額外觸發一次生產任務。如下圖：

　　

　　可以看到，上傳與生產嚴重脫節，雖然這樣可以走得通，但圖片生產與業務方耦合過於緊密。Serverless出現之後，其經典的事件驅動模型，給應用的形態提供了豐富的可能性。圖片服務除了業務主動的同步http、非同步訊息觸發之外，還有很多其他有趣的應用場景。例如上例，可以將業務主動的觸發，改為自動的雲端儲存非同步事件觸發，這樣一來業務不需再主動觸發圖片生產，實現瞭解耦。其次，雖然Serverless可以不需要考慮資源的動態伸縮情況，但同步的處理能力還是會有上限。這樣即使在高併發下，也可能會因為資源過度消耗產生問題。下面是愛奇藝某業務的圖片非同步事件驅動案例：

　　

　　當圖片上傳至雲端儲存後，觸發一個非同步事件，驅動圖片處理函式進行壓縮、加水印，然後再進行持久化的“一條龍”服務。圖片的處理邏輯完全與業務解耦，業務只需進行雲端儲存的上傳，而不必再呼叫一次進行圖片處理。如此也可輕鬆應對高峰流量，實現削峰填谷。

　　Serverless工作流

　　除了上面的例子，愛奇藝還有不少其他圖片生產業務。這些業務各有各的生產需求，比如A業務需要經過AI智慧識別，B業務需要先從視訊中抽圖，C業務需要對圖片進行增強。難點在於如何用一個抽象的流程，對現有Serverless服務進行復用組合，統一支援不同業務的生產需求。

　　此前我們使用第三方工作流系統進行流程的編排，驅動生產流程，後來引入了serverless工作流。

　　

　　現有工作流系統雖然能滿足我們的需求，但是存在不少問題。

　　維護成本極高。為了滿足業務執行需求，我們使用了幾十臺虛機部署工作流例項，無論是擴容或是虛機下線，都給我們帶來了極大的維護工作量。

　　資源部署複雜。為了避免業務之間相互影響，無論是工作流例項或依賴的中介軟體，都需要劃分生產線，進行資源的隔離。

　　與業務系統耦合。在工作流與業務系統解耦方面，雖然我們做了不少工作，但還是無法做到100%，還是時常會產生修改工作流程式碼滿足業務需求。

　　配置複雜。對流程編排的配置，需要大篇幅的配置檔案才能完成，且學習成本高。

　　基於以上問題，我們引入了Serverless工作流，替代傳統工作流系統進行流程的編排。下面以動圖的生產為例，做進一步說明。

　　可以看到這個相對複雜的流程，不需要外部工作流引擎驅動，全部依靠Serverless事件驅動自動觸發。開始通過輸入的引數進行分支選擇判斷，當輸入分別是原始視訊、mp4片段、動圖時，選擇不同的函式進行處理。隨後通過序列及並行的圖片處理函式，完成動圖的生產。

　　工作流下沉到雲端之後，業務開發完全不需要關心工作流的維護、部署、耦合等，且配置也可以做到靈活、簡單。

　　維護成本低。不再需要考慮虛機擴容下線等問題，對虛機的維護成本降低為零。

　　部署架構簡單。無需關心依賴中介軟體，生產線等資源隔離問題。並且資源利用率提升將近60%。

　　完全解耦。只需專注於業務邏輯，不再需要維護工作流系統程式碼。

　　配置靈活簡單。配置這樣一個流程，僅需不到100行配置檔案，配置工作量節省了90%。

　　

　　

　　 04 總結與展望

　　總結幾個關鍵詞，解耦、非同步、工作流、函式拆分及再組合。

　　圖片生產服務後續會進一步推動Serverless的落地。在事件驅動方面，將與雲端儲存深度合作，替代傳統HTTP或訊息觸發，全面推廣雲端儲存變更事件的觸發，實現圖片生產與業務的全解耦。在工作流方面，目前對於Serverless工作流的使用還沒有大面積鋪開，絕大多數業務的圖片生產還是依賴工作流系統，後續會加大落地力度，最終覆蓋愛奇藝全業務的圖片生產。

　　內容中臺目前對於Serverless的應用仍處於初步階段，無論是業務場景的覆蓋度，還是資料規模都還不高。但通過上述實際的應用案例，可以看到我們在圖片生產服務上，已經進行了比較全面的探索及實驗，後續會在更多中臺服務上實現落地。