圖靈平臺是美團配送技術團隊搭建的一站式算法平臺，圖靈平臺中的在線服務框架——圖靈OS主要聚焦於機器學習和深度學習在線服務模塊，爲模型和算法策略的線上部署和計算提供統一的平臺化解決方案，能夠有效提升算法迭代效率。本文將與大家探討圖靈OS在建設和實踐中的思考和優化思路，希望能對大家有所幫助或者啓發。
0. 寫在前面
AI可以說是目前互聯網行業炙手可熱的“明星”。無論是老牌巨頭，還是流量新貴，都在大力研發AI技術，爲自家的業務賦能。美團很早就開始探索不同的機器學習模型在各種業務場景的應用，從最開始的線性模型、樹模型，再到近幾年的深度神經網絡、BERT、DQN等，併成功應用於搜索、推薦、廣告、配送等業務，也取得了較好的效果與產出。
美團配送技術部建設的算法平臺——Turing（下稱圖靈平臺），旨在提供一站式的服務，覆蓋數據預處理、特徵生成、模型訓練、模型評估、模型部署、在線預測、AB實驗、算法效果評估的全流程，降低了算法工程師的使用門檻，幫助他們脫離繁瑣的工程化開發，把有限的精力聚焦於業務和算法邏輯的迭代優化。具體的實踐，大家可參考美團技術團隊此前推送的一篇技術博客《一站式機器學習平臺建設實踐》。
隨着機器學習平臺、特徵平臺、AB平臺等陸續完成，配送技術團隊發現在線預測部分逐漸成爲算法開發和迭代的瓶頸，爲此，我們開始啓動圖靈在線服務框架的整體研發。本文將與大家詳細探討圖靈平臺中的在線服務框架——圖靈OS（Online Serving）的設計和實踐，希望對大家能夠有所幫助或者啓發。
隨着圖靈平臺逐漸成熟，包括美團配送在內，已經有超過18個業務方接入了圖靈平臺，整體概況大致如下：共接入10+個BU（業務單元），100%覆蓋美團配送核心業務場景，支持500+個在線模型、2500+個特徵、180+個算法策略，每天支持百億次的在線預測。通過圖靈平臺賦能，算法迭代週期由天級別降至小時級別，大幅提升了配送算法的迭代效率。
1. 圖靈平臺介紹
圖靈平臺是一站式算法平臺，總體架構如下圖1所示，底層依託於Kubernetes和Docker，實現了對CPU/GPU等資源的統一調度和管理，集成了Spark ML、XGBoost、TensorFlow等機器學習/深度學習框架，包含特徵生產、模型訓練、模型部署、在線推理、AB實驗等一站式平臺功能，支撐了美團配送及閃購、騎行、買菜、地圖等事業部的調度、時間預估、配送範圍、搜索、推薦等各類AI應用。圖靈平臺主要包括機器學習平臺、特徵平臺、圖靈在線服務（Online Serving）、AB實驗平臺四大功能。
- 機器學習平臺：提供模型訓練、任務調度、模型評估和模型調優等功能，基於DAG實現拖拽式的可視化模型訓練。
- 特徵平臺：提供在線和離線特徵生產、特徵抽取和特徵聚合等功能，並推送到在線的特徵庫，提供高性能的特徵獲取服務。
- 圖靈在線服務：Online Serving，以下簡稱圖靈OS，爲特徵獲取、數據預處理、模型和算法策略的線上部署及高性能計算提供統一的平臺化解決方案。
- AB實驗平臺：提供事前的AA分組，事中的AB分流和事後的效果評估等功能，覆蓋AB實驗的完整生命週期。
圖靈OS主要指圖靈平臺的在線服務模塊，聚焦於機器學習/深度學習在線服務，目標是讓離線訓練好的模型能夠快速上線，有效提升各業務部門的算法迭代效率，快速拿到結果，對業務產生價值。以下將重點介紹圖靈在線服務（Turing Online Serving）。
2. 圖靈OS的建設背景
在美團配送業務發展初期，爲了支撐業務的快速發展，快速支持算法上線、快速試錯，各個業務線的工程方獨自開發在線預測的一系列功能，也就是我們所熟知的“煙囪模式”。此種模式各自爲戰，非常靈活，能夠快速支持業務的個性化需求。但隨着業務規模的逐漸擴大，這種“煙囪模式”的缺點就凸顯了出來，主要表現在以下三個方面：
- 重複造輪子：特徵獲取和預處理、特徵版本切換、模型加載和切換、在線預測和AB實驗等都是各自研發，從零做起。
- 平臺化能力缺失：缺乏對特徵、模型迭代上線的完整生命週期的平臺化運維、管理、監控和追蹤能力，研發效率低下。
- 算法與工程耦合嚴重：算法與工程邊界模糊，耦合嚴重，相互制約，算法迭代效率低下。
“煙囪模式”在業務發展早期做出了不可磨滅的貢獻，但隨着業務體量的增長，這種方式的邊際收益逐漸降低到了不可忍受的程度，亟需一個統一的在線服務框架來進行改變。
目前，市面上大部分主流開源的機器學習在線服務框架僅提供了模型預測功能，不包含預處理和後處理模塊，如下圖2所示。
比如谷歌TensorFlow Serving是一個用於機器學習模型Serving的高性能開源在線服務框架，提供gRPC/HTTP接口供外部調用，支持模型熱更新與自動模型版本管理，同時解決了資源調度、服務發現等痛點，對外提供穩定可靠的服務。但是TensorFlow Serving不包含預處理和後處理模塊，需要將業務工程方將輸入預處理成張量傳遞給TensorFlow Serving進行模型計算，然後再對模型計算結果進行後處理。預處理和後處理的邏輯對於算法策略非常重要，迭代也比較頻繁，這部分跟模型結合比較密切，更適合由算法同學負責，如果由工程方實現，則工程同學只是單純的實現算法同學設計的邏輯，耦合過於嚴重，迭代效率低，而且還容易導致設計和具體實現不一致，引發線上事故。
爲了解決上述問題，爲用戶提供更方便易用的算法平臺，圖靈平臺建設了統一的在線服務框架，通過整合模型計算和預處理/後處理等模塊，以算法版本的形式進行呈現，並進行迭代，免去了與算法與工程之間複雜的交互。
這裏我們對算法定義進行了擴展，本文中的算法（也稱算法策略）可以理解成一個組合函數：y=f1(x)+fi(x)+…+fn(x)，其中fi(x)可以是規則計算、模型計算（機器學習和深度學習）或者非模型算法計算（比如遺傳算法、運籌優化等）。該組合函數中任何組合因子的調整（比如模型輸入輸出變更、模型類型變更或者規則調整）都可看作是一次算法版本的迭代。算法迭代是算法開發-上線-效果評估-改進的循環過程。Turing OS的目標就是優化算法的迭代效率。
3. 圖靈OS 1.0
3.1 圖靈OS 1.0介紹
爲了解決“煙囪模式”開發過程中的重複造輪子和平臺化能力缺失的問題，我們着手搭建了圖靈OS 1.0框架。該框架整合了模型計算和預處理、後處理模塊，把繁雜的特徵獲取和預處理、模型計算、後處理等邏輯都封裝在圖靈在線服務框架中以SDK的形式對外提供。算法工程師基於圖靈在線服務SDK開發個性化的預處理和後處理邏輯；業務工程集成圖靈在線服務SDK和算法包，調用SDK提供的接口進行模型計算和算法計算。
通過圖靈OS 1.0，我們解決了各業務方獨自開發、獨自迭代以及重複造輪子的問題，大大簡化了算法工程師和工程研發人員的開發工作，而且工程是通過圖靈在線服務框架間接調用算法預處理和模型計算，不直接跟算法進行交互，一定程度上也減輕了工程和算法的耦合問題。
如圖3所示，該階段的圖靈在線服務框架集成了以下功能：
3.1.1 特徵獲取
- 通過特徵聚合、動態分組、本地緩存以及業務線級別物理資源隔離等手段，提供高可用、高性能的特徵在線獲取計算能力。
- 通過自定義MLDL（Machine Learning Definition Language）將特徵獲取流程配置化，並統一特徵獲取流程，提升在線服務特徵的易用性。
- DLBox（Deep Learning Box）支持將原始向量化特徵和模型放在同一節點進行本地計算，解決深度學習場景下需要召回大規模數據的性能問題，支撐配送各個業務高併發及算法快速迭代。
3.1.2 模型計算
- 支持本地（Local）和遠程（Remote）兩種模型部署模式，分別對應將模型部署在業務服務本地和專用的模型在線服務集羣中；通過多機異步並行計算，支持CPU/GPU資源異構等手段，解決大規模模型計算的性能問題；通過模型Sharding解決超大規模模型單機無法裝載的問題。
- 在深度學習模型計算方面，利用高性能計算加速庫MKL-DNN以及TVM等編譯優化技術進一步提升深度學習模型的推理性能。
- 通過MLDL封裝的模型特徵關聯關係以及預處理邏輯等配置，實現了特徵獲取、特徵處理以及組裝的自動化，提升了模型的開發迭代效率。
3.1.3 算法計算
- 支持算法版本管理、AB路由，支持動態獲取算法版本所關聯的模型、特徵和參數等，支持模型和參數的熱更新。
- 支持AB實驗以及靈活的灰度發佈放量，並通過統一埋點日誌實現AB實驗效果評估。
3.2 圖靈OS 1.0遺留問題
圖靈OS 1.0解決了各業務線重複造輪子、特徵混亂和平臺能力缺失等問題，通過提供一站式平臺化服務，支撐了美團配送各業務線大規模算法在線預測的場景和高性能計算的需求；使算法同學更加關注算法策略本身的迭代優化，提高了算法迭代的效率。但是對於前述的工程、算法、平臺三方耦合問題，還沒有很好的解決，主要體現在：
- 業務工程靜態依賴算法包，算法包部署在業務工程中，算法包更新迭代上線需要業務工程發版。
- 算法包與業務工程運行在同一個JVM中，雖然減少一次RPC消耗，但是算法包的計算性能會影響業務工程的性能，業務工程穩定性不可控，比如TensorFlow模型計算時對CPU的消耗過大、大模型的加載和切換對內存的消耗等問題。
- 隨着圖靈平臺提供的功能越來越豐富，圖靈在線服務SDK變得越來越臃腫，業務工程必須升級圖靈在線服務SDK才能使用圖靈平臺新功能，但是業務工程升級SDK風險較高，而且會拖慢業務工程部署的速度。
基於上述幾點可知，算法、工程和圖靈平臺三方高耦合，導致各自都存在很多痛點，如圖4所示。這些問題嚴重影響了算法迭代效率，算法迭代上線測試工期長，效率低：
- 算法痛點：算法包迭代強依賴業務工程上線，每次工程發版都需要走一個完整的研發測試周期，流程長，效率低。
- 工程痛點：算法包與業務工程在同一個JVM中，算法計算的性能將影響業務工程服務的性能；同時業務工程需要跟隨算法包的迭代頻繁發版，改動可能只涉及升級算法包的版本。
- 圖靈平臺痛點：圖靈在線服務SDK部署在業務工程中，版本收斂難度大，兼容難度大；同時圖靈新功能推廣難度大，需要業務工程升級圖靈在線服務SDK。
因此，必須將算法、工程和圖靈平臺更好的解耦，既滿足算法快速迭代的需求，又能滿足業務工程端穩定性的訴求，合作共贏。
4. 圖靈OS 2.0
針對圖靈OS 1.0框架中算法、工程和圖靈平臺三方高耦合的痛點，我們研發了圖靈OS 2.0框架，目標是解決算法、工程、圖靈平臺三者耦合的問題，讓算法迭代無需依賴工程發版，圖靈平臺新功能上線無需業務工程升級SDK，進一步提升算法迭代效率和工程開發效率。
圍繞解耦算法、工程和圖靈平臺的目標，在圖靈OS 2.0框架中，我們設計研發了算法包插件化熱部署框架、算法數據通道和算法編排框架等功能，支持算法自助迭代上線。同時設計研發了以沙箱引流、實時回放、性能壓測和Debug測試等功能爲一體的算法驗證平臺，保證了算法策略的高性能、正確性及穩定性。圖靈OS 2.0框架解耦了算法、工程和圖靈平臺，實現了算法與工程迭代的各自閉環。大部分算法迭代的整個流程無需工程研發人員、測試工程師的參與，算法工程師在小時級即可完成算法策略的迭代上線；通過圖靈OS 2.0的賦能，算法的研發迭代效率得到了大幅提升。
圖靈OS 2.0具體功能特性如下：
- 標準化輕量級SDK：業務工程只需依賴一個輕量級的圖靈OS SDK，無需頻繁升級，降低工程端接入難度，解耦業務工程與圖靈平臺。
- 算法插件化：自研圖靈算法插件框架，支持算法包作爲一個插件在圖靈OS服務中熱部署，解耦算法與工程；圖靈OS服務中可部署多個算法包的多個版本，每個算法包擁有獨立的線程池資源。
- 數據通道：在一些複雜的算法場景下，算法策略還需依賴業務工程完成：1）算法內部獲取數據，只能通過業務工程調用接口獲取結果之後傳遞給算法；2）算法內部調用算法，只能通過業務工程中轉同時調用算法A和算法B。爲了解決上述兩點，我們提出了數據通道（Data Channel）的概念，使得算法本身具備自主獲取數據的能力，而不是所有數據都需要業務工程獲取然後再透傳給算法。
- 算法編排：多個算法按照串行或者並行的方式組合爲有向無環圖圖（DAG），可以看作是一個算法編排；業務算法的抽象與沉澱，對應到新架構就是算法的組合與編排，算法編排爲業務上線和算法迭代進一步賦能，進一步提升了業務算法迭代效率，進一步解耦算法和工程。
- 沙箱引流：圖靈沙箱是一個與圖靈OS物理隔離，但運行環境完全一致的服務，流量經過沙箱不會對線上業務造成任何影響；沙箱可驗證算法邏輯的正確性，同時評估算法計算的性能，提升研發測試流程的效率。
- 圖靈回放及統一埋點：在算法計算及模型計算的過程中會產生很多重要數據（算法策略、模型、特徵、參數和數據通道等相關數據），這些數據不僅有助於快速排查定位系統問題，也爲AB實驗報告、沙箱引流和性能壓測等模塊提供了重要的數據基礎，爲了更好地自動記錄、存儲和使用這些數據，我們設計了實時回放平臺和統一埋點。
- 性能壓測：圖靈OS通過整合美團全鏈路壓測系統Quake的能力，複用統一回放平臺採集的流量數據來構造請求，對部署了新版本算法包的沙箱進行壓力測試，保證算法策略迭代的性能及穩定性。
以下將對上述幾個功能特性進行展開介紹，看看圖靈OS 2.0是如何解決算法、工程和圖靈平臺三方耦合痛點的。
4.1 標準化輕量級SDK
爲了解決業務工程和圖靈平臺的耦合痛點，即圖靈在線服務SDK部署在業務工程中，SDK版本收斂難度大的問題，我們主要從SDK輕量化、簡單易接入、穩定可擴展、安全可靠等幾個方面考慮對圖靈在線服務SDK進行了拆分和改造：
- SDK輕量化：將原有圖靈OS SDK邏輯下沉到圖靈OS服務中，只提供簡單通用的批量預測接口；該SDK無需過多暴露算法相關的細節，算法版本路由、實時/離線特徵獲取、模型計算等都隱藏到圖靈OS內部。輕量級的SDK內部集成了圖靈OS的自定義路由，業務方無需關注算法包部署在哪個圖靈OS集羣，對使用方完全透明。
- 簡單易接入：提供統一且通用的Thrift接口進行算法計算，使用Protobuf/Thrift來定義算法輸入輸出，相對於目前Java類定義接口的優勢是兼容性有保障；Protobuf接口定義完成後，算法和工程可以各自獨立進行代碼開發。
- 可擴展：輕量級SDK版本穩定，無需工程端反覆升級；Protobuf天然支持序列化，後續流量拷貝、回放埋點等都可以基於此進行。
- 高性能：針對大批量算法計算且要求高可用的場景，例如面向C端用戶的批量預測，我們設計了異步分批高度並行等手段提升算法計算性能；針對單任務計算耗時長、CPU消耗高且要求高可用的場景，例如分城市區域的調度路徑規劃，我們設計了客戶端快速失敗最優重試機制保證高可用，也均衡了圖靈OS的計算資源。
- 安全可靠：針對單個圖靈OS部署多個算法包的場景，提供線程池級別的資源隔離，針對各業務線不同的算法包，按業務場景垂直拆分，提供物理級別集羣資源隔離，同時增加熔斷降級機制，保證計算流程穩定可靠。
4.2 算法插件化
通過對圖靈OS SDK進行標準化輕量化改造，我們解決了業務工程和圖靈平臺之間耦合的痛點。通過對圖靈OS進行服務化改造，解決了算法和業務工程之間耦合的痛點。但是算法和圖靈平臺之間耦合的痛點依然存在且痛點增加：算法迭代上線依賴圖靈OS服務發版，並未能達到三方解耦的目標。
爲了解決算法與圖靈平臺之間的耦合痛點，進一步提升算法策略的迭代效率，我們下一步的設計思路是算法插件化，圖靈OS容器化：將算法包作爲一個插件，部署到圖靈OS中，算法包發版不要求圖靈OS發版，甚至不需要重啓圖靈OS，如圖7所示。
- 算法插件化：我們自研了圖靈OS算法插件框架，支持算法包以插件的形式部署到圖靈OS服務中；具體實現方案是自定義算法類加載器ClassLoader，不同的ClassLoader加載不同的算法包版本，通過加載多版本算法包以及指針替換，實現算法包熱部署。
- 圖靈OS容器化：圖靈OS充當一個插件容器，裝載算法包不同的算法版本，執行算法版本路由以及算法策略計算，圖靈OS經過容器化改造之後的流程：1）如果算法版本不需要新增參數，則工程端和圖靈OS都不需要發版；2）業務工程主要工作是傳遞參數給算法，邏輯簡單，如輸入參數無變化則不需要發版，算法包發版節奏自己掌控。
4.3 數據通道
通過上述手段，我們解決了算法、工程和圖靈平臺三者在發版迭代時的耦合問題。但是除了上述的耦合之外，還有一些複雜算法場景，算法與業務工程依然存在耦合，主要體現在算法依賴業務工程的以下兩點數據：
- 算法內部獲取數據：目前是通過業務工程調用接口獲取結果之後傳遞給算法，例如一些服務化接口數據、分佈式KV緩存數據等，算法和業務工程都需要進行開發迭代上線。
- 算法內部調用算法：目前通過業務工程同時調用算法A和算法B並編寫中轉邏輯來實現，例如算法A的輸入需要用到算法B的結果，或者需要綜合算法A和算法B的結果得到最終輸出，這些操作一般都交由業務工程來處理。一種可選方案是將算法A和算法B合併成一個龐大的算法，但該方案的劣勢是增加了算法A和算法B獨立進行AB實驗及灰度的研發成本。
爲了解決上述兩點，我們提出了數據通道（Data Channel）的概念，使算法本身具備自主獲取數據的能力。在算法內部算法可通過圖靈OS提供註解的方式支持數據通道，算法與業務工程的交互接口僅需傳遞一些關鍵參數及上下文數據即可，算法內部自行組裝該數據通道所需參數。經過數據通道化的改造，算法接口進一步簡化，算法與工程耦合度進一步降低，算法內部調用算法的問題，我們可通過下面介紹的算法編排來進行解決。
4.4 算法編排
一個完整的算法計算流程包括算法計算部分，以及針對輸入的預處理邏輯和計算結果的後處理邏輯等，算法計算可以是N次規則計算，N次模型計算（機器學習和深度學習等），或者非模型的算法計算（比如遺傳算法、運籌優化等），或者多種類型算法組合。我們把這種具有獨立輸入輸出的計算邏輯單元抽象爲一個算子，算子可編排、可複用，通用的兩類算子如下：
- 模型計算算子：即模型計算引擎執行模型計算，我們支持Local和Remote兩種模型計算模式，在Remote計算模式中，模型可能部署在不同的模型集羣中，算子是對模型計算的進一步封裝，將Local和Remote選擇及模型集羣路由等功能對用戶透明，算法工程師無需感知，我們會根據整體計算性能進行動態調整。
- 算法計算算子：即圖靈OS中的算法計算引擎執行算法策略計算，不同的算法插件可能部署在不同的圖靈OS中，同時也將圖靈OS集羣的路由功能進行了封裝，對用戶透明。
多個算子之間通過串行或者並行的方式組合爲一個有向無環圖（DAG），形成了算子編排，當前我們有兩種方式實現算子編排：
- 算法數據通道：不同圖靈OS中的算法計算引擎互相調用或者算法計算引擎調用模型計算引擎，算法數據通道是實現算子編排的一種具體手段。
- 算法總控邏輯：我們在算法調用的上層抽離出一層算法總控邏輯層，滿足複雜算法場景及多個算法關聯依賴的情況，該算法總控邏輯由算法工程師在算法包中實現；通過算法總控邏輯功能，算法工程師可以任意編排算法之間的關係，進一步解耦算法和工程。
從算法工程師的視角來看，圖靈OS以搭積木的方式提供服務，通過組合一個個獨立的子功能及算子，以標準的方式串並聯，從而形成滿足各式各樣需求的在線系統。
在該架構下，算法的工作主要有如下三部分：1）算法工程師進行業務流程的抽象與建模；2）算法工程師進行獨立的算子開發與測試；3）算法工程師基於業務流程抽象進行算子的編排與組合。算子編排爲業務功能上線和算法迭代進一步賦能，業務算法迭代效率進一步提升。
4.5 多模式集成
上文介紹了圖靈OS作爲一個容器可部署多個算法包的多個版本，並支持算法包熱部署。圖靈OS通過插件化熱部署以及編排等功能，解耦了業務工程、算法以及圖靈的三方耦合，極大地提升了算法的迭代效率。爲了進一步滿足業務的要求，我們提供了兩種圖靈OS部署集成模式：Standalone模式和Embedded模式。
Standalone（獨立模式）
Standalone模式下，圖靈OS是獨立於業務服務單獨部署的，業務服務通過輕量級SDK調用算法，圖靈輕量級SDK內部封裝了圖靈OS的自定義路由，以及Thrift-RPC調用圖靈OS服務的邏輯。
Embedded（內嵌模式）
在某些高併發及高性能要求的複雜場景中，對我們圖靈OS的集成模式及性能提出了更高的要求。在獨立部署模式下，業務工程每一次算法計算都有RPC的消耗，因此我們實現了圖靈OS新的集成模式——Embedded。在Embedded模式下，我們對外提供圖靈OS框架代碼包，業務方在自己的工程服務中集成圖靈OS框架包，業務服務同時也作爲一個圖靈OS容器，還是通過輕量級SDK調用算法，在業務服務本地進行算法計算。內嵌圖靈OS的特點如下：
- 業務工程因集成了圖靈OS框架代碼，而繼承了算法包插件化和熱部署的功能，具備了業務功能和圖靈OS容器的雙重屬性。
- 業務工程並不直接依賴算法包，而是由圖靈OS框架進行動態管理，算法包進行插件化熱部署，達到了算法和工程解耦的目的。
- 業務工程直接進行本地算法計算，減少了算法調用的RPC及序列化消耗，同時複用了業務工程服務器資源，進一步減少集羣資源消耗，提升了資源利用率。
在算法包插件部署時，以內嵌模式集成的業務工程將作爲容器裝載相應的算法包，路由到本地進行算法計算，如下圖9所示。
Standalone和Embedded模式各有利弊，誰都沒有絕對的優勢，使用時需要根據具體的業務場景進行選擇。兩種模式的對比如下：
| 部署模式 | 優點 | 缺點 | 適用場景 |
|---|---|---|---|
| Standalone | 耦合度更低，業務方只依賴圖靈輕量級SDK | 需要搭建圖靈OS集羣，佔用機器資源；有RPC調用開銷 | 適合大批量調用，需要分佈式多機異步並行計算的業務場景 |
| Embedded | 複用業務方機器，資源利用率高；少了RPC調用，性能高 | 無法充分發揮多機異步分佈式並行，只能單機並行 | 適合小批量調用，對單次調用RT性能要求較高的業務場景 |
4.6 圖靈沙箱
在圖靈OS支持算法插件熱部署之後，算法迭代效率相比之前大幅提升，算法工程師的上線自由度也得到大幅增加，無需經過業務工程和測試的排期開發和測試；但是也引入了新的問題：
- 算法迭代上線前，無法引線上流量進行預計算，提前對算法效果進行上線前評測，上線前校驗難，算法工程師測試效率較低。
- 當前線上實時評估和校驗困難，算法策略的線上性能和效果評估缺少流程化自動化工具。
- 頻繁的迭代上線對圖靈OS服務以及業務的穩定性來說也是很大的挑戰。
當時的可選方案是算法策略先部署上線，灰度切小流量，然後再分析統一埋點日誌評測算法效果。該方案的缺陷是無法在上線前對算法效果進行評測，問題發現時間過晚。如果灰度的功能有問題，會對線上的業務造成影響，產生Bad Case。針對上述上線前校驗環節的各個問題，我們研發了圖靈沙箱，在不干擾線上業務穩定的前提下，實現了算法的全鏈路仿真實驗。
圖靈沙箱是一個與圖靈OS服務物理隔離但運行環境完全一致的服務，流量經過沙箱不會對線上業務造成任何影響。如下圖10所示，線上流量引流到線上環境沙箱，圖靈OS和圖靈沙箱的各環境配置及數據都一致（版本、參數、特徵、模型等）。算法新版本（如下圖10中算法包1的版本V3）先部署沙箱，引流驗證算法正確性，同時還可以在沙箱內引流進行算法性能壓測。圖靈沙箱作爲算法驗證流程的自動化工具，提升了算法測試效率，進一步提升了算法版本的迭代效率。
4.7 統一回放平臺
爲了方便分析算法效果及異常時排查問題，我們需要把算法計算過程中的輸入、輸出、所用的特徵以及模型等數據都記錄下來，以便還原現場。但是算法計算過程中會產生大量的數據，對存儲和記錄帶來了挑戰：
- 數據量大：一次請求可能對應多次算法模型計算，並且往往會用到豐富的特徵值，導致中間計算數據數倍於請求量。
- 併發量高：集中收集存儲各圖靈OS服務產生的數據，需要具備承載這些服務高峯期QPS流量之和的能力。
- 定製性強：圖靈OS部署了數十種不同的算法，他們的請求和響應格式千差萬別，特徵和數據源等數據更是難以統一。
爲了更好地記錄和存儲這些重要數據，圖靈OS設計研發了統一回放平臺，針對上述問題給出瞭解決方案，如下圖11所示：
- 採取ES和HBase結合存儲回放數據，其中ES存儲關鍵索引字段，HBase存儲完整數據記錄，充分發揮二者的優勢，同時滿足了快速查詢搜索和海量數據存儲的要求。
- 利用Google Protobuf的DynamicMessage功能，對原始Google Protobuf格式進行擴展，動態支持回放數據格式的定義及數據組裝，並支持與ES索引的同步，既保證序列化和存儲的高性能，也保證各算法數據的高效接入。
- 考慮到對這些數據查詢的時效性要求不高，使用消息隊列將發送和存儲進行解耦，達到對流量削峯填谷的效果，圖靈OS平臺中的各算法通過回放Client自動接入回放。
4.8 性能壓測及調優
通過圖靈沙箱和統一回放，圖靈OS具備了快速驗證算法數據正確性的能力，但是在算法計算性能分析方面缺少自動化工具。圖靈OS通過整合公司全鏈路壓測系統Quake（Quake介紹詳見《全鏈路壓測平臺（Quake）在美團中的實踐》）的能力，複用統一回放平臺採集的流量數據來構造請求，對部署了新版算法包的圖靈OS或圖靈沙箱進行壓力測試。
壓測過程中記錄算法在不同QPS場景下的性能表現，主要包括CPU和內存等應用指標，TP時延和超時率等響應耗時數據，並與線上真實性能、歷史壓測數據和服務承諾的SLA進行對比分析給出壓測報告及優化指南，存在明顯性能問題時將阻斷算法包的上線流程。圖靈OS也接入了美團內部性能診斷優化平臺Scalpel，可以生成壓測過程中線程堆棧和性能熱點的分析報告，輔助用戶快速定位性能瓶頸點，爲具體優化方向提供參考。
5. 圖靈OS 2.0建設成果
5.1 算法研發流程
通過圖靈OS的算法插件化改造和動態熱部署的能力，我們解耦了算法、工程和圖靈平臺，實現了算法與工程迭代的各自閉環，提升了研發效率，算法迭代上線週期大幅縮短：
- 當模型迭代、特徵變更及算法策略迭代時，算法工程師可以自主完成全鏈路的開發測試，無需工程研發人員和測試工程師的介入；同時算法包可獨立部署，無需任何服務上線，上線後周知到工程側及產品方關注相關指標變化即可。
- 當新業務場景和新算法策略接入時，還需要算法和工程共同開發，定義好Protobuf接口之後，算法工程師和工程研發人員可以各自獨立開發代碼，各自上線。
通過使用圖靈OS提供的沙箱引流驗證和性能壓測診斷等自動化工具，算法策略迭代的效率進一步提升，算法迭代上線週期大幅縮短，由天級別提升至小時級別。算法工程師自主開發，然後部署圖靈OS進行自測調試，部署沙箱進行引流測試，通過壓測平臺評估效果性能，最後自主部署上線，整個流程無需工程研發人員及圖靈工程師的參與，達到自動運維的目標；同時通過各種手段保證算法策略的執行性能及圖靈OS的運行穩定性。
5.2 圖靈OS 2.0使用匯總
圖靈OS（即圖靈在線服務框架2.0）建設已有大半年的時間，整體概況大致如下：當前已搭建20+個圖靈OS集羣，已接入25+個算法包、50+個算法，每月算法包部署上線次數200+次；每天支持百億次算法策略計算。通過圖靈OS賦能，大部分算法迭代整個流程無需工程研發人員、測試工程師的參與，算法工程師在小時級即可完成算法策略的迭代上線。
當前，一個圖靈OS集羣可承載單業務線的多個算法包或單個部門的多個子業務線算法包，算法包和圖靈OS集羣可動態關聯及動態部署，圖靈OS同時支持業務線級別和算法包級別的物理資源隔離。爲了方便業務方的使用，我們提供了完善的接入文檔和視頻課程。除了圖靈平臺方搭建圖靈OS集羣之外，任何一個業務方基本上可以在1小時內構建出自己的圖靈OS服務。我們同時提供了最佳實踐文檔與性能調優配置等，使得業務方在沒有指導的情況下可以自行解決大部分問題。目前我們正在建設自動化運維工具，進一步降低了圖靈OS的接入門檻和運維成本。
6. 總結及未來展望
當然，肯定沒有完美的算法平臺及算法在線服務框架，圖靈OS還有很大的進步空間。隨着我們對機器學習和深度學習線上服務的持續探索，會有越來越多的應用場景需要圖靈OS支持，未來我們會在以下方面持續進行建設：
- 建設圖靈OS自動化運維工具和自動化測試工具，支持算法半自動化開發，進一步降低平臺接入成本和運維成本。
- 進一步完善圖靈OS框架，完善算法支撐能力，支持在Spark環境運行，當算法迭代時，基於海量的數據驗證算法新功能的正確性、性能及效果。
- 推進圖靈OS全圖化引擎的建設，通過抽象算法業務的通用組件，提供圖形化流程編排工具和圖執行引擎，爲業務上線和算法迭代進一步賦能，進一步提升迭代效率。
7. 作者簡介
永波、季尚、豔偉、非凡等，均來自美團配送技術部算法平臺組，負責圖靈平臺建設等相關工作。
8. 招聘信息
閱讀美團技術團隊更多技術文章合集
前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試
| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
