5 月 25 日，全球最具影響力的高端技術人學習成長社交平臺——TGO 鯤鵬會邀請了不同領域的技術管理者，從案例和實踐出發，一起分享討論自己在架構設計方面的想法和寶貴經驗，深入解讀可擴展、高可用架構。在活動現場，美圖公司技術總監王靜波結合美圖公司現狀為大家分享了在大規模的場景及其需要支撐全球用戶的場景下，美圖如何運用面向未來的雲端流程處理系統，從根本上解決處理時長、可用性和成本等問題。6 月 14—15 日，由 TGO 鯤鵬會主辦的 GTLC 全球技術領導力峰會總站將在上海舉行。
雲端圖片美化技術架構
上面是美圖繪畫機器人「Andy」根據照片繪製的圖片，Andy 是美圖雲端圖像處理的核心技術之一。
本地圖片處理的局限
一部分圖片處理從本地遷移到雲端是必然的路徑。以往美圖秀秀的圖片處理功能大多在設備端，但隨著時間推移遇到很多問題：
1、研發鏈條長。算法研發出來後需要為設備適配、測試、更新版本，速度較慢。
2、客戶端體積膨脹。每加一項算法客戶端體積都要增加，久而久之客戶端膨脹很厲害，在海外市場用戶對包體積比較敏感，這一點影響很大。
3、客戶端性能不足。一些低端設備難以提供很好的用戶體驗。
4、AI 訓練數據不足。本地處理的圖片很難為雲端提供數據訓練。
此外，4G 網絡的發展、帶寬和延遲的改進等客觀環境改善，加上圖片美化流行潮流迭代加快等因素，促使美圖開始研發雲端圖片美化架構。
雲端圖片美化架構
雲端處理圖片有三大基礎要求：速度快、成功率高、質量全面監控。
基於三大要求，美圖設計了如下架構：
上圖是一個簡化的方案：客戶端先上傳到存儲服務，再調用 API 服務進行處理，API 服務到客戶端服務是同步的，超時的話會有一個輪詢機制。
為了解決隱私顧慮，用戶上傳到雲端的圖片後，6 個月後會全部刪除，在此期間進行人工智慧的訓練。
為了保證速度和成功率，美圖做了一些優化措施。
1、客戶端：效果列表的預加載；上傳服務採用 token 預獲取；調節參數減少圖片體積。
2、上傳圖片時會有兩個源站服務，如果上傳我們自身的源站有問題，則自動切換到公有雲上面，兩個服務會產生同步；圖片、視頻會切片上傳減小壓力。
3、API 服務和處理服務保持長連接，對於處理服務會進行彈性調度。它根據現在 CPU 使用率來自動彈性調度，自動擴縮容，從而提升處理速度，降低成本。
美圖全球部署的問題
美圖秀秀、美顏相機、B+ 等產品在國外用戶量非常大，所以雲美化不僅要考慮國內，也要考慮國外市場。
因為美圖的存儲服務和處理服務是兩個不同的域名，可能會出現存儲服務是在中國的 region，但處理服務的 DNS 解析到新加坡去了，導致圖片處理失敗。
目前美圖採用的解決方案是，在存儲服務和 API 服務方面有一個特定的欄位定位 region，這樣在上傳一個圖片到存儲服務時就會知道下一次圖片處理應該到哪個 region。這個方案還會顯著提升容災切換能力，通過業務端切換備份機房速度更快。
全面質量監控
1、美圖有一個專門的文件上傳 SDK；產品有一個通道上報一些指標數據，包括用戶處理的效果 ID、上傳時間、處理時間、下載時間、失敗環節等等。
2、文件上傳的 SDK 也有監控，包括上傳時間，失敗率，速度等等
3、API 服務的監控。監控請求 API 服務之後，處理服務花了多長時間。API 服務監控能單獨看到處理伺服器的情況，給出最後的報表。
美圖根據詳細的監控數據可以做針對性優化，根據地區維度和效果維度監控反饋數據。
邊緣計算
運煤化準備演進的方向是邊緣計算。
邊緣計算的目標：數據上傳的時候上傳到 CDN 的邊緣節點，處理也是在邊緣節點處理，處理完成後，異步上傳到源站，減少相關步驟，節省時間，提升用戶體驗。
大規模視頻處理架構
圖片視頻處理需求傳統上有幾點：打水印、給視頻截幀、轉碼服務、為內容加入特效。
傳統處理方式下，給視頻要打一個水印，打一個水印就調一段腳本，相當於是業務方是命令的決策者；處理服務則是一個命令的提供者。
問題
這樣會存在一個問題，當業務方數量增多後，邏輯會非常混亂。假設，把水印的代碼稍微改一改，10 個業務方就都要按照這個參數來改，這樣改一個流程大概要半個月。
還有一些問題，首先決策方的業務代碼全是業務方決定，很難把控；其次這套服務沒有流程化；第三在於資源沒有辦法彈性調度。
解決方案
第一，業務方只要提交需求，比如需要對這個視頻進行處理，處理的決策過程放到處理服務，把決策下移到處理服務來。
第二，原來有很多的命令，裡面都是一個 shell 腳本或者是一個開原始碼。以前每次上線都是先把這一類命令放到物理機的某一個目錄上去統一放好，上線就把它配置上去。但是，當命令沒有放到那個文件夾裡面，調不到就會失敗。假設每次都要重複寫這樣一套流程，那麼新加一個業務寫一套流程，因此我們希望處理命令方能夠通過配置來做，處理命令寫好一次放在這個地方就 OK，當別人想要用服務的時候，就可以把這套東西配置起來，把鐘點工式的服務變成管家式的服務，把命令配置好。poseidon 是一段代碼，第一步先接收消息，第二步下載圖片，第三步是處理，處理結束後就回調業務方，只有處理這個步驟需要變化，其他步驟都是固定的，因此採用模板方法的設計模式來做。
第三，處理的邏輯用 trident 來補充。工程師會寫上這個函數，把這個函數到底怎麼樣配置、參數是什麼樣子等全部列下來，後面增加任何服務的時候只要寫一個 shell 腳本就行，中間接收消息、下載、回調、處理的過程等已經全部模板化，通過組裝的方式在界面上就能組裝出來。
處理原來是在物理機上，我們改造後放到 K8s 上進行，可以做彈性調度。最下面一層是雲存儲。
業務和處理
例如美拍的一個視頻處理規則要求視頻短邊小於 540 時做一些事，這是一個規則引擎以及一個工作引擎負責下一步的處理，處理完之後要回調也無妨，告訴它回調業務方哪一個接口、什麼格式，回調之後整個流程結束。那麼我們只要通過配置的方式，就可以完成業務規則的定義。
poseidon 和 trident 的工作核心定義是，寫好了一個函數是一個 python 腳本，調用一下它才能處理這個視頻。這裡提供三種方式調用，第一個是 HTTP 的同步調用；第二個是隊列的方式；第三個是跟 kafka 類似的 kaproyx。
代碼寫好之後首先要提供該配置數據，或者從 kafka 讀消息。讀完消息之後把圖片或者視頻下載下來，拿這個函數處理。處理完之後上傳到存儲服務，上傳完之後再回調到規則引擎。
把這個函數寫好之後，trident 能夠把函數配置和寫好的模板方法（poseidon 的方法）打包成一個 docker-image，放到 docker 裡面服務就 OK 了。
美圖的大規模圖片視頻處理架構主要由 3 大特性，第一是通過決策下移，從業務方下移到處理服務提升控制力；第二是處理流程化；第三是通過 K8s 等能夠做到大幅度的彈性調度。
Q&A
提問：APM 的部分，監控獲取信息是用一些商業的方案，還是用開源的方案？有沒有考慮到 APM 對自己本身業務性能的評審？
王靜波：APM 是一個通道，是一個被動旁路的行為。業務方主動把這些信息收集好之後發給它，它只是通過一個 HTTP 的接口把數據上傳。我們通過 IP 服務判斷用戶是在美國，或者是在中國福建廈門；是用的電信、聯通，還是長城寬帶？我們還有一個比較強悍的武器是哈勃。比如我們的秀秀加一個哈勃的 SDK 之後，秀秀所有的 HTTP 請求，只要在白名單裡面的都會上報 TCP 時間、DNS 時間、成功還是失敗、整個處理時間……大概有幾十個指標全部會上報。這個過程相當於做了一個代理一樣，所有的行為發到哈勃的 SDK，SDK 再代理出去，效果非常好。因為哈勃能夠知道完整的所有指標，所以哈勃系統能幫助我們進行優化，包括我們做了 DNS 的 SDK，通過哈勃系統數據發現，有一些用戶的 DNS 的時間非常長，那麼我們可以根據用戶需求做一個 DNS 的緩存 SDK- FastDNS。這個問題講的非常到位，管理學上有一句話，如果你不能度量它就不能管理它。我們很多時候不知道它的性能怎麼樣的時候，是沒有辦法去優化的。所以我們 APM 也好，我們哈勃系統也好，都是這樣做的。