低代码开发平台与零代码开发平台相比，谁的性价比更高

Posted 2023-04-19

这几年很火的一个概念叫低代码 ( Low Code Development ) 开发，用少量的代码就能开发复杂的业务系统。然后更进一步，由此又催生出一个新的概念：零代码开发 ( No Code Development )。

但是想想人工智能，吹了这么多年，落地的应用有多少呢？语音开空调？关窗帘？可以查天气的Siri？最有用的好像是自动驾驶，算是在一个细分领域的具体应用。是的，理想总是美好的，现实却要脚踏实地。本文就来扒一扒零代码开发平台美丽故事后的真实现状。

零代码开发是新技术吗？

其实零代码开发并非什么新鲜的概念。2000年左右就非常普遍。大家还记得水晶报表 ( Crystal Report ) 吗？不需要依赖开发人员，使用图形化的工具就能绘制报表。还有 Lotus Notes，可以在界面上配置数据表单，并且通过邮件的方式发送到各个部门填写。还有BPM软件（审批王、K2等），无需开发人员介入，使用图形化的方式就能配置表单与流程，实现业务流程的数字化。还有自助建站系统，选一个模版，画几个网页，就能生成一个高大上网站。然而这些都是20年前就存在的技术，零代码只是一个新头衔。

零代码开发平台可以做什么？

从应用范围上来说，零代码开发目前能做的和20年前差不多，还是局限于细节的开发领域。这些开发可以总结出共性，可以标准化，可以设计出图形化的界面给最终用户使用，因此能大幅提升效率。

目前的零代码开发平台主要有三类，界面设计类、表单流程类、数据管理类。

第一类是界面设计类，通过拖动的方式绘制用户界面。思路与传统的自助建站系统雷同，只是现在进行了扩展，不只是开发网页，还能与后台的业务数据交互。不仅能绘制电脑端的界面，还能设计手机端的样式。典型的厂商有 微软的 PowerApps，被西门子收购的Mendix，以及获得大笔融资的Outsystems 。

第二类是表单流程类，这一类工具谈不上新技术，基本上就是BPM厂商在炒作，还是20年前那一套图形化的流程设计、表单设计工具，换汤不换药。这一类工具只实现了审批的过程管理，流程结束，管理就结束了。

第三类是数据管理类，这一类工具最早的实现方式其实是Excel，可以设定很多字段，可以把数据录入进去然后进行统计。随着应用的深入，为了实现共享编辑，Google发明了云端的Excel，可以多人同时编辑，可有追踪每个人的修改痕迹。但Excel不能定义字段类型，不能做输入校验，不能控制权限，于是 Salesforce 发明了云端数据库的模式，可以在线创建数据表，设定字段，并融入了第一类和第二类开发工具的界面设计、流程设计的功能，打造了一套云端开发管理系统的新模式，也因此迅速红遍全球，成了最热门的管理软件开发工具。

零代码开发真的这么美丽吗？

前面Salesforce的故事只说了一半，零代码只是开发的第一步。我们都知道Excel可以配置公式，实现数据计算，并提供了数百个公式，可以实现很多很复杂的功能，这就是一种最基本的低代码。这些公式，给简单的Excel文档带来了更大的价值，说的高大上一点，也算是一种人工智能。

系统开发也一样，你不可能只是简单的录入和查看数据，为了让系统更智能，你必须要做很多计算。比如对于一套物品领用的管理系统，你需要实时扣减库存；对于一套会议室预约的系统，你需要计算会议室是否被占用；对于一套请假系统，你需要计算员工的年假还剩几天，还能不能继续请年假。这些就是开发人员所说的业务逻辑的部分。通过编写业务逻辑，可以让系统更智能，提升工作效率。

如何编写业务逻辑呢？Salesforce 的实现办法是使用触发器，在数据保存之前，编写代码进行校验，数据保存之后，更新相关的数据表。国产的低代码开发平台华炎魔方，也是类似的思路。

我就是不想写代码，能用零代码方式实现业务逻辑吗？

答案是可以，可以解决一小部分简单的需求。比如 Salesforce 提供了一个工具Process Builder，可以在界面上编写条件判断，执行更新数据库操作，实现基本的业务逻辑。

但是这类工具有点尴尬，如果你是一个程序员，写一段这样的业务逻辑可能只需要20行代码5分钟，但是想要画出这样一张零代码的流程图，肯定不止5分钟。如果你是一个业务人员，这上面的东西你真的能看懂吗？就算你看懂了，你能自己画出这样的流程图吗？或许IT部门的同事可以做到，但有没有真正提升开发效率我要打一个大大的问号❓。还有一点，这样的流程图，要怎么调试呢？

同时，对于大型项目，版本管理是很重要的课题，Salesforce当然也有对应的解决方案。你可以创建一个Salesforce DX项目，然后把所有界面上绘制的业务逻辑同步到本地，加入源码仓库进行版本管理。但问题又来了，你是通过图形化的方式绘制的业务逻辑，所以同步到本地的也是一大堆配置文件，各种属性用来记录配置界面上的各种参数，源码本身并没有可读性。当业务逻辑发生变更时，版本管理工具提供的代码差异比较功能更是鸡肋一样，没有价值。

零代码只是一个花架子，低代码开发平台是最好的选择

因此笔者认为，在界面上绘制业务逻辑是不懂开发的无奈选择，对于程序员来说，编写脚本思路更加清晰、更容易阅读和修改、更容易调试，开发效率更高。国产低代码开发平台华炎魔方选择编写脚本的方式来开发业务逻辑，可以很方便的实现本地调试、单步追踪、复制粘贴、以及多人协作下的源码版本管理。

低代码开发平台有什么好处呢？

效率！企业在数字化转型的过程中，需要面对很多问题。如何数字化？哪些部门需要数字化？哪些业务需要数字化？这些问题都需要在不断的摸索和试错中前行。并且业务部门永远只能描述需求，开发人员又不懂业务，如果按照传统的模式，项目上线通常需要几个月甚至数年的时间才能开发完成，这会严重阻碍业务创新的进程。而低代码开发平台就不一样了，程序员通常可以在一周甚至一天之内搭建出系统原型。业务人员可以一边试用系统原型，一边与程序员进行探讨，找到思路差异的部分。程序员也可以一边修改一边与业务人员确认。使用这种迭代开发模式，数据建模通常可以在1～2周内完成，根据业务需求的复杂程度不同，业务逻辑部分可以在2～4周内完成，系统就能正式上线了。系统推广到各部门应用之后，必然会继续反馈各种开发需求，基于低代码平台开发的系统核心业务逻辑采用配置的方式实现，只需要调整配置可以快速的响应需求，很多需求当天就能调整完，当晚就能更新到正式环境。

开发效率提高了，企业的业务创新能力也就自然提升了。在一个可控的时间段内，实现公司所有业务部门的数字化转型，把传统分散在各个Excel，各类文件，各种子系统中的数据收集到统一的数据平台上来，对于提升管理水平会有很大的帮助。举一个简单的例子：供应商管理，从供应商的初期评审、各种资质文件、到签订的每一个合同、每一次付款情况、每个项目的验收记录、每年的考评记录，都可以在一个界面上清晰的查看。对于客户，从初始的客户来源，到客户评级、每次的成交记录、谈判记录、客服记录、投诉记录、是否能及时付款、甚至客户在公司网站上的浏览记录等等，都可以完整的追踪。

只有程序员才能使用低代码开发平台吗？

低代码开发平台的第一个能力是数据建模，这一点不需要很高的编程水平，但需要懂数据库设计。怎样把用户的业务需求转换为数据表保存下来？各种业务要素，应该用什么样的字段类型来表现？数据表之间要怎么关联？数据量大时，如何优化数据结构提升查询效率？主表记录删除时，相关表记录应该如何处理？很多IT部门的专家、项目经理、产品经理都掌握类似的技能，这个环节都可以比程序员做的更好。

即使是编写业务逻辑，很多理科生在大学中都学过C语言课程。编程本身不难，定一个变量，写一个循环，写一个判断，难的是各种编程框架、各种编程语言、各种函数、各种控件、各种平台等等。低代码开发平台把所有的难题都在内核层面解决，开发人员只需要处理数据建模和核心业务逻辑编码两个部分，相对要简单很多。如果你曾经尝试过编写Excel的宏，那切换到低代码开发平台应该没有很大的难度。当然，一定需要时间去学习，我觉得逻辑思维清楚的人，通过培训课程，应该可以在1～3个月之内掌握低代码平台的开发能力。

学习低代码开发平台对于程序员的个人发展有帮助吗？

其实这是两条完全不同的发展路径。传统的程序员要阅读和编写大量的代码，使用各种编程语言，学习各种控件，各种函数，做的项目越多，编程水平越高。难题是技术的发展日新月异，要不断的学习新知识，新的开发工具甚至新的开发语言。30岁必须要开始考虑转型为项目经理或是产品经理，否则40岁以后必然要面对职业生涯的瓶颈。

而低代码开发平台的程序员专注于数据建模和业务逻辑实现，重点关注的是业务而不是编程，做的项目多了以后，可以成为这个行业内的数字化转型专家。你积累的主要是管理经验而不是编程经验。而管理模式虽然也在不断的试错，不断的优化，但是更新迭代的速度相对要慢很多，因此就好像很多管理学的教授一样，越老越值钱。

低代码：朝着更好的未来行进

得益于一些厂商的努力，低代码行业正在构建起健康的生态。我们在讨论低代码的未来时，需要清楚一点的是，低代码并非万能，它有清晰的能力边界，而非一些声音所说的会“抢走程序员的饭碗”。低代码是企业数字化建设当中“最后一公里”，在保障企业数字化进程的价值赋能下，中国市场会有低代码的一方天地。

 国内的简搭(jabdp)开发平台是一个低代码开发平台，复杂的业务功能，只需要会基本的sql语句和javascript语法，就能进行快速开发，满足其个性化的业务需求，设计出各种复杂的企业web应用。主要特点如下：

可灵活定制：简搭(jabdp)低代码平台提供了强大的定制能力，包括页面定制、数据表管理、业务流程定制等，便于实现各类企业应用。

权限管理：简搭(jabdp)低代码平台提供组织结构管理和精细的权限管理多人，便于企业根据实际情况灵活地进行权限设置和调整，促进内部协作。

易于部署和维护：简搭(jabdp)低代码平台提供一键部署功能，无需配置复杂的网络服务器；根据企业的需求变化进行系统维护也更容易。

支持二次开发和系统集成：简搭(jabdp)低代码平台是一个开放的快速开发平台，有经验的程序员依然可以基于jabdp定制开发出许多高级的功能，而不受jabdp本身的限制；同时，简搭(jabdp)低代码平台开发出的应用也可以很方便地与企业的现有信息系统集成，或者与微信、钉钉等第三方应用集成。

简搭(jabdp)开发平台适合用于大部分的企业级web应用的开发，尤其适合企业信息管理系统（MIS）、企业资源计划系统（ERP）、客户关系管理系统（CRM），业务支撑系 统（BSS）等。并且就一些经典的项目案例提取整合出各种类型的项目模板，共享给开发者参考，开发者可以在原有的项目基础上进行修改定制，以打造其个性化的企业信息化平台。

参考技术A 低代码开发是在零代码开发的基础上发展而来。意在更适配企业的需求。支持企业去开发更加功能复杂的管理系统。
目前我国的零代码开发技术还不是那么成熟，很多特殊功能是没办法通过零代码去完成的。而低代码开发平台很好的将零代码开发与代码开发相结合，让有需要的企业可以自由开发扩大自己的管理系统，让快速开发平台从以前服务小型企业走向服务于小、中、大企业。将市场范围扩的更广。
你自己可能通过百数的低代码开发平台去感受一下，申请一个免费账号，就可以随意开发自己的管理系统。基本上通过鼠标可以完成的就叫零代码开发，加上键盘敲字母的就叫代码开发了。
个人认为既然低代码可以满足零代码所有的功能，那为什么还需要用零代码呢？
而且目前低代码平台与零代码平台收费模式差不多，除了百数低代码平台拥有自己的在线私有云产品，其它不管是零代码还是低代码平台都是会员制收费模式。

技术揭秘！百度搜索中台低代码的探索与实践

一、关于低代码

低代码是软件系统的快速开发工具，开发者无需编码就可以实现常见的功能、少量代码即可完成功能扩展，从而实现便捷构建应用程序。随着企业数字化需求的快速增长，传统的软件开发方式的低下生产效率，成为制约企业数字化转型的主要矛盾，低代码得到快速发展。相比传统的软件开发模式和工具，低代码的开发门槛更低、研发效率更高；相比其他的快速开发工具，低代码的扩展性更高，可以胜任复杂场景下的核心开发诉求。研发效能也一直是各大互联网企业关注的焦点，随着近几年的探索和发展，市场上出现了众多的低代码平台，低代码也受到了越来越多的关注。

目前业界低代码框架主要解决的是一般领域的通用需求，可以低成本的拖拽组件来打造前后端一体的应用，主要用于 BRM（业务规则管理）、ERP、CRM等系统的快速研发。但是这种方式对专业领域的中后台开发者并不适用，他们面对的是复杂多样的场景，他们专注的问题是如何维护已经达到十万、甚至百万的代码，如何快速迭代、策略优化实现业务可持续增长，如何治理与保障服务的稳定性等等。如果低代码工具只能创建带界面的数据库应用，支持简单工作流场景，并不能给后者带来实际帮助。

搜索中台从业务场景和业务痛点出发，借鉴业界低代码理念，对复杂的后端系统开展了低代码探索和实践之路。工欲善其事，必先利其器，希望通过打造新的生产力工具，更高效地实现产品创新。

二、我们面对的场景

搜索中台为业务提供两种接入方式，一种是使用者以配置化的形式进行定制，之后使用提供的API接口访问中台的能力，另一种是允许使用者以代码开发、部署服务的形式在中台内部系统中进行定制，实现高度灵活的产品逻辑。前者更加接近“无代码”，但是扩展性和灵活性不够，应对的是一般性需求，后者我们在中台系统内提供了应用引擎（以下称Search-AE），业务可以直接入场开发，通过代码实现检索需求定制，满足更加灵活的业务场景。

随着深耕业务场景的规模爆发式增长，大量应用开始涌入 Search-AE，目前已经包含了200+ 独立业务系统。在需求高速迭代、规模快速增长的情况下，效能上面临的问题也越发凸显：

• 缺少有效沉淀

  在 Search-AE 发展之初，各个业务更多的是纵向发展，通用功能很难沉淀，应用之间的能力共享主要通过 copy-paste 来完成，而这些代码在一段时间的迭代后，又会因为一些微不同导致其往各自的方向发展，最终业务之间完全演变成各自独立的系统，本可以复用的能力变的更加难以有效沉淀。

• 高速迭代下系统的复杂性加大

  随着需求的快速迭代，业务系统的代码量和架构复杂度也在快速提升，部分业务代码量级已经发展到数十万级别的规模。同时业务需求又是第一位的，大家都在被需求推着走，开发过程中很难保证对文档做出有效沉淀。接手同学在维护迭代时只能通过大量源码去理解系统，难以保证高效开发。

• 研发全流程操作繁琐

  搜索本身很复杂，尤其在经历过多年的发展后，搜索系统成为链路长、连接复杂的大型分布式系统。环境部署、调试预览等都会对业务研发产生一定的负担。另一方面，研发全流程需要接触不同的工具平台，这些平台没有从全流程的维度去规划设计，它们之间的跳转、使用也会产生学习成本。有一个实际场景的例子：开发一个业务需求，先花一周时间读懂代码评估代码的修改点，再花一周去配置整套环境，还要花一周时间熟悉研发流程中的工具链，而真正写代码可能只需要一天。

总体来看，我们要解决的问题是：如何更快开发——少写代码，更快上手——系统易理解，更快交付——全流程操作简单。

三、思路与目标

业内的一些低代码平台主要聚焦的是前端的场景需求，将页面元素封装成通用组件，使用者拖拽这些组件实现页面形态的定制。搜索中台面对的是中后台场景，但是要解决的问题和思路是非常类似的。从每个业务的实际情况看，虽然最终的检索场景各不相同，但执行的功能流程都有一定的相似性，如果我们把通用的功能抽出来，业务通过组合这些通用能力来满足需求，就可以显著提升效率。同时，这些通用能力是标准化的，业务可以按标准规范进行开发，开发生态易于分享和使用，针对通用算子满足不了的业务场景，大家就会补充更多的通用组件，在下一次类似需求来到时快速满足。

统一业务框架：图引擎 & 图编排

我们的解决思路是使用图引擎来驱动业务逻辑的执行，通用和定制的能力都以算子形式提供，业务则以 DAG 图的形式串联这些算子。图本身没有一套固定的流程，算子间的连接和使用完全由业务场景决定，所以即使是完全差异化的业务都可以使用图引擎来构建系统。并且，图和算子定义了一套标准规范，开发的产品功能都通过算子的形式对外暴露，而算子又是可以插拔的，业务之间都可以方便的拿来复用。

但是，仅仅有图引擎是不够的，我们需要让算子在业务的使用之下快速沉淀起来：业务愿意去共建通用算子，并且这些算子对业务能够充分共享，即大家可以便捷的查看和使用这些通用算子。而使用图编排工具，可以以平台化的形式对这些算子进行呈现，研发同学可以快速的查看所需功能算子，也可以通过可视化拖拽低成本的配置使用。

建设图编排工具还有一个很重要的出发点是：我们希望通过可视化的图帮助开发同学快速的了解业务系统。这个图既是系统的实际运行图，也是帮助快速理解系统的执行流程图。我们使用图编排进行可视化之后，图本身就具备自解释性，研发同学可以在图上补充备注信息，图就相当于和代码同步的天然文档。对有一定规模的业务来说，通过“图文档”理解系统要比读源码理解更快，更加自然易懂。

全流程一站式研发

除了代码开发上的改善之外，我们希望有一套统一的工具对研发全流程进行提效：在图编排的基础上打造 All-in-one 的开发平台，将研发流程各个单点能力横向集成与拉通。业务研发者在研发过程中不需要学习对接各种开发工具或平台，所有的研发工作都收拢在一套工具里解决。同时这套流程又是标准化的，过去研发过程中所有的飞线技术栈都能统一起来，使用更加高效便捷的标准化解决方案。业务有能够提升效率的方式、工具也可以往这套工具里进行沉淀，共同打造。

四、Nimbus 低代码平台的设计与实践

我们在 iCoding（公司代码开发 IDE） 的基础上建设了 Nimbus 低代码平台，所以 Nimbus 天生就拥有了 IDE 包含的代码开发、编译调试等基础能力。对使用者来说，研发全流程的操作都可以在 IDE 内部完成，不需要对接外部工具系统，提供了很大的便利性。我们将研发全流程划分为五个阶段，分别是环境准备、开发、预览调试、测试和发布运维。每个阶段 Nimbus 都组建了适合的工具来降低开发者的研发成本。

一键生成线上同步的开发环境，开箱即用

在工程效能部同事的支持下，我们建设了可以开箱即用的云端开发环境。业务开发者在代码仓库可以一键申请开发镜像，后台会在云端拉起一个 Docker 容器，容器内运行着 iCoding 的服务端，可以使用浏览器的形式连接开发镜像，也可以使用 iCoding 客户端进行连接。

镜像内包含代码库、开发过程中的全部工具、服务编译运行所需要的全部依赖包、线上同步的服务配置词典等，业务开发者不需要额外的配置就可以直接开始开发。同时所有用户的开发环境也是完全一致的，不会因为系统、SDK、配置的不同导致的问题影响。当用户长时间未连接开发镜像时，镜像会自动挂起闲置，节省机器成本。镜像也可以分享给其他用户，便于问题排查。

在打包镜像的过程中我们发现应用的依赖非常多，如果将这些依赖都放入镜像中会导致镜像体积过大，不仅影响镜像的拉起时间，也对机器的磁盘空间造成很大压力。初期我们将这些依赖都放到 NFS 里，在镜像内通过 fuse 进行挂载，但是会导致业务无法修改这些依赖，在一些场景下使用体验不佳。我们又基于Overlayfs 虚拟了一层联合文件系统，用户看到的只是一个普通的文件系统目录，可以任意修改替换。实际文件系统则包含两层的合并内容，Lower 层指向了公共的 NFS 集群，里面有全部的依赖文件，和线上实时更新，Upper 层指向镜像的工作目录，用户可以修改 Lower 层的文件，修改后会自动移到 Upper 层，Lower 原始数据不受影响。使用 Overlayfs 后我们的镜像拉起速度非常快，绝大部分依赖都放到远程，开发镜像只需要5秒钟就可以拉起。

可视化拖拽算子，快速组建复杂场景

开发过程中，使用者可以在 Nimbus 中打开图编排工具来拖拽算子。每个算子都会有详细的描述信息，比如名称、类别、用途、属性等。这些信息通过注解的方式在代码中进行声明，图编排工具会扫描这些算子代码，读取相应的注解信息，并添加到算子仓库中。业务开发同学可以在图编排中对算子仓库中的算子进行浏览或检索，通过拖拽组建适合的业务场景执行图。拖拽后图的连接配置会直接保存到业务的代码库，下次打开可以重新加载。

在图编排工具中，我们也添加了一些交互来提示研发同学在图中添加算子、边的详细备注，帮助其他同学基于图快速了解系统。一些领域的问题可能具有相当的复杂度，用一张图表示并不直观，我们提供了子图的功能，可以将图与图之间关联在一起。开发者在图编排中可以双击跳转，也可以通过Peek 功能快速查看子图的结构。对于复杂的业务场景，研发同学就可以借助子图来层级递进的理解系统。

Nimbus 是在 IDE 基础上进行的设计，所以图编排可以和代码开发紧密关联在一起。在图中双击算子单元能够直接跳转到具体的代码实现，方便用户实际开发。图编排中也集成了调试分析的功能，用户可以在图中任意算子增加断点查看输入输出，也可以观察整个图的执行状况，各个阶段的耗时，通过图的执行过程快速掌握业务逻辑。

在实际的使用过程中，我们和业务同学将一些最优实践，高频出现的业务场景抽象成了通用的图模板，这些通用图模板可以直接在 Nimbus 中进行打开，业务可以在这些模板的基础上进行定制，为构建新场景时提供帮助参考。

免配置的端到端效果调试，使用更友好

预览调试过去一直是很繁琐的问题，系统的链路和模块太复杂了，尤其对新人来说是一个很大的挑战。Nimbus 提供了功能强大的预览工具，同时支持直连请求和端到端的效果调试。我们和 QA 同学一起搭建了沙盒环境，完全复刻了线上的在线模块，并和线上模块保持同步更新。在调试端到端的过程中，Nimbus 会将请求转发到沙盒环境，请求开发中的业务模块时，沙盒环境会拦截该请求，转发到实际开发调试的服务。新的效果预览方式中预览环境的大部分模块都使用公共服务，显著节省机器成本，同时省去了环境部署、同步更新的人力成本。

调试过程中，我们也可以通过 Nimbus 进行可观测性分析，如 logging、tracing 等等。Nimbus 中也打通了 IDE 的 live debug 功能，支持用户快速进行代码的断点调试。

现代化的测试工具集，集中在测试本身

过去测试流程主要依赖人来驱动，研发同学开发自测完之后，QA 同学需要将服务部署在测试环境，因为依赖较多，部署过程中需要 RD 和 QA 的反复沟通对接才能建立完整的测试环境。Nimbus 连接了一套公共测试集群，研发同学开发完之后可以一键部署仿真实例，仿真实例通过线下的 Paas 平台进行部署，环境和线上基本一致，可用于性能压测、效果验证等。同时 Nimbus 支持自动化回归测试功能，我们定期录制了线上流量，发起自动化回归时，Nimbus 会自动部署基线实例和测试实例，发送录制流量来生成 diff 以及性能报告，用于评估上线风险。

智能化的容量管理，快速适应服务变化

Search-AE 内混布了大量的业务模块，高峰期有百万级 QPS，服务的容量规划一直很难处理。搜索流量本身变化较快，加上业务频繁迭代，线下需要反复压测评估合适的部署方案。同时线上一直在变化，之前合适的部署方案可能因为上下游变更又产生资源不足或浪费。过去线上的容量问题一直需要研发和运维关注，我们希望在 Nimbus 中能够用全局视角统一的管理线上容量，让业务同学只需要关注在实际的代码开发上。

智能容量管理要解决的问题是在满足稳定性要求的前提下，确定各个服务的部署计划，让 Search-AE 整个集群的资源占用最少。智能容量管理的处理包含触发、分析和决策三个阶段。触发阶段包含三种情况：一种是业务迭代变更时会触发容量分析，第二种是线上持续的轮转服务触发分析，第三种是线上实际资源占用达到某个水位时触发快速分析。分析阶段主要的数据输入包含：

1. 和线上一致的仿真实例，阶梯递增的QPS压测下的资源占用、速度 SLA曲线。

2. 现在及历史的QPS、耗时数据。

3. 现在及历史的资源占用 Load 指标。

通过这些数据分析系统会综合判断服务是否需要变更部署安排，最终通过底层的调度引擎触发服务调整。过去大部分容量变化都依赖人去做评估调整，有了这套工具后，线上服务的部署调整就可以实现自动化。

五、总结与展望

业务创新加速，在需求越来越多、迭代越来越块、创新能力要求越来越高的背景下，如何通过技术手段为业务开发降本增效提质做出突破，是搜索中台、也是众多产品研发平台需要思考和解决的问题。搜索中台从业务场景和业务痛点出发，借鉴业界低代码理念，对复杂的后端系统深入开展了低代码的探索和实践，据此形成一套从技术思路、到系统能力、再到业务运营可借鉴可复用的复杂后端系统低代码解决方案，整个解决方案包含3个关键组成：

1. 基于图引擎&通用模板通用算子&业务微定制算子，打造低代码能力引擎，帮助业务少写代码

2. 打造低代码一体化平台，通过能力集成和可视化开发实现研发流程的全生命周期管理，帮助业务高效交付

3. 重视用户培育，营造共创氛围，促进创新生产力工具的应用、推广和共建，帮助低代码现代化生产力工具在实战中快速成长

低代码一体化平台Nimbus正式发布以来，在多个业务取得了显著收益，并收获了早期用户的高满意度和良好口碑，验证了通过低代码实现复杂业务场景降本增效提质的切实可行。它是一套工具，也是一套标准，我们期望打造开放共创的生态，前台和中台同学都可以基于这套标准来沉淀更多的通用算子、研发能力、应用案例和实践经验等等，而这些可以支撑我们进一步向更低代码、更高效能去迈进。在低代码的征途上，我们已经扬帆起航，将继续乘风破浪，勇往直前。期待搜索中台低代码一体化平台能够广泛应用、深入人心，促进多元业务高效率、高质量、低成本的敏捷迭代，为加速业务创新和发展做出更多贡献。

推荐阅读：

｜百度搜索中台海量数据管理的云原生和智能化实践

｜百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决？

｜快速剪辑-助力度咔智能剪辑提效实践

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注