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

Part 01 业务背景

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

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

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

Part 02 挑战

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