👉目录

1 背景

2 客户第一

3 性能和成本

4 功能设计

5 研发效率

6 运营效率

7 技术文档

8 发展的思考

这几年，眼看着中台直上云霄，又看着它跌落神坛。最早提中台建设的友商在去中台，腾讯内部的中台建设也开始趋向务实。但腾讯的中台并没有消失，而是以技术产品的形式继续默默耕耘，平台型技术产品服务于开发团队，曾经被纳入中台的范畴，但它比中台更长久，中台陨落，而平台长青。本文作者从零到一打造了腾讯 PCG 平台型技术产品——搜索中台 XSearch，他将以此为例，带大家了解做好一个平台型技术产品，需要考虑哪些点。

01

背景

   1.1 中台、平台、技术产品

当技术中台建设热潮退去，我们会发现留下来的“中台”都是如同基建一般的“平台”，尽管有很多文章在解释中台和平台的差异，但我一直认为中台和平台在技术层面并没有什么不同。在中台概念下建设的平台，我更愿意称之为技术产品，是一款 ToB 的产品。

   1.2 为什么写这篇文章

看过很多关于技术中台的介绍文章，大都在介绍为什么需要、做了什么，当然也有一些在介绍为什么不需要，这里我想写一些不一样的内容：我们的技术中台是怎么做，从理念到执行。既是对过往几年工作做总结，也让没做过技术产品的读者能了解我们是怎么做的。下面我会围绕：客户、核心竞争力、研发效率、运营效率、技术文档、发展思考这些方面展开。

02

客户第一

客户是技术产品存在的唯一原因。在公司内做技术产品，有 BG 统一管理的助力，我们找客户不会太困难，但相比做 ToC 产品，还是有一些差异，核心可以概括为几点：解决核心诉求、维护专业形象、保持沟通激活，下面展开讲讲。

   2.1 客户的核心诉求

对于 XSearch 来说，功能、性能、成本、效率、稳定性是最基本的要求，作为在 PCG 内外二十多个业务线上验证过的技术产品，当前大多数业务场景都能满足。

   2.2 专业的客户服务

（1）由谁来当 helper（客服）

在建设 helper 账号的初期，我们有人力和效果方面的矛盾：一方面我们希望能有专职的外包同学来承担 helper 提供业务接入、业务咨询、告警处理，以减少研发团队的体力劳动；另一方面，我们又期望 helper 能够解决用户问题，不需要再二次转手，也不要打扰到研发同学。由谁来当 helper？

• 如果对系统实现不熟悉的外包同学能解决问题，那么文档也能解决，如果文档能解决，那么我们就不需要提供咨询支持的外包同学。
• 如果文档解决不了，那么咨询外包同学也很难解决，他会成为任务分包的角色，这时候任务还是会落到背后的开发同学身上，此时必然打扰到开发同学，打乱原定的工作计划，且会让客户觉得 helper 并不专业。
• 服务告警和运维处理涉及系统稳定性，对值班同学和技术产品的自动运维能力要求较高，交给外包有一定风险。

权衡之后我们决定还是由研发同学做值班，同时通过持续建设文档来减少客户的咨询，付出的代价：少了一位全人力的研发。带来的收益：

• 每个人都有机会熟悉全系统所有模块。
• 对客户价值有更直接的认识。
• 促进用户手册建设。
• 更容易对不合理的设计提出挑战。

未来的可能性：如果我们的技术产品能做到如同 MySQL 那么易于维护，也可以培养专门做运维的外包/同事，做到研发和运维分离。

（2）沟通的专业性

刚开始做客服的开发同学，很容易在和客户沟通过程中陷入对立，或者是提供了错误的解答，所以我们在每周的值班复盘中有一个教练审查环节，对本周的所有沟通做审查并指出可提升的 case，提供指导。

   2.3 保持沟通激活

我们支持的业务是有限的，所以为每一个业务建独立的沟通渠道是可行的，XSearch 和每个业务线都有企业微信沟通群，在群里同步研发进展、服务升级、突发告警等等重大通知。同时，我们也定义了研发月报，每月汇报一次研发进展，让客户能了解到什么版本做了什么升级，这也体现出我们的专业性。

03

性能和成本

搜索召回类的技术产品，需要从海量数据中取出最相关的文档，除去业务个性化的排序效果，最容易被看到的亮点是性能和成本，这需要持续深耕以及精细运营。

   3.1 可演进的系统

易于修改的、可演进的系统，才能持续的进行性能和成本优化，从一开始我们的系统架构无论是集群架构还是核心模块内的实现，都采取解耦的设计，使得这几年来持续的性能优化，不需要将系统推倒重来。

2019 年 6 月份第一版 XSearch 的设计：

现在（2022年7月）的 XSearch 大结构上和 2019 年的设计类似，局部架构有调整，功能也丰富了很多。

   3.2 持续的技术深耕

从 19 年中台立项开始，我们一直投入人力在进行性能优化，有时候是以技术专项的面目出现，有时候是以业务接入优化来体现。在这过程中，我们积累了一系列的总结文档，整体可以归类为：

• 架构优化，譬如：二级和三级扇出架构、微服务合并。
• 新技术应用，譬如：新 rpc 框架、协程、SIMD 并行指令。
• 空间换时间，譬如：业务缓存、计算缓存、jemalloc 内存池。
• 数据结构优化，譬如：用块链代替稀疏位图、贴合 cacheline 的内存结构。
• 策略简化，譬如：多次查询改成单次，再通过更好的检索策略补充效果。
• 实现细节，譬如：去掉拷贝、去掉锁、复用对象。

   3.3 精细运营

通过技术先进性实现成本优化是有门槛的工作，而精细运营则显得像是体力劳动，以至于很多内部的技术产品在早期会忽略掉精细运营（XSearch 早期也不例外）。

后来我们对 XSearch 的精细运营投入了很多精力，治理历史包袱，并将精细化运营制度化，服务 20+ 业务线，管理上百个业务集群，没有出现因为 CPU 空跑而导致客户成本暴涨的“成本事故”。

• 设备选型：
• 高内存高计算型的服务，使用 AMD 设备，并且不开 NUMA。
• 无须实时访问磁盘的服务，选用非 SSD 磁盘。
• 配额最小化：CPU/磁盘/内存，全部最小化配置。
• 自动化调度：通过 123 平台（注：内部容器服务管理平台）的调度配置，配置自动缩容阈值。
• 云原生看板建设 CPU 使用率看板，查看 CPU 变化趋势。
• 利用率监控 CPU 峰值利用率低于 50% 的发出告警。
• 专人检查 CPU 使用率、使用量、流量变化，最晚 T+1 和业务沟通处理。
• 对 CPU 有毛刺的离线计算业务做针对性治理，和业务团队沟通将流量打散。

04

功能设计

功能也是业务是否使用我们产品的重要参考点，可以分为以下几点：新业务接入和老业务迁移是否方便；上手门槛高不高；好不好做个性化定制；有没有配套的 debug 工具 等等。下面从功能设计、XSearch 能力举例、debug 能力展开介绍。

   4.1 功能设计关注点

（1）方便迁入

• 采用类 json 的 DSL 语法，既满足通过任何检索规则组合实现复杂检索策略的需求，后来也为使用 ES 的业务迁移到 XSearch 提供了便利。

（2）一致性

• 风格一致的代码、文档可以提高阅读效率，对于技术产品的功能设计也一样有价值，产品在不断的增加功能，一致性的设计会让一个技术产品显得越来越强（而不是增加多个需要重新学习的技术产品），在增加向量召回功能的时候，我们把向量当作一种和倒排、正排、枚举并列的一种索引能力，复用原来 XSearch 的全套流程，既减少开发量，使用上也不突兀。

（3）易用性

• 通用检索能力，大多数的客户不需要了解分词、query 理解、检索语句组装，所以我们将检索策略做成可视化配置，只需要在界面上做选择，就能获得一个不错的召回能力。
• 个性化能力，如果通用检索无法满足，需要定制化怎么办？我们通过 DSL 语法、排序插件、脚本插件提供广阔的个性能定制。
• debug 能力，业务在使用检索引擎时，用于 debug 的时间往往不比写一段召回代码的时间短，所以 debug 能力的建设一样非常重要。

（4）通用和定制的权衡

• 想要规模化的产品，必然是通用的。而业务产品又可能提出来定制需求，我们通过配置化、插件系统解决大多数定制问题，譬如：要搜索标题还是搜索标签、要用默认排序还是自定义排序等等。但部分问题没办法完美解决，会付出代价，譬如：架构设计和协议设计。
• 代价-架构设计：当只服务一个业务的时候，系统的变数少，不需要考虑太多插件扩展，架构简单服务耗时短、开发周期短。
• 代价-协议设计：不用考虑多业务有不同字段的需求，当有新增字段时，直接追加新字段即可。而考虑到多业务时，要么是牺牲性能，定义 map 类型来应对不同业务的差异化字段，要么是使用 oneof，把不同业务的个性化字段拆分到不同 message 中，不管那种方式，都会给协议增加复杂度，对性能有影响。

（5）性能和便利的权衡

• 单个业务下的技术产品，选择一般是单一明确的，追求性能或者追求易用，而平台化的技术产品则需要考虑提供多种选择。譬如：接口协议的设计上，正排索引值是返回序列化后的字符串，还是返回原始数字，追求性能的用户希望返回原始数字，追求易用性的用户希望返回字符串直接用来展示。

   4.2 XSearch 的检索能力

XSearch 的功能按照层次划分，涵盖召回、Query 理解、插件定制、数据通道、运营系统这几个层次，可以用一张图表达：

   4.3 XSearch 的 debug 能力

基于我们自己做业务开发时遇到的案例，我们建设比较丰富的 debug 技能点，涵盖：

• 模拟查询。
• 解释查询。
• 文档查询。
• 索引信息查看。
• 全链路 trace。

有了这些能力，为什么不召回、为什么召回、召回经过哪些运算，都可以通过工具看到。

05

研发效率

研发效率是技术产品保持竞争力的根基，从 2019 年立项开始，我们就在持续投入，但和大多数初创期的团队一样，早期做得比较粗糙，2020 年在 PCG 推行 EPC 的大趋势下，顺势将单元测试、MR 流水线、代码评审、代码规范等各类配套设施补全，并在 2021 年借力 iCode\iRead\iWork，让我们在代码质量上更进一步。

   5.1 流程制度

规定一套唯一的、符合高效率原则的流程制度，减少选择、减少出错。

   5.2 基础设施

基于公司平台配置项目基础设施，确保流程制度可实施。功能点包括：

（1）流水线

• MR 流水线。
• 主干提交流水线。

（2）工蜂仓库设置

• 分支和 tag 命名规范，提升可读。
• 主干代码只能通过 MR 合入。
• MR 必须经过有经验开发者、绿带认证者评审。

（3）基于流水线做的拦截

• 开发者必须获得开发者资质，包括：编码规范考试、代码安全考试。
• 增量代码单测覆盖率 > 85%。

（4）工具

• 需求扭转流程管理。
• 基于 VSCode 或者 Vim 的代码格式化工具。
• 测试、灰度、全量发布工具。

   5.3 代码评审

代码评审是一个团队的事情，让一个团队有效率、有质量的执行代码评审，需要文化、人、制度和工具多方面的配合。

• 公司文化，受益于这几年公司对工程素养的重视，大量的宣导、强制课程学习、内部论坛讨论，团队全员受过 CR 的基础培训和引导。我们也通过小团队内的讨论和制度的强制落实，让每个人会意识到：
• 代码可以写得更好；
• CR 活动需要花费不少时间；
• CR 是完成需求过程中的必要环节。
• 团队制度，设计一套代码评审流程，并由核心同学带头落实。
• 团队成员，借力公司课程、职级晋升的代码质量要求，让多数人有意愿、有能力、有时间执行代码评审。
• 评审工具，通过流水线、工蜂、研效看板，确保代码评审过程可高效执行。

06

运营效率

技术产品的运营有规模化效应，相比每个业务团队自己运维 XSearch，搜索中台采用全托管的模式，让业务团队更省力，也促使 XSearch 建设一套完整的运营流程。

   6.1 关键能力

• 一站式运营系统，用户使用 XSearch 的所有的操作都在运营系统中完成，包括数据接入、检索策略、debug；管理员操作的审批、部署也都在运营系统中完成；
• 用户手册，减少人工咨询；
• helper 账号，人工咨询和业务接入审批等；
• 值班制度，全职投入，处理告警、用户咨询、云原生治理、业务审核等工作；
• 群沟通渠道，每个业务一个沟通群；

   6.2 运作模式

我们通过技术文档、运营系统、沟通渠道、云服务，将用户、客户、值班人员联系到一起，如下图所示：

07

技术文档

文档可以跨越时间的限制，进行信息的规模化传递和交流，可以帮助团队也可以帮助个人，它是主干开发、代码评审、流水线等效率技能的放大器。

   7.1 新人文档

怎么让团队新人、中台共建者能更快的参与 XSearch 系统开发？这是我们的《新人大礼包》要解决的问题。

首先整理《搜索中台开发入门手册—通用篇》，让读者可以了解 XSearch 的目标、XSearch 的整个研发流程、了解需要获得开发者资质、5 分钟能搭建开发环境、流水线是怎么回事、怎么做代码评审等等基础入门信息。

再进一步，团队在需求协作过程中，是否能有良好的职业素养？

基于这几年工作中的观察，整理《如何成为一名靠谱的程序员：职业素养入门指南》一文，记录一些职业素养的思考和建议，涵盖：需求沟通、开发技能、代码评审、文档规范、协作交流、效率产品、服务运营等方面，所有这些组合形成团队的导向。

   7.2 开发和运营文档

怎么让知识传播以获得更大的价值？怎么让技术产品不因人员更替而受损？这些都要求 XSearch 有优质的代码和技术文档，这几年我们把文档的“架子”搭起来了。

   7.3 用户手册

XSearch 用户手册是读写比很高的文档，当前基本覆盖客户使用过程中可能遇到的所有问题：能力了解、入门使用、细节功能、自助 debug、合作共建。

08

发展的思考

任何产品都有它的生命周期，平台型技术产品和 ToC 产品有什么样的不同，它和过去我们的平台又有哪些区别，未来可能往哪些方向发展，下面讲讲我的思考。

   8.1 长周期

XSearch 是复杂的技术产品，它的建设周期比一般的 ToC 产品要长得多，技术产品也许需要一年的时间才能萌芽，而对于 ToC 产品可能一年就是一生。因为周期长所以收益可能是滞后的，一个从业务产品中成长出来的技术产品非常依赖业务的稳健发展、业务负责人和公司的长期主义，另一方面，技术产品团队本身也要不断的证明自身的价值，需要有强烈的自驱追求卓越的冲动。

   8.2 市场化

以前公司内的技术产品一般作为平台基建存在，不用考虑营收，而在各种设施都上云的趋势下，基础组件也可以作为技术产品售卖，现在也在逐步的强调技术产品及其费用结算，这让开发者有机会用公司内的业务孵化技术产品，最后能走出公司创造更大的价值。对技术产品开发者来说是很好的鼓励和压力，对于 XSearch 来说，期望有一天能实现云上售卖，在国产软件上占一席之地。

   8.3 考核导向

公司内技术产品的发展，有必要提一下考核导向，这几年中台技术产品考核，包括：研效、SLA 签约、成本结算、问卷调查等等，在往高效率高性能低成本的技术产品研发上引导，为促进技术产品的健康发展提供了很大助力。

-End-

原创作者｜吴银光