1. 推薦系統(tǒng)業(yè)務現(xiàn)狀

從圖中我們可以看出，推薦系統(tǒng)大體可以分為三個階段，最初的探索階段，早在2010年左右，已經(jīng)有了千人千面的說法，現(xiàn)在我們在學習推薦系統(tǒng)時，看一些文檔或者資料，大都會拿亞馬遜基于協(xié)同過濾的推薦、豆瓣基于標簽的推薦系統(tǒng)做介紹，它們都是早期推薦系統(tǒng)應用在工業(yè)界的代表。到了第二階段 ( 普及深入階段 )，淘寶、京東以及一些垂直行業(yè)開始大范圍嘗試個性化推薦，此時，工程架構，算法策略層面都有了一些新的發(fā)展，比如一些大型推薦系統(tǒng)已經(jīng)開始向?qū)崟r特征，實時模型方向進行探索，以提升時效性，從而達到更好的推薦效果。到了第三個階段 ( 規(guī)模化精細化階段 )，進入移動互聯(lián)網(wǎng)時代，推薦已經(jīng)不僅限于PC端的單一場景推薦，出現(xiàn)了移動端及多場景的推薦需求?，F(xiàn)今，從拼多多、快手、抖音的推薦，再到百度、頭條的信息流推薦，推薦系統(tǒng)已經(jīng)成為一個網(wǎng)站的靈魂，驅(qū)動著各種各樣的業(yè)務場景，在這一階段，智能化，工程化，標準化，注重開發(fā)效率和成本已成了技術探索的新方向?？傮w看來，推薦系統(tǒng)的發(fā)展趨勢是一個從無到有，從有到精的過程，不管是工程，算法或者場景業(yè)務都有了深入的發(fā)展。

2. 業(yè)務趨勢

推薦系統(tǒng)從業(yè)務方面來說，呈現(xiàn)四個趨勢：

① 場景更豐富：早期做推薦的時候，推薦的開發(fā)門檻和成本很高，一個網(wǎng)站集中精力維護好一個場景，那時最經(jīng)典的場景可能就是主頁下方的"猜你喜歡"。到了現(xiàn)在，多端，多個資源位，更多的細分場景都會有推薦需求。舉個例子，從進入頁面的"猜你喜歡"，導航九宮格的推薦，再到列表頁或下單頁的"看了又看"，"買了又買"，乃至在一個資源位上多個時段都有個性化的需求。在技術層面上，過去一個系統(tǒng)支撐一個場景或者一種模式，或者為了簡單，一個架構，一個數(shù)據(jù)流，一個模型勉強應付多個場景，已無法滿足業(yè)務精細化運作的需要?，F(xiàn)在，一個推薦系統(tǒng)需要支持很多的場景，不同的場景也需要有不同的數(shù)據(jù)流，業(yè)務邏輯，模型來深入刻畫；另一方面，早期做推薦系統(tǒng)是一個門檻很高的事情，對工程、算法的要求比較高，且業(yè)務邏輯高度定制，很難標準化、低門檻的開發(fā)，而現(xiàn)在隨著場景越來越豐富，推薦需求的旺盛增加，原來的工作模式已不能滿足需要，推薦場景開發(fā)需要向靈活化，標準化，規(guī)?；l(fā)展。

② 運營更精細：從簡單規(guī)則 ( 比如像置頂，置底，黑白名單過濾 ) 向復雜規(guī)則轉(zhuǎn)變，通用規(guī)則向個性化規(guī)則轉(zhuǎn)變；技術主導變?yōu)榧夹g+業(yè)務聯(lián)營。推薦系統(tǒng)的效果好壞不再全是技術主導，業(yè)務也利用內(nèi)容物料，規(guī)則玩法等運營手段發(fā)揮重要的作用。

③ 服務更實時：早期推薦模型都是基于歷史數(shù)據(jù)采用離線批量的方式構建，離線的特征，離線的模型，導致系統(tǒng)時效性差，用戶實時或近實時行為的影響無法體現(xiàn)在推薦的結(jié)果中，用戶體驗不好。讓用戶能夠更快感受到變化，批量非實時向流式實時閉環(huán)推薦發(fā)展是推薦效果提升的必然趨勢。

④ 未來的重要趨勢：系統(tǒng)更智能，更知心。早期的一些簡單算法或者規(guī)則，被更豐富，更復雜的AI算法所替代。推薦系統(tǒng)與AI結(jié)合的越來越緊密。推薦系統(tǒng)已經(jīng)成為AI賦能的重要場景之一，如何構建一套對AI友好的推薦系統(tǒng)，在技術上也是一個很大挑戰(zhàn)。

3. 帶來的技術挑戰(zhàn)

① 當前推薦系統(tǒng)的基本架構

在前面所講的業(yè)務大趨勢下，推薦系統(tǒng)技術層面正面臨一些挑戰(zhàn)。我們先了解一下當前推薦系統(tǒng)的基本架構，一般分為五個板塊：

• 數(shù)據(jù)流：推薦系統(tǒng)的特點就是高度和數(shù)據(jù)流相關，那么技術層面要解決數(shù)據(jù)怎么來，數(shù)據(jù)怎么用，數(shù)據(jù)怎么加工處理，正確性和時效性如何保證等問題。

• 離線板塊：系統(tǒng)內(nèi)涉及到一些數(shù)據(jù)加工，任務處理，模型生產(chǎn)，指標報表等離線任務，怎么協(xié)調(diào)這些任務有序高效進行，并獲得正確有效的結(jié)果。

• 在線板塊：推薦系統(tǒng)對外提供實時推薦的能力，涉及到諸多的在線處理過程和規(guī)則。如何在適應業(yè)務快速變化的同時保證可用性和性能是至關重要的。

• AI：當下推薦系統(tǒng)的重要組成部分，其包含整個AI模型生成到服務的全生命周期。如何從系統(tǒng)層面支撐AI全生命周期以及如何有機集成進系統(tǒng)是一個挑戰(zhàn)。

• 基礎設施：推薦系統(tǒng)是一個多領域交叉的綜合應用，需要有眾多的中間件、基礎組件做支撐，如何管理和運維，減少依賴，有效利用是一個重要的命題。

上面說的五大板塊，對照起來實際上就是這張示意圖。虛線框是數(shù)據(jù)流，藍色框是離線部分，黃色框是在線部分，綠色的是基礎組件。相較于簡化的示意圖，在實際系統(tǒng)中，會變得更加復雜。比如就日志或數(shù)據(jù)收集這一部分，日志就可能因為來源，收集方式多樣，導致開發(fā)，維護和管理的復雜度激增。各家公司的推薦系統(tǒng)涉及到大量的應用服務和中間件，它們的技術選型，實現(xiàn)方式，部署方式并不完全一致，但是整體邏輯結(jié)構卻是可以映射到剛才提到的五個板塊內(nèi)。但是這樣的架構存在什么問題呢？我們可以結(jié)合四個趨勢來看，如果只針對性的支撐一個場景，這樣是可以的，但是當場景變得更多，更精細，問題便出現(xiàn)了。比如"猜你喜歡"，"看了又看"，召回物料可能不一樣，召回的算法邏輯可能不一樣，精排模型可能不同，甚至整個處理流程也可能不一樣，而它們卻在一個代碼模塊中，各場景的邏輯必然會形成耦合，互相影響，繼而影響系統(tǒng)穩(wěn)定性。另一方面，因為板塊割裂，很多領域邏輯分散在服務或中間件中，比如數(shù)據(jù)處理一般采用Azkaban/Airflow一類的中間件系統(tǒng)去調(diào)度處理任務，這就不可避免的將業(yè)務邏輯用大量的膠水代碼封裝在中間件系統(tǒng)中，如果一個開發(fā)者想要了解一個推薦系統(tǒng)的業(yè)務流程，就會變得非常困難。隨著業(yè)務的不斷發(fā)展，這一現(xiàn)象會加劇，大量的場景規(guī)則，服務，運營策略，算法模型越來越多，最終導致系統(tǒng)難以維護，變成誰都不敢動的“老古董”。

② 當前推薦系統(tǒng)面臨的技術挑戰(zhàn)

我簡單的總結(jié)了一下，主要有四方面的挑戰(zhàn)。

a. 開發(fā)運維部署遷移困難，曲線陡峭，效率低下。因為推薦系統(tǒng)等智能系統(tǒng)，都涉及到大量的基礎組件和服務，各有特點，缺乏一體化的管理運維手段，如何把完整系統(tǒng)搭起來并管理，期間中間件或者服務出問題，都可能會導致系統(tǒng)不可用。這對于沒有豐富的組件維護經(jīng)驗或者人力不足的團隊來講，是一個巨大挑戰(zhàn)。

b. 這實際上是一個應用治理的問題，服務，流程，規(guī)則，策略，數(shù)據(jù)，產(chǎn)物繁多，組織管理困難。圖中任何一個框是一種服務，也可能是若干個服務，這些服務之間的依賴不直觀，很難管理。數(shù)據(jù)流邏輯繁瑣復雜，系統(tǒng)有很多的離線數(shù)據(jù)流，在線的數(shù)據(jù)流，還會產(chǎn)生大量數(shù)據(jù)產(chǎn)物，缺乏標準化的管理，極易出錯。不同場景的差異化難以組織，不同的服務，策略間相互影響，其中一個可能表現(xiàn)就是在一個服務模塊代碼中因為要處理不同場景的邏輯而產(chǎn)生大量if分支邏輯。從架構上講，一個好的場景服務應該是縱向切分的，不同的場景是不同的系統(tǒng)，場景間互相隔離，但這又會導致系統(tǒng)資源浪費，管理上面也很麻煩。因此，需要采取更加系統(tǒng)化的方法去治理它。

c. 系統(tǒng)涉及到數(shù)據(jù)/在線/離線/AI各個領域，技術棧割裂，整個推薦流程需要大量的膠水代碼來整合集成。而膠水代碼的一個特點就是難以復用，不同人之間也難以維護。這樣的割裂突出表現(xiàn)在以下三點：

• 眾多領域技術，彼此割裂，難以集成

• 數(shù)據(jù)質(zhì)量難以保證，效果也無法保證

• 定制性膠水代碼驅(qū)動，無法復用，遷移

d. 大量重復程序化工作難以避免。在面臨支持多個場景的情況下，表現(xiàn)很突出。落地一個新的場景，可能需要各個系統(tǒng)配合開發(fā)，部署，而且這個過程是高度重復和繁瑣的，最終導致成本很高。這也是現(xiàn)在大一點的公司，為了效率和標準化，開始推動推薦系統(tǒng)中臺化建設的一個原因，其目的是能夠在一個平臺上低成本的完成場景的快速開發(fā)和應用。

上述這些問題的表現(xiàn)都可以用一個字來總結(jié)，那就是"亂"。

4. 如何戡"亂"

那么我來講一講如何戡亂，首先我們深入分析一下亂的原因。

① "亂"的原因：

a. 智能系統(tǒng)特有的復雜性，涉及到龐大的服務依賴，數(shù)據(jù)依賴，知識依賴。推薦系統(tǒng)涉及到的服務模塊很多，而一個服務又涉及多個依賴，整個服務的依賴關系就會很復雜，從而管理上就需要很大的成本。數(shù)據(jù)依賴層面，系統(tǒng)涉及到大量的原始攝取數(shù)據(jù)，中間加工數(shù)據(jù)，以及最終的結(jié)果服務數(shù)據(jù)，數(shù)據(jù)的質(zhì)量對最終的推薦效果影響是至關重要的，而這種依賴又非常的隱含，極易出錯還難以排查。最后，特別提出"知識依賴"這一概念，推薦系統(tǒng)一直以來在應用系統(tǒng)中以其技術復雜性著稱，其在工程上，策略上，數(shù)據(jù)處理上，算法模型上，有很多模式經(jīng)驗及潛在技能門檻。但這些知識在系統(tǒng)中是隱性的，存在于架構師、專家的腦袋里面，并沒有固化和沉淀到系統(tǒng)內(nèi)。強依賴架構師憑借自己的認知和經(jīng)驗去構建，驅(qū)動整個系統(tǒng)流程。而正是因為是人來主導，那自然會隨著人的水平的高低以及偏好，產(chǎn)生實現(xiàn)上的差異，難以沉淀和繼承，后期持續(xù)演化也會很脆弱。

b. 領域架構缺失 現(xiàn)有的框架都在解決局部問題，需要抽象出一層專門解決推薦場景應用開發(fā)領域自身的問題。比如Airflow是做離線任務調(diào)度領域的平臺工具，F(xiàn)link是做數(shù)據(jù)處理領域相關的框架，這兩者都是各自領域很優(yōu)秀的框架或平臺，但是要解決推薦領域的問題，他們都只能解決其中部分子領域問題，缺失一個面向推薦領域的一體化平臺或框架，其結(jié)果就是從業(yè)務問題直接穿透到子領域?qū)?，在實現(xiàn)上，缺乏抽象和隔離，使用膠水代碼將下層服務拼接在一起完成邏輯實現(xiàn)。雖然子領域框架能夠解決了一些局部問題，但它們之間如何協(xié)同，管理，以及在其之上更有序的解決推薦領域?qū)用娴臉I(yè)務問題成為了如何讓架構更好服務場景業(yè)務的關鍵。所謂戡亂，就是需要形成一個中間推薦場景開發(fā)的領域?qū)?，承接服務依賴，?shù)據(jù)依賴，知識依賴，并協(xié)調(diào)子領域服務更有效工作。

② 這一層應當如何做？

a. 統(tǒng)一的場景開發(fā)和管理接口。對于上層來講，開發(fā)一個"看了又看"，"買了又買"等不同的場景，開發(fā)過程和接口應該是相似的，只需要面向這一層開發(fā)，無需關注下層細節(jié)。

b. 統(tǒng)一的底層架構和集成標準。下層非常復雜，涉及到眾多子領域，作為開發(fā)者，常常在選型和集成上犯難，也無法將它們協(xié)調(diào)起來，那么我們需要這一層能夠把復雜度給屏蔽掉，開發(fā)者面對的是統(tǒng)一的數(shù)據(jù)結(jié)構和接口規(guī)范，而無需關注具體的執(zhí)行層選型和實現(xiàn)。

c. 領域內(nèi)要素治理：

• 合適粒度的領域?qū)嶓w抽象及實現(xiàn)。在推薦服務中，有大大小小的服務，規(guī)則，策略及數(shù)據(jù)，我們稱之為領域資源要素，它們需要有合適的領域抽象和粒度，粒度不能太大，也不能太小。是一個規(guī)則那么我們就用規(guī)則去承載，如果是一個服務，那么我們就應該用一個服務來承載。這樣能夠在提供靈活性的同時，控制整體復雜性

• 統(tǒng)一靈活的管理方式。我們需要針對領域要素有統(tǒng)一靈活的管理方式，領域的業(yè)務邏輯通過統(tǒng)一的編排管理方式來構建。

• 成熟可復用的單元。資源要素的載體是成熟可復用的單元，組件、策略等避免重新開發(fā)，產(chǎn)生重復的成本，應該通過復用讓使用者更低成本使用。

有幾個指導思想，來指導我們具體應該如何將這一層做好。

02

推薦系統(tǒng)"治理"的指導思想

1. "治理"的指導思想

① 聲明式 ( Declarative )： 解決復雜系統(tǒng)，復雜流程管理的靈丹妙藥。早期在沒有k8s的時候，微服務運維管理是一個復雜的過程，需要人工編寫很多的腳本完成應用的部署更新擴縮容等工作，使用者必須明確描述其所有操作細節(jié)。因為相對于聲明式，這種過程命令式的運維腳本，需要使用的人要能夠掌控過程執(zhí)行所有細節(jié)，這對于大型復雜系統(tǒng)來講是一個很大挑戰(zhàn)。聲明式編程的思想流行會使這樣的工作大大簡化，服務負責內(nèi)部自身復雜運行邏輯，上層使用者只需要聲明出自己的目標即可，系統(tǒng)自動幫你完成，無需關注其達成目標的具體過程。就像SQL一樣，之所以大家用著覺得簡單，其很大原因是SQL就是一個聲明式的編程語言。這一思想已經(jīng)逐步成為架構師解決復雜系統(tǒng)管理的推薦思路。比如，當下很熱門的運維部署框架Ansible，運維人員只需要按要求編寫安裝部署劇本，系統(tǒng)就會自動安裝和部署相應的服務。

② 框架平臺：在目標定位上，是開發(fā)一款工具，還是開發(fā)一個框架平臺，會直接影響到我們的系統(tǒng)設計決策。工具的特點是被集成，可以為使用者提供更靈活有效的手段解決具體問題，但對于使用者本身有比較高的要求，最終結(jié)果如何，高度依賴使用的方式。而對于框架來講，將實現(xiàn)過程讓渡給框架，開發(fā)者無需了解全過程，只需要按照框架提供的規(guī)范進行開發(fā)即可，這一定程度約束了開發(fā)者的行為，也降低了上手門檻，這實際上是依賴反轉(zhuǎn)思想的體現(xiàn)。我們提到的知識依賴，就可以通過框架或平臺把它們沉淀下來。而使用者自然會在框架的幫助下，使其開發(fā)的系統(tǒng)是相對可靠的。比如web開發(fā)框架Spring，亦或是持續(xù)集成平臺Jenkins，它們的作用就是提供一個領域業(yè)務模式或流程，能夠使得初學者只需要掌握平臺或框架的使用便能在其領域達到一個比較高的水平，獲得方法論指引，避免前人的錯誤。

③ 組件化：其特點是標準化，復用性和靈活性?？蚣芎退且来骊P系，是它的契約，組件是按照契約去實現(xiàn)及被集成。

④ 低代碼 ( LowCode )：特點是簡單，快速。當下比較熱門的概念，一個框架或者平臺，不需要寫代碼或者少寫代碼就能夠完成開發(fā)，是基于框架開發(fā)基礎上的更進一步，能夠?qū)I(yè)務過程，核心邏輯封裝成一些低代碼的模塊，這對于簡單化業(yè)務過程，降低使用門檻有很大的幫助。

2. FlowEngine

基于上述的挑戰(zhàn)及解決思路，第四范式研發(fā)了這樣一個聲明式的、低代碼的、組件化的智能場景開發(fā)和管理的框架平臺。在這個框架基礎上可以快速開發(fā)和管理推薦等智能場景。

03

Flowengine架構

接下來簡單介紹一下Flowengine架構，它位于場景業(yè)務服務和子領域執(zhí)行層之間。它的出現(xiàn)其目的便是將我們?nèi)笔У念I域?qū)友a充上。

1. 表現(xiàn)

Flowengine提供了一套聲明式API，可用來創(chuàng)建，管理智能場景 ( 推薦 )，表現(xiàn)為以下方面：

• 場景沉淀，遷移，快速構建。在框架無狀態(tài)的前提下，將應用邏輯，業(yè)務規(guī)則和服務依賴保存成一個方案文件，從而做到可以在不同的Flowengine平臺下無痛遷移分享。

• 領域要素 ( 組件，JOB，F(xiàn)UNC等 ) 的管理，集成，更新。提供要素的開發(fā)，發(fā)布，集成，運行等全生命周期管理，使得其能夠在明確的標準下被集成和管理。

• 業(yè)務邏輯編排 ( 批/流/在線pipeline )。場景業(yè)務邏輯是對領域要素的邏輯編排，這就使得其天然具備敏捷性，業(yè)務上也能做到垂直切分隔離，卻共用相同的執(zhí)行底層。在業(yè)務隔離和資源共享層面達成了統(tǒng)一。

• 預置核心組件及標準流程方案。簡單的業(yè)務可以通過已有方案自動的生成推薦服務，達到開箱即用的目的。如果存在場景差異也可以在此基礎上進行修改和完善，但修改過程僅僅發(fā)生在方案場景層面，從而有效的控制了修改風險蔓延，做到了框架與方案的分離，從而在易用性，規(guī)范性與靈活性，差異性上達成了統(tǒng)一，這個在傳統(tǒng)架構上是一個不可調(diào)和的矛盾。

• 標準化的底層集成方式，上層簡單，下層開放。標準化的底層集成方式，均采用業(yè)務組件或技術組件的方式集成，對上層呈現(xiàn)為可被pipeline編排的資源要素，使用者無需關注執(zhí)行層差異。這樣就保證了上層是接口簡單，下層是開放的。

2. 構成與基本實現(xiàn)

簡單說一下它的構成：

• Flowengine-Hub：用于存放方案，組件，F(xiàn)UNC/JOB等資源要素的倉庫。

• EngineManager：用來管理和監(jiān)控引擎并作為適配層屏蔽下層復雜度。

• EngineKernel：單個引擎的核心，用于管理當前引擎領域?qū)嶓w，業(yè)務流程，并提供運行環(huán)境及通信支持。

• Flowengine-Data：一個AI/BI為一體的數(shù)據(jù)服務，用于管理引擎數(shù)據(jù)、元數(shù)據(jù)及對外提供統(tǒng)一的數(shù)據(jù)流服務。

基本實現(xiàn)：

• 基于k8s微服務管理。從大的架構上看，F(xiàn)lowengine是一個CloudNative架構，通過利用k8s的能力，實現(xiàn)了引擎內(nèi)微服務的管理及動態(tài)化。一個引擎是由一個或者多個微服務共同組成，運行組件的標準格式是在docker鏡像基礎上再封裝而來，天然容器化友好。另外，在Docker和k8s的支撐下，框架對于基礎環(huán)境的復雜性有了很好的適應能力。

• 在計算引擎層面，集成了Spark，F(xiàn)link以及自研的模型訓練 ( GDBT ) 等框架，通過進一步的集成優(yōu)化，使得開發(fā)者無需關注這些框架的使用細節(jié)，通過統(tǒng)一的編程接口便能夠完成開發(fā)。

• 批流一體的數(shù)據(jù)流管理及元數(shù)據(jù)管理，引入數(shù)據(jù)攝取，加工，服務三個過程，抽象出一，二，三級表的抽象表概念，開發(fā)者無需關注數(shù)據(jù)的存儲和計算細節(jié)，采用統(tǒng)一的方式完成數(shù)據(jù)流開發(fā)，從而降低開發(fā)的復雜度及分散性。

• 業(yè)務編排框架。提供批，流，在線三大可視化業(yè)務編排能力，使得業(yè)務邏輯開發(fā)變成了無代碼的拖拉拽操作。另一方面，通過集中的編排管理及任務分發(fā)，解決了場景業(yè)務邏輯散落在各個執(zhí)行組件中的問題。在引擎層便能夠管理業(yè)務全過程，這對于后期開發(fā)維護都大有幫助。

接下來我們介紹一下應用Flowengine之后的架構是什么樣子的。

04

應用Flowengine后推薦的架構

1. 業(yè)務分解與技術映射

業(yè)務分解：如圖，業(yè)務上一個推薦的場景大體是這樣的，它包含在線的業(yè)務流程，這一個流程大體可以分為召回，過濾，粗排，精排等幾個部分，這里通常會因為業(yè)務過程的變化而變化。另一塊是數(shù)據(jù)處理及離線處理，這里會有數(shù)據(jù)怎么獲取，加工，以及提供給在線服務使用的邏輯。它也會隨著業(yè)務變化而變化。最后一部分，對于智能推薦，人工智能的作用舉足輕重，它包含數(shù)據(jù)接入處理，特征工程，模型訓練，模型服務等多個過程，這其中也包含了離線和在線等諸多服務模塊。

技術映射：那么，對于上述分解出的三大業(yè)務部分，在Flowengine框架上如何映射呢？轉(zhuǎn)化到Flowengine上面，我們用引擎的概念來映射，一個推薦場景就是一個引擎，如圖，這個引擎我們可以起名叫reco-engine，這個引擎里存在一個在線編排的pipeline叫reco-func-pipeline，而它就具備把推薦服務流程通過編排表達出來形成在線服務能力。Flowengine-Data支持數(shù)據(jù)的接入，它提供數(shù)據(jù)的攝取和服務的能力，比如說是kafka數(shù)據(jù)引入，ES或者Mysql的服務輸出，并提供數(shù)據(jù)表之間的處理能力，開發(fā)者只需要關注數(shù)據(jù)流本身的處理邏輯，而無需關注數(shù)據(jù)的存取和調(diào)度。而對于AI模型服務來講，它也是一個引擎，在引擎內(nèi)部便能完成AI模型從開發(fā)到部署的全流程。場景引擎reco-engine只需要在需要模型服務時調(diào)用該AI引擎的服務即可。這樣我們一個推薦的場景就變成了一個主場景引擎及若干AI模型引擎構成，而它們的底層資源管理和調(diào)度都無需場景開發(fā)者關心。和我們之前講的傳統(tǒng)架構比，結(jié)構上清晰了許多，而這一切都歸功于必要的領域?qū)映橄蟆?/span>

2. 帶來的價值

接下來我們總結(jié)一下應用了Flowengine之后帶來的價值：

• 面向Flowengine聲明業(yè)務過程，簡單，統(tǒng)一。聲明元數(shù)據(jù)，聲明編排過程。我們不需要管理執(zhí)行層的具體細節(jié)，使得復雜度大大降低，業(yè)務過程也變得更加標準化。

• 服務及中間件數(shù)量減少，資源消耗減少，維護方便。推薦系統(tǒng)因為業(yè)務上的發(fā)展，會增生很多小服務，這些服務管理麻煩，還占用資源。比如說推薦系統(tǒng)一般會一個兜底的服務，定期生成靜態(tài)的推薦結(jié)果，用來在正常推薦響應失敗時降級出推薦結(jié)果。在Flowengine的支持下，可以通過創(chuàng)建一個離線的pipeline解決這類需求，那么這樣的小服務就可以避免。

• 邏輯分層，合適的拆分粒度。服務，策略，腳本，配置都能夠合理安排，體現(xiàn)最小知識原則，其靈活性，復用性更強。

• 減少大量膠水代碼和重復代碼，串聯(lián)流程基于編排框架，無需再自己管理流程，聲明配置即可，低代碼，效率高，好管理。開發(fā)方案和使用方案分離，分工會更加清晰，也便于經(jīng)驗及方法論傳遞。

• 場景縱向隔離，便于業(yè)務差異化發(fā)展，業(yè)務不能綁架技術，技術更不能綁架業(yè)務。在引擎層面做到相互隔離，一個引擎就是一個場景，開發(fā)，升級，變更都能夠互不影響。

• 服務運維，環(huán)境遷移部署更便利，CloudNative架構，無狀態(tài)設計，方案可導入導出。從解決思路上講，Docker解決了單一服務的遷移問題，而Flowengine解決場景的遷移問題。

最后給大家做一些實例的展示。

05

實例演示

Flowengine支持頁面、SDK和CLI多種操作方式。左側(cè)是引擎Web管理界面和CLI截圖。右側(cè)是一個應用方案包結(jié)構，包含了應用的定義meta_info.yaml以及依賴組件的定義。

下圖是Flowengine-data 的管理界面，可以管理數(shù)據(jù)表及數(shù)據(jù)攝取，加工，服務的處理過程。

最后是業(yè)務編排的操作界面。它包含離線編排，在線編排，流式編排。

06

總結(jié)

隨著智能場景越來越多，原來項目式，單點式的場景開發(fā)維護，必然導致整體研發(fā)成本的爆炸性增加。正如十來年前，web應用的大發(fā)展，催生了大量優(yōu)秀的web開發(fā)框架一樣，智能場景應用的大發(fā)展也將會重演這樣的歷史。Flowengine正是我們在這一領域的探索，以我們對智能應用的架構理解，構建一套加速開發(fā)和運維過程的框架平臺，跟進未來的發(fā)展趨勢。

李瀚

第四范式 | 平臺架構師

李瀚，第四范式先知平臺架構師，十余年大型互聯(lián)網(wǎng)推薦，搜索系統(tǒng)架構設計開發(fā)經(jīng)驗。負責業(yè)務產(chǎn)品的整體架構設計工作。目前重點聚焦在自研AI場景領域系統(tǒng)開發(fā)框架 ( FLowEngine ) 的設計研發(fā)及推薦，搜索等智能系統(tǒng)應用架構設計及落地。