如今可视化搭建、低代码等通过拖拉拽生产页面的方案已经很常见,然而它们大多用于活动页搭建、中后台 CURD 场景等相对来说非核心的业务场景,主要原因是 C 端核心场景对于性能、灵活性等方面都有非常高的要求,大部分基于搭建的系统难以满足。
云音乐在过去半年到一年的建设中,建设了从搭建 UI 到投放数据的灵渠搭建能力,并在新首页改版中完全覆盖了新版首页发现流、音乐流两个流量最大的核心页面和 26 个全部模块,可以说新版首页完全就是「搭」出来的。
本文将介绍我们如何通过可视化搭建系统支撑云音乐新版首页这样的核心场景,并满足其对性能、动态化和精细化运营的诉求。从中也可以看到可视化搭建、低代码等解决方案理论上能够覆盖的场景比想象中更大。
在云音乐新框架改版中,发现流和音乐流是两个核心的信息流页面。
首页作为最大的流量入口,不同的垂直业务都会在首页上提需新增模块,从而技术上面临几个核心问题:
在常规的需求交付链路中,不同角色各司其职完成不同部分的开发,然后联调、测试并且发版上线。
这样整个链路的沟通成本、重复开发成本、以及发版、放量周期带来的时间成本都非常高。
而在云音乐新版首页的交付中,我们在灵渠平台上通过结合搭建、投放、客户端动态化 DSL 引擎的能力建设,把整个需求交付链路重构为只需要一名开发(一般是大前端开发)就能独立完成的过程。
在需求交付后,灵渠平台也能直接通过开发者的配置提供面向运营的配置表单,提供通用的资源、内容、计划配置等通用能力。
今天动态化能力已经是各大 App 厂商不可或缺的基础能力,相比于跨端技术能够把 Android、iOS 双份开发人力缩减到一份,动态化能力允许我们在不经过「发版-放量」的过程快速进行迭代调整,对业务迭代和价值验证来说无疑更加重要。
然而,动态化能力的增强几乎同时就意味着性能上的损耗,我们可以从当前主流的几种动态化方案的能力和其性能表现看出,并不存在一劳永逸能够满足所有场景诉求的动态化方案,我们需要针对我们的业务诉求做出合适的选择。
以首页为例,核心大流量场景往往需要给垂直业务场景分发流量,这种场景有几个特点:
所以对于流量分发类场景来说,客户端 DSL 是最合适的客户端动态化方案。
在具体的客户端 DSL 方案上,我们没有从头造轮子,而是基于优酷团队开源的 GaiaX 做了上层封装和定制开发。对接了云音乐内部的生态(如路由、RPC 等)。同时在此基础上封装了大量通用容器,如弹窗容器、RN 混排容器、图片分享容器等等。
引入客户端 DSL 后,随之而来的问题是其带来的学习成本,GaiaX 的 DSL 本质上由三个文件 组成。
这样带来的问题是,DSL 的代码本身可读性并不好,和开发者过去熟悉的技术栈都不一致,会带来非常高的开发成本。于此同时,我们也需要建设对应的配套工具(例如预览、调试、发布流程)来支持开发者开发。
GaiaX 显然也意识到了这个问题,提供了 GaiaX Studio 这个基于可视化搭建的 DSL 开发工具,但可惜的是这个工具并不开源,我们无法在此基础上开发我们需要的能力(例如对接云音乐的换肤、RPC 等等)。
于是,开发一套具备可视化搭建能力的 DSL 搭建系统,同时在这个系统上去建设开发者配套能力就成为我们的首选项。
最终的产品形态是我们建设了一套在线的可视化搭建系统,同时支持直接扫码预览、错误检查、内部系统(换肤、图片素材管理)对接、发布流程、数据 Mock 等等开发者配套,使得不同技术栈的开发者(主要是大前端同学)可以直接在线通过拖拉拽直接开发出可投放的 DSL 卡片。
无侵入性进行数据编排,通常的做法有 SPI,Groovy脚本,第三方系统 (类似选品系统 平台只提供对接)
考虑到云音乐已经有一套完整的BFF能力, 具体可以参考之前发布的文章 基于GraphQL的云音乐BFF建设实践。我们决定使用其能力,在搭建端可以选择BFF生产的对应数据源,并且在用户访问时自动完成对应的数据组装。
同时在搭建端我们也提供了可视化的数据字段选择、mock 等能力,通过这种方式让 UI 视图的开发者自己也可以开发对应 UI 字段的数据源后端。而业务后端的开发者只需要提供底层 service 即可。
完成了卡片的开发后,下一个问题是卡片如何被投放出去。
流量分发场景需要通过精准的目标受众定位、选择合适的投放形式、渠道和时机、设定合适的投放内容和时间,来实现投放效果最优化和投放效益的最大化。通过有效的投放策略,内容投放平台可以帮助提高资源曝光率、点击率和转化率,从而实现内容投放效果的最大化。
灵渠作为投放平台,提供了多种投放策略,以及策略规则组合配置。基于灵渠平台的策略能力,我们可以把「某个位置上面向某个人在某个时间应该出什么样的 UI」也通过策略化的能力承载。
灵渠平台具有多种投放策略,如客户端版本、人群圈选、频控策略、AB实验等,并且支持通过bff开发业务自定义策略,做到了策略的复用性以及灵活性。
上面所说的都是 DSL 卡片从搭建、投放到最后端上渲染出来的链路,但并非整个页面都是由 DSL 搭建的,页面框架本身还需要考虑下拉刷新动作、数据缓存管理、列表 cell 复用等等问题。
而这些需求不仅仅是首页才有,在大部分信息流场景都是存在的,所以我们在端上封装了整页混排容器,把信息流页面大部分通用能力都封装到一起。之所以要考虑混排,是因为有时候 DSL 不能完全满足某些业务模块的诉求,所以我们允许在部分模块上使用 Native 或者 React-Native 进行开发。
在承载了首页这样的大流量核心场景后,模块的数量、复杂度、参与人数的增加,都给稳定性带来更多的挑战。虽然引擎和系统本身的稳定性很少出问题,但是开发者在使用平台时却经常产生很多意料之外的问题。
灵渠搭建平台在不同阶段提供了不同的质量保障:
在质量保证上灵渠平台还提供了配置资源位兜底, 在下游发生一些异常等其他情况拿不到数据时候,能继续透出模板数据。配置如下图所示。另外还支持用户纬度的兜底数据配置,满足新首页推荐流中个性化模块兜底的场景,如最近播放。
本文介绍了云音乐如何通过可视化搭建系统支撑新版首页这样的核心场景,并满足其对性能、动态化和精细化运营的要求。文章还探讨了动态化能力的重要性和各种动态化方案的能力和性能表现,以及针对不同业务诉求做出合适选择的必要性。
展望未来,可视化搭建、低代码、客户端DSL等解决方案将会在更广泛的业务场景中得到应用,从而进一步提高开发效率和满足业务需求。
本文发布自网易云音乐技术团队,文章未经授权禁止任何形式的转载。我们常年招收各类技术岗位,如果你准备换工作,又恰好喜欢云音乐,那就加入我们 grp.music-fe(at)corp.netease.com!