从 Flink Forward Asia 2021，看Flink未来开启新篇章

Posted 2022-02-12 阿里云云栖号

简介：本文将对FFA Keynote议题作一些简单的归纳总结，感兴趣的小伙伴们可以在FFA官网[2]找到相关主题视频观看直播回放。

作者 | 梅源（Yuan Mei）
来源 | 阿里技术公众号

律回春晖渐，万象始更新，这句诗用来形容2021年的大数据领域再合适不过，而Flink在2021年也开启了新的篇章。

2022年1月8-9号，Flink Forward Asia（FFA）线上峰会成功举行。Flink Forward Asia 是由 Apache 官方授权，Apache Flink中文社区主持举办的会议。目前，Flink Forward Asia 已成为国内最大的 Apache 顶级项目会议之一，是 Flink 开发者和使用者的年度盛会。在线上峰会的同时，FFA还举办了首届以实时计算为主题的Flink Hackathon，共有267支参赛队伍，最终27支队伍入围参与线下决赛。未来Flink Hackathon也会常态化举办，集思广益。

FFA大会从社区发展，业界影响力以及生态技术演进这三方面总结了Flink在过去一年的发展。社区方面，根据Apache软件基金会2021财年报告公布的各项核心指标，Flink已连续三年位列Apache社区最活跃的项目之一。而作为社区的最小原子，Flink的社区代码开发者（Contributor）已超过1400名，年增长率超过20%。其中尤其值得一提的是Flink中文社区的蓬勃发展：Flink的官方公众号订阅数超过5万人，全年推送超过140篇和Flink技术，生态以及行业实践相关的最新资讯。最近，Flink社区开通了Flink官方视频号，希望通过更加丰富新颖的形式从更多纬度让大家对Flink有更全面的了解。此外，Flink社区重构和改版了去年开通的Flink官方学习网站Flink Learning[1]，希望通过这个学习网站，汇总沉淀和Flink相关的学习资料，场景案例以及活动信息，使Flink Learning真正成为大家学习研究探索Flink的好帮手。

业界影响力方面，Flink已成为业界实时计算的事实标准。越来越多的公司不仅使用Flink，也积极参与Flink的发展与建设，共同完善Flink。目前，Flink的代码开发者来自全球超过100+公司。去年举办的4场的线下meet up，阿里巴巴、字节跳动，携程和360都提供了大力支持。而今年FFA大会有来自互联网，金融，能源，制造业，电信等各个行业的40+知名公司共83个主题演讲。从生态技术演进来看，Flink在云原生，高可用性，流批一体和AI四个主打方向上都取得了不错的成绩。特别值得一提的是Flink新推出了流批一体的进阶版，流式数仓（Streaming Warehouse）这个概念，实现流批实时分析一体化，真正意义上完成流批一体计算和流批一体存储的融合，让整个数仓的数据流动起来。流式数仓将是Flink未来最重要的方向之一，在Flink社区也会同步推广。

本文将对FFA Keynote议题作一些简单的归纳总结，感兴趣的小伙伴们可以在FFA官网[2]找到相关主题视频观看直播回放。

一 主会场议题

在主议题之前，阿里巴巴集团副总裁，阿里巴巴开源技术委员会负责人，阿里云智能计算平台负责人贾扬清老师作为开场嘉宾，分享了他对开源在云计算的大背景下的思考：开源，无论是从技术贡献还是生态发展来看，已从最初的替代和补充逐步发展成为创新和引领的角色。阿里巴巴到目前为止已经开源了2700多个项目，是国内互联网技术企业中的先锋。而Flink作为阿里巴巴最具影响力的开源项目之一，无论是在技术先进性还是生态丰富性上都无可争议。不仅如此，阿里巴巴在过去几年中积极拓展Flink的适用场景，通过自身大规模业务打磨迭代开源技术，进而将这些技术回馈Flink社区，并携手其他开源项目形成更全面的联合解决方案，真正做到了开源开放，持续回馈，加速普及。

下面来重点聊一聊几个主议题。

1 Flink Next –– Beyond Stream Processing

主议题照例由Apache Flink中文社区发起人，阿里巴巴开源大数据平台负责人王峰（花名莫问）老师开启，主要介绍 Flink 社区在 2021 年取得的成果以及未来的发展方向，包括云原生，Flink容错，流批一体和机器学习四个部分。

云原生 –– 部署架构演进

Flink部署的三种模式

说起开源大数据的发展，绕不开云原生，两者相依相生相辅相成。作为开源大数据的引擎课代表Flink的部署模式是如何在云原生大背景下演进的是个很有趣的话题。Flink最早的部署模式是经典的静态（Static）Standalone模式，这里的静态是指用户必须根据业务估算预留资源，资源少了作业就跑不起来，所以大部分情况下需要按最大资源量来预留。显而易见这种模式对于用户来说既复杂资源利用率也不高。第二种模式我们称为主动（Active）模式，这里的主动是指Flink会根据业务资源的使用情况主动的去向底层Kubernetes或者Yarn申请和释放资源。这种模式需要Flink和底层Kubernetes或者Yarn深度集成，适用于需要对资源深度把控的用户，对中小用户来讲太过复杂。这就引出了第三种模式我们称为适应性（Adaptive/Reactive）模式。在这种模式下，Flink可以像云上其他应用一样根据所给的资源（增加或减少资源pod），通过改变自身拓扑结构来动态调整运行。从用户的角度来看，他并不需要了解资源是如何分配的，所以第三种模式对于用户的门槛相对较低。

还有一个值得思考的问题是云原生到底给Flink带来了什么，除了弹性资源管理，数据多备份，自适应运维管理，标准化的工具和操作，笔者觉得更重要的是降低用户的使用门槛，用更小的成本给用户提供更简单，稳定和丰富的使用体验。

Flink容错 –– 稳定快速的Checkpoint

和Checkpointing相关的讨论几乎贯穿了Flink的整个发展历程，它是整个Flink容错架构的核心。Flink会定期给所有的算子状态做快照检查点（Checkpoint），如果Flink作业失败，作业会从上一个完整的Checkpoint恢复。在实际工作中，我们发现引擎这一层很大部分的Oncall的问题都跟做Checkpoint相关，所以如何能够高频稳定的完成Checkpoint是提升Flink高可用性（容错）的重点。造成做Checkpoint失败（超时）的主要原因来自两方面：一是中间数据流动缓慢造成Checkpoint Barrier流动缓慢，二是算子状态过大造成状态数据上传超时。Flink针对这两个方面都有重点项目在跟进：Buffer Debloating和Generalized Log-Based Checkpoint。

Buffer Debloating是在不影响吞吐和延迟的前提下缩减上下游需要缓存的数据到刚好算子不空转，目前Buffer Debloating默认上游会动态缓存下游1秒钟能处理的数据（这个时间是可以配置的）。Buffer Debloating在Flink-1.14版本已经发布。Generalized Log-Based Checkpoint是一种基于log打点的方式来做Checkpoint的方法，类似传统DB的write ahead log，好处是能快速，高频且稳定的做Checkpoint，代价是需要额外多写/存一份log。我们知道Flink做Checkpoint由同步和异步两个过程组成，同步的过程通常很快，主要的耗时在异步上传状态文件这个过程中。Generalized Log-Based Checkpoint的原理就是将Checkpointing这个过程和耗时的异步上传文件这个过程剥离开，也同时和底层状态存储的物化过程解耦。Generalized Log-Based Checkpoint预计会在Flink-1.15版本发布。

分论坛核心技术专场talk“Flink新一代流计算和容错（Flink Fault Tolerance 2.0）”对这个部分有更为详细的阐述，感兴趣的同学可以找来看看。

流批一体 –– 架构演进和落地

流批一体是近些年Flink一直在力推的创新性理念，从最早提出这个理念到当前被广泛接受，莫问老师分享了流批一体在Flink的系统架构各个层面演进的过程及其落地场景，如下图所示。

1）架构演进

API层面，去年流批统一的SQL/Table API（Declarative API）首次在阿里巴巴双十一最核心的天猫营销活动分析大屏场景中落地[3]，今年更近一步，完成了Imperative API的整合，形成流批统一的DataStream API，而陈旧的DataSet API将逐步被淘汰。架构层面，同一个作业可以同时处理有限数据集和无限数据集；并且connector框架可以同时对接流式存储和批式存储，做到一套代码可以处理两套数据源。运行层面，一套调度框架可以同时适用于流和批的作业；流批shuffle是pluggable的，复用一套shuffle接口。阿里巴巴实时计算团队在今年开源了存算分离的Remote Shuffle Service[4]，放在Flink开源项目的Flink-extended这个子项目组里面。Flink-extended[5]里面包含很多其他Flink生态项目，有兴趣的同学可以去看一看。

继去年在天猫双十一核心大屏业务上线后，流批一体今年逐步在阿里巴巴更多核心业务上推广。除了阿里巴巴，有越来越多的公司认可流批一体这个理念。今年FFA有个专门的流批一体分论坛，由字节跳动，美团，京东以及小米等公司分享流批一体在其业务中的实践。此外在核心技术专场中有专门针对流批一体架构演进的专场talk“面向流批一体的 Flink Runtime 新进展”，对这个话题感兴趣的同学可以了解一下。对新版connector框架原理感兴趣的同学可以参考核心技术专场中的“Flink Connector社区新动向与Hybrid Source原理实践”。

2）场景落地

莫问老师指出，流批一体这一技术理念落地需要具体的场景支撑来体现其真正价值，基于此，他分享了流批一体最为典型的两个应用场景。

场景1 Flink CDC：全增量一体化数据集成

在传统的数据集成中，离线和实时数据集成是两套不同的技术栈，需要全量和增量定时合并，时效性也比较差。Flink的流批一体能力结合Flink CDC的能力可以实现一体化数据集成：先全量的同步完历史数据后自动接到断点，实时的续传增量数据，实现一站式数据同步（读取数据库全量数据后自动切换，通过binlog增量同步）。这里的自动切换的实现基于新版流批一体Source框架。

Flink CDC目前已可以支持大部分主流数据库包括mysql、Postgres、Oracle、MongoDB、MariaDB，其他的如TiDB，DB2，SQL Server也在积极开发中。对Flink CDC如何能够实现一站式数据集成感兴趣的同学可以参考分论坛实时数据湖专场中的talk“Flink CDC 如何简化实时数据入湖入仓”。

场景2 Streaming Warehouse：流式数仓

前面提到，今年的一大亮点是莫问老师提出的流式数仓（Streaming Warehouse）这个概念，这个概念提出的大背景是为了解决实时离线数仓一体化的问题。

实时离线数仓一体化这个问题目前比较常用的解决方案是用实时和离线两条链路来实现：1）实时流处理链路（Flink + Kafka）对数据进行分层ODS，DWD，DWS，并实时写入在线服务层，提供在线服务（实时OLAP）；2）同时会有一条离线链路定期对实时数据进行补充和历史修正。这里除了常见的流批不统一带来的开发效率，维护成本，流批口径不统一等问题以外，其实还有一个更隐蔽同时也更难解决的问题：为了保证实时性，实时链路中的ODS，DWD，DWS这些分层数据是存在消息队列（比如Kafka）中的，但是消息队列中的数据是没办法有效进行实时分析的，如果引入其他的OLAP系统会增加系统复杂度同时也不能保证数据一致性。

为了解决消息队列无法有效率的进行实时分析的问题，Flink引入了Dynamic Table动态表来存放实时链路产生的分层数据，如上图所示。这样一来，Flink可以通过Flink SQL的流批一体能力实时的串联起整个分层数仓；通过Flink SQL对Dynamic Table的OLAP查询提供实时分析的能力。我们可以把这个理解成流批一体的进阶版本流批实时分析一体化，也就是莫问老师这里提出的流式数仓（StreamHouse = Streaming + Warehouse）这个概念，真正做到在一套方法论的大框架下实现一套API，一套计算，一套中间存储的全链路一体化。

Dynamic Table（动态表）不同于一般意义上的Source和Sink，是Flink的内置表。之所以称为动态表是因为此表具有流表二象性。流表二象性通过列存LSM Tree和Log两种不同的存储形式来支持，分别对应于Flink SQL的批（全量分析）和流（增量处理）两种模式。Dynamic Table通过Flink自身的Checkpointing一致性语义机制保证流表二象性在两种存储形式下的一致性语义。这里需要特别注意的是，流表二象存储的数据一致性问题是混拼系统（引入其他OLAP和消息队列）无法轻易规避和解决的问题（因为中间涉及多系统间的一致性读写同步），这也是Flink Dynamic Table区别于其他类似系统的核心竞争力之一。如果大家对动态表的实现感兴趣的话可以看一看流批一体分论坛中“基于Flink Dynamic Table构建流批一体数仓”这个talk，里面有对Dynamic Table更详细的介绍。

这个部分的最后有一个流式数仓的demo，用上述一体化的方法论展示了流作业在实时OLAP分析发现业务逻辑有错后，如何批式做订正并实时支持OLAP查询更正的一个流批实时分析一体化的典型场景，还是很受启发的，大家可以看一看。想对流式数仓有更详细了解的同学可以参考莫问老师关于流式数仓的专访[6]。

机器学习 –– Apache Flink ML 2.0 全新架构

机器学习作为Apache Flink的另一大重要场景，在今年Flink流批一体API和架构进一步完善的基础上，基于流批一体DataStream API完成重构，全面升级到Flink ML 2.0。Flink ML最大的特点是实时离线一体化，以及与之相配套的实时离线一体化管理调度（Flink AI Flow）和执行。在Flink ML 2.0中有几个新的亮点是值得看一看的：1）Flink基于DataStream在引擎部分原生的支持全新的迭代计算框架，支持更灵活的分布式同步和异步迭代；2）发布了一套新版Flink ML pipeline API，遵循机器学习用户更熟悉Scikit-Learn风格（Transformer，Estimator，Model）；3）支持一体化的深度学习集成，Flink ML Estimator可以将Pytorch和Tensorflow拉起；4）流批一体能力使得Flink ML 2.0可以同时对接流和批的数据集。

Flink ML 2.0目前已经由阿里巴巴实时计算团队和机器学习团队共同完成，贡献给Flink社区，成为Flink的一个子项目Flink-ML[7]。值得一提的是除了阿里巴巴，现在还有很多其他公司也在共同建设Flink ML的生态，比如360贡献了Clink[8]。核心技术专场中“为实时机器学习设计的算法接口与迭代引擎”这个talk详细介绍了Flink ML 2.0的架构演进，此外今年FFA还有一个机器学习专场，感兴趣的同学可以看一看。

PyFlink方面，Flink对AI的主流开发语言Python的支持更加完备：PyFlink在功能上完全追平了Table API 和Data Stream API的能力，在性能上创新性的通过JNI调用C，再在C里面调用Python解析器的方法消除了Python UDF和Java跨进程通信，使得Python UDF性能接近Java UDF，兼顾开发和运行的效率。分论坛核心技术专场“基于 FFI 的 PyFlink 下一代 Python 运行时介绍”有对这部分更详细的解释。

二 实时计算在字节跳动的发展与展望

主议题第二场由字节跳动计算基础架构负责人师锐老师带来。字节跳动的产品业务场景主要都是以实时信息流推荐为主，因此以Flink为支撑的实时计算广泛应用在字节跳动的各个产品中。字节跳动旗下全线产品总MAU目前已超过19亿，由于其业务特性，其数据量（EB级别，1EB = 2^60 Bytes）和实时推荐的请求量（百万QPS）都是巨大的。我们可以看到在师锐老师分享的字节跳动引擎资源使用的对比图中，Flink和Spark基本持平，这在一般的公司是不太常见的，从这个方面也可以看出字节跳动整个业务线对以Flink为基础的流计算的依赖。

字节跳动主要计算引擎资源对比图

字节跳动从2017年开始调研并逐步使用Flink流式计算，到2019年初，所有流式作业已完成从JStorm到Flink的迁移。2019年开始，随着Flink SQL和Flink批式计算的成熟，Flink Batch也在字节跳动数据同步等场景相继落地，现在每天大约有10w+ Flink Batch作业运行。师锐老师特别提到，从去年开始，流批一体也逐步在字节跳动公司内部推广应用，感兴趣的小伙伴可以参考流批一体分论坛专场中的talk“流批一体在字节跳动特征平台的实践”。目前字节跳动全球Flink流式作业达到4w个，其中SQL作业占30%，使用的CPU核数超过400万核，晚高峰Flink作业处理消息的QPS达到90亿，Checkpoint高峰流量吞吐达到600GB/s，还是很惊人的！

Flink在字节跳动发展图

在字节跳动的分享中，基于存算分离架构的流批一体消息队列BMQ值得提一提（BMQ目前承接了字节90%的消息队列流量）。在BMQ之前，字节使用Kafka作为消息队列，集群升级扩缩容需要大量拷贝数据，所以完成一个集群的升级差不多需要一周的时间。为了解决这个问题，字节团队基于存算分离的架构重新设计实现了消息队列，BMQ。在BMQ的架构之下，数据存放在分布式文件系统HDFS中，Meta存放在K-V存储中。由于BMQ的计算层Proxy无状态所以非常容易做扩缩容，迁移时间可在分钟级完成。另一方面，BMQ可以同时提供Stream API和Batch API，所以可以同时支持流和批的消费，实现存储层的流批一体。有些小伙伴可能有疑问，这和上面提到的动态表（Dynamic Table）一样吗？笔者觉得还是很不一样的，因为要解决的问题不一样：动态表要解决流批实时分析一体化的问题，所以它的流批存储格式是完全不一样的（为了分别加速流处理和批查询）；而BMQ所有数据只写一份在HDFS上，主要还是为支持高效的大规模消息传输和读写服务的。

师锐老师提到他们下一步计划是推进Flink OLAP的落地。他指出，Flink拥有丰富的connector生态可以实现跨数据源查询，Flink OLAP能力在字节内部测试过可以媲美Presto，甚至在有些情况下更优，现在有关Flink OLAP的改进和优化也在积极推进Flink社区中。本次FFA字节跳动有7个分会场talk，从核心技术提升到行业实践涵盖了方方面面，对Flink在字节跳动内部如何演进使用感兴趣的同学可以去看看。

三 工商银行实时大数据平台建设历程及展望

主议题第三场由中国工商银行大数据平台负责人袁一老师带来，他从金融行业的视角分享了有关工行实时大数据平台建设的历程和思路。

首先我们来看一张描述工行数据流向的示意图，如上图所示。应用产生的数据会写入到MySQL或Oracle等关系型数据库，之后将数据库产生的日志复制到Kafka消息队列中作为实时处理平台的数据源。实时处理平台有三个数据出口，一是通过Flink实时ETL可以实现实时数据入湖；二是将Flink的结果输出到HBase或者ES等联机数据库中提供面向应用的数据中台服务，三是通过Presto或CK等分析型引擎，提供面向分析师的BI分析能力。工行内部的高时效业务场景，基本上都可以包含在这条链路体系之中。

聪明的小伙伴们可能已经发现了，上面这条复杂数据链路和Flink流式数仓（Streaming Warehouse）场景几乎一摸一样。但是通过Flink的流式数仓，我们可以把工行的这条中间贯穿很多系统和组件的链路简化成Flink单链路，通过Flink的动态表（Dynamic Table）提供的流批实时分析一体化的能力来完成实时入湖，实时数据服务和实时分析！

另一个比较有趣的点是金融行业的数据中台在设计的时候会特别考虑数据私密和安全的问题。他们采用的方法有以下几种：1）采用全生命周期的数据监控审计，用于数据访问的审计和追溯；2）在数据发生移动的时候给数据本身加水印可以方便溯源；3）通过SQL实现自然人级别的动态数据访问权限控制；4）通过专家规则和Machine Learning来自动识别海量数据中的敏感数据。这些思想和方法在数据安全，数据私密越来越受重视的今天很有借鉴意义。袁一老师还详细分享了很多和金融行业相关的业务场景，相信会对业务场景感兴趣的同学有所启发。

四 Deconstructing Stream Storage

主议题的最后一场由Pravega中国社区创始人，戴尔科技集团OSA软件开发总监滕昱老师压轴：解构流存储。

Pravega是提供流批统一能力的开源分布式流存储，有如下特点：1）相同键值下可以保证数据有序；2）可以根据数据流量动态扩缩存储单元；3）支持事务性写入；4）支持Checkpointing和一致性读写；5）分层存储设计。所有的这些特性都封装在Stream抽象的设计理念之下，也给流式计算屏蔽了很多流存储端的复杂性。在这次分享中，滕昱老师着重介绍了Pravega的分层存储架构（Tiered Storage）：其底层是一个基于分布式文件/对象存储的持久性主存储，中间是基于内存的全局Cache层，最上层是分布式Log抽象层。滕昱老师还同时分享了Pravega的分层存储架构与Kafka和Pulsar这两个消息系统在架构上的区别以及对性能的影响，感兴趣的同学可以去详细了解一下。

在Pravega的分享中有几个比较有趣的点：

一是Pravega针对现在比较火热的物联网边缘计算的定制优化。比如Pravega针对多客户端的两阶段数据聚合，在Writer进行第一阶段聚合，在Segment Store进行第二阶段聚合，极大的提高了吞吐量。这种数据聚合优化非常适用于有大量客户端但每个客户端产生的数据量比较小的情况，而这就是物联网的典型特点。

二是Pravega和Flink联动的端到端的auto-scaling。弹性扩缩容是云原生大背景下非常重要的问题，前面提到Pravega的一大特点就是可以自动扩缩容，调整Segment数目，而这个数目可以很好的作为Flink Reactive Scaling的指标，两者相结合后可以做到从计算到存储端到端的auto-scaling，目前这项工作已在两边社区合作规划中。滕昱老师的分享中还有一个Demo展示了Pravega和Flink联动scaling的效果。

滕昱老师表示未来存储和计算，流和表的界限逐渐模糊，Pravega流批一体的存储设计也暗合了Flink未来很重要的一个发展方向。Pravega社区会积极与包括Flink在内的数据湖仓相关的开源社区通力合作，构建解决方案。今年Pravega和Flink社区共同发布了白皮书，未来也期望和Flink社区有更多合作，将Flink计算推向数据的产生端，通过Pravega能实现数据从端到云的流动。

五 圆桌会议

今年FFA主会场新增加了一个环节圆桌会议（分北京和上海两场），邀请了业界来自阿里巴巴，字节跳动，美团，快手，小米，工商银行，戴尔科技集团和小红书在内的多位大数据专家负责人，共同探讨Flink以及实时计算的未来。各位大佬友好真诚并且很接地气讨论了很多大家都比较关心的问题，由于篇幅关系，这里仅列出了讨论的部分相关话题，大家可以找视频感受一下：

• 如何看待Flink在实时计算方面已趋于成熟这个话题，目前大家都用实时计算做什么？
• 实时计算的未来是怎样的（技术和业务层面）？基于此，Flink需要探索哪些新的领域，解决哪些关键问题？
• 有人认为实时计算的门槛和代价比较高，相对偏小众；也有很多人认为实时计算是未来的方向，大数据和 AI 都会向实时化方向演进；大家怎么看这个问题？
• Flink在整个开源大数据生态中应该如何定位，如何保持差异化？
• 如何看待公司内部技术实践，技术创新与开源社区之间的关系，大家使用和回馈社区的策略又是什么？
• 使用和贡献开源项目有哪些优势？公司内部在做Flink哪方面的探索？过程中又遇到过哪些挑战？
• Flink在内部使用的未来规划，以及接下来有哪些打算贡献社区的创新技术？
• 如何看待 Flink 与生态项目之间的（合作、竞争）关系？
• 什么样的开源社区是对大家有帮助的开源社区？同时又是一个可持续发展的社区？

六 总结和感想

过去的2021年是大数据领域的风口年，对于Apache Flink，实时计算的领跑者，能否抓住这个风口也是很关键的一年。在Flink SQL趋于成熟，流批一体在业内逐步被接受落地的当口，我们需要思考未来Flink何去何从，这也是我们正在做的事情。在此基础上，Flink推出了流批一体的进阶版，流式数仓（Streaming Warehouse）这个概念，希望能实现流批实时分析一体化，真正意义上完成流批一体计算和流批一体存储的融合，做到在一套方法论的大框架下实现一套API，一套计算，一套中间存储的全链路一体化。流式数仓将是Flink未来最重要的方向，道阻且长，行则将至，行而不辍，未来可期！

[1] Flink官方学习网站Flink Learning（Flink 中文社区 | 中文学习教程）

[2] Flink Forward 峰会 - Flink Forward Asia 2021

[3]40亿条/秒！Flink流批一体在阿里双11首次落地的背后

[4]Remote Shuffle Service（https://github.com/flink-extended/flink-remote-shuffle）

[5]Flink-extended（flink-extended · GitHub）

[6] Apache Flink不止于计算，数仓架构或兴起新一轮变革（https://c.tb.cn/F3.0OfNLU）

[7]Flink-ML（https://github.com/apache/flink-ml）

[8]Clink（https://github.com/flink-extended/clink）

原文链接

本文为阿里云原创内容，未经允许不得转载。