一、关于低代码
低代码是软件系统的快速开发工具，开发者无需编码就可以实现常见的功能、少量代码即可完成功能扩展，从而实现便捷构建应用程序。随着企业数字化需求的快速增长，传统的软件开发方式的低下生产效率，成为制约企业数字化转型的主要矛盾，低代码得到快速发展。相比传统的软件开发模式和工具，低代码的开发门槛更低、研发效率更高；相比其他的快速开发工具，低代码的扩展性更高，可以胜任复杂场景下的核心开发诉求。研发效能也一直是各大互联网企业关注的焦点，随着近几年的探索和发展，市场上出现了众多的低代码平台，低代码也受到了越来越多的关注。
目前业界低代码框架主要解决的是一般领域的通用需求，可以低成本的拖拽组件来打造前后端一体的应用，主要用于 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 整个集群的资源占用最少。智能容量管理的处理包含触发、分析和决策三个阶段。触发阶段包含三种情况：一种是业务迭代变更时会触发容量分析，第二种是线上持续的轮转服务触发分析，第三种是线上实际资源占用达到某个水位时触发快速分析。分析阶段主要的数据输入包含：
- 和线上一致的仿真实例，阶梯递增的QPS压测下的资源占用、速度 SLA曲线。
- 现在及历史的QPS、耗时数据。
- 现在及历史的资源占用 Load 指标。
通过这些数据分析系统会综合判断服务是否需要变更部署安排，最终通过底层的调度引擎触发服务调整。过去大部分容量变化都依赖人去做评估调整，有了这套工具后，线上服务的部署调整就可以实现自动化。
五、总结与展望
业务创新加速，在需求越来越多、迭代越来越块、创新能力要求越来越高的背景下，如何通过技术手段为业务开发降本增效提质做出突破，是搜索中台、也是众多产品研发平台需要思考和解决的问题。搜索中台从业务场景和业务痛点出发，借鉴业界低代码理念，对复杂的后端系统深入开展了低代码的探索和实践，据此形成一套从技术思路、到系统能力、再到业务运营可借鉴可复用的复杂后端系统低代码解决方案，整个解决方案包含3个关键组成：
- 基于图引擎&通用模板通用算子&业务微定制算子，打造低代码能力引擎，帮助业务少写代码
- 打造低代码一体化平台，通过能力集成和可视化开发实现研发流程的全生命周期管理，帮助业务高效交付
- 重视用户培育，营造共创氛围，促进创新生产力工具的应用、推广和共建，帮助低代码现代化生产力工具在实战中快速成长
低代码一体化平台Nimbus正式发布以来，在多个业务取得了显著收益，并收获了早期用户的高满意度和良好口碑，验证了通过低代码实现复杂业务场景降本增效提质的切实可行。它是一套工具，也是一套标准，我们期望打造开放共创的生态，前台和中台同学都可以基于这套标准来沉淀更多的通用算子、研发能力、应用案例和实践经验等等，而这些可以支撑我们进一步向更低代码、更高效能去迈进。在低代码的征途上，我们已经扬帆起航，将继续乘风破浪，勇往直前。期待搜索中台低代码一体化平台能够广泛应用、深入人心，促进多元业务高效率、高质量、低成本的敏捷迭代，为加速业务创新和发展做出更多贡献。
推荐阅读：
---------- END ----------
百度 Geek 说
百度官方技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢迎各位同学关注