中台已死,平台长青

2024-07-31 12:03:02 浏览数 (2)

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

7 月 31 日晚 7 点半,腾讯云开发者视频号「鹅厂程序员面对面」直播间,还将带来一场关于中台、建模、领域驱动等干货内容的直播,千万别错过!

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 年借力 iCodeiReadiWork,让我们在代码质量上更进一步。

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 签约、成本结算、问卷调查等等,在往高效率高性能低成本的技术产品研发上引导,为促进技术产品的健康发展提供了很大助力。

0 人点赞