美團跨端一體化富文本管理技術實踐

爲了減少產品和前端開發人員之間的矛盾,不斷降本提效,美團醫藥技術部構建了跨端一體化富文本管理平臺Page-佩奇。本文系統介紹了該平臺的定位、設計思路、實現原理以及取得的成效。希望這些實戰經驗與總結,能給大家帶來一些啓發或幫助。

一、引言

在互聯網圈,開發和產品經理之間相愛相殺的故事,相信大家都有所耳聞。歸根結底,往往都是從簡單的改需求開始,然後你來我往、互不相讓,接着吵架鬥嘴,最後導致矛盾不斷升級,甚至帶來比較嚴重的後果。

圖1

在這種背景下,如果把一些功能相對簡單的、需求變動比較頻繁的頁面,直接交給產品或者運營自己去通過平臺實現,是不是就可以從一定程度上減少產品和開發人員之間的矛盾呢?

二、背景

當然上述的情況,美團也不例外。近些年,美團到家事業羣(包括美團外賣、美團配送、閃購、醫藥、團好貨等)的各個業務穩步發展,業務前端對接的運營團隊有近幾十個,每個運營團隊又有不同的運營規則,這些規則還存在一些細微的樣式差別,同時規則內容還會隨着運營季節、節日、地理位置等進行變化和更新。這些需求具體來說有以下幾個特點:

  1. 需求量大:業務穩步發展,業務需求不斷疊加,甚至部分業務呈指數級增長,且業務方向涉及到一些業務規則、消息通知、協議文檔、規則介紹等需求。
  2. 變更頻繁:面對市場監管和法務的要求,以及新業務調整等因素的影響,會涉及到需求的頻繁變更,像一些業務FAQ、產品介紹、協議文檔、業務規則、系統更新日誌等頁面,需要做到快速響應和及時上線。
  3. 複雜度低:這些頁面沒有複雜的交互邏輯,如果能把這些簡單的頁面交給運營/產品去實現,開發人員就能有更多的時間去進行復雜功能的研發。
  4. 時效性高:臨時性業務需求較多,且生命週期較短,具有定期下線和週期性上線等特點。

基於以上特點,爲了提高研發效率,美團醫藥技術部開始構建了一個跨端一體化富文本管理平臺,希望提供解決這一大類問題的產研方案。不過,部門最初的目標是開發一套提效工具,解決大量諸如幫助文檔、協議頁、消息通知、規則說明等靜態頁面的生產與發佈問題,讓產品和運營同學能夠以所見即所得的方式自主完成靜態頁面製作與發佈,進而縮短溝通成本和研發成本。

但是,隨着越來越多業務部門開始諮詢並使用這個平臺,我們後續不斷完善並擴充了很多的功能。經過多次版本的設計和迭代開發後,將該平臺命名爲Page-佩奇,並且註冊成爲美團內部的公共服務,開始爲美團內部更多同學提供更好的使用體驗。

本文將系統地介紹Page-佩奇平臺的定位、設計思路、實現原理及取得成效。我們也希望這些實戰經驗與總結,能給更多同學帶來一些啓發和思考。

三、跨端一體化富文本管理解決方案

3.1 平臺定位

我們希望將Page-佩奇打造成一款爲產品、運營、開發等用戶提供快速一站式發佈網頁的產研工作臺,這是對該平臺的一個定位。

  • 對產品運營而言,他們能夠可視化地去創建或修改一些活動說明、協議類、消息類的文章,無需開發排期,省去向開發二次傳遞消息等繁瑣的流程,也無需等待漫長的發佈時間,從而達到靈活快速地進行可視化頁面的發佈與管理。
  • 對開發同學而言,他們能夠在線編寫代碼,並實現秒級的發佈上線,並且支持ES 6、JavaScript 、Less、CSS語法,我們還提供了基礎的工具、圖表庫等,能夠生成豐富多樣的頁面。幫助開發同學快速實現數據圖表展示,設計特定樣式,完成各種交互邏輯等需求。
  • 對項目管理方而言,他們能夠清晰地看到整個需求流轉狀態和開發日誌信息,爲運營管理提供強大的“抓手”。

一般來講,傳統開發流程是這樣的:首先產品提出需求,然後召集研發評審,最後研發同學開發並且部署上線;當需求上線之後,如果有問題需要反饋,產品再找研發同學進行溝通並修復,這種開發流程也是目前互聯網公司比較常見的開發流程。

圖2 傳統開發流程圖

而美團Page-佩奇平臺的開發流程是:首先產品同學提出需求,然後自己在Page平臺進行編輯和發佈上線,當需求上線之後有問題需要反饋,直接就能觸達到產品同學,他們通常可自行進行修復。如果需求需要定製化,或者需要做一些複雜的邏輯處理,那麼再讓研發人員配合在平臺上進行開發併發布上線。

圖3 Page佩奇平臺開發流程圖

簡單來說,對那些功能相對簡單、需求變動比較頻繁的頁面,如果用傳統的開發流程將會增加產研溝通和研發排期成本,因此傳統方案主要適用於功能複雜型的需求。而Page佩奇平臺開發流程,並不適合功能複雜型的需求,特別適用於功能相對簡單、需求變動比較頻繁的頁面需求。

綜上所述,可以看出這兩種開發流程其實起到了一個互補的作用,如果一起使用,既可以減少工作量,又可以達到降本提效的目的。

3.2 設計思路

我們最初設計Page-佩奇平臺的初心其實很簡單,爲了給產品和運營提供一個通過富文本編輯器快速製作併發佈網頁的工具。但是,在使用的過程中,很多缺陷也就慢慢地開始暴露,大致有下面這些問題:

  1. 簡單的富文本編輯器滿足不了想要的頁面效果,怎麼辦?
  2. 如果能導入想要的模板,是否會更友好?
  3. 怎麼查看這個頁面的訪問數據?如何能監控這個頁面的性能問題?
  4. 發佈的頁面是否有存在安全風險?

於是,我們針對這些問題進行了一些思考和調研:

  • 當富文本編輯器滿足不了想要實現的效果的時候,可以引入了WebIDE編輯器,可以讓研發同學再二次編輯進行實現。
  • 一個系統想要讓用戶用得高效便捷,那麼就要完善它的周邊生態。就需要配備完善的模板素材和物料供用戶靈活選擇。
  • 如果用戶想要了解頁面的運行情況,那麼頁面運行的性能數據、訪問的數據也是必不可少的。
  • 如果發佈的內容存在不當言論,就會造成不可控的法律風險,所以內容風險審覈也是必不可少的。

實現一個功能很容易,但是想要實現一個相對完善的功能,就必須好好下功夫,多思考和多調研。於是,圍繞着這些問題,我們不斷挖掘和延伸出了一系列功能:

  1. 富文本編輯:強大而簡單的可視化編輯器,讓一切操作變得簡單、直觀。產品同學可以通過編輯器自主創建、編輯網頁,即使無程序開發經驗也可以通過富文本編輯器隨意操作,實現自己想要的效果,最終可以實現一鍵快速發佈上線。
  2. WebIDE:定製化需求,比如,與客戶端和後端進行一些通信和請求需求,以及針對產品創建的HTML進行二次加工需求,均可以基於WebIDE通過JavaScript代碼實現。具備專業開發經驗的同學也可以選擇通過前端框架jQuery、Vue,Echarts或者工具庫Lodash、Axios實現在線編輯代碼。
  3. 頁面管理:靈活方便地管理頁面。大家可以對有權限的文檔進行查看、編輯、授權、下線、版本對比、操作日誌、回滾等操作,且提供便捷的文檔搜索功能。
  4. 模板市場:豐富多樣的網頁模板,簡易而又具備個性。模板市場提供豐富的頁面模板,大家可選擇使用自己的模板快速創建網頁,且發佈的每個頁面又可以作爲自己的模板,再基於這個模板,可隨時添加個性化的操作。
  5. 物料平臺:提供基礎Utils、Echart、Vue、jQuery等物料,方便開發基於產品的頁面進行代碼的二次開發。
  6. 多平臺跨端接入:高效快捷地接入業務系統。通過通信SDK,其他系統可以快速接入Page-佩奇平臺。同時支持以HTTP、Thrift方式的開放API供大家選擇,支持客戶端、後端調用開放API。
  7. 內容風險審覈:嚴謹高效的審覈機制。接入美團內部的風險審覈公共服務,針對發佈的風險內容將快速審覈,防止誤操作造成不可控的法律風險。
  8. 數據大盤:提供頁面的數據監測,幫助大家時刻掌握流量動向。接入美團內部一站式數據分析平臺,幫助大家安全、快速、高效地掌握頁面的各種監測數據。
  9. 權限管理:創建的每個頁面都有相對獨立的權限,只有經過授權的人才能查看和操作該頁面。
  10. 業務監控:提供頁面級別JavaScript錯誤和資源加載成功率等數據,方便開發排查和解決線上問題。

功能流程圖如下所示:

圖4 Page佩奇平臺功能流程圖

3.3 實現原理

3.3.1 基礎服務

Page-佩奇平臺的基礎服務有四個部分,包括物料服務、編譯服務、產品賦能、擴展服務。

圖5 整體架構圖

3.3.2 核心架構

圖6 核心架構圖

Page-佩奇平臺核心架構主要包含頁面基礎配置層、頁面組裝層以及頁面生成層。我們通過Vuex全局狀態對數據進行維護。

  • 頁面基礎配置層主要提供生成頁面的各種能力,包括富文本的各種操作能力、編輯源碼(HTML、CSS、JavaScript)的能力、自定義域名配置、適配的容器(PC/H5)、發佈環境等。
  • 頁面組裝層則會基於基礎配置層所提供的的能力,實現頁面的自由編輯,承載大量的交互邏輯,用戶的所有操作都在這一層進行。
    • 業務PV和UV埋點,錯誤統計,訪問成功率上報。
    • 自動適配PC和移動端樣式。
    • 內網頁面顯示外網不可訪問標籤。
  • 頁面生成層則需要根據組裝後的配置進行解析和預處理、編譯等操作,最終生成HTML、CSS、JavaScript渲染到網頁當中。

3.3.3 關鍵流程

圖7 關鍵流程圖

如上圖7所示,平臺的核心流程主要包含頁面創建之後的頁面預覽、編譯服務、生成頁面。

  • 頁面預覽:創建、編輯之後的頁面,將會根據內容進行頁面重組,對樣式和JavaScript進行預編譯之後,對文本+JavaScript+CSS進行組裝,生成HTML代碼塊,然後將代碼塊轉換成Blob URL,最終以iframe的方式預覽頁面。
  • 編譯服務:文件樹狀結構和代碼發送請求到後端接口,基於Webpack將Less編譯成CSS,ES 6語法編譯成ES 5。通用物料使用CDN進行引入,不再進行二次編譯。
  • 生成頁面:當創建、編輯之後的頁面進行發佈時,服務端將會進行代碼質量檢測、內容安全審查、代碼質量檢測、單元測試、上傳對象存儲平臺、同步CDN檢測,最終生成頁面鏈接進行訪問。

3.3.4 多平臺接入

Page-佩奇平臺也可以作爲一個完善的富文本編輯器供業務系統使用,支持內嵌到其他系統內。作爲消息發佈等功能承載,減少重複的開發工作,同時我們配備完善的SDK供大家選擇使用。通過Page-SDK可以直接觸發Page平臺發佈、管理等操作,具體的流程如下圖所示:

圖8 Page-SDK流程圖

3.3.5 OPEN API

在使用Page-佩奇平臺的時候,美團內部一些業務方提出想要通過Page-佩奇平臺進行頁面的發佈,同時想要拿到發佈的內容做一些自定義的處理。於是,我們提供了Open API開放能力,支持以HTTP和Thrift兩種方式進行調用。下面主要講一下Thrift API實現的思路,首先我們先了解下Thrift整體流程:

圖9 Thrift整體流程圖

Thrift的主要使用過程如下:

  1. 服務端預先編寫接口定義語言 IDL(Interface Definition Language)文件定義接口。
  2. 使用Thrift提供的編譯器,基於IDL編譯出服務語言對應的接口文件。
  3. 被調用服務完成服務註冊,調用發起服務完成服務發現。
  4. 採用統一傳輸協議進行服務調用與數據傳輸。

那麼下面我們具體講下,Node語言是如何實現和其他服務語言實現調用的。由於我們的服務使用的Node語言,因此我們的Node服務就充當了服務端的角色,而其他語言(Java等)調用就充當了客戶端的角色。

圖10 Thrift使用詳細流程圖

  • 生成文件:由服務端定義IDL接口描述文件,然後基於IDL文件轉換爲對應語言的代碼文件,由於我們用的是Node語言,所以轉換成JavaScript文件。
  • 服務端啓動服務:引入生成的JavaScript文件,解析接口、處理接口、啓動並監聽服務。
  • 服務註冊:通過服務器內置的“服務治理代理”,將服務註冊到美團內部的服務註冊路由中心(也就是命名服務),讓服務可被調用方發現。
  • 數據傳輸:被調用時,根據“服務治理服務”協議序列化和反序列化,與其他服務進行數據傳輸。

目前,美團內部已經有相對成熟的NPM包服務,已經幫我們實現了服務註冊、數據傳輸、服務發現和獲取流程。客戶端如果想調用我們所提供的的Open API開放能力,首先申請AppKey,然後選擇使用Thrift方式或者HTTP的方式,按照所要求的參數進行請求調用。

3.4 方案實踐

3.4.1 H5協議

能力:富文本編輯。 描述:提供富文本可視化編輯,產品和運營無需前端就可以發佈和二次編輯頁面。 場景:文本協議,消息通知,產品FAQ。

具體案例:

圖11 H5靜態文本協議案例

3.4.2 業務自定義渲染

能力:開放API(Thirft + HTTP)。 描述:提供開放API,支持業務自定義和樣式渲染到業務系統,同時解決了iframe體驗問題。 場景:客戶端、後端、小程序的同學,可根據API渲染文案,實現動態化管理富文本信息。

具體案例:

小程序使用<rich-text>組件、Vue使用v-html指令實現動態化渲染商品選擇說明。

    {
    "code": 0,
    "data": {
      "tag": "蘋果,標準",
      "title": "如何挑選蘋果",
      "html": "<h1>如何挑選蘋果</h1>><p>以下標準可供消費者參考</p><ul><li>酸甜</li><li>硬度</li></ul>",
      "css": "",
      "js": "",
      "file": {}
    },
    "msg": "success"
}

3.4.3 投放需求

能力:WebIDE代碼編輯。 描述:開發基於WebIDE代碼開發工作,基於渠道和環境修改下載鏈接,能夠做到分鐘級支撐。 場景:根據產品創建靜態頁面進行邏輯和樣式開發。

具體案例:

    var ua = window.navigator.userAgent
    var URL_MAP = {
        ios: 'https://apps.apple.com/cn/app/xxx',
        android: 'xxx.apk',
        ios_dpmerchant: 'itms-apps://itunes.apple.com/cn/app/xxx'
    }
    
    if (ua.match(/android/i)) location.href = URL_MAP.android
    if (ua.match(/(ipad|iphone|ipod).*os\s([\d_]+)/i)) {
        if (/xx\/com\.xxx\.xx\.mobile/.test(ua)) {
            location.href = URL_MAP.ios_dpmerchant
        } else {
            location.href = URL_MAP.ios
        }
    }

3.4.4 客戶端通信中間頁

能力:WebIDE代碼編輯 + 物料平臺。 描述:通過物料平臺,引入公司客戶端橋SDK,可以快速完成客戶端通信需求。方便前端調試客戶端基礎橋功能。 場景:客戶端跳轉,通信中間頁。

具體案例:

    // 業務僞代碼
    XXX.ready(() => {
        XXX.sendMessage({
        	  sign: true,
            params: {
                id: window.URL
            }
        }, () => {
            console.error('通信成功')
        }, () => {
            console.error('通信失敗')
        })
    })

3.4.5 業務系統內嵌Page

能力:提供膠水層Page-SDK,連接業務系統和Page。 描述:業務系統與Page-佩奇平臺可進行通信,業務系統可調用Page發佈、預覽、編輯等功能,Page可返回業務系統頁面鏈接、內容、權限等信息。減少重複前後端工作,提升研發效率。 場景:前端富文本信息渲染,後端富文本信息管理後臺。

具體案例:

圖12 業務系統內嵌Page案例

3.5 業務成績

截止目前數據統計,Page佩奇平臺生成網頁5000多個,編輯頁面次數16000多次,累計頁面訪問PV超過8260萬。現在,美團已經有十多個部門和三十多條業務線接入並使用了Page佩奇平臺。

圖13 Page平臺每日生成頁面統計

四、總結與展望

富文本編輯器和WebIDE不僅是複雜的系統,而且還是比較熱門的研究方向。特別是在和美團的基建結合之後,能夠解決團隊內部很多效率和質量問題。這套系統還提供了語法智能提示、Diff對比、前置檢測、命令行調試等功能,不僅要關注業務發佈出去頁面的穩定性和質量,更要有內置的一系列研發插件,主動幫助研發提高代碼質量,降低不必要的錯誤。

經過長期的技術和業務演進,Page-佩奇平臺已經能夠有效地幫助研發人員大幅提升開發效率,具備初級的Design To Code能力,但是仍有許多業務場景值得去我們探索。我們也期待優秀的你參與進來,一起共同建設。

  • WebIDE融合:完善基礎設施建設和功能需求,更好地支持Vue、React、ES 6、TS、Less語法,預覽模式採用瀏覽器編譯,能有效地提高預覽的速度,發佈使用後端編譯的模式。
  • 研發流程鏈路:針對代碼進行有效評估,包括ESlint、代碼重複率、智能提示是否可以三方庫替代。出具開發代碼質量、業務上線的質量報告。
  • 綜合研發平臺:減少團隊同學瞭解整體基建的時間成本,內置了監控、性能、任務管理等功能,提升業務開發效率。建設自動化日報、週報系統,降低非開發工作量佔比。
  • 物料開放能力:接入公共組件平臺,沉澱更多的物料,快速滿足產品更多樣化的需求。

五、作者簡介

高瞻、宇立、肖瑩、浩暢,來自美團醫藥終端團隊。王詠、陳文,來自美團閃購終端團隊。

六、招聘信息

美團醫藥長期招聘Android、iOS、FE前端工程師,座標在北京和成都。感興趣的同學可將簡歷發送至:[email protected](郵件主題請註明:美團醫藥終端)。

閱讀美團技術團隊更多技術文章合集

前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試

| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞,可查看美團技術團隊歷年技術文章合集。

| 本文系美團技術團隊出品,著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容,敬請註明“內容轉載自美團技術團隊”。本文未經許可,不得進行商業性轉載或者使用。任何商用行爲,請發送郵件至[email protected]申請授權。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章