背景
随着高德地圖業務的快速開展，除了導航本身的算法業務外，其他中小型業務對算法政策的需求越來越多、越來越快，近兩年參與的一些新項目從算法調研到應用上線都在一周級，例如與共享出行相關的各種算法服務，風控、排程、營銷等各個體系的業務需求。類似于傳統導航中成熟的長周期、高流量、低延遲時間的架構和開發方式已無法滿足此類業務初期的快速試錯和優化改進訴求，找到合适的為業務賦能的算法服務方式就變得勢在必行。
在落地實施的過程中，采用一體化架構。所謂的一體化是指整個算法、工程一體化，涉及資料、系統等全鍊路打通，實作資料流的系統化流動；算法業務調研兼顧工程服務開發，測試、驗證過程自動化、智能化，進而形成業務閉環，推動業務的快速疊代。
項目初期，需要快速試錯和政策優化。此時，業務需求的QPS往往不高（<1k），是以，傳統的應用開發和部署方式，一方面拖慢了業務節奏，另一方面浪費了大量資源。
在此過程中，我們希望達到的目标就是離線政策調研即服務邏輯開發，離線調研完成即服務化完成，這樣就能夠顯著降低算法調研到政策上線的時間。因為性能（QPS、RT）壓力不大，離線用Python進行快速的開發就成為可能。
從長期看，随着業務逐漸成熟，算法快速組合、服務調用量和服務性能成為衡量算法服務重要的評價标準，此時合理的優化就應該被向前推進，例如核心算法邏輯高性能化将會變成重要的工作。
是以，算法工程一體化的建設過程也就是滿足業務從初創期到成熟期疊代的過程。
系統總體邏輯架構
- 統一接入網關服務
- 業務算法透出服務
- 算法模型及代碼管理服務
- 品質保障體系
注：GBFC為資料服務層，主要用于擷取各種算法所需要的資料和特征，讓業務算法服務達到無狀态的條件，同時也便于資料在各條業務線的共享和共建。
統一接入網關
網關服務目的是将各種算法API進行隔離，提供原子服務群組合服務。業務端需要調用各種算法如價值判斷、風險預估、營銷推薦時，統一網關對各個業務提供統一算法API，避免各個服務重複調用。算法網關對算法進行統一監控，包括服務性能，接口可用性等，同時對資料進行統一收集，便于資料管理和特征生産，進行實時線上學習，提升使用者體驗，保障算法效果。
網關服務一方面可以進行一些共用的預處理操作，例如鑒權、路由、限流、降級、熔斷、灰階、AB、陪跑等，用于保障服務的可用性和擴充性。同時又能進行服務組合，例如語音識别、圖像處理等，使得各個算法服務能夠有機的結合在一起，這樣使得業務算法層隻需要維護原子性服務，即可進行複雜的業務處理。
是以，網關服務必然需要一個靈活、彈性、輕量、無狀态的算法業務層的支撐，在技術選型方面，目前火熱的Serverless架構剛好能夠很好的滿足上述需求。
Serverless架構上的業務算法服務
2009 年，伯克利以獨特的視角定義了雲計算，尤其是最近的四年，這篇文章被大量引用，其中的觀點剛好非常契合業務初期的技術場景，比如減少服務化的工作，隻關心業務邏輯或算法邏輯，實作快速疊代、按需計算等。2019年，伯克利又進一步提出：
Serverless所提供的接口，簡化了雲計算的程式設計，其代表了程式員生産力的又一次變革，一如程式設計語言從彙編時代演變為進階語言時代。
在目前關于Serverless的探索中，FaaS基本被認為是最佳範例，這與其自身特點有關。FaaS非常輕量級，無狀态，運作快，對于純粹的無狀态應用特别合适，雖然在冷啟動層面存在一些瓶頸，但這種架構還是解決了很多問題，而業務初期的算法快速實踐，剛好與這種架構的特點相契合。
在Serverless架構的基礎之上，我們對算法服務按照下圖的方式進行了部署。
按照上圖所示，算法服務在本地開發完成後，可以直接作為Function進行釋出，即之前所說的離線政策調研完成的同時就是服務代碼完成。而這個特性也很好的解決了算法同學和業務脫節的問題，很多算法同學無法獨立完成整個工程服務開發，需要将代碼送出給工程人員進行整合、包裝、釋出，但這種協作方式在整個業務鍊條中是不合理的。
一方面算法同學無法獨立完成業務支撐，另一方面，工程同學不僅要處理邏輯調用，還需要花時間去了解目前算法實作方式、原理、所需資料、異常情況等各種問題，經常是一個相對簡單的算法服務，會議和溝通占據了絕大多數時間，是以引入FaaS不僅簡化了這個業務開發流程，同時也讓算法部署盡量是原子化，友善業務間組裝複用。
我們在實作的路徑上，首先完成了Python的運作時環境的建構工作，能夠将Python代碼及相關模型直接服務化，模型部分支援PMML,TensorFlow等，這樣就實作了業務初期所需要的快速疊代，減少試錯成本的訴求。
此後會逐漸完善基于Golang,Java等運作時環境，選擇Golang的原因是對于并行性支援良好，不僅可以實作業務所需要的性能訴求，同時又保留着開發相對簡單的特點。
經過算法原子化、函數化後，就賦予了算法同學獨立負責線上業務的能力，但也帶了幾個嚴肅的問題：服務的穩定性，工程的品質，服務的正确性。如果簡單的把這些扔給算法同學，就僅是工作量的轉移，并且還可能引起整個業務的當機風險。是以，品質保障體系建設就變成了重要的一環。
品質保障體系建設
很多人會認為，要做品質保障，就是送出到測試人員進行測試或回歸測試，其實不然。前兩部分省卻的人工成本被轉移到測試同學的身上，因為算法同學的工程化能力相對偏弱，是不是就要引入更多的測試同學做驗證？
如果抱着這種思維，那麼，業務的疊代速度依然無法快速起來。是以就必須考慮：這種品質保障能否完全的自動化呢？答案是肯定的。
在政策的調研過程中一般會經曆以下幾個步驟，1. 資料分析；2.算法設計；3.資料驗證；4.人工/自動評測；5.政策疊代重複步驟1-4。在這個過程中，剛好包含了品質保障體系所需要的資料、資料集、測試集及驗證集。
算法同學可以通過使用三個集合實作自動化的壓測流程，輸出QPS、RT、一緻率等相關資訊，使用資料集，實作穩定性測試；使用測試集，實作了邏輯正确性驗證；通過驗證集實作了效果測試。
當然，上述隻是品質保障的一部分。一般業務快速疊代的過程中，常常需要進行AB驗證，或者是全量陪跑驗證，在過程實施中通過引流和過程鍊，我們實作了全量陪跑的過程，對待上線的算法實作了全方位的品質評估。
小結
算法、工程的統一化建設基本實作了業務初期的快速疊代需求。在項目開展的過程中，對工程同學的挑戰除了來自于工程化實踐外，同時也需要對業務所處的階段要有清晰的認識。
目前情況下，算法和工程之是以可以獨立開展，有一個必要的前提是資料和算法分離，也就是算法服務是無狀态、函數化的。正是因為如此，也需要花費不少的時間在特征服務層的建設上。同樣，特征服務層的建設也可以遵循相似的邏輯實作共建、共享。
最後需要再次說明的是，算法工程一體化的架構設計能夠基本滿足業務類算法的訴求。但對于一些對計算量要求巨大的AI項目，頻繁的資料擷取導緻的算力、功耗瓶頸已經明顯制約算法創新。業内正在通過将資料存儲單元和計算單元融為一體，實作計算存儲一體化的硬體架構革新，突破AI算力瓶頸。