新活动平台建设历程与架构演进

01 前言

历时近两年的重新设计和迭代重构，用户技术中心的新活动平台建设bilibili活动中台 终于落地完成！并迎来了里程碑时刻 ------ 接过新老迭代的历史交接棒，从内到外、从开发到搭建实现全面升级，开启了活动生产工业化新时代：

界面交互层面：在界面和交互上推倒重来，实现了简洁美观、符合直觉、简单易用的现代化升级；
业务功能层面：在功能上去繁就简，聚焦核心业务，对活动搭建和业务开发两条主场景进行重新思考和设计，简化流程并提高了整体效率和体验；
系统架构层面：模块解耦提升扩展性的同时，围绕业务诉求进行迭代演进，通过技术驱动来赋能业务，提高业务边界和想像力，助力活动业务跑得更好更快；
开发生态层面：通过开发工具链的升级，把平台开放能力提升到了一个新的高度，为业务开发者创造了更加友好的开发环境和平台生态。

本文将从新活动平台（以下简称为活动平台）的建设历程展开，阐述我们在整个开发过程中的设计理念、建设规划和架构思考。不同建设阶段中面临的挑战，以及活动平台团队是如何解决的。希望能对你有点帮助。

开始之前，先来简单认识一下活动平台：

活动平台最核心的页面：制作页

02 活动平台是什么

活动平台本质上是一个低代码平台 。低代码平台是一种成熟的业务应用开发方案，这里不再赘述。除了低代码的标签外，活动平台也是一个 CMS（Content Management System）系统，除了最核心的活动业务，还能广泛应用在其它各种页面生产场景。因此从业务抽象的角度来总结的话，可以从服务对象 和业务模式两方面来概括活动平台：

2.1 服务对象

活动平台服务对象包括运营、用户、研发三类，其中：

运营：是平台的 B 端用户，负责生产活动页面；
用户：是平台的 C 端用户，负责消费活动页面；
研发：包括平台研发+业务研发

平台研发：平台系统维护者，负责平台迭代建设、开发通用组件、维护组件生态和数据源生态，并对外提供开发工具；
业务研发：负责通过平台提供的开发工具来开发业务组件，供运营消费组件来生产活动页面

2.2 业务模式

活动平台业务模式包括 No Code、Low Code、Pro Code 三种模式，其中：

No Code 模式：服务于全搭建的业务场景 ------ 页面搭建配置过程由运营完全负责，无需研发介入。研发在平台上发布可复用的业务组件，运营基于业务组件生产各种不同的活动页面。基于丰富的组件生态，可以覆盖 > 99% 业务场景。
Low Code 模式：服务于半搭建半开发的业务场景 ------ 比如一个活动页面里 90% 部分可以基于平台搭建，剩下的 10% 没有对应的平台组件，同时也不具备可复用价值。那么在运营搭建好页面框架的基础上，研发介入生产一次性的定制功能代码块组件并发布到平台，然后交由运营操作组装，与页面进行有机结合，实现完整的页面功能。大概覆盖 < 1% 业务场景。
Pro Code 模式：服务于少数需要全定制开发的业务场景------ 比如个别大型活动，需要使用动画框架、定制模板能力或者定制渲染器。那么开发者可以通过平台开发工具，定制开发页面后，通过平台来发布和管理页面。同时如果页面有部分模块是可以复用平台组件的，那么可以基于平台的片段加载器能力，来直接复用运营搭建的页面片段，提高开发效率。

三类服务对象和三种业务模式的关系示意图

03. 背景和目标

3.1 项目背景

为什么要建设活动平台，主要有两点原因：

环境原因：在公司提效的大背景下，需要整合统一各部门的活动搭建能力，比如活动业务的 Flash 平台、Native 平台、直播业务的云雀平台。通过横向对比各平台的技术能力现状及业务覆盖情况，最终选择基于 Flash 平台进行迭代升级：

平台原因：Flash 平台自上线运行多年以来，一直都是通过技术自驱进行迭代，虽然功能强大且生态丰富，但由于长期缺少整体设计、架构优化和产品化的规划打磨，因此界面和交互较为陈旧、核心功能重技术轻体验、架构扩展性差跟不上时代变化、整体活动搭建和开发体验和效率都较差，急需进行改造升级。

3.2 面临挑战

活动平台是由多套服务组成的复杂系统，涉及业务广泛，想要对其进行从内到外的整体改造升级，是一个巨大的挑战。

1）内部挑战

从长期的用户使用反馈和平台开发视角来看，主要包括几个方面的问题：

1. 平台体验方面：

a. 制作页问题：功能布局不合理、图层拖拽体验差，无法跨层级拖拽、组件列表管理方式不直观... 等等；

b. 画布问题：部分组件无法预览、容器无法多级嵌套、搭建过程无法全真预览体验较差... 等等；

c. 数据源问题：数据源割裂分散、数据源配置项繁冗重复、低频的高级功能导致使用复杂度上升... 等等；

d. 组件问题：没有平台级的弹窗组件、数据源组件使用成本高、组件重复且质量参差不齐... 等等。

2. 架构设计方面：

a. 整体架构问题：历史包袱重，核心模块耦合严重，牵一发动全身，无法进行独立测试，功能扩展性差；

b. 渲染器问题：B 端和 C 端使用两套渲染器，无法从根本上解决画布渲染下和页面预览下可能出现的组件表现不一致问题；

c. 模块设计问题：画布、图层、表单等核心模块设计不合理，使得开发需要模块间联动的复杂业务组件变得困难甚至不可行（比如答题、集卡组件）；

d. 拖拽能力问题：组件列表和图层树采用两套拖拽实现方案，功能和体验割裂，且三方库的拖拽能力越来越难以满足快速发展的业务需求；

e. 开发环境问题：开发模式和搭建模式使用两套不同的可视化方案，容易出现组件开发和搭建环境下渲染表现不一致；加上无法实时预览、开发工具碎片化等问题，导致整体开发体验较差

3. 存量业务方面： 平台维护组件数量多达330+ 个，如何低成本地进行新架构的快速适配和迁移；

2）外部挑战

活动平台目前接入垂类业务技术团队 8 个（直播、漫画、电商、OGV、猫耳、商业、星辰、大会员），垂类业务方开发组件 230+ 个，运营使用团队 20+ 个，日均支持 35+ 个活动。

涉及的业务范围广而多，如何在不影响业务正常运转的情况下，对平台进行渐进式的改造重构；
如何最小化业务方的技术迁移成本，同时保证迁移效果接近无损，需要谨慎设计和合理规划。

3.3 建设目标

我们基于平台开发经验和业务现状，结合对未来的规划，进行全面审视和重新思考后，新活动平台明确了几个建设目标：

解决所有用户反馈的使用问题，打造体验一流、更具生产力的一站式活动页面可视化搭建系统；
以体验和效率为目标，重新设计 No Code、Low Code、Pro Code 三种业务模式，更好地服务于运营、用户和研发；
系统架构设计在满足中短期规划的同时，保留足够的灵活度和拓展性，为长期业务发展做一定的准备。

为了保证能顺利推进完成业务和技术上的双重目标，需要制定一套行之有效的方法论来支撑和指导。

建设理念：业务优先，技术驱动

活动部门做为职能部门，保障业务是我们的基本生命线；同时做为技术团队，技术驱动是第一生产力。技术自驱也是我们团队一直以来的行事风格，Flash 平台建设如此，新活动平台建设也是如此。

执行策略：短线技术优化，保障业务开展；长线技术升级，助力业务增长

通过短期的技术优化，来确保活动业务能够顺利交付。同时，我们着眼长远，通过技术迭代不断提升工程能力和效率。在这个过程中，技术不仅支持业务发展，还能推动业务创新，优化活动形式和效果，让活动越办越好，最终实现良性循环。

基于这个理念和策略，活动平台整体建设规划了三个阶段，来逐步推进落地。

04. 建设历程

以半年为周期，我们规划了两个时期三个阶段的推进节奏：

短线技术优化期，目标是保障业务开展

1.活动平台一阶段：

关键词：界面交互重构，用户体验升级。
业务目标：重新设计 No Code 模式的搭建流程，集中解决活动页面搭建问题，提高运营使用效率和体验。

升级技术升级期，目标是助力业务增长

2.活动平台二阶段：

关键词：平台架构升级，组件生态建设。
业务目标：通过长线渐进式技术升级，解决整体架构性问题，并完成 No Code 模式底层重构，开始赋能业务。

3.活动平台三阶段：

关键词：开放能力补完，C端性能优化。
业务目标：长线技术规划图谱补全，基于新架构重新设计 Low Code 和 Pro Code 模式，助力业务跑得更好。

4.1 一阶段

运营是活动平台生产端的主要用户，平均每天花费超过 4h 时间用于搭建活动页面，由于前面提到的包括制作页、画布、数据源、组件在内的各种问题，使得运营一直以来在使用活动平时都要忍受相对糟糕的的体验和低下的效率。

因此这阶段的主要目标，是在不涉及系统底层架构大改的基础上，通过局部模块的重新设计和调优，来重塑 No Code 模式的搭建流程，集中解决活动页面搭建问题，在保障业务正常开展的同时，短期内快速提高运营整体使用效率和体验。包括：

提供更现代化的界面和交互，产品化打磨流程和细节；
解决大部分痛点体验问题，从创建到搭建到管理，从数据源到组件全流程覆盖；
提高整体活动页搭建效率，提高业务产出。

1）技术架构设计

先来快速了解下平台整体系统架构组成：

eva 服务：活动平台前台应用。运营主要使用的服务，承载了活动页面的全生命周期（创建、搭建、发布、分析、管理），包括 6 大模块（活动列表、制作页、活动效果、功能数据、权限控制、辅助工具）和 2 个生态（组件生态、数据源）。其中制作页是最核心的模块，也是运营使用最高频的功能，主要由画布、图层树、属性表单、组件列表四部分组成。
eva-server 服务：活动平台 node 服务。主要负责预览/线上页面的 HTML 构建、基础 SSR 服务、页面部署上线，以及提供平台内部使用的接口能力。
page-service 服务：活动平台页面服务。主要负责页面分发，配合 SLB（Server Load Balancing - 服务器负载均衡）和 BFS（bilibili file storage - B站文件存储服务）能力来实现轻量级的路由管理，以及通过内存化缓存来提升服务稳定性，同时还支持了服务多活和 SLB 降级。
page 产物：用户最终消费的静态页面。

这阶段的架构设计，我们在保持整体框架不变的基础上，对 No Code 模式流程里涉及的功能模块都进行了优化（白底的模块，15+），并对几个重点模块做了重新设计（黄底的模块，5+），包括最核心的制作页模块改造和一体化数据源改造。

2）重点建设案例

由于涉及优化的模块太多太广，篇幅原因无法一一展开，这里我挑两个重点案例来具体阐述。

a. 画布改造

画布改造是为了解决一直被诟病的组件预览问题，我们通过新的技术方案来实现所有组件的实时全真预览能力。详细对比了 component 方案和 iframe 两种技术方案：

考虑到体验和效果优先，为了保证运营在页面搭建过程中能实时便捷地预览组件配置效果，最终选择了 iframe 方案。但该方案存在跨页面拖拽的交互问题，如何解决呢？

经过探索和实践，我们采用了在画布上引入 previewWarp 中间层的方式来解决 iframe 的跨页面拖拽问题。具体方案为：

previewWarp 以透明浮层的方式覆盖在画布的 iframe 容器上方，默认为隐藏状态；
从组件列表拖拽组件进画布时，previewWarp 浮层显示并且作为 Drop 的目标区域，实现画布的拖拽交互；
拖拽完成后 previewWarp 自动隐藏，避免影响画布本身的交互操作；
同时通过 Message 通信通知 iframe 页面添加组件到图层树，并触发重新渲染画布，达到实时预览的效果。

previewWrap 工作流程示意

b. 数据源改造

数据源改造是为了解决另一个长期被诟病的问题 ------ 活动玩法组件配置太复杂、配置难、易配错。我们通过重新设计整个配置链路，提供一站式的配置面板来降低运营使用数据源的心智负担，以及减少线上问题的发生。

采用的技术方案，简要来说是：动态维护一个表单栈 stackForm，存储当前层的 callerId、data 等数据，层级增加时 push，层级减少时 pop，并检查当 returnId = callerId 时，触发上一层的回调，返回当前层的配置数据。最后携带数据源 ID 和数据返回到入口处，交由组件自行处理信息回填等操作。

一体化数据源使用示意

数据源配置入口与数据源组件配置表单直接绑定，让运营在使用上一气呵成，省去了来回跳转的麻烦。因此与一体化数据源面板一起重新设计的，还有首批数据源组件：任务组件、抽奖组件、征稿组件。不仅在组件功能和组件表单上做了对应的升级联动，还在数据源表单项上进行了重新思考，保留最核心的配置项，合理删减低频功能，下调高级功能的显示优先级，为运营进一步减赋提效。

流程和功能简化后，对降低配置难度和提高配置效率有着显著的效果：

举一个例子：运营配置一个完成任务获得抽奖机会的活动：

经过对上线后的数据分析统计，一体化数据源改造使得由于配置出错导致的线上问题减少了 30%+！

3）阶段建设成果

这阶段完成了一系列模块的优化项，覆盖了 No Code 搭建流程的方方页面：

制作页优化：全新设计的制作页面、升级图层树，优化拖拽体验、支持跨层级拖拽组件、重新设计表单控件、升级组件列表...... 等等；
画布优化：iframe 画布方案、重新设计通信方案、渲染器升级，支持容器多级嵌套... 等等；
数据源优化：一体化数据源面板方案、重新设计各类数据源配置项、统一活动概念... 等等；
组件优化：新增平台级的弹窗、标签卡组件、任务、抽奖、征稿等多个数据源组件一体化改造、容器、标签卡等基础组件优化... 等等。

兼具体验和效率的新版制作页

同时也在业务上取得了可观的成果，并多次收到运营使用上的的正面反馈！

解决了 80% 的体验和效率问题，平均搭建耗时 3.56h，征稿类活动搭建耗时 3.89h，提效 20%+；
新搭建流程覆盖了 **42%**选题会活动；
简化了征稿活动流程，提效 34%。