风流不在谈锋胜,袖手无言味最长。这篇文章主要讲述技术揭秘!百度搜索中台低代码的探索与实践相关的知识,希望能为你提供帮助。
文章图片
一、关于低代码
低代码是软件系统的快速开发工具,开发者无需编码就可以实现常见的功能、少量代码即可完成功能扩展,从而实现便捷构建应用程序。随着企业数字化需求的快速增长,传统的软件开发方式的低下生产效率,成为制约企业数字化转型的主要矛盾,低代码得到快速发展。相比传统的软件开发模式和工具,低代码的开发门槛更低、研发效率更高;相比其他的快速开发工具,低代码的扩展性更高,可以胜任复杂场景下的核心开发诉求。研发效能也一直是各大互联网企业关注的焦点,随着近几年的探索和发展,市场上出现了众多的低代码平台,低代码也受到了越来越多的关注。
目前业界低代码框架主要解决的是一般领域的通用需求,可以低成本的拖拽组件来打造前后端一体的应用,主要用于 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个关键组成:
- 基于图引擎&
通用模板通用算子&
业务微定制算子,打造低代码能力引擎,帮助业务少写代码
- 打造低代码一体化平台,通过能力集成和可视化开发实现研发流程的全生命周期管理,帮助业务高效交付
- 重视用户培育,营造共创氛围,促进创新生产力工具的应用、推广和共建,帮助低代码现代化生产力工具在实战中快速成长
推荐阅读:
|百度搜索中台海量数据管理的云原生和智能化实践
|百度搜索中“鱼龙混杂”的加盟信息,如何靠AI 解决?
|快速剪辑-助力度咔智能剪辑提效实践
---------- END ----------
百度 Geek 说
百度官方技术公众号上线啦!
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
【技术揭秘!百度搜索中台低代码的探索与实践】欢迎各位同学关注
推荐阅读
- 所以我们需要站在用户的场景去考虑整体的内容
- ELK收集nginx日志
- #yyds干货盘点#Linux根目录包含内容
- 亮剑-精讲stream,万物皆可stream
- CGLIB动态代理探索(ASM,Spring)#yyds干货盘点#
- binlog2sql的对MySQL列的兼容性测试
- WordPress的帖子编辑器省略换行符吗()
- WordPress分页上一页/下一个箭头
- 主题开发的WordPress离线文档[关闭]