如何设计一个高效的分布式日志服务平台
作者 | 百度智能小程序团队
导读
本文首先介绍了分布式服务下日志服务建设的挑战，然后介绍了下业内 ELK 的通用解决方案及与天眼日志服务的差异性，接下来详细介绍了天眼日志服务平台的整体架构，如何做采集、传输、检索、隔离、清理等机制的，最后对日志服务与大模型进行结合，不断探索效能的提升。
全文 11796 字，预计阅读时间 30 分钟。
01 分布式服务下日志服务挑战
分布式服务系统中，每个服务有大量的服务器，而每台服务器每天都会产生大量的日志。我们面临的主要挑战有：
1、日志量巨大：在分布式服务环境中，日志分散在多个节点上，每个服务都会产生大量的日志，因此需要一种可靠的机制来收集和聚合日志数据。
2、多样化的日志格式：不同的服务可能使用不同的日志格式，例如日志输出的字段、顺序和级别等，这会增加日志服务的开发和维护难度。
3、日志服务的可扩展性和可靠性：随着分布式服务数量的增加和规模的扩大，日志服务需要能够进行横向扩展和纵向扩展，以保证其性能和可靠性。
所以我们该如何提供分布式系统下高效、低延迟、高性能的日志服务呢？
02 业内 ELK 通用解决方案
2.1 Elastic Stack 发展历程
2.2 Elastic Stack 组件架构图
2.2.1 Ingest 组件
Ingest 是获取日志数据的相关组件。
shippers 和 sources 是收集的原始日志组件，承接着原始日志（log 文件日志、系统日志、网络日志等）采集和发送，其中 Elastic Agent、APM、Beats 收集和发送日志、指标和性能数据。
queues 和 processors 是原始日志数据的处理管道，使用这些组件可以定制化的对原始日志数据进行处理和转换，在存储之前可以模板化数据格式，方便 elasticsearch 更好的承接存储和检索功能。
Elastic Agent 是一种使用单一、统一的方式，为主机添加对日志、指标和其他类型数据的监控。它还可以保护主机免受安全威胁、从操作系统查询数据、从远程服务或硬件转发数据等等。每个代理都有一个策略，可以向其中添加新数据源、安全保护等的集成。
Fleet 能够集中管理 Elastic Agent 及其策略。使用 Fleet 可以监控所有 Elastic Agent 的状态、管理 agent 策略以及升级 Elastic Agent 二进制文件或集成。
Elastic APM 是一个基于 Elastic Stack 构建的应用程序性能监控系统。通过收集有关传入请求、数据库查询、缓存调用、外部 HTTP 请求等响应时间的详细性能信息，实时监控软件服务和应用程序。
Beats 是在服务器上作为代理安装的数据发送器，用于将操作数据发送到 Elasticsearch。Beats 可用于许多标准的可观察性数据场景，包括审计数据、日志文件和日志、云数据、可用性、指标、网络流量和 Windows 事件日志。
Elasticsearch Ingest Pipelines 可以在将数据存储到 Elasticsearch 之前对数据执行常见的转换。将一个或多个“处理器”任务配置为按顺序运行，在将文档存储到 Elasticsearch 之前对文档进行特定更改。
Logstash 是一个具有实时数据收集引擎。它可以动态地统一来自不同来源的数据，并将数据规范化到目的地。Logstash 支持丰富的输入、过滤器和输出插件。
2.2.2 Store 组件
Store 是承接日志存储和检索组件，这里是使用的 Elasticsearch 承接该功能。
Elasticsearch 是 Elastic Stack 核心的分布式搜索和分析引擎。它为所有类型的数据提供近乎实时的搜索和分析。无论结构化或非结构化文本、数字数据还是地理空间数据，Elasticsearch 都可以以支持快速搜索的方式高效地存储和索引这些数据。Elasticsearch 提供了一个 REST API，使您能够在 Elasticsearch 中存储和检索数据。REST API 还提供对 Elasticsearch 的搜索和分析功能的访问。
2.2.3 Consumer 组件
Consumer 是消费 store 存储数据的组件，这里组要有可视化的 kibana 和 Elasticsearch Client。
Kibana 是利用 Elasticsearch 数据和管理 Elastic Stack 的工具。使用它可以分析和可视化存储在 Elasticsearch 中的数据。
Elasticsearch Client 提供了一种方便的机制来管理来自语言（如 Java、Ruby、Go、Python 等）的 Elasticsearch 的 API 请求和响应。
2.3 天眼对比 ELK 差异
1、接入便捷性
ELK：方案依赖完整流程部署准备，操作配置复杂，接入跑通耗时长。
天眼：只需简单三步配置，页面申请产品线接入、页面获取产品线 appkey、依赖管理中增加天眼 SDK 依赖并配置 appkey 到系统配置中。
2、资源定制化
ELK：资源修改、配置每次都需要重启才能生效，不支持多资源配置化选择。
天眼：产品线接入时可以选择使用业务自身传输、存储资源或自动使用系统默认资源，资源切换只需页面简单配置并即时自动生效。
3、扩容成本与效率
ELK：方案仅支持单个业务产品线，其他业务产线接入需重新部署一套，资源无法共享，扩容需手动增加相应实例等。
天眼：资源集中管理，产品线动态接入，资源动态配置即时生效，大部分资源自动共享同时又支持资源独享配置；扩容直接通过平台页面化操作，简单便捷。
4、日志动态清理
ELK：依赖人工发现、手动清理和处理资源占用。
天眼：自动化监测 ES 集群概况，自动计算资源占用情况，当达到监控阈值时自动执行时间最早的索引资源清理。
5、自适应存储
ELK：传统方案受限于存储资源空间和成本，存储成本高、可保存的数据量有限。
天眼：实现了日志转存文件及从文件自动化恢复，日志存储成本低，存储周期长。
天眼通过自建分布式日志平台，有效的解决 ELK 日志方案下存在的缺陷问题；当前天眼日志量级：日均 10TB 日志量，并发 QPS：10w+，接入产品线数：1000+。
GEEK TALK
03 天眼
3.1 天眼系统架构
上图为完整的天眼核心系统架构，概述如下：
1、天眼日志采集支持 SDK 及监听日志文件两种方式，其中 SDK 主要通过实现日志插件接口获得完整日志结构信息，并传输至天眼日志传输管道；获得的日志信息 LogEvent 结构完整，同时基于 LogEvent 增加了产品线标识等字段，为日志隔离和检索提供核心依据；监听日志文件方式实现业务方 0 开发成本接入，仅需简单配置即可实现日志接入，支持产品线字段标识的同时，日志消息体解析也实现了正则匹配规则自动化匹配。
2、天眼日志传输采用高并发性能队列 Disruptor，并且二次采用高性能队列 Bigpipe 实现日志传输异步解耦，解决了传统队列因加锁和伪共享等问题带来的性能缺陷；同时在传输过程中提供日志过滤和日志告警规则配置化自动化执行。
3、天眼日志存储通过轮询消费 Bigpipe 日志消息，最终写入 ES 的 BulkProcessor，由 ES 自动调度并发写入 ES 进行存储；在日志传输和存储过程中实现了日志传输资源与存储资源隔离，根据产品线配置自动化选择传输与存储资源。
4、天眼自动化清理实现在存储资源有限的情况下自适应存储，自动化转存与恢复实现了在 ES 资源有限情况下低成本长时间存储解决方案。
3.2 天眼日志采集
日志平台核心目的是采集分布式场景下的业务日志进行集中处理和存储，采集方式主要包含如下：
1、借助常见日志框架提供的插件接口，在生成日志事件的同时执行其他自定义处理逻辑，例如 log4j2 提供的 Appender 等。
2、通过各种拦截器插件在固定位置拦截并主动生成和打印业务日志，将这类日志信息主动发送至日志消息传输队列中供消费使用，常见的如 http、rpc 调用链请求与返回信息打印，以及 mybatis 执行过程 SQL 明细打印等。
3、监听日志文件写入，从文件系统上的一个文件进行读取，工作原理有些类似 UNIX 的 tail -0F 命令，当日志写入本地文件时捕获写入行内容并进行其他自定义处理，例如将日志行信息发送至消息队列供下游使用。
4、syslog：监听来自 514 端口的 syslog 消息，并将其转换为 RFC3164 格式。
更多可用的日志采集实现方式，可以参考：Input Plugins
下面以天眼日志采集为例详细介绍日志采集实现过程：
天眼平台供支持两类日志采集实现方式，一类是 SDK、一类是 minos（百度自研的新一代的流式日志传输系统）。
3.2.1 天眼 SDK 日志采集
天眼 SDK 日志采集方式为通过 Java SDK 方式向业务方提供日志采集组件实现，达到自动收集业务日志并自动传输的目的；核心分为 message 日志流和 trace 日志流两大块：
1、message 日志流主要通过日志框架提供的 Appender 接口实现，共支持 log4j、logback、log4j2 等主流日志框架。
以 logback 为例，通过继承并实现 AppenderBase 抽象类提供的 append 方法，在 logback 日志框架生成 LogEvent 后获取日志事件对象并提交给 LogbackTask 执行任务处理，在 LogbackTask 中可以对日志事件内容进行进一步包装完善，并执行一些日志过滤策略等，最终得到的日志事件信息将直接发送至日志传输队列进行传输处理；
2、trace 日志流主要通过各类拦截器拦截业务请求调用链及业务执行链路，通过获取调用链详细信息主动生成调用链日志事件，并发送至日志传输队列进行消费使用，常见的调用链日志包含 http 与 rpc 请求及响应日志、mybatis 组件 SQL 执行日志等；
下图为 trace 日志流实现类图，描述了 trace 日志流抽象实现过程：
以 mybatis 为例，trace 日志流核心拦截器实现类为 IlogMybatisPlugin，实现 ibatis Interceptor 接口
核心代码：
在 end 方法中将 SQL 执行过程中产生的各类信息通过参数传入，并组装成 SqlLogNode（继承至通用日志节点 LogNode）发布到队列。
使用时需要业务方手动将插件注册到 SqlSessionFactory，以生效插件：
3.2.2 天眼 minos 日志采集
minos 日志采集主要是借助百度自研的 minos 数据传输平台，实现机器实例上的日志文件信息实时传输至目的地，常见传输目的地有 Bigpipe、HDFS、AFS 等；目前天眼主要是通过将 minos 采集到的日志发送到 Bigpipe 实现，并由后续的 Bigpipe 消费者统一消费和处理；同时针对日志来源为 minos 的日志在消费过程中增加了日志解析与转换策略，确保采集到的日志格式和 SDK 方式生成的日志格式基本一致；
在日志采集过程中，天眼如何解决平台化标识：
1、在产品线接入天眼时，天眼给对应产品线生成产品线唯一标识；
2、SDK 接入方式下，产品线服务端通过系统变量配置产品线标识，SDK 在运行过程中会自动读取该变量值并设置到 LogNode 属性中；
3、LogNode 作为日志完整信息对象，在传输过程中最终存储到 ES，同时 ES 在建索引时为产品线唯一标识分配字段属性；
4、产品线唯一标识贯穿整个分布式日志链路并和日志内容强绑定。
3.3 高并发数据传输和存储
在 ELK 方案中，生成的日志信息直接发送给 logstash 进行传输，并写入到 es，整个过程基本为同步操作，并发性能完全依赖 logstash 服务端及 ES 服务端性能；
天眼则是通过异步方式解耦日志传输过程，以及在日志入口处引入 Disruptor 高性能队列，并发性能直奔千万级别；同时在 Disruptor 本地队列之后再设计 Bigpipe 离线队列，用来长效存储和传输日志消息；以及引入兜底文件队列 BigQueue 解决方案，处理在极少数异常情况下写本地队列或离线队列失败时的兜底保障，如下图所示：
Disruptor 是一个高性能的用于线程间消息处理的开源框架。Disruptor 内部使用了 RingBuffer，它是 Disruptor 的核心的数据结构。
Disruptor 队列设计特性：
固定大小数组：由于数组占用一块连续的内存空间，可以利用 CPU 的缓存策略，预先读取数组元素附近的元素；
数组预填充：避免了垃圾回收代来的系统开销；
缓存行填充：解决伪共享问题；
位操作：加快系统的计算速度；
使用数组+系列号的这种方法最大限度的提高了速度。因为如果使用传统的队列的话，在多线程环境下对队列头和队列尾的锁竞争是一种很大的系统开销。
Bigpipe 是一个分布式中间件系统，支持 Topic 和 Queue 模型，不仅可以完成传统消息队列可以实现的诸如消息、命令的实时传输，也可以用于日志数据的实时传输。Bigpipe 能够帮助模块间的通信实现解耦，并能保证消息的不丢不重；
BigQueue 是基于内存映射文件的大型、快速和持久队列；
1、快 : 接近直接内存访问的速度，enqueue 和 dequeue 都接近于 O(1)内存访问。
2、大：队列的总大小仅受可用磁盘空间的限制。
3、持久：队列中的所有数据都持久保存在磁盘上，并且是抗崩溃的。
4、可靠：即使您的进程崩溃，操作系统也将负责保留生成的消息。
5、实时：生产者线程产生的消息将立即对消费者线程可见。
6、内存高效：自动分页和交换算法，只有最近访问的数据保留在内存中。
7、线程安全：多个线程可以同时入队和出队而不会损坏数据。
8、简单轻量：目前源文件个数 12 个，库 jar 不到 30K。
在采集到日志事件后，进入传输过程中，天眼 SDK 中支持日志过滤规则策略匹配，针对命中策略的日志进行过滤，实现过程如下图所示：
未命中过滤规则的日志消息事件将继续发送至 Bigpipe，至此日志生产阶段即完成，后续通过天眼消费者模块订阅 Bigpipe 消费并批量推送至 ES。
3.4 天眼日志检索
基于天眼链路最终存储到 ES 的日志数据，天眼平台提供了可视化日志检索页面，能够根据产品线唯一标识（日志源 ID）指定业务范围进行检索，同时支持各种检索条件，效果如下图所示：
3.4.1 检索条件详解
日志源 id 列表：获取日志源对应的日志
检索时间范围：日志的时间范围
排序类型：日志的存入时间/日志存入的算分
查询数量：查询出多少数量的日志
日志级别：查询什么级别的日志，如：DEBUG / INFO / WARN / ERROR
算分条件：支持五种算分查询，文本查询、等值查询、短语查询、前缀查询、逻辑查询；五选一
过滤条件：只显示符合过滤条件信息的日志
3.4.2 算分条件检索详细说明
支持五种算分查询：文本查询、等值查询、短语查询、前缀查询、逻辑查询。五选一
搜索内容字段：message、exception
说明：
"analyzer": "my_ik_max_word"：底层使用 ik_max_word，message 和 exception 信息在存储是会以最细粒度拆词进行存储；
"search_analyzer": "my_ik_smart"：底层使用 ik_smart，在查询内容是，会将查询内容以最粗粒度拆分进行查询。
3.4.2.1 文本查询
底层实现原理
天眼管理端对应图
使用说明：
multi_match 中的 best_fields 会将任何与查询匹配的文档作为结果返回，但是只使用最佳字段的 _score 评分作为评分结果返回
3.4.2.2 等值查询
底层实现原理
天眼管理端对应图
使用说明：
multi_match 中的 best_fields 会将任何与查询匹配的文档作为结果返回，但是只使用最佳字段的 _score 评分作为评分结果返回
设置 analyzer 参数来定义查询语句时对其中词条执行的分析过程
Keyword Analyzer - 不分词，直接将输入当做输出
3.4.2.3 短语查询
底层实现原理
天眼管理端对应图
使用说明：
phrase 在 fields 中的每个字段上均执行 match_phrase 查询，并将最佳字段的 _score 作为结果返回
默认使用 match_phrase 时会精确匹配查询的短语，需要全部单词和顺序要完全一样，标点符号除外
slop 指查询词条相隔多远时仍然能将文档视为匹配 什么是相隔多远？ 意思是说为了让查询和文档匹配你需要移动词条多少次？以 "I like swimming and riding!" 的文档为例，想匹配 "I like riding"，只需要将 "riding" 词条向前移动两次，因此设置 slop 参数值为 2， 就可以匹配到。
3.4.2.4 前缀查询
底层实现原理
天眼管理端对应图
使用说明：
phrase_prefix 在 fields 中的字段上均执行 match_phrase_prefix 查询，并将每个字段的分数进行合并
match_phrase_prefix 和 match_phrase 用法是一样的，区别就在于它允许对最后一个词条前缀匹配，例如：查询 I like sw 就能匹配到 I like swimming and riding。
max_expansions 说的是参数 max_expansions 控制着可以与前缀匹配的词的数量，默认值是 50。以 I like swi 查询为例，它会先查找第一个与前缀 swi 匹配的词，然后依次查找搜集与之匹配的词（按字母顺序），直到没有更多可匹配的词或当数量超过 max_expansions 时结束。
match_phrase_prefix 用起来非常方便，能够实现输入即搜索的效果，但是也会出现问题。 假如说查询 I like s 并且想要匹配 I like swimming ，结果是默认情况下它会搜索出前 50 个组合，如果前 50 个没有 swimming ，那就不会显示出结果。只能是用户继续输入后面的字母才可能匹配出结果。
3.4.2.5 逻辑查询
底层实现原理
天眼管理端对应图：
simple_query_string 查询支持以下操作符（默认是 OR），用于解释查询字符串中的文本:
+ AND
| OR
- 非
" 包装许多标记以表示要搜索的短语
* 在术语的末尾表示前缀查询
( and ) 表示优先级
~N 在一个单词之后表示编辑距离(模糊)
~N 在短语后面表示溢出量
官方使用文档：https://www.elastic.co/guide/en/elasticsearch/reference/6.8/query-dsl-simple-query-string-query.html
使用示例解释：
这个搜索的目的是只返回包含 foo 或 bar 但不包含 baz 的文档。然而，由于使用了 OR 的 default_operator，这个搜索实际上返回了包含 foo 或 bar 的文档以及不包含 baz 的文档。要按预期返回文档，将查询字符串更改为 foo bar +-baz。
3.5 日志资源隔离
在庞大的企业级软件生产环境下，业务系统会产生海量日志数据。一方面，随着业务方的不断增加，日志系统有限的资源会被耗尽，导致服务不稳定甚至宕机。另一方面，不同业务的日志量级、QPS 存在差异，极端情况下不同业务方会对共享资源进行竞争，导致部分业务的日志查询延时变高。这对日志系统的资源管理带来了挑战。
天眼平台采用资源隔离的方式解决此问题，来为业务提供实时、高效、安全的存储与查询服务。
资源隔离主要围绕着日志的传输资源与日志的存储资源进行。业务方在接入天眼系统时，可以根据业务需要在平台交互界面，进行传输资源与存储资源的隔离配置，这种隔离资源的配置方式避免了共享资源竞争导致的日志延迟增加与潜在的日志丢失问题。
具体的隔离实现方案如图 3.5.1 所示，主要包括以下步骤：
1、业务方生产日志：如 3.2 介绍到的，业务方运行时产生的日志可以通过 SDK 或 minos 的方式将日志传输至分布式队列 BP 中；
2、天眼平台订阅日志：在业务方通过天眼平台进行 ES、BP 资源的配置之后，配置监听器会监测到变更内容，再根据配置的变更类型管理日志订阅器、分发器的生命周期，包括 ES 客户端、BP 客户端的创建与销毁；
3、平台内部日志处理：日志订阅器通过 BP 客户端收到业务方的日志后，首先会采用 3.3 中提到的业务方过滤规则进行过滤拦截，再将日志转换为事件放入绑定的内存通道中；
4、天眼平台分发日志：日志分发器会不断从绑定的内存通道中拉取日志事件，并通过 ES 客户端对日志进行存储，如果存储失败则会触发相应 backoff 策略，例如异常行为记录；
5、业务方日志查询：日志存储至 ES 集群之后，业务方可以通过平台界面便捷地进行日志查询。
△3.5.1 天眼-资源隔离方案
可见在复杂的多应用场景下，隔离资源机制是一种高效管理日志系统资源的方式。天眼日志系统提供了灵活的资源配置来避免资源浪费，提供了共享资源的隔离来降低业务方日志查询的延迟、提升日志查询的安全性，进而推动业务的增长和运营效率。
3.6 日志动态清理与存储降级
随着业务的长期运行与发展，日志量级也在不断增加。一方面，针对近期产生的日志，业务方有迫切的查询需求。针对产生较久的日志，迫于监管与审计要求也有低频率访问的诉求。如何在成本可控并且保证平台稳定的前提下，维护这些海量日志并提供查询服务对日志系统而言也是一个挑战。
天眼平台通过资源清理机制和日志存储降级机制来解决这个问题。
资源清理机制主要用作 ES 集群的索引清理。随着日志量的增加，集群的资源占用率也在增加，在极端情况下，过高的磁盘与内存占用率会导致 ES 服务的性能下降，甚至服务的宕机。资源清理机制会定期查询 ES 集群的资源占用情况，一旦集群的磁盘资源超过业务方设定的阈值，会优先清理最旧的日志，直到资源占用率恢复正常水平。
存储降级机制主要用作 ES 集群的索引备份与恢复。将日志长期存储在昂贵的 ES 集群中是一种资源浪费，也为日志系统增加了额外的开销。存储降级机制会定期对 ES 集群进行快照，然后将快照转存到更低开销的大对象存储服务（BOS）中，转存之后的快照有 180 天的有效期以应对审查与监管。当业务方需要查询降级存储后的日志时，只需要从大对象存储服务中拉取快照，再恢复到 ES 集群以提供查询能力。
具体的资源清理机制与存储降级机制如图 3.6.1 所示，主要包括以下步骤：
1、集群状态查询：资源清理任务通过定期查询集群信息的方式监测资源占用率，当资源占用率超过业务方设定的阈值时会触发资源清理；
2、集群索引清理：通过查询索引信息并进行资源占用情况计算，再根据时间倒序删除依次最旧的索引，直到满足设定的阈值；
3、集群索引备份：存储降级任务会定期对集群进行快照请求，然后将快照文件转存到低开销的大文件存储服务中完成存储的降级；
4、集群索引恢复：在业务方需要查询降级存储后的日志时，服务会将快照文件从大文件存储服务中拉取目标快照，再通过快照恢复请求对快照进行恢复，以提供业务方查询。
△3.6.1 天眼-日志动态清理与存储降级方案
可见在面对海量日志的存储与查询，通过资源清理机制可以防止集群资源过载同时提升日志检索效率，通过存储降级机制可以提升资源利用率同时确保审计的合规性，从而在业务高速增长使用的同时保证日志系统的健壮性。
3.7 最佳实践
基于前面提到的天眼平台设计思想，结合其中部分能力展开介绍天眼在运维管理方面的实践。
3.7.1 天眼平台化实践
天眼通过抽象产品线概念，针对不同的接入方提供产品线接入流程，为业务生成产品线唯一标识并与业务日志绑定；产品线相关流程如下：
1、产品线日志源申请流程
支持产品线选择日志采集方式包含 SDK、Minos 两种方式，选择 minos 接入时，bns 与日志存储路径必选，方便系统根据配置自动执行日志采集。
同时在 Bigpipe 资源与 ES 资源方面，平台支持多种资源隔离独立使用，不同的产品线可以配置各自独有的传输和存储资源，保障数据安全性和稳定性。
2、日志源申请后，需要管理员审核后才能进行使用（申请后无需操作，仅需等待管理员通过审核后，进行 SDK 接入）
access_key 的值查看权限：仅日志源绑定产品线的经理及接口人可查，access_key 将作为产品线接入天眼鉴权的关键依据。
3.7.2 日志过滤实践
产品线接口人可以基于自身产品线新增日志过滤规则配置，配置的规则将自动生效于日志采集传输流程中：
选择消息日志后将弹出详细过滤规则配置菜单，当前系统共支持三种过滤规则，分别是按日志内容、按日志名称、按日志内容和日志名称组合三种方式：
过滤规则配置完成后可以在列表管理每条规则：
04 思考与总结
随着分布式业务系统的日益复杂，为业务方提供高效、低延迟、高性能的日志服务系统显得尤为重要。本文介绍了天眼平台是如何进行日志采集、传输并支持检索的，此外还通过支持日志的资源隔离，解耦各业务方的日志通路和存储，从而实现业务日志的高效查询和业务问题的高效定位。此外通过对日志进行监控可以主动发现系统问题，并通过告警日志的 trace_id 快速定位问题，从而提升问题发现导解决的效率。
随着大模型技术的不断发展，我们也通过大模型进行一些业务迭代，进而提升业务检索和排查效率。例如：我们可以直接询问，今天有几笔异常核销订单；订单 7539661906 核销异常原因是什么等等。通过与大模型的结合，我们缩短了业务方问题排查定位的路径，提升了业务运维效率和交互体验。后续我们也将不断与大模型进行深入打磨和持续深耕，持续沉淀和输出相关的通用方案。
——END——
推荐阅读：
视频与图片检索中的多模态语义匹配模型：原理、启示、应用与展望
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/825fb813d86740ec988c4a2d4】。文章转载请联系作者。
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论