本文作者：[帝青]

在實際業務需求背景下，TangoFlow 尋求構建組裝式架構，整合雲音樂服務端技術棧，提供基礎邏輯編排功能，以某種方式（網關API、統一SDK等）暴露編排結果；從長遠來看，作為研發全鏈路低代碼化中的一環，構建符合雲音樂現狀及長遠願景的服務端低代碼平台；今天我們一起來聊下TangoFlow 的產生背景以及平台化建設實踐；

背景及訴求

1、BFF場景下靈活編排訴求

目前雲音樂的前後端協作基於Restful API進行交互，服務端在Controller層通過來自RPC的原子接口數據，組裝出前端視圖需要的數據並返回給前端，所以會存在客户端相關接口的契約定義對服務端有深度依賴，導致在協作上存在大量的溝通成本以及排期依賴，同時由於客户端UI的多變性，導致服務端面向客户端接口複用性較差，大前端同學苦惱於難以得到自己想要的數據，而服務端同學基於自己並不熟悉的視圖拼接模型數據時也感到異常痛苦。

BFF 研發模式一直是業界廣泛青睞的前後端協作模式，它能有效解耦前後端在協作上的依賴關係，從而大幅度提升研發效率，目前雲音樂內部已經完成基於GraphQL的BFF的研發模式提供，這種研發模式在雲音樂內部有較為廣泛的落地，在2022年完成了基於GraphQL的BFF應用建設解決上述問題， 目前已在較多團隊中推廣使用，但隨着使用會存在以下問題：

• 受限於GraphQL引擎，編排能力不足：GraphQL是一種用於API的查詢語言。可以將GraphQL看作一種新的API標準，它提供了一種高效、靈活的數據提供方式，但基於GraphQL引擎存在一些限制，在較為複雜的邏輯處理上無法進行靈活的編排，在組裝RPC服務時，會存在很多個性化需求，目前是通過groovy腳本輸入做輸出做重新的組裝，腳本內部存在大量業務邏輯，導致groovy腳本濫用；
• 降低資源開銷：當前BFF應用採用的是一個febase應用對應一個BFF後端引擎服務集羣，目前測試、預發、線上都會創建對應的引擎服務集羣，但基本無流量，且線上流量也都比較低，所以會存在大量的資源浪費；
• BFF引擎服務集羣存在運維分工不清晰現象，缺乏機制保障，目前前端同學負責對BFF API接口搭建、自測、完成接口交付，但對於引擎服務集羣穩定性、容量水位缺少評估經驗，同時服務穩定性偏後置，在穩定性和容量水位服務端同學做的會更多一些，會更有經驗；

2、業務上的編排訴求

• 尋求業務架構可編排能力，基於現有業務沉澱服務資產，靈活快速高效編排出符合業務需求的流程，並以觸發器（網關API服務、RPC服務、本地資源... ...）的形式暴露流程服務；
• 活動場景編排提效：在活動場景下， 玩法中台之前產出了輕量級流程編排組件（在產品調研中有提及：《輕量級流程編排組件介紹》），由於接入比較較為複雜，平台使用體驗一般，導致推廣不是很廣泛，對於玩法中台場景存在較多可沉澱的場景，能夠通過複用已有資產組裝完成新的業務場景；

3、標準化推進落地困難

• 規範落地難： 目前雲音樂存在諸多規範，但在真正落地效果上並不是很好；
• 調試測試效率低： 目前在網易PostMan在公司是禁用的，所以現在大家都在GoTest上使用，使用起來會比較重，且會存在跨平台/工具的操作，使用體驗、效率比較低，測試代碼運行大多需要啓動整個應用，而應用的啓動通常都是分鐘級的，這就導致我們研發效率進一步降低。
• 服務治理能力弱： 代碼本質上是非結構化的文本數據，我們很難基於代碼進行統計，此時接口和服務、工具間的依賴關係就顯得尤為重要，但基於編碼的方式我們是很難做到精準統計，雖然有一些調用鏈追蹤工具可以提供幫助，但還是不夠直接，還是需要人肉的去做進一步的識別；服務治理能力（限流、降級、靜態化、Redis治理... ...)仍然較為分散，應用維度治理能力仍然需要跨平台操作，易用性、開發者體驗仍需提升；
• 降低資源開銷： 一方面是BFF自身的資源開銷問題，另一方面，現在微服務比較多且佔用資源不一，如何將微服務合併為一個微服務，進一步降低成本

4、全鏈路低代碼建設

對於一個完整的 web 應用來講，會經過用户界面-接口服務-數據服務等多個模塊，目前雲音樂已完成了前端低代碼的建設，已經大大提升了UI層的交付效率，接下來會在整個鏈路上進行嘗試，對於服務端的邏輯編排、服務編排以及更長遠的基於模型編排驅動方式，是我們重點關注的對象，期望能夠從全鏈路上降低開發成本、提升交付效率和質量；

所以基於上述背景，我們規劃、設計流程編排平台，對於BFF應用，主要是解決編排的問題，同時支持更復雜的編排場景，服務編排出來的產物可以是RPC、API服務，編排出來的RPC、API服務直接集成在BFF中，靈活解決BFF應用的服務編排問題，同時從機制上解決引擎服務集羣穩定性的問題，支持paas服務的管理方式，降低服務成本，同時在平台建設過程中，注重對資產的沉澱、平台研發易用性和使用效率；從長遠來看，在整個研發全鏈路上進行低代碼嘗試，對於服務端的邏輯編排、服務編排以及更長遠的基於模型編排驅動方式提供基礎演進路線，能夠更進一步實現技術中心全棧化，提升交付效率，降低交付成本；

流程編排思路

構建編排一個完整流程，主要是能夠將可被編排資源以順序、分支、循環、並行等的流程串聯，可以被編排的資源主要可以分為兩類，一類是業務域服務，一類是工具域服務，通過對對業務域服務、工具域服務的組裝、編排，可以靈活構建一套符合業務需求的服務工作流；

下面針對業務域和工具域簡單介紹下：

1、業務域：主要是指當前雲音樂的不同業務領域的服務能力聚合，通過對RPC、HTTP、FaaS等的服務沉澱，在業務領域模型比較穩定的情況下，沉澱出不同的業務域模型，比如評論域、活動域、用户域等，平時的業務需求主要來自上層聚合層，則是對領域模型中沉澱出來的服務能力的服務編排，此時便可以通過服務編排的方式提供更為靈活的聚合類服務；當前的業務領域沉澱比較弱，期望能以Tango Flow項目為契機沉澱業務領域資產；

2、工具域：主要是針對工具的分類聚合，這裏主要抽象為了一下三種類型：

• 中間件域：可以提供發送或消費消息隊列，數據可以增刪改查Redis服務，比如更多的分佈式鎖，分佈式計數、指標監控等都會在中間件域中沉澱出來，便於搭建上層業務場景；
• AI工具域：當前雲音樂正在沉澱相關能力，後續提供出來的一些能力，比如文本分類、知識問答等，則可以工具的形式在Tango Flow平台提供，從而可以靈活搭建更上層的業務場景；
• 平台服務域：目前雲音樂的一些能力都是相對比較單點的，比如當前有告警能力、數據監控、簡單數據分析、以及流量治理能力，那按照發現問題、分析問題、解決問題的思路，是不是可以將這些能力串起來，比如將發出來的告警經過簡單分析，去獲取數據監控，在交給數據分析模塊進行分析，分析發現是某種問題，可以通過限流來臨時止血，進而整個流程可以自動化掉；

當前的工具領域沉澱比較弱且很分散，期望能以Tango Flow項目為契機沉澱工具域資產；整個邏輯編排是對業務域和工具域資產的編排，具體表現如下圖：

產品架構

1、邏輯編排態： Tango Flow平台整合現有OX資產（業務側的RPC接口、HTTP接口）及規範信息，用户可以在該平台完成流程的搭建、測試、發佈動作；

2、邏輯運行態： 流量從APP端達到網關、BFF、業務服務，那Flow Engine可以完全嵌入到這三層，比如現階段直接取代BFF能力，通過邏輯編排出來網關API；

產品介紹

產品優勢

下面針對個別特點進行簡單介紹，部分會在產品使用及應用場景章節介紹：

1、自研編排引擎

TangoFlow自研邏輯編排引擎，編排引擎是靜態流程的Runtime載體；同時也是一個邏輯概念，和使用姿勢有關係，可以服務的形式承接網關流量，也可以以SDK的方式集成在業務應用中，自研編排引擎具有以下特點：

2、自研DSL協議

DSL分為元信息定義和邏輯流程定義，元信息定義會受流程內容影響而有很大不同，在下面這個例子中，元信息定義包括Trigger定義、RPC節點定義、Groovy腳本定義，更接近編程語言，後期藉助AI Native prompt提升效率；

3、集羣託管機制

託管集羣是真正的運行TangoFlow 流程的服務，在運行TangoFlow的流程時，需要首先指定運行在哪個託管集羣上，從開發 -> 迴歸 -> 預發 -> 線上，每個都需要制定運行的託管集羣；

1、引擎多租户，降低資源開銷

託管集羣服務時支持多租户的，可以將不同應用指定到同一個託管集羣上，一方面降低運維成本，另一方面也能夠減低機器成本， 在服務達到容量瓶頸時可以對託管集羣進行擴容，或重新新建託管集羣承載新的服務；

2、每個業務線或領域，都有一個“積木”系統

託管集羣的維護儘量按照業務線或業務領域規劃，對於BFF場景，線下和預發可以用公共的環境，對於線上服務由於流量較大，需要單獨申請託管集羣承載運行時流程；

3、建立統一運維協作機制

由於角色的不同，可角色分為兩大類：託管集羣負責人，開發角色，同時為了集羣的穩定性，會涉及到審批和通知，便於集羣負責人對容量和穩定性進行把控，所以需要應用關聯到託管集羣和流程發佈時通知到託管集羣負責人、或需要託管集羣做審核，簡單示意圖如下：

• 託管集羣負責人角色：一般為服務端開發
• 負責感知、審核應用關聯集羣、流程發佈
• 特點：對穩定性、容量敏感，對引擎服務集羣容量、穩定性負責
• 開發角色: 前端、客户端、服務端
• 負責流程搭建、測試、交付
• 特點：可能對服務容量、穩定性不敏感

4、環境隔離

由於線下環境的特殊性（環境隔離），雲音樂有一套自己的環境隔離策略，TangoFlow能夠通過API網關負責API路由託管集羣負責環境路的方案解決環境隔離問題；

1、環境路由規則： 優先同標識環境服務路由；未找到同環境，則迴歸環境服務兜底

2、傳統環境隔離： 網關負責API路由、環境路由；需部署相應環境業務集羣服務

3、Tango Flow環境隔離： 網關負責API路由；Tango Flow引擎負責環境路由

產品使用

整體流程主要包括四個部分：編排搭建 -> 自測、調試 -> 發佈流程 -> 運維，如下圖所示

下面針對針流程編排中關鍵步驟進行簡單介紹：

1、流程中概念

一個完整的流程包括Trigger +邏輯控制 + 數據來源 + 數據整合，下面對這幾個概念進行簡單介紹：

1、Trigger：流程編排後以何種方式暴露，流量以不同的方式調用到流程，比如可以以網關API、服務端SDK、事件消息、定時任務等方式，目前一期已支持網關API和業務服務接入SDK的方式完成流程的觸發；

2、邏輯控制：用於控制流程邏輯流向，目前支持串行調用，並行調用、IF-Else、Switch、For迭代器（List、Map）的方式，能夠支持絕大部分業務場景，對於一些邏輯比較複雜的場景可以通過Groovy腳本來完成；

3、數據來源：產生數據的源頭，目前已支持雲音樂RPC、網關HTTP接口、Groovy腳本、本地接口調用、固定值，這些都可以產生數據，被流程拿來進行編排，產生的數據可以在流程上進行流轉；

4、數據整合：作為整個流程返回的結果，可以自由組裝數據來源產生的數據，同時支持JsonPath的取數方式；

2、邏輯編排可視化

流程編排頁面是TangoFlow最核心的頁面，從區域上劃分為組件區域、邏輯編排區域、屬性面板，在調試情況下會彈出調試區域，同時支持分支切換、歷史版本、視圖切換（支持設計和DSL的切換）、流程快速發佈等能力。

3、參數選擇

在需要上游某個節點的返回結果作為當前流程節點的輸入，在TangoFlow平台中所有的參數選擇都是基於組件標識來識別的，可以選擇將整個結果作為當前的輸入，也可以通過 jsonPath來選擇具體的某個值作為輸入；

舉個具體的例子：定義在觸發器中gw\_http0中的一個參數userId，可以在下游RPC調用中被選擇作為RPC的入參，另外也可以在結果集整合的時候作為結果被使用，在下面這個case中，是通過節點標識取到的該節點返回之中的data.rowkey信息作為返回結果的一部分；

4、流程調試

支持整個流程的調試、節點維度調試（RPC、HTTP、Groovy腳本）的調試能力，並且無需發佈，可指定環境、直接測試、調試記錄；

1、流程調試： 針對整個流程的測試，Trigger開始觸發

2、節點調試： 單個RPC、HTTP-IN、Groovy腳本調試

3、可視化調試記錄： 入參、結果、調試記錄棧、運行DSL

5、Mock機制

測試過程中，對於不容易構造或者不容易獲取的對象，用一個虛擬的對象來代替以便測試的測試方法，只用於線下環境快速聯調，在團隊並行開發能極大提高效率；

Tango Flow支持Request Mock和Response Mock，Mock數據來自於統一資產平台（OX），數據可以在Tango Flow平台按需進行調整；同時在編排時若某個節點打開了Mock可在編排視圖中會有特殊標記提示流程節點開啓了Mock；

1、Request Mock

支持 RPC、HTTP、Groovy ，用於服務已就緒，Request Mock 數據作為請求數據，忽略上游傳入數據的場景；

2、Response Mock

支持Trigger、 RPC、HTTP、Groovy ，用於下游服務接口未就緒、服務不存在等導致無法構建或獲取對象場景

6、流程持續發佈

發佈流水線全生命週期管理，秒級完成發佈，卡點環節使發佈可靠、低風險、隨時按需執行，流程發佈具有以下特點：

1、多分支並行開發： 可多分支並行開發，一個發佈單對應一個分支，新建發佈單從master分之拉取數據，發佈完成後覆蓋master；

2、發佈策略： 線下環境發佈策略：開發、迴歸隨意發佈，迴歸環境只有一個，互相覆蓋；線上環境發佈策略：預發、線上通道獨佔，互斥發佈；

3、回滾策略：回滾發佈以新發布單形式存在，與其他共用發佈單共享發佈通道，回滾但不能合併到Master；

4、發佈卡點：託管集羣具有可配置的流程發佈卡點機制，在開啓發布審核時，在卡點環節會提示需要託管集羣負責人審核才能進行預發和線上環境發佈，保證發佈的安全性，後續也會持續優化發佈卡點邏輯。

以下為一個具體case，由於公共預發集羣和線上集羣都設置了開啓審核，所以需要集羣負責人審核通過後才能繼續發佈

7、監控告警

不同維度數據，不同負責人關注信息不一樣，根據訪問分佈、RT訪問分佈，並在流程維度有RT和調用錯誤率的告警；

應用場景

一期流程編排暴露出來的能力是網關API和API-SDK，同時支持的數據節點主要是RPC接口、HTTP接口、本地接口調用、Groovy腳本，所以一期主要適用場景在：協議轉換、數據聚合和簡單邏輯編排的場景；

對於以上適用場景，可以具體應用到以下場景：

1、BFF場景

主要是解當前BFF決編排的問題，從機制上解決引擎服務集羣穩定性的問題，支持paas服務的管理方式，降低服務機器成本；更多的從協議轉換、數據聚合、邏輯編排維度提供能力；

2、服務端業務場景（統一服務端SDK）

靈活輕量的利用編排平台沉澱的服務端技術棧資產能力完成業務需求（只需接入引擎SDK，相當於接入了已沉澱的SDK的使用姿勢），降低服務端資產使用成本，提高交付效率，在一定意義上實現技術架構轉型；

總結

本文介紹了Tango Flow平台建設的問題、訴求及構建思路，首要是解決編排的問題，支持更復雜的編排場景，服務編排出來的產物可以是RPC、API服務，編排出來的RPC、API服務直接集成在BFF中，靈活解決BFF應用的服務編排問題，同時從機制上解決引擎服務集羣穩定性的問題，支持paas服務的管理方式，降低服務成本，同時在平台建設過程中，注重對資產的沉澱、平台研發易用性和使用效率；從長遠來看，在整個研發全鏈路上進行低代碼嘗試，對於服務端的邏輯編排、服務編排以及更長遠的基於模型編排驅動方式提供基礎演進路線，能夠更進一步實現技術中心全棧化，提升交付效率，降低交付成本；

Tango Flow是雲音樂自研的流程編排平台，具有豐富的應用場景，可以用在BFF場景、服務端業務場景（統一服務端SDK），並具有場景易擴展能力；Tango Flow可通過可視化拖拉拽的方式快速搭建、測試和發佈流程，平台提供簡單易用流程搭建能力，通過組件標識+JsonPath可完成參數在流程節點之間傳遞；支持整個流程的調試、節點維度調試（RPC、HTTP、Groovy腳本）的調試能力，並且無需發佈，可指定環境、直接測試、調試記錄；建立統一的運維協作機制，發佈流水線全生命週期管理，秒級完成發佈，卡點環節使發佈可靠、低風險、隨時按需執行；具有監控告警能力，不同維度數據，不同負責人關注信息不一樣，根據訪問分佈、RT訪問分佈，並在流程維度有RT和調用錯誤率的告警；

未來規劃

1、服務端低代碼演進 ：提供更多觸發場景，整合現有服務端技術棧組件；

2、前後端低代碼一體化：完成模型驅動，實現前後端低代碼一體化；

3、平台體驗 & 效率 優化：基於業務痛點及反饋，完善和優化現有平台能力；

最後

更多崗位，可進入網易招聘官網查看 https://hr.163.com/