大运河:端到端研发模式在商业化的应用实践
文章摘要：大运河商业化端到端解决方案。项目针对B端和C端的不同挑战，提出了一种标准化协议，约定前后端基于协议通信，实现组件化和配置化开发。大运河通过协议化生产、可视化配置和统一的运行时，结合高效发布能力，提高了研发效率和资产复用。
一、前言
大运河为商业化大前端到端研发解决方案。大运河为世界上最长的人工河流，贯穿中国东北平原，链接北京和杭州，是中国古代最重要的水利工程之一。大运河的建设目的主要是提升南北运输的效率，这和我们技术大运河项目的提效目的一致。
二、项目建设背景
业务特点与挑战
商业化B端和C端的研发效率分别面临着不同的挑战。
对于C端而言，我们可以看到快手app里的广告很少出现全页类型，大多数都是嵌入在其他FT业务页面中的卡片；因此需要受到其他FT框架的制约，需要依赖他们来实现样式、功能和逻辑的复用，比如动效设计需要和接入的业务视图联动、曝光打点依赖业务组件的生命周期回调；以上种种在以往的研发模式中都需要客户端同学的重度参与，这样的研发模式带来的最大的问题就是需要强依赖发版，发版效率成为最大的挑战之一。
我们再来看B端的情况，商业化B端服务于多种商业客户，为他们提供广告制作、创编、投放、出价、计费、数据等种种能力；整体的复杂度较高，甚至有的复杂场景涉及到了上百个字段的状态；单客户使用时长较长，需要完成的动作复杂性也更高，需要有更好的操作效率和更高效的信息获取能力来帮助决策，产品会对这些点会反复进行打磨；同时我们对于2023年的需求进行了统计，B端的需求量占商业化前端总需求的占比达到了70%；然而在这类场景的开发模式仍然是传统的烟囱式的开发模式，对业务规则、研发资产都没有一个很好的复用和沉淀方式，并且存在前后端边界模糊、业务逻辑不收敛等历史债，B端缺乏统一的效率提升手段和相关工具支撑。
方案能力目标
根据我们的现状分析，我们希望的解决方案的能力有哪些？
广告样式、布局、业务数据、端侧资源的修改、不重启服务也不进行编译式发版，快速的进行需求上线；
资产沉淀 - 提到端侧的资产，每个FT都会做的事情物料库组件库，这里的资产不仅仅包含端侧的资产，也包含了我们与端侧模块所对应的服务资产，我们希望每个业务领域有这样的对应关系；提到资产组件化，很多同学也会有疑问这不是每个团队都会去沉淀的事情，但是我们思考的是如何让大家都去彻底的做这件事情？
就涉及到第三点，我们需要有统一的组件化协议设计；各端使用同一套组件化协议去渲染以及去做前后端交流，组件的结构化配置是协议的核心，端侧关注组件的逻辑沉淀和复用， 服务端关心各组件的业务数据填充；
在我们这种机制下各端只注重自己的业务逻辑开发和沉淀，我们仍然需要提供平台能力，将所有的职责进行串联，从而生产一份多端组件化协议，同时也会通过平台使研发流程进行规范化和标准化
三、端到端研发模式的引入
大运河的端到端含义
前后端基于标准化协议来通信，前端运行时对协议进行解析和渲染，后端运行时使用标准化的数据服务来构建和更新协议；
- 标准化协议平台无关性，与终端所使用的框架无关，多端可理解、可使用、可移植；
- 协议强约束下，端侧聚焦渲染，服务端聚焦业务逻辑，前后端边界更加合理；
- 借由协议化的使用强要求组件沉淀，前后端关联的数据资产配置沉淀，复用度提升；
- 前后端提供配置化方案，免发版，可热发；并提供动态脚本的执行能力，可以灵活应对各种业务场景；
运行域整体架构
从上图可以看出大运河运行域主要通过大运河协议来进行端侧和服务端的通信，不论端侧的实现是TK、KRN或者是Web，协议都是统一的；由于协议本身是渲染框架无关的，所以在实际的渲染层需要根据不同的渲染终端来实现运行时用来解析协议和渲染；不论终端是什么框架，运行时的能力有相当高的通性，比如协议的解析、布局、样式、埋点、事件等等；但根据各个场景不同的需要特性能力建设略有不同，比如C端重动效，而B端交互较为复杂重联动和异步刷新等；
这个协议是怎么生产的？可以看到我们提供统一的服务端运行时来进行协议生产，在这一层我们将后端服务和协议进行关联，并且进行协议填充，这一层也支持运行动态脚本来提升我们对业务逻辑的灵活的适配；协议所关联的后端服务数据的来源是多样的，像C端主要是由广告样式中台下发，而B端可以直接来自于后端微服务或者API接口，也可以通过后端低码对领域服务进行编排，使用编排结果来进行协议填充；服务编排就是我们的后端低码模式，可以在该层对渲染层逻辑进行更为灵活的适配；
标准协议定义
大运河的标准化协是在千象协议上进行扩展的结构，主要包含信息层、渲染信息和数据层三大块内容；下面介绍几个重要的部分含义；
- componentCode：组件静态资源信息和版本信息；
- flattenedView：描述大运河模块/页面的组件树结构，以及每个组件的后端数据填充结果，是大运河协议中的核心；
- linkage: 主要描述组件出发异步变更的规则；
协议化生产相关能力
- 我们提供了可视化配置页面来进行协议的生产，这方面的基本的面板和属性配置能力来自于千象低代码引擎；在这个基础上我们也基于千象灵活的扩展能力扩展了相当多的端到端协议能力，比如协议联动配置、数据源相关的一系列配置能力；
- 大运河在物料生产方面，不仅统一了端到端组件的物料协议格式，而且打通了物料生产流程，可使用物料中台能力快速创建端到端组件，并可以拉取到相关配置能力，快速在大运河平台进行注册；
以上是大运河共性的方案，对于B、C端由于业务场景不同，能力建设的特点有所不同，我们下面分端介绍一下B/C各自的建设特点：
四、大运河分端场景的解决方案；
大运河B端
B端的高复杂度决定了不但需要约束，而且需要相当的灵活度；
我们分析一些核心业务发现，虽然复杂但有规律，我们的前端同学在业务中的需求“重复度”是较高的，如果能借助协议化的改造使得业务逻辑可以收敛，并且搭配配置化热发就可以相当程度上覆盖这些“重复度”较高的需求；
由于B端的高复杂度，那就需要我们抽象出一套联动方案，该联动方案既不能在搭建复杂度上无限上升，也要拥有比较强的灵活性；
除此之外我们也需要一套合理的管理域能力来串联各方角色，并且提供高效率和稳定的研发流能力；
联动设计
我们设想一下，当用户产生一个动作后，无非有两种可能的结果：
- 需要获取新的业务数据、需要服务端校验、提交数据等需要服务端响应；
- 纯展示变化不涉及到已有的业务数据变动；
在大运河的协议模式下，那就变成了需要异步更新协议或者不需要：
- 触发服务端数据更新：大运河将目标搭建模块统一抽象，将所有可能引起协议变更的事件统一抽象；基于这套事件模型我们统一了组件和协议的交互规范，能够大幅度降低联动的配置成本；
- default: 默认，首次刷新；
- submit: 提交，由组件事件触发；
- auto: 自动，由组件值变化触发；
- outside-params: 外部参数；
- 纯前端联动：大运河提供前端副作用能力，能在一些生命周期中执行前端副作用脚本来实现前端联动；
管理域设计
管理域从职责上是承担研发同学日常工作的主要阵地，是大运河前后端职责串联的核心关键，平台的技术设计、研发流的合理性都对整体效率和稳定性有重要的影响；大运河平台设计基于变更的研发流，合理的分支能力、为多模块并行作业打下了良好基础；并且平台在多环节设置安全性的校验和卡口，以提升稳定性；
B端大运河整体流程
深化业务解决方案
大运河主要面向的B端场景是非标准化的。对商业化广告的核心链路，以业务的诉求为核心，依托现有设计的良好的额扩展性，产出针对性的解决方案，帮助业务完成其技术架构升级：
发展时间线和核心观测指标
大运河B端于2023年10月开始进行产品、技术方案设计，12月大运河平台上线，1月第一个业务接入上线；
截止24年6月初，我们已经累积渗透7个商业化业务，承接65次产品需求，发布相关模块100+；由于是组件化结构协议，组件复用度上表现出良好的水平，单组件平均复用8+次，组件复用率达到了80%以上；大运河B端渗透率单月峰值达到了7%；211达成率我们也会持续观察；
大运河C端
客户端广告分布在主站的各个角落，信息流、搜索、直播、放映厅等，这些页面形态各式各样，端侧技术实现也各有不同。 我们在接入时往往需要入侵到这些宿主业务代码中，受到宿主业务技术框架的制约。并且为了更好的转化效果，广告样式的出现，往往伴随着动画效果，需要与宿主业务的组件进行联动，这就导致了商业化的广告业务无法完全闭环，受制于接入侧框架。
【图：C端广告示例】
在这样的背景下，当需要新增/调整样式、修改出入场动画、以及对齐宿主业务的需求迭代时，均需要依赖客户端发版。这里会导致两个问题：
1、双端的研发效率 。我们需要分别安排Android和iOS进行来开发相同的业务逻辑；
2、业务的触达效率 。客户端发版本需要按照主站的节奏，每周二封版、周四全量，后续一周的时间才能覆盖到60%用户；
解决思路与实现
对于依赖客户端原生代码的问题，我们的主要思路是将原生代码管理动态化组件的方式，升级为： 通过协议和动态化代码去管理动态化组件 。
首先，我们需要用通用协议也就是大运河协议来描述这些组件，包括他们的类型、位置以及动画等信息。
第二步，要去解析和执行协议。 传统做法是在Android、iOS两端分别实现协议的解析和执行。我们的思路时用 js来实现这个过程 ，这里可以复用前端的逻辑，即大运河统一运行时(Runtime)。
在客户端上，可以非常容易的把这个js跑在TK容器里面。这样我们就能避免双端对协议解析和处理，从而减少对客户端发版的依赖。
【图：解决思路】
基本实现过程
核心点： 支持在TK容器中创建TK容器 ，因为大运河Runtime本身是跑在TK容器里面的，我们需要让它能够创建其他TK容器；
第二步，把大运河Runtime的视图添加到广告场景的顶层(最上层)；
第三步就是把协议传给Runtime，由Runtime来创建和管理组件。
【图：大运河实现过程】
实际案例分析
这是激励简易直播间的一个例子，如下图所示，左边两张分别是直播中和直播结束两种状态，不同的状态下组件有所区别。同时随着迭代，在最底部会出现各式各样的卡片。 右边的4张图就是可能出现的一些例子，比如可能会带有一些actionbar。
【图：激励简易直播间】
在使用动态化组件的背景下， 传统 的研发思路是预先在这5个位置埋入组件坑位，各个坑位的出现动画逻辑都由客户端原生侧来控制。虽然通过下发不同的动态化组件，能够达到展示不同组件的效果。但是，如果要增加、调整位置，就需要客户端发版本来解决。
【图：传统思路】
在使用大运河方案的情况下，只需要一个原生容器（下图虚线部分），绿色部分就是Runtime的视图，我们把这个视图添加到客户端原生容器中。其他的，包括播放器、倒计时、按钮等所有组件，都通过协议下发，由Runtime进行创建和管理。客户端原生代码就不用关心场景内部逻辑。
【图：接入大运河方案】
C端能力扩展 — TK2Web
在大运河统一协议、统一运行时的建设过程中，加速了前端与客户端的技术碰撞和升级，基于此扩展出了大运河TK2Web，使得原本只能执行在客户端容器内的200多个广告样式卡片可以渲染在浏览器中，并在广告创意编辑阶段进行实时预览。
【图：客户端的TK2Web】
客户端的TK卡片代码是从tk build编译成js的，这个js之前只能够运行在iOS/Android的TK容器中。现在我们开发了一个定制的WebTK容器，首先引入了一个定制的运行时，提供所需的各类组件，使得浏览器能够执行客户端TK的js代码，并且结合卡片相关数据，能够将客户端的广告卡片在浏览器中渲染出来。
【图：TK2Web基本原理】
以下为磁力智投平台上的案例。通过TK2Web方案，我们实现了客户端组件在前端的1:1还原，前端同学不用再关心卡片内部的元素，只要使用对于的js并传入所需的数据，即可实现完全一致的效果。这个定制的WebTK容器，在实际运行过程中是作为一个iframe嵌入在外部页面中，类似客户端内的TK容器，多个组件之间互相隔离，一个页面能够支持预览多个组件。
【图：创意编辑】
C端阶段性总结
截止目前，大运河C端渗透了大约23%的广告位，开发了14个大运河相关组件。5月份TK2Web功能正式在2个业务平台落地，已支持27个广告组件，在近两次的迭代中，预计节省了19pd的人力投入。
【图：C端阶段总结】
五、未来规划
一、提升业务渗透，在业务需求中体现价值
在Q2我们完成了B端7个业务域、50多个场景的接入，C端完成了搜索和激励广告的接入，TK2Web首次在业务落地；
到今年年底，我们B端和C端的渗透率目标分别是渗透15%的需求和50%的场景；
二、大运河框架的不断升级和扩展
整体来看，大运河目前还是一个比较年轻的项目，还有很多功能需要完善，我们期望框架的能力至少能够走在业务需求前面，不阻碍业务需求的接入，通过持续的完善大运河框架，能够为更多业务场景赋能。
【图：大运河未来规划】
2人已赞赏
分享
2
12
1