【早早聊】如何落地微前端一體化運營工做臺

前言

你們好，我是飛豬前端，今天分享的主題是《如何落地微前端一體化運營工做臺》，首先簡單的介紹一下本身，花名叫作侑夕，對外網絡id爲Tw93，目前有部分時間在弄飛豬前端技術對外影響力，運營飛豬前端團隊的公衆號Fliggy F2E以及掘金專欄，藉此給大夥介紹一些飛豬前端體系化建設。

總覽

以前1七、1八、19年分別弄的飛豬Weex、互動、Serverless從0到1的建設，今年20年主要是弄飛豬微前端一體化運營工做臺的建設，也即今天分享的主題

將從「爲何要作飛豬一體化運營工做臺、要作成什麼樣子、怎麼作的、後面想怎麼作」這4塊來給你們講述。

爲何要作飛豬一體化運營工做臺

飛豬運營屬性的發展

在12年的時候，阿里ALLIN 無線過程當中，飛豬App當時也隨之產生了，至關於工具屬性，用於給用戶快速查詢機票門票信息；等到了14年左右工具屬性逐步豐富起來，同時通過雙十一的火爆，慢慢轉變成一個營銷賣貨的屬性，當時各類營銷平臺慢慢作起來了；

到了17年左右，當時主打場景運營心智，包括出境超市、週末好去處等主題心智，導購類平臺在這個時候逐步萌芽；等到了18年後隨着抖音/直播的火爆，飛豬運營類型也更加豐富起來了，由主題進化到內容心智。



隨着業務逐步豐富發展，內部的各類小二運營平臺也在從「可用提效」往「精耕細做」發展，隨着運營一體化工做臺的建設，目前正處在下圖箭頭處

發展過程當中的痛點

伴隨飛豬業務的發展，咱們在近兩年爲提高運營效率創建了多種場景的運營類平臺，可知足運營完成業務訴求。



但隨着產品自己業務複雜度在不斷提升，只能給運營解決溫飽問題，加上各平臺須要互投互通訴求逐漸強烈，在此體系下沒法給業務帶來 1 + 1 > 2 的價值，面臨以下繼需解決的痛點：

要作成什麼樣子

爲解決以上痛點，咱們啓動一體化運營工做臺建設項目，旨在藉助新技術探索和升級給運營同窗提供更好更高效的運營平臺解決方案，一期目標爲技術側的探通，完成工做臺框架的搭建，知足多平臺場景使用，沉澱一套以現有業務爲基礎的泛運營平臺微前端解決方案



基於此咱們從實際業務運營配置場景入手，結合現有中後臺技術和微前端解決方案，產出以下方案架構圖：



底層藉助Ant Design 體系加上 qiankun 的能力，中間層輔助一體化工做臺裏面涉及的貼合現有業務場景的規範；更上一層沉澱組件化widget的能力，用於各類功能的互通，同時成爲現有子應用的組合來源；在最上層即飛豬運營工做臺的上層主應用，包括總體框架、快捷導航、權限登陸控制、運營場景的聚集，包括後續要作的業務運營SOP解決方案。

怎麼作的

前端側深度使用共建qiankun

在前端側，咱們深度使用和更共建qiankun，qiankun 底層應⽤之間的加載使⽤ single-spa，上層實現樣式隔離、js 沙箱、預加載等上層能⼒，同時提供umi-plugin-qiankun來解決 umi 下的快速使用，成爲咱們前端側的選擇方案。



在子應用路由控制這一塊，咱們經過藉助現有antd pro的路由配置，加上qiankun的配置項整合成一個經過的配置config，藉此對於子應用的接入只需配置此處便可，同時能夠作到後面的統一管控。



前端側除了微前端還有路由這一塊，其實還包括能夠作的更多的事情，包括咱們整合了公共資源如antd、loadsh、router等等統一大版本，經過寫了umi-externals-url進行處理，藉此能夠減小將近1/3的資源；包括在體驗度量方面咱們藉助內部的能力，能夠將使用用戶進行分層分析包括錯誤性能監控；同時產出具有能夠錄屏、截圖的在線反饋系統，便於用於在使用過程當中直接反饋通知直接issue提交給對應的負責同窗；

後端側自建統一網關串通主子應用

在後端側，咱們在運營工做臺 Node 側自建了 Gateway 網關 middleware，底層依賴http-proxy-middleware能力實現，借用服務端 proxy 轉發接口同時在請求上加上 token 來解決接口登陸權限以及跨域的問題，同時對於主子應用直接接入會出現內網登陸登陸權限不通的問題，此處咱們使用的 免登受權 的能力，讓子應用的登陸讓主應用自己來提供，這樣經過中間網關層配合咱們給 qiankun pr 的 Fetch 自定義能力和 Slave Namebase 可解決請求和路由跳轉的兼容問題。

Widget 業務組件化

微前端能夠很好解決主子應用間無縫的接入問題，可是對於區塊場景還不成熟，存在現有問題：

• 隨着業務場景的成熟發展，加上區塊能力嵌入配置的場景逐步增多；
• 藉此解攜抽離原有通用招造投搭能力,減小維護壓力；
• 逐步豐富現有widget能力,知足後續更多場景的接入使用,以及系統打通

基於此咱們經過類widget npm組件包的方式來實現業務組件，包括制定對應的協議來驅動對應的widget渲染和展現，便於後端同窗對其更加可控，同時在視覺規範上，咱們收攏各類場景下的使用展現，便於一個widget能夠更加無縫的嵌入到已有系統

如咱們想作搭建系統裏面配置互動玩法的配置，藉助互動玩法配置widget能夠達到以下的一體化配置：

運營平臺的交互體驗

說到中後臺的的前端側展現，大部分場景都沒有設計交互同窗支持，加上一線研發同窗對交互視覺標準的理解不一樣，致使很多頁面的使用體驗勉強只能達到能用的狀態，距離好看好用還有很大距離。



基於此，咱們梳理幾類運營場景的視覺規範須要把握的原則點：

• 同類統一：不折騰，通用層面遵循 Ant Design；同類型 / 同功能模塊展現保持一致
• 舒服對齊：對齊會讓頁面或者強迫症的同窗看起來會很舒服；標題、按鈕、表單、tag 多集合類需確保對齊
• 不經常使用的收起：將不重要內容收起，便於讓用戶找關鍵執行點；類表格將不經常使用的內容隱藏或者放到抽屜裏面去
• 簡單不阻礙：讓新用戶不看說明書也能夠知曉下一步操做；不能讓用戶因爲XXX緣由走不到下一步

好比說以下的展現：



經過將現有的原子類展現統一後，再日後走，咱們將現有的開箱即用進行統一交互，而後沉澱出對應的能力，包括搜索列表、場景卡片組、表單預覽的能力，有了這些能力的沉澱，後續新頁面的產生較以前可上升一個大的階段



如FormRender的表單的沉澱，咱們能夠藉此此能力能夠生產大量的表單頁面，同時展現徹底讓後端側來控制展現，這樣能夠作到協議驅動展現，更多詳細可見 alibaba/form-render

後面想作啥

以上即咱們第一個階段作的事情，對於下一期重點會放在場景SOP能力的開發，同時在中間層進行開箱即用的瘋狂提效，底層進行更多的抽象以及規範化，最底層在工程上造成統一的初始化、發佈的能力



對於運營配置的場景，最終目的是爲了提高運營配置的效率以及能夠不斷經過數據來優化業務的使用效果，後續咱們將以SOP的形式逐步來優化運營側的配置，最終造成一體化的配置能力;



對於技術側，將嘗試更多的新技術探索，特別在微前端規範統一方面，如何讓現有系統能夠接入目前主流的微前端的子應用能力，包括上層子應用的管控平臺；同時目前的新打包體系或許能夠給咱們不少新的思路來擴充現有的打包的能力；以及上述的開箱即用協議驅動的搭建如何經過低代碼的搭建的方式來更多提高咱們的快速生成的能力！

Welcome 來飛豬

廣告時間到啦，其實飛豬前端團隊在阿里是一個比較厲害的前端團隊，拔赤大大P9帶隊，總體成員有成熟的高P也有年輕的小鮮肉，你們都技術思想都很Open，平時生日會、團隊、出國outing，不亦樂乎



在技術上，目前咱們在新穎技術、中臺技術、基礎技術上均有團隊規劃發展，若是你比較感興趣，能夠直接來聊，同時有能力過來帶一個方向也是很歡迎的！



最後也很歡迎，關注飛豬前端公衆號「Fliggy F2E」，裏面有很多體系化建設的文章乾貨，值得一讀！

本文使用 mdnice 排版