前言

为应对软件危机，诞生了软件工程，以期望其达到降低软件生产成本、改进软件产品质量、提高软件生产率水平的目标。自上个世纪60年代以来，从模块化、面向对象设计到设计模式，从瀑布流模型到敏捷开发，dev-ops, 软件生产的指导理论和工程方法都在不断进步，软件的生产效率有了很大改善。然而直到今天，业务需求的增长和企业开发资源紧缺的矛盾依然广泛存在。
与此同时, 近年来no-code/low-code的理念得到越来越多的国内外企业的重视，各类零代码、低代码开发平台层出不穷。据Gartner的研究预测，到2024年低代码平台将被应用于65%的应用程序开发。尽管它也不是解决所有问题的“银弹”, 但是低代码作为一个趋势，代表了业界向自动化编码迈进了重要的一步，在AI编程变得普适之前，低代码能够大幅提升业务交付效率。
本文结合爱奇艺App后端在业务数据同步方面的实践，分享基于低代码平台高效交付业务需求及避免重复开发的经验。

Part 01 业务背景

首先以移动端为例，我们先简单回顾下业务数据在呈现给用户之前普遍会经历的大致过程：

数据生产后台: 运营人员或者自动化程序通过业务生产后台将数据生产出来。比如编辑或者用户发布的文章、上传的视频，或者爬虫程序自动抓取网络上的资源，数据生产后台将这些数据存放的数据库中，并提供读取服务供下游业务获取数据。当数据发生修改后，通过消息通知下游更新数据；
数据同步：业务部门通过数据同步服务将生产后台产生的数据进行转换、聚合等加工处理，写入到数据库和分布式缓存里；
数据库&缓存: 存储各类业务数据供业务后端接口读取；
后端接口：接受App前端的请求，从缓存、数据库以及第三方接口读取各类业务数据，按业务需要进行各种组装处理。
App前端：请求后端接口并解析返回的数据，并在设备上进行渲染呈现给用户。

出于整体组织效率考虑，一般来说，数据生产部门主要专注于数据生产的场景，对于数据最终如何使用无需过多专注。而实际通常来说，最终呈现给用户的数据是丰富多样的，这通常意味着我们需要聚合不同生产方的数据，出于性能上的考虑，这种聚合完全交由后端接口在响应用户请求时实时访问多方数据源接口来聚合是不现实的。同时面向用户的业务往往并发流量较高，基于高并发以及高可用的需要，数据往往会存储在不同的数据库中间件里并保持一致性。基于这样的背景，数据同步服务承担了数据从生产侧交付给消费侧的桥梁角色，这使得生产部门能更加专注于内容生产环节的迭代，而消费侧(一般是后台接口)专注于如何快速交付业务接口以及保证服务接口的高性能和高可用。

Part 02 挑战

在业务早期，数据同步处理的数据类型和数据量不算太高，这种模式下各个部分职责划分也比较清晰，各个业务环节迭代都比较高效。然而随着业务不断发展，需求场景不断丰富，逐渐出现了一些问题。主要表现为：

人力瓶颈：数据同步模块承载的业务数量来源越来越多, 光就本人所在团队来说目前已经有30+数据同步业务，而绝大部分业务需求的都需要对底层数据进行调整，数据同步环节的开发人力逐渐成为瓶颈;
迭代周期紧迫，项目质量难以保证：由于业务需求对底层数据依赖关系通常并不能直观的识别出来，这造成了产品同学在交付需求文稿时容易遗漏对数据层的分析，甚至业务开发同学在早期需求评估阶段也无法准确识别出对哪些基础数据有依赖，这导致在版本临近交付时才能识别出底层数据的需求依赖, 这就意味着留给数据同步环节的开发时间非常紧迫。同时这个节点测试团队的排期也已经确定了，测试资源往往不能充分保证，这些因素对项目质量带来了一定的风险。比如，有时为了快速交付业务需求，会直接在原有程序里新集成业务上不关联的新需求，从而在不同业务之间形成了不必要的耦合，为项目后期维护增加了风险和复杂度。
存储中间件的管理维护成本增加：数据同步模块负责将各类业务数据到落地存储中间件，而下游众多的业务接口需要访问这些中间件来获取数据，这使得接口需要了解数据存储的细节。一旦需要调整存储方案(比如中间件依赖的虚机要下线维护,需要迁移集群)，除了迁移存量数据，数据同步模块和众多业务接口均需要调整，而调整的第一步，仅仅确认几十个项目里哪些需要调整的工作量就不容小觑，更不用说进而再制定并实施跨越众多项目的协同迁移计划。为此我们开发了一些基础数据接口和封装数据访问的sdk, 这在一定程度上解决了问题,但另一方面也新增加了基础数据接口和相关sdk的维护成本。
重复编码的场景较多：比如，每一个同步业务需要开发监听消息队列，访问生产方接口的代码，同时非业务必要能力开发比如重试、限流、监控等，在每个具体业务都需要实现。对这个问题，我们一度寄希望于通用的同步模板项目来解决。但实践下来，模板的通用性和业务的多样性之间存在矛盾，同时每个业务仍然需要创建项目开发、测试代码，仍然有较高维护成本。放眼整个公司，还有很多兄弟团队也有大量类似的场景，比如pc端，h5端和我们可能都依赖相同的上游生产方，存在大量相同场景的重复实现，这种情况下如何避免重复开发呢？

Part 03 方案调研

基于上述这些问题，我们希望寻求维护成本更低、开发效率更高的解决方案。为此我们对数据同步相关产品进行了调研，结果发现大部分都是面向异构数据库的同步，或者只能支持批处理任务，抑或不能方便扩展访问外部接口, 综合下来并没有发现能较好适配我们业务场景的。当然调研的这些产品很多特性为我们提供了重要的参考，比如dataX的插件机制和Spring Cloud Data Flow的编排能力给了我们很多启发。

在后续的调研中，近年来逐渐兴起的低代码开发平台方案走进了我们的视野。低代码开发平台是无需编码（0代码或无代码）或通过少量代码就可以快速生成应用程序的开发平台。它允许终端用户使用易于理解的可视化工具开发自己的应用程序，而不是传统的编写代码方式。构建业务流程、逻辑和数据模型等所需的功能，必要时还可以添加自己的代码。完成业务逻辑、功能构建后，即可一键交付应用并进行更新。

结合我们的业务遇到的问题，我们期望通过低代码平台以较低成本实现如下目标：
1. 快速交付能力。 能够通过可视化编排来快速实现业务逻辑。
2. 避免重复开发。 这里有三层含义：
（1）功能单元复用：同样的功能，无论是中间件的访问，还是某些业务接口的访问，只需要开发一次即可，新的业务需求里如果有相同的场景，比如访问同一个公共访问的接口，能够直接复用之前的工作；
（2）业务场景复用：不同业务团队有类似的业务场景时，可以快速移植，只需要调整少量参数即可实现；
（3）CI流程复用：所有业务的开发和上线能够复用相同的构建、部署流程，从而降低维护成本。
3. 能够灵活扩展。 比如使用到之前未支持的中间件，需要能够方便的集成到已有的功能体系里来,并且能在后续业务里复用。
4. 高可用。 稳定性是业务的基石, 对数据同步来说，异常重试、限流、监控、告警等基础能力必不可少。
5. 方便查看业务对中间件的依赖。 比如能查看一组redis集群被哪些业务使用，一个业务使用了哪些中间件资源，方便后期的维护。

Part 04 爱奇艺鹊桥平台介绍

基于前文所述背景，鹊桥平台的设计思想主要是：

封装可复用的逻辑节点, 通过对这些逻辑节点可视化的进行编排快速落地业务流程；
通过平台化复用基础能力；一次开发，所有业务应用都受益。

例如可以将消息消费，消息实体解析和特定接口的读取分别封装成可以复用的逻辑节点，在实现业务逻辑时，只需要将这些逻辑节点进行组合串联即可。在运行阶段，数据在每个逻辑节点被加工处理并按顺序向下游传递，也可以根据业务需要增加判断分支，这样业务可以通过类似画流程图的方式快速交付。

如上图所示，鹊桥主要有管理后台和同步引擎两个部分组成。管理后台供业务开发同学完成业务逻辑的编排和发布。主要功能有：

操作简单，提供了可视化的业务编辑器，可以通过拖拽的方式完成业务开发；业务编排完成并发布后，会生成业务描述配置信息并存入云配置中心后续供同步引擎使用；如下图所示为业务开发的编辑器，最左侧是各自逻辑插件的列表，可以直接拖到中间的画布上组合形成完整的业务处理流程。通过右侧的属性配置表单可以为每个逻辑节点指定业务相关的配置参数，比如限流配置，重试配置，关联服务授权信息等。

提供实体映射模板管理功能。映射模板描述了如何将一个json数据转换为业务需要的数据，开发同学可以在后台对模板进行调试。可以通过实体转换逻辑节点按照映射模板来完成字段的转换。后期新增和修改字段逻辑时，只需要调整模板重新发布即可生效，不用再拉分支修改代码，从而更加快速的完成需求交付。当前线上已经发生多次10分钟内交付业务需求的案例。

提供逻辑节点插件管理。扩展插件实现约定的编程接口并在后台里导入后，就可以在业务编辑器里使用。需要指定插件所在的仓库坐标、逻辑实现类全路径名，同时在录入时可以定义插件的属性配置表单。一般数据同步业务都是后端开发同学来完成，后端一般比较熟悉相关业务逻辑，相对来说完成插件后台的逻辑扩展不存在门槛，但是由于需要将逻辑插件和可视化编辑器进行集成，涉及到前端页面的开发，这往往是后端同学不熟悉的领域。为了避免后端同学学习前端的成本，我们将属性表单的生成做成了拖拽式的，无需前端技术基础也可以快速完成表单的开发。

中间件资源的管理。可以将业务需要的中间件资源导入后台，之后在开发业务时，可以在对应逻辑节点的属性配置表单里通过下拉框选择到。同时平台自动维护了业务和中间件的依赖关系。
管理后台和公司相关基础支持平台打通，最大限度的避免重复性人工流程。比如和应用运维平台打通实现一键部署；和日志平台打通，自动完成业务日志的投递；和监控告警平台打通，业务应用创建后自动注册到监控告警平台。

同步引擎完成对数据的处理。首先在应用构建阶段会基于业务配置分析当前需要使用的的逻辑节点插件列表并将列表内的插件和引擎核心模块一起打包；应用部署后，引擎在启动阶段会加载配置中心的业务配置，完成中间件资源访问的初始化，并逻辑节点进行初始化，这一步主要是加载业务配置里为每个逻辑节点实例设置的配置参数，并执行插件实现的初始化逻辑。初始化正常结束之后，引擎将进入运行阶段，开始处理线上数据。数据从起始节点进入业务流程后，依次执行各个逻辑节点。引擎在运行过程中会定时上报心跳给监测服务，一旦心跳超时，会触发告警通知业务开发同学及时处理。而业务指标(比如tps、成功率、耗时))的监控数据则会投递给监控系统。
如上所述，管理后台面向开发人员提供业务开发维护能力，同步引擎负责解释和执行编排好的业务逻辑。业务同学无需再针对每个业务需求都按照常规方式“拉分支à修改代码à提测à上线”的流程,只需要简单拖拽和配置即可，业务交付效率大大提升。同时稳定相关的基础能力已经通过平台化进行了沉淀和复用，在保证业务稳定的同时降低了维护成本。
自爱奇艺鹊桥平台上线以来，目前已经承载了近20个数据同步业务，30+应用实例，集成了30+业务逻辑节点。为相关业务的快速迭代提供了稳定支撑。后续我们会将存量的同步业务移植到该平台来降低维护成本。

总结 & 展望

本文主要介绍了鹊桥平台的主要功能，就目前来说鹊桥将传统方式小时级到天级的开发耗时缩短到分钟级，极大提升了开发效率；同时开箱即用的高可用能力保证了业务的稳定性。
后续我们考虑从如下几个方向继续优化迭代：

进一步提供数据访问层服务代码的自动生成，进一步降低开发成本；

支持在私有云平台上部署以为更多的业务团队赋能；

结合平台形成公司内部的业务数据集市，避免不同业务团队间的重复开发。

参考文献：

1. The Rise of No/Low Code Software Development—No Experience Needed?

2. https://zhuanlan.zhihu.com/p/128581398

3. https://baike.baidu.com/item/软件危机/564526?fr=aladdin

本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。

原文链接：

低代码在爱奇艺鹊桥数据同步平台的实践

创作场景

低代码在爱奇艺鹊桥数据同步平台的实践