共计 9550 个字符，预计需要花费 24 分钟才能阅读完成。
摘要：本文整顿自阿里云计算平台算法专家张颖莹，在 Flink Forward Asia 2022 AI 特色工程专场的分享。本篇内容次要分为五个局部：
1. 阿里云大数据平台的智能运维
2. 智能运维算法服务利用场景
3. 传统算法工程链路的局限性
4. 应用 Flink ML 搭建智能运维算法服务
5. 总结和开源打算
一、阿里云大数据平台的智能运维
阿里云计算平台提供了多个十分外围的大数据计算和人工智能相干的产品，撑持了阿里团体外部以及云上各行各业客户很多外围的业务场景。在这里我筛选了三个十分典型的大数据计算产品来给大家做介绍，它们是大数据计算服务 MaxCompute、实时计算 Flink、实时数仓 Hologres。
这些产品所撑持的业务场景大家其实也都十分相熟，比方咱们日常在手机淘宝、蚂蚁森林中收取的能量数据就依赖于像 MaxCompute 大数据计算服务定时产出，因为它次要负责大规模数据的离线计算；双十一期间，咱们会看到十分多炫酷的数字大屏，这些大屏上实时滚动的数字就依赖于像 Flink 实时大数据处理系统；当咱们日常在手机淘宝上搜寻一些商品的关键词的时候，Hologres 则会在底层帮咱们进行实时的交互式剖析，从而为咱们举荐出实时的搜寻后果。
能够看出，这几个大数据平台所撑持的业务场景是十分丰盛的，它的用户规模十分的宏大，平台自身的架构也十分复杂。因而保障平台的稳定性就变成了一项重要且富裕挑战性的工作。咱们计算平台专门设置了一支运维中台的研发团队，也就是我所在的团队，来负责大数据平台的对立运维管控。
比拟有意思的一点是，咱们既是大数据平台的使用者，同时咱们也负责平台的智能化运维工作。
从运维的视角来看，咱们最关怀的外围问题次要有三个层面，别离是稳定性、老本、效率。
- 在稳定性层面，波及到的问题包含是否可能及时发现大数据平台中产生的异样、定位异样背地的根本原因、及时的止血和修复问题。
- 在老本层面，咱们关怀是否通过更加正当的资源配置以及优化利用的排布，在保障稳定性的前提下，可能让咱们的老本降到最低。
- 在效率层面，咱们不仅关注大数据平台自身的性能的晋升，同时咱们也心愿应用大数据平台的用户能到可能失去十分高效的技术支持和答疑。
后面提到的典型场景当然都离不开数据的撑持，随着零碎的云原生化以及可观测性理念的遍及，咱们当初所能获取到的零碎层面的可观测性数据也越来越丰盛了，包含指标、日志、Trace 等等多种不同状态的数据。
基于传统的人工剖析曾经很难实现对海量数据的全面高效剖析，因而也就催生出了对于智能运维算法能力的需要。那么在智能运维场景里，咱们对算法模型都有哪些需要呢？
首先，咱们心愿算法模型可能解决来自多个不同数据源、各个不同状态的数据。比方咱们后面所提到的指标就属于工夫序列类型的数据，而日志属于文本类型的数据。
同时，咱们心愿在智能运维场景中的算法还要具备足够高的性能。因为在运维的场景中，咱们须要面对的往往是信息密度比拟低的海量数据。
此外，无论是从大数据平台所撑持的业务场景来看（比方咱们方才提到的双十一的数字大屏），还是从阿里云所承诺给用户的服务质量的角度而言，咱们对于智能运维场景中算法的实时性也都有十分高的要求。
二、智能运维算法服务利用场景
那么接下来咱们就通过几个典型的案例来给大家介绍，在智能运维的场景中都有哪一些比拟典型的算法模型，以及他们是如何利用在咱们的理论业务场景中的。咱们仍然会从智能运维的外围场景稳定性、老本和效率三个层面进行开展。
稳定性层面，咱们后面提到的关键问题是，咱们是否及时发现零碎中的异样。在咱们理论的生产中，对应的平台的运维人员会去建设本人的一套外围指标监控大盘，但对于像阿里云这样宏大的平台，即便是外围指标，它的数量也远远超过了人工可能笼罩的领域。因而咱们就须要利用工夫序列的异样检测算法，它能主动捕捉在运维场景中几种比拟典型的异样，包含方差的变动、均值的变动、尖峰深谷、断崖式跌落、趋势增长等等。
那么通过这些智能继续的异样检测算法，咱们就可能更快的发现零碎中的异样问题，最终的目标则是为了保障咱们承诺给用户的稳定性 SLA。常见的稳定性 SLA 的量化规范是 MTTR，也就是问题从产生到最终解决的耗时。而工夫序列异样检测算法所要解决的是其中十分要害的 MTTD 环节。因而如果咱们可能去缩短工夫序列异样检测算法链路侧的延时，就可能缩短 MTTD，进而缩短 MTTR，最终保障咱们整体稳定性 SLA 的达成。
老本层面，咱们心愿通过更加正当的资源配置，使得在保障用户体验和平台稳定性的前提下，可能把老本降到最低。为了达到这个目标，须要具备以下两个基本要素。
- 咱们须要可能对用户的负载和资源需要进行十分精准的预测。
- 咱们在零碎底层的调度侧须要具备主动扩缩容的能力。
目前随着咱们整个零碎的云原生化，底层零碎的主动扩缩容能力曾经根本具备了，因而精准的预测就变得十分要害。在过来，当咱们无奈对用户的负载进行精准预测的时候，通常只能依据教训设置比拟恒定的值，但这种设置办法会导致低峰时段的资源节约，顶峰时段的用户资源需要又无奈充沛失去满足，既节约了机器又影响了用户的体验。
如果咱们有了更加精准的算法，就能更加精准的捕捉用户负载的简单的周期性，同时能够依据精准的预测后果，分不同的时段设置更加正当的资源配置，使得在低峰时候资源的节约缩小，顶峰时候用户的资源需要又能尽可能的失去保障。
当然咱们晓得在理论的业务场景中，用户的资源需要不是完满且安稳的周期性曲线。因而咱们须要联合最新的数据，及时对咱们的预测算法做出调整，调整咱们的预测后果以及相应的置信度。最终优化咱们给用户举荐的资源配置策略，或者修改后期谬误的一些资源配置策略。因而咱们对于工夫序列预测算法链路上延时的革新，能够使得咱们可能更加精准灵便的去应答线上资源的渐变状况。
效率层面，咱们的大数据计算平台上运行着十分多的用户的作业，无论是零碎层面，还是用户本身操作层面的问题，都有可能导致作业呈现报错。当用户接管到零碎报错的时候，大多数用户都不晓得如何解决。因而他们通常的做法就是，通过提工单的形式来寻求业余技术支持的帮忙。
而随着咱们用户体量的不断扩大，技术支持的答疑工作量也变得越来越大，而且其实很多的报错都是同一个起因造成的，所以给技术支持带来了十分多低效反复的答疑。因而咱们心愿利用日志聚类算法来实现对海量原始日志的高效压缩，使咱们可能把海量的原始日志聚合成数量十分无限的日志类别。这样运维人员只需针对研发数量十分无限的日志类别，再联合他们的专家教训标注对应的解决方案即可。
当下一次其余用户遇到相似问题的时候，咱们就能通过日志聚类算法去匹配报错所对应的解决方案，并通过答疑机器人间接传递给用户。从而大大晋升工单的拦挡率，缩小技术支持的答疑工作量。同时对于用户来说，也能在接管到报错很短的工夫内，就失去解决方案的举荐，进而晋升用户侧的满意度。
那么在这里咱们为什么会须要用到流式的日志聚类呢？
首先，咱们的系统日志是源源不断生成的。其次，以往离线进行训练的算法链路，会导致用户在接管到报错，来寻求技术支持帮忙的时候，底层的日志都还没聚类实现，因而也就无奈举荐出适合的解决方案了。所以利用流式日志聚类算法，咱们可能保障用户在接管到报错很短的工夫内，就可能实现聚类，并且举荐出适合的解决方案。
通过这三个场景的解说，咱们能够理解到在智能运维场景中，这几个算法模型的实时性都有十分高的要求，因而传统的算法链路通常难以满足咱们的须要。
三、传统算法工程链路的局限性
接下来咱们就通过具体的传统算法工程链路来给大家解说它的局限性。上图展现了咱们以往在实践中常常会应用到的传统算法工程链路。
在数据的输出层，咱们有一个流式产生的数据源。比方它可能是各个模块产生的日志数据，或者是各个模块一直上报上来的指标数据。这些数据的格局通常是比拟芜杂的，所以咱们须要利用 Flink 作业对数据进行实时的预处理。把它加工成咱们后续算法所冀望的格局，并把它输入、存储到一个数据库中。
而在传统的链路中，咱们的 AI 算法局部通常是部署在单机上的一段代码，并通过调度机制进行定时的调度。这段算法会离线的从数据库中读取一批数据，进行模型的离线训练，并把训练好的模型也存储下来。
在咱们理论的运维实场景中，通常会须要一些比拟实时性的剖析后果，所以咱们以往都是去减少另外一个 Flink 作业。在这个作业中，一方面咱们会去对接源头的流式数据源，同时咱们也会去调用离线训练好的模型。这样的话就能使得咱们的剖析后果的实时性，不会受到模型自身训练频率的影响。
这样的做法尽管勉强可能运行，但它依然存在着十分大的局限性。首先咱们能够看到，整个流程十分简短。数据的预处理阶段、模型的共建阶段、后续的数据分析阶段都扩散在了各个不同链路中。咱们波及到了两个作业和一段代码脚本，同时上一个阶段的产出是被下一个阶段强依赖的，因而整个链路的运维保障老本十分高。
同时，咱们方才提到了 AI 算法局部是通过部署在机器上的定时调度的程序去执行的，因而它的实时性非常低。此外，我因为部署在单机上，算法的性能也很难失去保障，所以咱们须要去对这一套传统算法工程链路进行革新优化。
四、应用 Flink ML 搭建智能运维算法服务
那么为什么 Flink ML 会成为咱们的最佳抉择呢？在答复这个问题之前，咱们首先须要剖析一下在智能运维场景中，这些经典的算法模型都具备哪些特点。
咱们在后面提到了，运维中的三大外围问题，稳定性、老本、效率。这三个畛域中都别离存在一些各自比拟经典的算法模型。比方在稳定性层面，为了更好的去检测指标中的异样，咱们会用到工夫序列异样检测算法；在老本层面，为了可能更好的去提前进行资源的优化配置，咱们会用到工夫序列预测算法；在效率层面，为了构建日志知识库，咱们会用到日志聚类算法。
这三个算法模型尽管解决的具体问题不同，但它们都具备一些独特个性。
- 对于工夫序列相干的两个模型，比方异样检测和预测算法，他们所须要的训练数据绝对较小，因而它们的模型训练速度相对来说比拟快。而对于日志聚类算法，它自身的算法复杂度十分高，然而咱们通过一些设计便能够实现数据的增量训练。
- 这些模型对于新数据比拟敏感。具体的来说，新数据可能会影响到继续异样检测对于“什么是失常模式”的判断，新数据也会影响到工夫序列算法对趋势的判断。此外，新数据还会影响到日志聚类算法对于聚类核心的计算。因而这三种算法模型都须要联合最新数据及时对模型进行更新。
- 在智能运维场景中，咱们对模型自身的可解释性要求比拟高，所以在理论的利用中，咱们都偏向于应用一些传统的机器学习模型。
通过剖析这几个经典算法模型的独特特点，接下来咱们就开始思考，咱们应该采取什么样的形式，来对咱们的算法架构进行优化降级。咱们发现 Flink ML 具备的一些个性，不仅和咱们后面所剖析的几个算法模型的特点十分匹配，而且它也能解决咱们后面所提到的几个痛点问题。
Flink ML 是一套面向传统实时机器学习的框架，它开始于 2021 年 4 月，是 Apache Flink 的子项目，因而咱们应用 Flink ML 就可能充沛的利用到 Flink 自身的一些个性。首当其冲的当然是实时性，其次是 Flink 流批一体的个性。所谓流批一体是指，Flink 同时反对在无线数据流上的流式解决，以及有线数据流上的批量解决。这样的话就可能满足咱们在模型训练过程中不同状态的需要。
此外，Flink 还提供了 CDC 连接器来实现数据的增量读取，所谓 CDC 就是 Change Data Capture，它能够实时读取数据库中的存量历史数据，并监控和捕捉在这期间数据库的变动，从而实现数据的增量更新。CDC 的个性使得咱们能够在很大水平上，升高对于数据库的读写压力，缩小网络开销，缩小整个链路的延时。
除了后面提到的这三个 Flink 相干的个性以外，Flink ML 自身还具备另外两个个性。首先它提供对于用户十分敌对的 API，因而在很大水平上缩小了用户应用和了解框架的老本。用户不须要理解算子背地的具体实现细节，就能够间接调用，因而能够晋升开发效率。
此外，还有一点很重要的个性是，Flink ML 提供了十分齐备的机器学习基础设施。从特色工程到后续的具体的分类聚类回归模型，Flink ML 都提供了十分丰盛的机器学习相干的算子，因而很大水平上也提供了 Flink ML 的可复用性。
正是因为 Flink ML 具备的低劣个性，咱们决定应用它来对咱们的智能运维相干的算法服务的架构进行降级。
接下来咱们就以日志聚类算法为例，为大家展现具体的降级革新过程。
在进入具体的流程前，咱们先来理解一下日志聚类的业务背景和面临的挑战。咱们后面曾经提到过，在老本层面，咱们会利用日志聚类算法来实现对海量日志的高效聚合，帮忙运维人员联合他们的专家教训来构建出日志知识库，从而晋升后续运维环节的效率。然而要实现这样的目标并不是件容易的事，因为咱们的系统日志，特地是报错日志具备以下的几个特点和挑战：
- 咱们的系统日志是海量，且信息密度非常低，这就对咱们的算法性能有十分高的要求。
- 咱们的日志数据是文本类型的，也就是非结构化的数据，它绝对于结构化的数据，解决上要简单的多。
- 咱们的日志中蕴含了十分多的变量，特地是在咱们大数据畛域的日志，通常蕴含十分多的表名、列名等等变量。
- 这些日志一方面具备肯定的格局标准，同时它也具备肯定的语义性。因为咱们整个零碎的规模十分宏大，开发人员也十分的泛滥。
- 咱们的系统日志是实时生成的，因而随时都有可能呈现新的日志类型，所以传统的那些基于正则表达式或者是规定对日志的进行监控或者是知识库的建设计划都不太可行。
所以对于咱们的日志聚类算法而言，它须要可能主动实时的将海量的数据聚合为无限的日志类别，同时须要思考日志中的语义性，并且还须要可能应答日志中可能随时呈现的新的日志类型。
接下来咱们通过具体的事例，让大家更直观的理解到，日志聚类到底在实现一件什么样的事件。
从上图中大家能够看到六段日志原文，其中前三段日志原文除了表名不同以外，日志的其余局部都完全一致。后三条日志尽管在表述形式上与后面的三条不尽相同，但从语义上它们想表白的意思是雷同的。因而在零碎层面，咱们认为这六条日志原文应该都属于同一个日志类型，所以咱们心愿，通过日志聚类算法来把这六条日志原文聚合成同一个日志类别。
那么咱们怎么实现这样的目标呢？首先在预处理阶段，咱们会剔除日志原文中的变量，因为这些变量对后续的聚类并没有太大的帮忙。剔除变量之后，咱们就可能失去日志模板，而日志的模板的长度是无法控制的。有些日志的原文可能十分长，因而它的日志模板也十分长。所以咱们须要利用 hash 编码的形式，来对日志模板进行标识，不便后续的剖析。
通过预处理当前，咱们就可能把后面的六条日志原文，转换为这里的两条日志模板。接下来咱们就须要去对这两条日志模板，进行语义层面的进一步剖析。
首先咱们会对这两条日志模板进行分词，并抉择一些信息量比拟大的词作为咱们的特色列表。接下来就能够基于这些特色列表，对咱们的日志模板进行向量化的构建。
具体的构建过程是，当这个词呈现在日志模板中的时候，咱们就会把相应的地位置为 1，否则置为零。这样咱们就可能失去对应日志模板的向量示意，有了这样一个特色矩阵当前，咱们就能够持续调用聚类算法来实现对日志模板的聚合了。
能够看到，这两个日志模板的大多数特色都是完全一致的，所以咱们在计算向量之间的间隔的时候，这两个日志模板的间隔会十分的靠近。所以很大概率，它能通过后续的聚类算法聚合到同类别中，接下来咱们会依据咱们的特色列表以及每个类别中各个日志模板蕴含的特色来提取出关键词列表，加强咱们聚类后果的可解释性。
同时咱们的研发人员也能够针对这类日志类别进行对应解决方案的标注，这样的话，它就不须要去对原始的六条日志别离进行标注，只须要对整个类别进行对立的解决方案标注，极大晋升了构建日志知识库的效率。
下面的过程在咱们的算法中是怎么的流程呢？如上图所示，首先咱们从 SLS 中读取日志数据，而后对读取过去的日志数据进行预处理和编码，失去日志模板。并持续进行后续的文本层面的剖析，包含分词、特征选择、提取关键词、日志模板的特色示意、标准化。
接着咱们会调用档次聚类算法来失去咱们的聚类后果，也就是各个日志模板所对应的日志类别，并把它写到数据库中去。当新的日志模板生成的时候，咱们会从数据库中去读取已有的聚类后果，并从各个日志类别中抉择一些具备代表性的日志模板，和咱们新产生的那些日志模板一起进行新一轮的聚类，这样就实现了数据的增量训练。
那么这样一个算法流程是怎么在 Flink ML 的架构上得以实现的？
首先咱们会建设一个 Flink 作业，在这个 Flink 作业中，咱们仍然会去 SLS 中读取流式生成的数据，而接下来的环节，因为咱们须要将新生成的数据与数据库中的存量聚类后果进行对立剖析，因而咱们会在 Flink 作业中开发一个 Python UDF。在这个 UDF 中咱们会去实现 SLS 流式数据和 RDS 存量数据的拼接，同时在这个环节，咱们也会应用到后面提到的 Flink CDC 连接器来直线数据的增量读取。
接下来的环节，与咱们传统的算法链路中比拟统一，咱们会去开发一个 Python UDF 来实现数据的预处理和编码，失去日志模板。接下来的几个环节在咱们以往的链路中，其实是通过部署在机器上的 Python 脚本实现的。当初咱们也都把它们迁徙到了 Flink 作业中来，具体包含分词、特征选择、关键词的提取以及日志模板的向量化和标准化。目前这三个环节都还是通过 Python UDF 实现的，它所对应的 Flink ML 算子也正在紧锣密鼓的开发中，后续咱们也会把这几个环节都替换为对应的 Flink ML 算子。
在实现了特征向量的构建当前，接下来的一步，咱们调用的是 Flink ML 的算子来实现档次聚类。在失去聚类后果当前，咱们会去更新各个日志类别的代表性日志，也就是更新咱们各个聚类后果的聚类核心，并把新的数据写回到 RDS 中。这个时候 RDS 中数据的更新就会被咱们后面所提到的 Flink CDC 连接器感知到，从而实现数据的增量读取。
尽管咱们的整个 Flink ML 框架是针对日志聚类算法设计的，但其中的很多环节都是能够复用的。具体的来说，在数据的读取阶段，无论是从 SLS 中读取流式数据，还是从数据库中去读取存量的数据，咱们都能够应用 Flink 自身的一些算子进行复用。
在特色工程阶段，尽管咱们目前还应用 PythonPDF，但后续这一部分全都能够替换成对应的 Flink ML 算子。具体的来说，在分词和向量化阶段咱们能够应用 CountVectorizer 算子；应用 TF-IDF 算子进行特征选择；在特色标准化阶段，能够去调用 StandardScaler 算子。
接下来的环节，对于档次聚类，咱们目前调用的 Flink ML 算子也是齐全开源的，大家如果有相似的需要能够间接进行调用。同时 Flink ML 档次聚类算子还提供了十分多用户能够自定义的参数，比方用户能够批改向量之间间隔的计算形式等等。
此外，除了档次聚类算子以外，Flink ML 还提供了其余的一些聚类算法，比方 K-MEANS 等等。在这些算子参数中，有一个参数十分要害，它也是使 Flink ML 算子区别于其余像 Spark ML 算子的重要参数，那就是 Windows 窗口参数。
也正是因为窗口参数的存在，使得咱们在有限数据流上的实时聚类成为可能。所谓窗口参数，它就是把有限的数据流聚合成为比拟无限的 Mini-batch 模式的数据。
Flink ML 也提供了多种窗口策略可供选择，咱们能够依据零碎工夫进行窗口的计算，也能够依据记录的工夫进行窗口的计算，也能够依照理论流入的记录数进行窗口的计算。但无论咱们抉择哪一种窗口策略，窗口与窗口之间都是不会重叠的，这样咱们就能避免脏数据的生成。而窗口大小的设置大家则能够依据本人对于实时性的需要进行灵便的调节
到这里咱们就能够来总结一下，咱们应用 Flink ML 进行算法链路降级当前到底有哪些收益。为了更好的进行比照，咱们首先来看一下旧链路的架构。
在旧链路中，咱们会应用 Flink 作业从 SLS 中读取数据，并进行预处理和编码。预处理和编码之后的数据，咱们会写入到另外一个 SLS 中，新的 SLS 会存储咱们的日志原文，它对应的日志模板以及编码，还有一些原始日志中就蕴含的一些业务维度相干的信息。
在传统链路中，咱们的 Python 脚本会定期从中批量的获取新的数据，并且从 RDS 中获取之前的聚类后果，对这两局部数据进行合并，构建特色工程，实现聚类，并将后果写回到 RDS 中。而在旧链路中，咱们还有一个剖析的链路，即咱们通常须要去对 SLS 的数据和 RDS 的数据进行联结剖析。比方咱们可能须要去统计每一个日志类别所对应的底层的日志的数量，或者可能须要依据一段日志原文查问它所对应的日志类别是什么。
因为这两局部的数据是别离由 Flink 作业和 Python 脚本生成的，它们也别离存储在 SLS 和 RDS 中。而 SLS 的数据是流式的，咱们无奈对原有的数据进行批改，因而在分析阶段，咱们不得不对 SLS 和 RDS 进行频繁的联结查问，才可能失去最终的剖析后果，并且以 API 的形式提供给咱们的用户或者是内部的零碎。
那么通过 Flink ML 革新当前的新链路是什么样的？首先咱们能够看到，之前部署在机器上，定时进行调度的 Python 脚本曾经不见了。之前在 Python 脚本中执行的特色工程和聚类局部曾经齐全迁徙到了后面的 Flink 作业中。同时因为咱们的预处理，特色工程和聚类都在同一个 Flink 作业中进行，因而在后果的输入阶段，本来咱们只存储在 RDS 中的聚类后果，也能同时作为新的字段减少到 SLA 中进行写入。
这样在后续的剖析环节，就不再须要十分高频的对 SLS 和 RDS 进行联结查问，同时也升高了咱们的剖析老本。所以到这里咱们能够来总结一下，咱们应用 Flink ML 进行链路降级的收益。
首先从链路的整体延时来看，过来因为思考到 Python 脚本的性能，以及定时调度的问题，咱们总体的链路延时会在五分钟左右。而当初咱们基于 Flink ML 进行链路降级当前，整体的延时能够达到 30 秒。
此外，大家也能够从流程图中直观的看到，咱们进行了链路革新当前，整个流程变得简洁了很多，咱们不再须要独自保护 Flink 作业和 Python 脚本，只须要保障一个 Flink 作业的失常运行，因而在运维老本方面可能失去显著的升高。
此外，咱们方才也提到，基于新的链路，咱们不再须要高频的去对 SLS 和 RDS 进行联结剖析，因而咱们的剖析老本也失去了很大水平的升高。
最初，在算法自身的性能层面，之前的算法是部署在单机上的，它的性能无奈保障。而当初咱们把算法替换成了 Flink ML 的算子，因而它在性能层面能够失去更多的晋升和保障。
五、总结和开源打算
接下来让咱们简略的对明天的分享做一下回顾和总结。
咱们的分享从运维场景中三大外围问题，稳定性、老本、效率登程，并为大家介绍了这三个场景中十分典型的三种算法模型，别离是时序异样检测、时序预测、日志聚类，并且咱们通过理论的案例来给大家分享了，算法模型是如何在咱们的理论业务场景中施展效用的。
同时从这些理论的业务场景中，咱们也能够更加直观的感触到，机器学习模型对于实时性和性能层面都有着十分高的要求。而 Flink ML 所具备的个性刚好可能完满解决咱们的痛点，它具备实时性、流批一体、CDC 增量读取等 Flink 自身的个性。此外 Flink ML 自身还提供了十分易用的 API 和十分丰盛的机器学习基础设施。
在明天的分享中，咱们也以日志聚类算法为例，为大家解说了咱们整体的链路革新过程。并且从链路的延时、老本、性能层面给大家介绍了咱们的整体收益。
原文链接
本文为阿里云原创内容，未经容许不得转载。
