工作十年,在腾讯沉淀的高可用系统架构设计经验

工作十年,在腾讯沉淀的高可用系统架构设计经验

腾小云导读

在体系的开发过程中,许多开发者都为了完成体系的高可用性而发愁。本文从研制标准层面、运用服务层面、存储层面、产品层面、运维布置层面、反常应急层面这六大层面去分析一个高可用体系的架构规划需求有哪些要害的规划和考虑。期望腾讯的经历办法,能够给广阔开发者供给参阅。内容较长,您能够保藏后持续阅览。

看目录点保藏,随时涨技能

1 高可用体系的架构规划思想

1.1 可用性和高可用概念

1.2 高可用体系规划思想

2研制标准层面

2.1 计划规划和编码标准

2.2 容量规划和评价

2.3 QPS 预估(漏斗型)

3 运用服务层面

3.1 无情况和负载均衡规划

3.2 弹性扩缩容规划

3.3 异步解耦和削峰规划(音讯行列)

3.4 毛病和容错规划

3.5 过载保护规划(限流、熔断、降级)

4 存储层面

4.1 集群存储(会集式存储)

4.2 分布式存储

5 产品层面

6 运维布置层面

6.1 开发阶段-灰度发布、接口测验规划

6.2 开发阶段-监控告警规划

6.3开发阶段-安全性、防进犯规划

6.4布置阶段-多机房布置(容灾规划)

6.5线上运转阶段-毛病演练(混沌试验)

6.6线上运转阶段-接口拨测系列规划

7 反常应急层面

工作十年,在腾讯沉淀的高可用系统架构设计经验

01、高可用体系的架构规划思想

1.1 可用性和高可用概念

可用性是一个能够量化的目标,是指在某个考察时刻,体系能够正常运转的概率或时刻占有率期望值。行业内一般用几个 9 表示可用性目标,对运用的可用性程度一般衡量标准有三个 9 到五个 9。一般咱们的体系至少要到 4 个 9(99.99%)的可用性才干谈得上高可用。

高可用High Availability 的定义(From 维基百科):

高可用是 IT 术语,指体系无中止地履行其功用的才干,代表体系的可用性程度,是进行体系规划时的准则之一。服务不或许 100% 可用,因而要进步咱们的高可用,就要尽最大或许的去添加咱们服务的可用性,进步可用性目标。

一句话来表述就是:高可用就是让咱们的服务在任何情况下,都尽最大或许地能够对外供给服务。

2.2 高可用体系规划思想

高可用体系的架构规划,需求有一套比较科学的工程管理套路。要从产品、开发、运维、基建等全方位去考量和规划。高可用体系的架构规划思想包含但不限于

  • 做好研制标准。体系都是研制人员规划和编码写出来的,因而首要要对研制层面有一个标准和标准。

  • 做好容量规划和评价。首要是让开发人员对体系要抗住的量级有一个根本认知,便利进行合理的架构规划和演进。

  • 做好服务层面的高可用。首要是负载均衡、弹性扩缩容、异步解耦、毛病容错、过载保护等。

  • 做好存储层面的高可用。首要是冗余备份(热备,冷备)、失效搬运(承认,搬运,康复)等。

  • 做好运维层面的高可用。首要是发布测验、监控告警、容灾、毛病演练等。

  • 做好产品层面的高可用。首要是兜底战略等。

  • 做好应急预案。首要是要考虑在呈现问题后怎样快速康复,不至于让咱们的反常事态扩展。

02、研制标准层面

2.1 计划规划和编码标准

研制标准层面是咱们简略忽视的一个点。可是咱们全部的规划,都是研制人员来完结的,包含从规划文档到编码再到发布上线。因而,研制层面也要有一个标准流程和套路,以让咱们更好地去研制和保护一个高可用的体系:

阶段
事项
规划阶段 标准好相关计划规划文档的模板和提纲,让团队内部坚持一致。
计划规划后必定要进行评定。在团队中,新项目必定要评定,重构项目必定要评定,大的体系优化或许升级必定要评定,其他的一般研制工作量超越一周的主张也要评定。
编码阶段 履行代码标准:
  • 工程的 layout 目录需结构标准,团队内部坚持一致,尽量简练;
  • 遵从团队内部的代码标准。一般公司都有对应言语的标准,假如没有则参阅官方的标准,代码标准能够大大削减 bug 而且进步可用性。
单测掩盖率:
  • 代码编写完需求有必定的单测才干来确保代码的健壮性,一同也能保证咱们后续调整逻辑或许优化的时分能够确保代码的安稳。
  • 包含:增量掩盖率、全量掩盖率。详细的掩盖率要到达多少,能够依据团队内部的实际情况来定,一般定的规矩是 50% 的掩盖率。
日志标准

不要随便打日志、要接入远程日志、要能够分布式链路追寻。

发布上线阶段 参阅下面运维布置层面章节的灰度发布和接口测验相关阐明(即6.1)

2.2 容量规划和评价

  • 容量评价:

是指需求评价好在做的这个体系是为了应对一个什么体量的事务、这个事务恳求量的平均值、高峰的峰值大概都在一个什么等级。

假如是新体系,那么就需求先搜集产品和运营同事对事务的大体预估,开发者依据他们给的数据再进行详细评价。假如是老体系,那么就能够依据历史数据来评价。评价的时分,要从一个全体角度来看大局的量级,然后再细化到每个子事务模块要承载的量级。

  • 容量规划:

是指体系在规划的时分,就要能够初步规划好体系大致能够保持的量级,比方是十万级还是百万等级的恳求量,或许更多。不同量级对应的体系架构规划彻底不一样。特别到了千万、亿等级的量级的时分,架构规划会有更多的考量。

这儿值得留意的是,不需求在一开始就规划出远超当时事务实在流量的体系,要依据事务实际情况来规划。一同,容量规划还涉及到:体系上下流的各个模块、依托的存储、依托的三方服务别离需求多少资源,需求有一个相对可量化的数据。容量规划阶段更多是要依托本身和团队的经历,比方要了解体系的 log 的功用、redis 的功用、rpc 接口的功用、服务化结构的功用等等,然后依据各种组件的功用来综合评价现已规划的体系的全体功用情况。

容量评价和容量规划之后,还需求做就是功用压测。最好是能够做到全链路压测。

功用压测的意图是确保体系的容量规划是否精确。假设规划的这个体系,规划的是能够抗千万等级的恳求。那么实际上,真的能够抗住吗 ?在上线之前首要要依据经历来判别,其次是必定要经过功用压测得出精确结论。功用压测要重视的目标许多,可是要点要重视的是两个目标:一个是 QPS,一个是呼应耗时要确保压测的成果契合预期

压测的步骤:能够先分模块独自压测。最终假如情况答应,那么最好履行全链路压测。

2.3 QPS 预估(漏斗型)

QPS 预估(漏斗型)指的是:一个实在的恳求过来后,从接入层开始别离经过了整个体系的哪些层级、哪些模块,每一个层级的 QPS 的量等级离有多少。

从恳求链路上来看,层级越往下,下流层级的量级就会越少。由于每经过一个层级,都有或许会被各种条件过滤掉一部分恳求。例如进入活动页后检查产品概况然后下单这个例子,首要进入活动页,全部的恳求都会进入拜访。然后只会有部分用户查询产品概况。最终检查产品概况的这些用户又只会有部分用户会下单。这儿就会有一个漏斗,所以从上层模块到下层模块的量级必定是逐渐削减的。

QPS 预估(漏斗型)需求开发者依照恳求的层面和模块,来构建预估漏斗模型,然后预估好每一个层级的量级。包含但不限于从服务、接口、分布式缓存等各个层面来预估,最终构成完好的 QPS 漏斗模型。

03、运用服务层面

3.1 无情况和负载均衡规划

要做到体系的高可用,一般运用服务的常规规划都是无情况的。这也就意味着,开发者能够布置多个实例来进步体系的可用性。而这多个实例之间的流量分配,就需求依托体系的负载均衡才干。「无情况 + 负载均衡」既能够让体系进步并发才干,也能够进步体系的可用性。

假如开发者的事务服务运用的是各种微服务结构,那么大概率在这个微服务结构里边就包含了服务发现和负载均衡的才干。这一整套流程包含:服务注册和发现、负载均衡、健康情况检查和主动剔除。当体系的任何一个服务实例呈现毛病后,它会被主动剔除去。当体系有新增一个服务实例后,它会被会主动添加进来供给服务。

假如咱们不是运用的微服务结构来开发的,那么就需求依托负载均衡的代理服务,例如 LVS、Nginx 来帮体系完成负载均衡。当然,腾讯云的 CLB 负载均衡也支撑亿级连接和千万级并发,各位感兴趣的话可自行搜索了解。

3.2 弹性扩缩容规划

弹性扩缩容规划是应对突峰流量的十分有用的手法之一,一同也是保证体系服务可用性的必要手法。弹性扩缩容针对的是体系无情况的运用服务而言的。服务是无情况的,因而能够随时依据恳求量的大小来进行扩缩容,流量大就扩容来应对大量恳求,流量小的时分就缩容削减资源占用。

怎样完成弹性扩缩容呢? 现阶段都是云原生年代,大部分的公司都是选用容器化(K8s)布置,那么根据这个情况的话,弹性扩缩容就十分简略了,只需求装备好 K8s 的弹性条件就能主动依据 CPU 的运用率来完成。

假如不是容器化布置,是物理机布置的方法,那么要做到弹性扩缩容,有必要要有一个公司内部的基础建造才干、能够在运营渠道上针对服务的 CPU 或许 QPS 进行监控。假如超越必定的份额就主动扩缩容,就和 K8s 的弹性原理是一样的,仅仅需求自行完成。

3.3 异步解耦和削峰规划(音讯行列)

要想体系能够高可用? 从架构层面来说,要做到分层、分模块来规划。而分层分模块之后各个模块之间,还能够进行异步处理、解耦处理。意图是为了不相互影响,经过异步和解耦能够使体系的架构大大的提高可用性。

架构层面的异步解耦方法就是选用音讯行列(比方常见的 Kafka),而且一同音讯行列还有削峰的作用,这两者都能够进步体系的架构可用性:

选用音讯行列之后,能够把同步的流程转换为异步的流程,音讯生成者和顾客都只需求和音讯行列进行交互。这样不仅做了异步处理,还将音讯生成者和顾客进行了阻隔。

方法

解析

异步

异步处理的优势在于,不论音讯的后续处理的事务服务是否完结,只需音讯行列还没满,那么就能够履行对外供给服务。而消费方则能够依据本身处理才干来消费音讯,再进行处理。

解耦

解耦的优势在于假如消费方反常,并不影响生产方,仍然能够对外供给服务。音讯顾客康复后能够持续从音讯行列里边,获取消费数据后履行事务逻辑。

削峰

选用音讯行列之后,还能够做到削峰的作用,当并发较高的时分乃至是流量突发的时分,只需音讯生产者能够将音讯写入到音讯行列中,那么这个音讯就不会丢。后续处理逻辑会渐渐的去音讯行列里边消费这些突发的流量数据。这样就不会由于有突发流量而把整个体系打垮。

3.4 毛病和容错规划

任何服务,必定会存在失利的情况,不或许有 100% 的可用性。服务在线上运转过程中,总会遇到各种各样意想不到的问题会让服务呈现情况,因而业界来评价可用性 SLA 都是说多少个 9,例如 4 个 9(99.99%)的可用性。

为此,一般规划主张遵从「design for failure」的规划准则,规划出一套可容错的体系。需求做到尽早回来、主动修复,细节如下:

要点

解析

遵从 fail fast 准则

Fail fast 准则是说,当体系的主流程的任何一步呈现问题的时分,应该快速合理地结束整个流程,赶快回来过错,而不是等到呈现负面影响才处理。

具有自我保护的才干

当体系依托的其他服务呈现问题的时分,要赶快的进行降级、兜底等各种反常保护措施,防止呈现连锁反应导致整个服务彻底不行用。例如当体系依托的数据存储呈现问题,不能一向重试然后导致数据彻底不行用。

3.5 过载保护规划(限流、熔断、降级)

体系无法高可用的一个重要原因就在于:体系常常会有突发的流量到来,导致服务超载运转。这个时分首要要做的是快速扩容,而且开发者事前就要预留好必定的冗余。别的一个情况下,就算扩容了,可是还是会超载。例如超越了下流依托的存储的最大容量、或许超越了下流依托的三方服务的最大容量。

那么这个时分,体系就需求履行过载保护战略了,首要包含限流、熔断、降级,过载保护是为了确保服务部分可用,不至于导致整个服务彻底不行用。

过载保护手法 解析
限流

限流是指对进入体系的恳求进行限流处理,假如恳求量超越了体系最大处理才干或许超越了开发者指定的处理才干,那么直接拒绝恳求,经过这种丢弃部分恳求的方法能够确保整个体系有必定的可用性,不至于让整个体系彻底不行用。那么怎样判别超越最大处理才干呢?一般就是运用 QPS 来判别,假如 QPS 超越阈值,那么就直接拒绝恳求。

限流有许多细节的战略,例如针对接口限流、针对服务限流、针对用户限流。

熔断,断路(开路)的价值在于限制毛病影响范围。一般期望控制、削减或中止和毛病体系之间的通讯,然后降低毛病体系的负载,这有利于体系的康复。一般体系的服务都会有许多下流依托,假如下流依托的服务呈现问题,例如开始就超时乃至呼应十分慢的话,假如不做任何处理,那么会导致整个恳求都被卡住形成超时,那么体系的事务服务对外就无法供给任何正常的功用
为此,熔断战略就能够处理这个问题,熔断就是当体系依托的下流服务呈现问题时,能够快速对其进行熔断(不发起恳求),这样体系的事务服务至少能够供给部分功用。
熔断的规划至少需求包含:熔断恳求判别机制算法、熔断康复、熔断告警三部分。
降级 降级是指开发者划分好体系的中心功用和非中心功用,然后当体系超越最大处理才干之后,直接封闭掉非中心的功用,然后确保中心功用的可用。封闭非中心的功用后能够使体系开释部分资源,然后能够有资源来处理中心功用。

熔断和降级这两个战略虽有些相似,字面的意思都是要快速拒绝恳求。可是却是两个维度的规划:降级的意图是应对体系本身的毛病,而熔断的意图是应对体系依托的外部服务毛病。

04、存储层面

当时的互联网年代,运用服务根本都是无情况的。因而运用服务的高可用相对来说会比较简略。可是数据存储的高可用相对来说,会杂乱许多。由于数据是有情况的,那详细开发者要怎样保证数据存储的高可用。下文一同来分析下。

存储层面的高可用计划本质是经过数据的冗余来完成,将数据仿制到多个存储介质里边,能够有用的防止数据丢失,一同还能够进步并发才干。由于数据是有情况的,这儿会比服务的高可用要杂乱许多。

常见的处理存储高可用的计划有两种:集群存储和分布式存储。业界大多是围绕这些来构建,或许是做相关衍生和扩展。下面展开讲解。

4.1 集群存储(会集式存储)

集群存储是指由若干个「通用存储设备」组成的用于存储的集群。组成集群存储的每个存储体系的功用和容量均可经过「集群」的方法得以叠加和扩展。

集群存储合适事务存储量规模一般的场景,常规的事务数据存储一般都是集群存储方法就足够了。现在一般事务数据存储的运用默许都是集群方法。比方 Redis、MySQL 等存储类型。一般中大型互联网公司默许是集群存储的方法。

集群存储就是常说的「 1 主多备」或许「 1 主多从」的架构。写数据经过主机,读数据一般经过从机。集群存储首要需求考虑如下几个问题:

  • 主机怎么将数据仿制给备机(从机)?数据的写入都是经过主机,因而数据同步到备机(从机),就是要经过主机进行数据仿制到备机(从机)。还需求考虑主备同步的时刻延迟问题。
  • 备机(从机)怎么检测主机情况?
  • 主机毛病后,备机(从机)怎样切换为主机?主从架构中,假如主机产生毛病,可直接将备机(从机)切换为主机。

4.2 分布式存储

分布式是指将不同的事务分布在不同的节点。分布式中的每一个节点,都能够做集群。

「分布式存储体系」是将数据涣散存储在多台独立的设备上。传统的网络存储体系选用会集的存储服务器寄存全部数据,存储服务器成为体系功用的瓶颈,也是可靠性和安全性的焦点,不能满意大规模存储运用的需求。

分布式网络存储体系选用可扩展的体系结构,运用多台存储服务器分管存储负荷,运用方位服务器定位存储信息。它不但进步了体系的可靠性、可用性和存取功率,还易于扩展。

分布式存储合适十分大规模的数据存储,事务数据量巨大的场景能够选用这种方法。常见的分布式存储比方 COS、GooseFS、Hadoop(HDFS)、HBase、Elasticsearch 等。

05

产品层面

产品层面的高可用架构处理计划,根本上就是指兜底产品战略。降级/限流的战略,更多的是从后端的事务服务和架构上的规划来考虑相关处理计划。这儿说的兜底战略也可叫做「柔性降级战略」,更多的则是经过产品层面上来考虑。下面举几个例子:

  • 当体系的页面获取不到数据时,或许无法拜访时,要怎么友爱的奉告用户。如「稍后重试」之类的方法。

  • 当体系的实在的页面无法拜访的时分,就需求产品供给一个默许页面,假如后端无法获取实在数据,那么直接烘托默许页面。

  • 服务器需求停机保护,那么产品层面就会显现一个停机页面,全部用户只会弹出这个停机页面,不会恳求后端服务。

  • 抽奖产品显现一个默许兜底产品等等。

06、运维布置层面

6.1 开发阶段-灰度发布、接口测验规划

灰度发布、接口测验、接口拨测系列规划包含但不限于:

  • 灰度发布:

服务发布上线的时分,要有一个灰度的过程。先灰度 1-2 个服务实例,然后逐渐放量观察。假如全部 ok,再逐渐灰度,直到全部实例发布完毕。

  • 接口测验:

每次服务发布上线的时分,服务供给的各种接口,都要有接口测验用例。接口测验用例测验经过后,服务才干发布上线。这样意图是为了检查体系对外供给的接口是否能够正常运转,防止服务发布后才发现有问题。

灰度发布和接口测验,一般在大公司里边会有相关的 DevOps 流程来确保。

6.2 开发阶段-监控告警规划

监控告警的规划,对部分大公司来说不是问题。由于必定会有一些比较专门的人去做这种基础才干的建造,会有对应的配套体系,事务开发者只需求装备或运用即可。

那假如公司内部没有相关基础建造,就需求开发者别离来接入对应的体系,或许直接接入一些目标、链路、日志、事情等多数据支撑、更加一体化的监控渠道,比方腾讯云可观测渠道。

体系 建造要求
监控体系

一般在监控体系这方面的开源处理计划包含但不限于这些:

ELK (Elasticsearch、Logstash、Kibana) 日志搜集和分析:咱们的日志记载不能都本地存储,由于微服务化后,日志散落在许多机器上,因而有必要要有一个远程日志记载的体系,ELK 是不贰人选。

Prometheus 监控搜集:能够监控各种体系层面的目标,包含自定义的一些事务目标

OpenTracing 分布式全链路追寻:一个恳求的上下流这么多服务,怎样能够把一个恳求的上下流全部串起来,那么就要依托 OpenTracing,能够把一个恳求下的全部链路都串起来而且有详细的记载。

OpenTelemetry 可观测体系标准:最新的标准,大一统,集合了盯梢数据(Traces),目标数据(Metrics),日志数据(Logs)来观测分布式体系情况的才干。

咱们会依托开源体系进行自建或许扩展,乃至直接运用都行,然后咱们的监控的目标一般会包含:

基础设施层的监控:首要是针对网络、交换机、路由器等低层基础设备,这些设备假如呈现问题,那么依托其运转的事务服务肯定就无法安稳的供给服务,咱们常见的中心监控目标包含网络流量(入和出)、网络丢包情况、网络连接数等。

操作体系层的监控:这儿需求包含物理机和容器。常见的中心目标监控包含 CPU 运用率、内存占用率、磁盘 IO 和网络带宽等。

运用服务层的监控:这儿的目标会比较多,中心的比方主调恳求量、被调恳求量、接口成功率、接口失利率、呼应时刻(平均值、P99、P95 等)等。

事务内部的自定义监控:每个事务服务自己的一些自定义的监控目标。比方电商体系这儿的:阅览、付出、发货等各种情况的事务目标。

端用户层的监控:前面的监控更多的都是内部体系层面的,可是用户真正拜访到页面,中心还有外网的情况,用户真正获取到数据的耗时、打开页面的耗时等这些信息也是十分重要的,可是这个一般就是需求客户端或许前端去进行计算了。

告警体系 这些体系接入完,还仅仅做到监控和计算,当呈现问题时,还需求进行实时告警,因而要有一个实时告警体系,假如没有实时报警,体系运转反常后就无法快速感知,这样就无法快速处理,就会给运用者的事务带来严重毛病和灾难。
告警规划需求包含:实时性:完成秒级监控。
面性:掩盖全部体系事务。
实用性:预警分为多个等级。监控人员能够便利、实用地依据预警严重程度做出精确的决议计划。
多样性:预警方法供给推拉模式。包含短信,邮件,可视化界面,便利监控人员及时发现问题。

6.3 开发阶段-安全性、防进犯规划

安全性、防进犯规划的意图是为了防刷、防黑产、防黑客,防止被外部恶意进犯。一般有两个战略:

  • 在公司等级的流量入口做好一致的防刷和鉴权的才干,例如在一致接入层做好封装。

  • 在事务服务内部,做好相关的事务鉴权,比方登录态信息、例如添加事务鉴权的逻辑。

6.4 布置阶段-多机房布置(容灾规划)

一般的高可用战略,都是针对一个机房内的服务层面来规划的,可是假如整个机房都不行用了,例如地震、火灾、光纤挖断等情况怎样办?这就需求体系的服务和存储能够进行容灾了。容灾的常见计划就是多机房布置。

类型 解析
服务的多机房布置 服务的多机房布置比较简略。由于咱们的服务都是无情况的,因而只需名字服务能够发现不同机房的服务,就能够完成调用。这儿需求留意的是名字服务(或许说负载均衡服务)要能够有就近拜访的才干。
存储的多机房布置 存储的多机房布置,这个会比较难搞一点,由于存储是有情况的,布置在不同的机房就涉及到存储的同步和仿制问题。

条件不答应的情况下,确保多机房布置事务服务就能够了。

6.5 线上运转阶段-毛病演练(混沌试验)

毛病演练在大公司是一个常见的手法。在业界,Netflix 早在 2010 年就构建了混沌试验东西 Chaos Monkey。混沌试验工程对于提高杂乱分布式体系的健壮性和可靠性发挥了重要作用。

简略的毛病演练就是模拟机房断电、断网、服务挂掉等场景,然后看整个体系运转是否正常。体系就要参阅混沌试验工程来进行详细的规划和规划,这个是一个相对较大的工程、作用较好,可是需求有大量人力去开发这种基础建造。

6.6 线上运转阶段-接口拨测系列规划

接口拨测和巡检类似,就是服务上线后,每隔一个固定时刻(比方 5s)调用后端的各种接口,假如接口反常则进行告警。

针对接口拨测,一般也会有相关配套设施来供给相关的才干去完成。假如没有供给,那么开发者能够写一个接口拨测(巡检)的服务,定期去调用重要的接口。

07、反常应急层面

即使前面做了许多保证,也不必定招架住线上的各种反常情况。假如真出问题让体系的服务反常、无法供给服务,开发者还有最终一根救命稻草——那就是应急预案,将服务反常的丢失降低到最小。

应急预案是需求开发者事前规划好,事务体系在各个层级呈现问题后第一时刻怎样康复,并制定好相关规矩和流程。当呈现反常情况后能够依照既有的流程去履行。这样防止呈现问题后手忙脚乱导致事态扩展。

工作十年,在腾讯沉淀的高可用系统架构设计经验

最终,咱们整理出本文的思想导图如上,供各位参阅。总体来说,咱们从研制标准层面、运用服务层面、存储层面、产品层面、运维布置层面、反常应急层面这六大层面,分析了一个高可用体系的架构规划需求有哪些要害的规划和考虑。

以上就是本次共享的全部内容,假如您觉得内容有用,欢迎点赞、保藏,把内容共享给更多开发者。

-End-

原创作者|吴德宝

技能责编|吴德宝

腾小云福利来也

扫码一键收取 「腾讯云开发者-春季限定红包封面」

工作十年,在腾讯沉淀的高可用系统架构设计经验

最近微信改版啦,有粉丝反应收不到小云的文章。

请重视「腾讯云开发者」并点亮星标

周一三晚8点 和小云一同涨(领)技(福)术(利)

工作十年,在腾讯沉淀的高可用系统架构设计经验

你或许感兴趣的腾讯工程师作品

|编程言语70年:谁是世界上最好的编程言语?

|腾讯工程师聊 ChatGPT 技能「文集」

| 一文揭秘微信游戏推荐体系

|微信全文搜索耗时降94%?咱们用了这种计划

技能盲盒:前端|后端|AI与算法|运维|工程师文化

阅览原文