【早早聊】如何落地微前端一体化运营工做台

前言

你们好，我是飞猪前端，今天分享的主题是《如何落地微前端一体化运营工做台》，首先简单的介绍一下本身，花名叫作侑夕，对外网络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 排版