百度垂搜架构历经多年发展，内部沉淀了多个开发者平台\工具，涉及覆盖了搜索系统的多个阶段模块，如何高效地串联系统全流程，为业务提效提质，可靠的工程化基建和更上层的抽象设计是关键。本文阐述了百度垂搜一站式研发平台（经天）的思考和探索过程，以及如何通过FaaS机制和SaaS服务产品化来为业务提效提质。摘要：百度垂搜架构历经多年发展，内部沉淀了多个开发者平台\工具，涉及覆盖了搜索系统的多个阶段模块，如何高效地串联系统全流程，为业务提效提质，可靠的工程化基建和更上层的抽象设计是关键。本文阐述了百度垂搜一站式研发平台（经天）的思考和探索过程，以及如何通过FaaS机制和
01 背景
百度垂搜架构团队为数十个业务线的上百个搜索场景提供全链路的技术支持，经过多年的发展，内部已经沉淀了多个开发者平台\工具，覆盖了检索、展现、策略、离线等多个模块。伴随着众多垂类业务的持续深耕发展，自定义的开发场景和接入需求越来越多，在此过程中出现了以下问题：
架构研发维护成本高：研发平台分散，缺乏完善的工程化基建和模型抽象，很多基础能力没有快速复用的机制，重复研发成本高；历史平台技术栈落后，前后端逻辑分离不彻底，长期维护成本高。业务接入学习门槛高：搜索系统链路长、模块数量多、功能类型丰富、上下游连接复杂，历史平台没有从全流程视角去规划建设，研发入口分散不统一，业务接入研发流程复杂，学习使用门槛高。那有没有一些合适的方案，既能有效降低架构自身的研发维护成本，同时又能给业务方的研发学习门槛流程提效？进一步深入来看，一方面，需要我们建设更高效的工程化基建，降低架构侧的研发、运维成本。另一方面，需要将面向业务方的搜索研发环节更好地收敛、抽象、建模，降低业务研发的使用及迭代门槛，端到端地为业务方提供一站式服务。
在平台易用性、基建方面，业界目前对于工程化应用尤其是Web端的应用场景，主要聚焦于通过使用Serverless技术方案来低成本、快速可靠地完成业务需求，比较典型的有AWS Lambda、Google Cloud Functions、阿里云FC、百度云CFC等，在工程化场景中Serverless方案可以快速完成业务迭代和服务部署，有效降低运维负担，提升开发效率。
在检索流程方面，我们通过对常见场景的抽象与分析，发现很多业务需求存在大量通用共性之处，我们可以对那些通用、高频使用的检索流程进行可视化建模，沉淀建设各类标准化的搜索服务SaaS产品，并通过DAG可视化、低代码等平台化的方式将服务提供给业务方，让业务方少写甚至不写代码。
基于以上思路，我们建设了垂搜的一站式研发平台（经天），其主要从两大目标入手：
FaaS机制：让架构研发用户仅需聚焦其业务逻辑的实现，由平台侧统一提供在线调试、上线发布、容量管理、运维管控等能力。从聚焦于服务研发转变为聚焦于函数开发，全面提升平台类工程应用的研发效率。SaaS服务：将一系列基础搜索产品加配置组成的解决方案，封装沉淀为针对特定场景的搜索套餐，提供标准化业务接入、迭代的流程，提升业务的接入效能。03 一站式研发平台（经天）的设计与实践
3.1 “一站式”应用中心
经天的目标之一是“统一”，统一整合、收纳存量的各类平台工具，随着各方向能力在平台上的持续扩展，用户势必会面临一个问题：我如何快速找到我所关心的功能？针对这个问题，我们考虑在产品入口层面使用“千人千面”的方案，不同的用户角色默认初始化不同的导航类目，比如：研发用户展现各类研发、迭代工具的入口，而运营用户展现各类运维报表的快捷导航。用户可以通过收藏置顶等方式，自定义其关心的能力入口。
通过一站式应用中心，我们将各能力入口统一、聚合在了一起，用户可以快速概览目前管理系统提供的所有能力。3.2 Faas机制
我们通过调研发现百度智能云已经对外提供了函数计算产品CFC，其提供基于事件机制，弹性、高可用、扩展性好、极速响应的云端无服务器计算能力，其支持多种语言及函数触发器，满足多样化的事件触发场景。经过深入考察后，我们最终选择百度智能云函数计算CFC作为经天FaaS的底层基座，在其上扩展了更全面的面向业务场景的FaaS管理能力。△示意图：业务方仅需关注函数本身的业务逻辑开发
我们面临的挑战
函数调用性能不足
一方面，由于函数在需要响应事件的容器中运行，因此存在一定的延时（启动容器和runtime的耗时），这被称为”冷启动”。当函数执行完成后，函数容器会保留一段时间，如果另一个事件在此时被触发，则它的响应速度要快得多，这通常被称为”热启动”。热启动和冷启动的耗时差异在于容器和runtime的启动等初始化的过程；
另一方面，函数本身在被调用时，由于无法像常驻内存的应用可以将一些热点数据缓存起来，当函数中存在需要对接上下游应用的情况时，每次调用函数都要去做一些请求BNS（BNS 即 Baidu Naming Service）解析等预处理的工作，造成额外的资源开销和耗时。
复杂场景难以应对
由于FaaS实现的是“无服务器”架构，每个函数都是状态无关的，这就导致应用程序状态管理困难，尤其是在需要保存数据或维护状态的应用场景中尤为明显，同时还存在一些逻辑复杂，需要异步处理或常驻内存的场景，纯函数的方案可扩展性有限；
出于对资源有效利用的考虑，CFC的底层限制了函数同步调用时间不能超过5分钟，异步调用（定时触发的方式）不能超过60分钟，一旦超时容器即被销毁。垂搜团队内部目前存在很多长时类型的定时任务，依赖函数的定时触发器无法满足所有需求。深度定制SDK（性能提升）
由于函数是触发式调用，调用完成后数据不会在内存中持久化或保留在容器中，当函数中存在BNS查询请求时，函数执行速度会受到较大影响，而像使用Golang开发的这类传统应用，其在初始化完成后会将BNS结果暂存内存中并持续更新，当后续请求到达时直接从内存中读取数据，相比之下，这里函数调用的耗时差距就体现出来了。
我们基于GDP（Go Develop Platform，百度 Go 业务开发平台）深入定制了面向业务方的FaaS Go SDK及相关demo。经天提供了BNS加速服务，支持用户在线配置函数中使用到的BNS，当系统调用端触发函数时，会通过header头直接下发BNS结果给函数，SDK内会自动捕获并无感转换BNS结果，以减少函数执行时的BNS查询时间。
在实际场景中，往往业务需要为某类服务写一系列函数，而CFC仅支持单个代码片段与单个函数的匹配，为每个函数创建单独的代码仓库不利于维护。我们在SDK中定制了服务组概念，提供了函数与调度处理器的映射机制，在一个业务代码库中可以关联多个函数，同时每个函数也都支持单独的版本管理，灵活满足了业务实际使用场景。
函数预热（性能提升）
函数首次访问存在冷启的情况，会明显导致响应时间增加，针对热点函数，我们为用户提供了函数预热能力，在平台开启该功能后，经天系统将对函数容器持续保活（至少保有一个活跃的容器），以确保函数每次被触发时都有已就绪的容器，减去容器初始化和runtime准备的时间，从而提升函数整体响应速度。多功能API网关（能力扩展）
我们支持可视化配置 “HTTP路由 - 函数” 的映射机制，用户写好函数后，无需编写路由分发逻辑，只需在平台上配置自定义的路径及函数名，即可完成API网关路由的绑定。允许业务配置鉴权中间件，当启用鉴权时，网关会首先完成请求端的内部鉴权，鉴权通过后会将用户信息、参数签名等下发给函数，由函数SDK完成验参等操作。在确保数据安全流转的同时，让研发用户更加聚焦其业务逻辑本身的实现。
同时，针对复杂场景（常驻内存或复杂异步任务），当函数方案无法快速满足时，我们的API网关能力也兼容外部系统的对接，用户可以独立部署运维自己的Server服务，只需按照指定的签名规则，在平台完成路由注册、调试后，即可发布API接口。多场景异步任务（能力扩展）
经天FaaS机制除了支持常规的HTTP服务场景外，也能满足异步任务需求：
用户可以直接为指定函数配置定时任务，由CFC提供底层调度，不过由于CFC对资源的硬限制，其最大运行时长限制为1小时，适合简易型任务使用。
同时，作为对FaaS能力的补充，我们也自建了一套基于docker容器的定时任务调度机制，业务方仅需将其任务代码及环境打包成docker镜像并推送至镜像仓库，在平台完成简单配置即可。其不受运行时长限制，且能指定专属task agent机器运行，更好地满足了长时型定时任务需求。3.3 Saas服务产品化
面对模块多、链路复杂、功能丰富多样的搜索系统，新业务接入和存量业务迭代需求的项目上手门槛高，业务需要学习大量策略算子(100+)和模块配置逻辑细节，修改涉及模块多\流程长，业务和架构人力投入大。基于众多垂类搜索场景接入流程和系统策略能力抽象沉淀，设计了基础能力和能力编排产品化机制，并构建了文本相关性、语义向量、结构化、向量数据库等多种典型搜索解决方案（套餐），支持业务低门槛快速接入新场景，架构服务部署通过工作流编排实现自动化，大量减少架构自身重复性枯燥工作。△搜索SaaS服务产品化
在SaaS服务产品化的设计过程中，我们主要围绕两大核心点来设计：
基于已有的搜索策略框架，统一数据结构和通信协议，制定套餐的标准化接口；采用高度组件化、模块化的设计思路，建设易扩展的平台能力；3.3.1 套餐标准化接口
基于上面的思考和设计，我们通过将数据引入、召回、排序、结果组装等服务抽象沉淀为公共产品，再将这些产品以“积木化”的方式拼接组成套餐提供给业务，通过虚拟化的应用管理，对用户隐藏底层的架构实现，以逻辑应用来支持业务调研、请求、配置等接入迭代场景。
在深入调研及实践后，我们制定了SaaS产品套餐的标准接口及调用流程：3.3.2 初阶动态表单机制
SaaS平台化的建设涉及前端、后端、架构系统侧等多方同学的协作配合，且配置细节又多而繁杂，往往一处配置的改动都会涉及多方协作，协同迭代效率不够理想。
通过 JSON Schema 协议动态渲染表单，是业界比较流行的中后台表单解决方案之一。结合我们的使用场景，我们通过使用标准的JSON Schema 协议来统一管控套餐的表单配置，建设了套餐市场，允许架构&业务自助对外发布套餐产品，使用 FormRender 及 ant-design UI库，提供了美观、统一的表单展现交互能力。SaaS套餐的研发同学只需按照标准的 JSON Schema 协议即可所见既所得地定制前端表单，极大减少了平台侧研发人力成本的投入。△套餐配置阶段的动态表单
我们遇到的痛点
JSON Schema 协议渲染表单，可以轻松应对常见的 input / select / radio等表单使用场景，但是在实际的开发中，可能会遇到如下的应用场景：
普适性不高/难以用 schema 描述的组件：我需要写一个异步加载的搜索输入框;完全定制化的需求：我需要在表单内部写一个 excel 上传按钮;业务逻辑耦合高：我当前的表单可选项依赖于上面某个表单的用户输入值;FormRender 内置的控件不能满足全部业务功能需求，我们通过定制自定义组件 widget 来解决这些痛点，widget 是一个普通的 React 组件，它会接收 FormRender 传递给它的一些 props，根据这些 props 我们可以完成控件的受控、联动、校验等操作。在组件定制完成后，用户在 JSON Schema 中描述表单时，仅需使用自定义组件名即可使用其能力：
△自定义组件
通过 JSON Schema 以及搭配自定义widget组件，经天的动态表单渲染能力不仅可以满足SaaS检索产品套餐的可视化表单渲染，还可以满足其他所有平台表单类需求。而表单类需求，在平台化建设过程中的往往占比非常大，灵活地运用表单动态渲染技术，大幅减少了平台侧研发人力的投入。
3.3.3 进阶DAG可视化
不管是检索架构的SaaS套餐，还是展现架构vsgo框架的seda引擎算子等，其内部都大量使用了DAG（Directed Acyclic Graph）设计，相比平铺的表单设计或原始代码配置，DAG可以快速、清晰地呈现任务及任务之间、节点与节点之间的依赖关系。为此经天设计了可复用的DAG可视化组件，除了支持配置展现，还支持用户拖拽连线、编辑节点等。通过可视化的DAG交互，可以让研发同学更直观地理解业务流程，友好的交互体验进一步提升了业务方的迭代效率。04 总结与展望
业务加速创新，在需求越来越多、迭代越来越块、创新能力要求越来越高的背景下，如何通过技术手段为业务开发降本增效提质做出突破，是搜索架构、也是众多产品研发平台需要思考和解决的问题。经天一站式研发平台从业务场景和痛点出发，对复杂的后端系统深入开展了平台化探索和实践，据此形成一套从技术思路、到系统能力、再到业务运营可借鉴可复用的一站式平台解决方案，整个解决方案包含3个关键组成：
基于FaaS机制，实现业务需求的快速迭代，帮助业务少写代码;标准化搜索流程，对流程进行抽象、可视化建模，以搭积木的方式，为大部分典型场景提供SaaS服务套餐产品，进一步降低搜索赋能门槛;重视用户培育，营造共创氛围，促进创新生产力工具的应用、推广和共建，在实战中持续成长;搜索SaaS服务产品化推进以来，我们通过套餐市场已经陆续对外提供了10+套餐，覆盖了文本相关性、向量检索、结构化检索等多个常见业务场景，大幅提升了业务快速接入迭代效率。一些新业务接入的典型场景，可以实现小时级交付完整的搜索服务生产环境。
经天一站式研发平台自上线以来，日均为180+位搜索研发用户提供了各类服务。相比于传统研发模式，FaaS能力使得业务开发成本降低了80%，目前已托管了300+函数，月均调用400w+次，相比传统Server托管的模式，服务器/带宽等运维成本节省了约95%。
目前垂搜内多个平台/工具已经按照经天一站式研发平台的标准进行了重构、收敛、融合，并收获了早期用户的高满意度和良好口碑，验证了经天一站式研发平台实现复杂业务场景降本增效提质的切实可行性。它是一个平台，一套工具，也是一套标准，我们期望打造开放共创的生态，业务和架构同学都可以基于这套标准来沉淀更多的研发能力、应用案例和实践经验等等，而这些可以支撑我们进一步向更高效能、更好体验去迈进，促进多元业务高效率、高质量、低成本地敏捷迭代，为加速业务创新和发展做出更多贡献。来源：百度Geek说
