《原动力 x 云原生正发声 降本增效大讲堂》第二讲——《Kubernetes 云上资源的分析与优化》原创

各位网友大家好，欢迎观看原动力云原生正发生降本增效大讲堂系列基础直播。今天是该大讲堂的第一期第二讲直播主题是cos云上资源的分析与优化。在7月7日晚上八点会进行第三讲，欢迎大家预约观看。原动力云原生正发生降本增效大讲堂是由中国信通院、腾讯云V药产业标准工作组联合策划，目的是与开发者一同交流提升资源利用率、降本增效的方法与优秀实践。本期我们请到了腾讯云容器技术专家胡启明老师，胡启明老师是开源项目grand方和负责人。今天会为我们分析一下Co上为什么存在着资源的浪费，以及如何在保证业务正常运行的情况中去优化资源利用率，实现降本增效。我们有请胡老师。

大家好，我是胡启明，我自器担技术专家。我是开源项目founder和负责人。专注于kinetics原生领域八年左右。那么在近一年的时间，我主要关注于基于降本增效。在开源领域，我也是ines等项目的tributor。今天很高兴参与降本这样的一个活动。好，那我们现在正式开始。今天我们分享的主题是cuinetic云上资源的分析与优化。啊，这是我的个人简介。啊，今天的分享主要分为三个部分。第一个部分呢，我们会介绍资源。啊，以及我们在使用这样的一个资源管理模型的时候遇到的一些问题。

啊，第二个部分呢，我们会介绍的弹性伸缩能力与V。使用弹力。啊，第三个部分呢，我们会介绍基于我们的开源项目crane来去做coineinetic的资源分析与优化。怎么样去解决上面提到的啊，资源管理的问题和弹性伸缩的问题。好，首先我们看一下的资源管理模型。啊，就是。这个相当于相对大家来讲可能是比较熟悉的啊。啊。那么也要明最大可以使用的一个量，那么就是的。我的调度。

那么这样的一个request模型，用户去设置的时候，常常会发现一个问题啊，因为用户的开发者，或者说上线的这个应用的S，他不一定对这个业务的真正线上运行的一个情况。呃，会完全的感知啊，比如说他并不知道这个业务真正在线上运行的时候，需要的一个CPU是多少是多少。那么他也不一定能够判断出来，呃，这个业务上线之后，我们面对的这个业务的场景下，它的资源使用量会上涨到哪一个维度。所以。因此我们的。业务开发或者说运维再去配置，这样子的时候就选择比较保守的策略。我们常常会把这样的一个配置啊设的偏高。啊，那么这样带来的一个问题就是我们。的一个资源浪费就会比较明显，比较显著啊，大家可以看一下。

啊，这里我们这个应用它的一个。Request。四个啊，但是呢，它这个应用实际的使用啊，在这段时间之内，绝大部分间没有超过两个。那么中间就带来了一定的资源浪费。啊，这就是我们啊，因为过于保守，或者说呃，对于这个业务运行情况不了解啊，那么所以呃出现的一个问题。那我们再看第二个场景啊，大家可以大家都知道啊，我们的CP是一个压缩资源。那么压缩的C，我们达。这样这时候就会导致我们应用去处理啊，我们的这个程序的时候，它就会变慢啊，但是呢，如果你这样的一个业务是一个对于延时不敏感的业务，这时候他其实他不一定能够感知的非常的明显。

啊，这就是叫可压缩资源。啊，但是呢，内存这个资源它是不可压缩资源，那么如果我们的。业务在使用的内存的时候超过了这个机器的上限，这时候会发生什么事呢？啊，比如说这里我们有个例子。这个，那么它在呃晚上的时候，它的一个业务的使用量就会降低啊，那么在白天高峰期的时候，它的一个业务量呢，就会偏高。那么它的一个注意规律呢，也是比较相似的啊，可能因为可能是比较相似的业务同时布在了同一个节点上。啊，那么。在业的高峰期啊，这个容器的一个存的量就有可能会达到它的一个值，它的一个上限。

那么但是呢，由于我们去调度这样的一个应用的时候，是根据它的request去调度的。那么就会导致业务的高峰期，有可能这个节点上的这个内存就会被耗。啊，那么在资源被耗尽的时候会发生什么事呢？啊，这里我们有一条规则，大家可以看一下。如果节点耗时逐。这个驱逐的规则呢，排序规则呢，是根据容器实际的内存使用超出request量来去排序。所以说我们这时候会去驱逐一个它的用量大request的这样的一个。那么这时候业务就会发现一个损伤，因为它的容器被kill。啊，并且呢，这时候往往是处在一个高峰期。那么业务就受到了损伤。那么再看另外一个场景啊。

内存的这样的一个上，如果容器内所有的进程分配内存超过它的一个内存。啊，那么这就是场景个然刷的就报错了，那么这是因为这样的一个特性，所以就也导致了呃，应用的开发者或者S来去配置这个应用。资源的时候，往往会采取更保守的策略啊，因为这个呃，业务的稳定性永远是第一要素，我们要保证它的一个稳定性和正确性。那么呃，在某些场景下，这个资源的浪费是可以被容，那么这也就更加了我们云上资源的一个浪费情况。啊，大家可以看一下啊，这是我们啊对于云上资源的一个常见的现状啊，就是我们的业务，当我们上到netic啊，云原生容器平台啊，这样的一些高大上的一些词的。

这样的一些平台之后呢。往往发现它的资源的用量和使用率会偏低啊，上面一张图呢，是可以看到我们这个资金中。资源。很大。啊，但是呢，实际使用量呢，嗯，却在很低的地方徘徊抖动，中间有很大的一个浪费。那么资源的一个分配率呢？啊，我们就可以算出来，其实在我们这个集群中，它的一个资源利用率的峰值。不会超过15%啊，均值。也不会超过10%。啊，那么就带来了大量的资源的一个使用浪费。那么这个其实也是非常常见的一个现象。不光是在内啊，外部的很多公司啊，也是遇到这样的一个问题。第二部分呢，我们来介绍一下伸缩。我们。

呢，它的一个中文就是一个水的D的自动弹缩器。啊，可以看到我们。加balance啊，通过入口请求到我们的一个工作负载，就是一个deploy啊，那么这个deploy里面呢，它有几个D。啊，那么我们为了让这样的一个deployment加pod，在用户流量呃增大的时候能够自动的扩容。然后在流的一。啊，那么我们的hpa，它会去让用户设置一个最小的副本啊和一个最大的本数，并且让设用户设一个呃，目标的一个CPU使用率。

比如说40%，50%这样的一个目标使用率，我们根据这样的一个目标使用率，在这个最小副本和最大副本之间自动的去做弹性的伸缩。啊，那么在社区也是发展了很久了啊，大概有三到四年左右，那么版本呢，也是从一延伸到V2啊，前段时间刚刚也是V2版本已经G了。那么它的功能呢，也相对比较完善。比如提供了metrics exnal metrics这样的一个部，让用户通过部监控来去业弹性，比如说我们用的最常见的基于普罗米修斯的adapt啊，让用户基于普罗米修斯的marix。自动做弹性。啊，那么社区有一个开源产品叫柯达啊，他专注于通过的方式来去让业务弹性。

的本质呢，它也是使用了基卡M。呃，数据的一个来去做一个弹性的输入。通过external max的方式让做水平弹性。就是我的这个业务流量的红峰来临的时候，那么我的一个啊指标它才会上升，比如说我的MQ啊，它的它的它会提升啊，它的那个数量会增加，我的CPU的用量会提升。啊，但是呢。如果你这个资源红峰已经来了，这时候我再去扩的时候，常常会发现。扩容是来不及的啊，面是追谈是方面原因，另外面因是我们的业，我们的容器业务不一定动的速度能赶上这个流量来的速度。

比如说我们很多的业务，它的一个启动时间。我去创建这个pod。载十分钟、20分钟甚至更长时间。来个分容器。这个就已经前业垮。那么这是一个比较大的问题啊，就是由于动慢。导致了很多的业务没有办法去使用。我们的。

或者说我们的实时的matrix一定会有抖动的。啊，比如说这里，我们这里有一个一个声V啊深V的话，那么它是一个流量的一个抖动，那在这个时间点，如果我们使用H，那么就会导致我们的一个副本会有一个剧烈的抖动。那这里可能有一些啊。朋友就说了，诶，那HP里面有一个功能叫behavior对吧。那我们通过设置behavior确实是可以。去减少这样的一个抖动性问题。但是呢，当你调大这个behavior来去减少抖动的同时，你的一个HP的弹性也会变得迟钝，那么也会导致你这个弹性的效果就没有那么的理想。啊，所以说这个behavior可以解决一部分的问题。啊，但是呢，并没有解决最根本的问题，下面呢，我们来介绍一下VPA。VPA呢，它是一个垂直的一个pod的弹性伸缩。

那么他采取的一个工作流呢，啊，很简单。就是我们首先去观测这个pod的啊，它的一个资源指标CPU。啊，并且呢，我们通过我们的VPA的算法来去推荐一个它比较合理的一个资源配置。那么最后呢，再讲这样的一个资源配置，更新到这样的一个应用上去，我们整个这个VP就是这一个，呃，工作流的一个不断的一个循环的执行。那么这里可以看到更新资源，这里我们打了一个。Experimental就是它是一个啊，实验性的，为什么呢？是因为在cuine中，它是不允许我们去把pod的资源进行一个直接更新的。当我们把这个的资源更新之后。它必须要对这个po进行重建啊，因为我们讲究叫imutable infrastructure啊。

那么。这样的一套VPA，我们它是它是由去的这样的一个VPA的组。那么Google呢，它内部有一个啊能力叫做auto。啊，那么autot是然后把的autot了，一个开源，就成为了我们社区的个V。那么autot的集群管理的整个里面的集群使用量48%以上，所以说内部已经大规模啊去使用了这样子的一个啊，垂直弹性伸缩的能力。啊，并且这个数据呢，是谷歌当年在发布的一篇auto的论文的时候的一个数据，那么呃，现在的数据有可能它的一个呃占有率会更高啊，下面呢，我们来看一下这个VPA，它详细的一个工作原理，以及呢它的一个局限性。

啊，首先我们用户会去创建一个VP的对象。那么这样的一个对象呢？我们会有一个VPA的一个recommend，它的一个推荐器。啊，它会呃，定期的去获取这个VP对象里面的弹性配置。那么同时呢？那么它会根据这两个信息计算出来啊，通过它的一个VP的算法，我们把它叫做的一个算法来去计算出来你的这个。啊，更新到这个VP对象上去。那么我们还有一个组件叫做VPA的。他会去获取这样的一个弹性配置。会去对这样的一些做E。

它会自动的再去创建一个新的来替代它。那么这这样一个新的pod的创建请求就会被v PA admission plug给拦截。那么拦截之后呢，会把这个V。这样新建的pod就会使用我们VP推荐的那个资源配置来去创建。那么这个就是VP的一个工作原理。啊，这是为什么呢？啊，因为呃VPA它的一个最关键点。业务很难接受，我们通过VP随时的去重建。这个其实很好理解。我们的业务。

市想正在去接收一个一个实时用户的一个一个数据的一个处理，这时候突然把这重建。那么用户的一个使用就会。那如果我是一个，呃。我正。跑到一半的时候，突然这个被重建了，那这时候。我的这个计算必须要重来，那也会浪费很多的时间。啊，因为我们这样的一个重建，它其实是没有办法知这个业务的一个连续性的啊，那么并且它重建一定会对当前的一个业务的。业务的一个使用受到一个影响。那么这就导致了我们是很多时候很难去在环境去使用。啊，第部分我们会介绍我们怎么样去使用，来去解决前面提到的这样的一些问题。啊，首先介绍一下。它的一个英文的一个全称呢，就是cloud resource a，云上资源的分析。

和降本。它是，呃，我们团队去开源的一个。基于的降本的开源项目。啊，也是欢迎大家去了解这个项目，也是我们也是非常活跃的一个开源社区，也欢迎大家一起参与。啊，那么呢，它是基于一个的理论。来去啊，编排设计它的一个能力模型的。比如说这里我们能力模型分五层。最底下的一层是一个成本的一个。啊，比如说我们做多维度的业务成本分摊表啊，标签管理分期账单。啊，那么第四层呢，是一个，呃，对于资源利用率的一个报表。异常的识别资源浪费。那么第三层呢，我们会支持一些趋势和变化分内的一些评比。

那么层呢，是一个资。比如说我们提供了资源回收再分配的能力啊。request推荐的能。预测的智能弹性能力，包括机型的推荐能力。优化的工具和手段来帮助用户去做这样的账本。下面呢，我们来介绍一下啊中的一些能力，详细介绍。呃，比如说我们第一个能力呢，是叫云上资源的分析与优化能力。在CU上有一个重要的概念叫做。Infrastructure as code啊，Co实践是啊，非常的到位。我们所有的资，我们都是们service g。

那么它都可以用通过一段的配置来去声明。那么我们的一个可提供了一套分析推荐的插件能力。它有很多的分析推荐的插件来去分析这个carbonine中的云资源。那么同时呢，我们它的一个输入一方面呢，是这个云资源。另外一方面呢，是这个中的观测数据。那么云资源加上观测数据，加上我们提供的一个分析算法。那么这三者啊，作为一个输入，再加上我们的一个资源图。我们的分析推荐的一个插件，比如说我们这里提供了资源推荐的插件啊，副本数推荐的插件，那么我们就能够在这个插件内啊计算，并且给用户去推荐一个优化的一个建议。

比如说我们这里提供了。资源推荐的插件，那么它就会根据你这样的一个应用的配置啊，再根据你应用的实际的使用量。那么再根据我们的推荐的一个算法得到你。呃，建议的一个资源的CPU和memory的一个配置的。那么有这样的这个分析结果之后，我们有一些工具包，比如说我们的QCL的插件。有我们的资源化的一个报告的，能够把这样的一个分析汇。给用户，让用户呢，能够观测到通过我们的分析优化啊，能够达到呃，多少的优化的结果。那么优化的结果我们可以通过我们A。来去计算，在云端你这样的一个优化能够给你带来多少费用的省，那么这样的一个分析结果就能够帮助你在上做一个成本的决策，你是否要去采纳这样的更新结果给你带来多大的收益。

啊，这就是我们的云上资源的分析与优化系统。优系统。不但提供。啊，定的frame。来去自定义你的一个分析和推荐的一个逻辑。啊，下面呢，我们会详细的介绍这一套分析和推荐系统中的两个功能。这两个功能呢，目前也是已经大规模实现并落地的一个能力。首先呢，是资源推荐的能力。业务的诉求呢，是让应用应用的资源配置更简单，比如说我们前面，呃，在第一第一节提到的啊，我们用户不会去配置。

啊，它的一个资源配置导致了一个成本的浪费。啊，那么的方案呢，是根据应用的历史用量去进行推荐啊。并且呢，我们还支持按照这个机型的规则做调整啊，因为我们现在很多的业务都在一个，那么架构的一个资源规呢。机型的规格都是啊，会做规整的，比如说你是个1.5C3G的一个资源，那么它就会向上整到24G上。那么我们的一个推结果也会根据这样的一个规则做规则。那么我们那个算法呢，是基于前面提到的VPA的一个算法。那么达到的一个效果呢，大家可以看一下右边这两张图啊，上面呢，是没有使用资源推荐之前我们的很多的业务呢，它的一个呃，机型都是偏大的。横坐标，横坐标是CPU啊，纵坐标呢是内存。推荐。

它的一个cp memory的一个规，有了一个显著的。啊，那么。这里我们的资源推荐呢，是使用一个推荐建议的方式，去让用户去选择什么时间和是否要去采纳这样的一个建议。那么用户一旦采纳。那么只有在用户采纳的那个那个时刻之后，他才会去啊，批量的啊rolling的去更新用户的应用，这样呢，就避免了啊VPA无时无刻去更新。应用的配置导致的这个应用无数个都有可能被重启的这样的一个问题啊，然后下面呢，一个能力呢，是副本数和弹性的推荐。那么解决的问题是是什么呢？就是用户他去配置它的应用的副本数呢，往往也是基于基于一个经验值，或者基于一个保守的配置，那么CRA的方案呢，他也会去扫描啊这个集群中的一个应用，它会去根据它的应用历史的一个用量。

来去基于的算法，来去推荐未来的一个。那么。其中呢，有一些它的应用，它的一个呃用量，它是有昼夜规律的波动，那么对于这样的一些业务呢，我们还会去推荐它的一个弹性配置。啊。因，但是呢，我们还是去保留的这样的一个速度，为什么呢？不是所有的业务都是适做的。推荐配置，那么就能够降本了。那么对于那些能够支持动态的扩缩容的业务，并且它的业务也是有规律性的啊，那么对于这样的业务呢，我们会建议他，你可以去配一个。

智能弹性的。来，去对你进行降本增效。那么最后达到的一个效果呢，可以看到啊，我们的业务在做这个，呃之前。它的一个大于数大于三个的这样的业务其实也是有很多的。啊，这里有一个背景啊，因为我们做副本数推荐的时候，也要考虑这个应用的高可用，所以我们的副本数推荐会保障啊，它不会对于副本数小于三的业务进行推荐。啊，那么在进行一个复读推荐之后呢。在像这些大于副本数大于三的这些业务，它的一个副本数的这个数量呢，大大的减少啊，大部分呢，其实业务配了很多的副本数，但实际上经过我们的计算发现，它其实都可以降到我们的一个三个副本啊，也是可以去满足。这个业务的一个诉求啊，那么这是我们大规模去落地的一个实践啊，跟大家去做一个汇报啊，我们的，嗯，智能推荐的能力，在腾讯内部研业务。

呃，部署到呃数百个cuine的集群啊，管控了数百万个CPU的核。那么在全面上线一个月之内呢，我们大盘的总和数啊，缩减了25%啊，这是呢，我们在我们内部的控制台怎么去集成我们的智能推荐的。啊，这是我们会去把中资的这样的一个建议展现到控制中去，让用户看到些。当前的一个是怎么样，然后推荐的一个资源量是怎么样。啊，那么副本数建议呢，也是一样，我们会呃展示他当前的一个副本数是怎么样啊，推荐的副本数是多少。那么在这个页面中，我们还会去帮户啊整理出我们整个这个用户的工作环境中总共有多少个。

啊应用那么其可以优，那你采纳这个优化建低C图形的方式展现出方便用决。那么我们还支持C。个。非常的方便。下面我们介绍一下智能弹性的功能。描述。呃，弹性。通过预测未来的一个matrix的使用量啊来去解决刚才两个问题。

第一个能力呢，我们把它称为提前扩容，保证服务质量。啊，这里我们使用的时间预测算法呢，叫做FFT，就是快速傅立叶变换。那么根据74天ma预七轨。啊，那么我们是通过取预测窗口里面的matrix的最大值啊，来去做一个提前的扩容。这里可以给大家看一下啊，这个是我们的一个。Max的一个曲线。啊，红色的呢个C呢，是我们绿出来的一个。啊，那么我们通过这个使用预测的使用量，我们能够预测未来的一个max的一个趋势，并且我们在计算本数的时候，我们在每一个时刻都会取备来一段预测窗口内的。

啊，CPU的使用量的一个最大值来去做弹性，这样就保证了。在我们知道未来趋势的情况下，我们可以提前的去弹出。那么这里用户啊，可能会问了。万一我们的算法出现故障么办？这里还供了一个兜，就是我们实际量做略。那么这就帮助了用户，如果我们的资源的一个预测失效的时候，你还是可以基于它实际的用量啊去做弹性的。那么第二个能力呢，是我们会减少一个无效的缩容。啊，因为我们能够预测未来的一个资源用量，那么当这个呃曲线发生抖动的时候，我们因为取得预测窗口中的最大值，所以我们的整个曲线的抖动呢，它的一个毛色的程度啊，是明显降低的。

比如说。啊，这里。大家可以看到在这个时间点，我们这里有一个明显的实际的一个matrix，是有一个明显的一个毛刺啊，那么我们使用预测的数据呢，可以使得这个毛刺啊。问题大大解决。那么这样对应用的一个稳定性的影响呢，就会降得更低。Pro的配置。啊，我们，呃，支持了，按周期的方式去配，我们的第三个能力呢，是我们对一些大。或者节假日等有规律的流量洪峰。第四个特性是E。易于兼容社。并且呢，我们还支持了run的模式，可以去观测啊，你这个EP运的情况。

啊，社区的P呢，是支持的。啊。当比如他被运维要求说我要使用一个HBA的时候，他其实不敢去配置它，因为他也不知道。的。那么在这种模式下。去。在他的status中去展现他预测的一个嗯，本数并不会真正的去做弹性，那么用户可以把这个预测的本数观测到，他到它的一个观测系统去来去看这样的一个呃，副本数的一个曲线是不是满足他的期望，这样呢，来帮助他去落地弹性功能。啊，这个我们企业的右边呢，展现了一个EP的对象啊，它跟社区的H对象呢，是非常像的。

并且我们增加了一些新的字段。这个是EP1张。用户创建一个。资源对象，一个叫time series prediction。的。我们社区的在创建了之后。Controller就会开始工作。啊，去根据的一线定义中marix的配置。

API请求。那么一条呢，他会去向ma server去请求它的CPU的用量。那另外一条呢，会去的。Adapt。那最后max adapt会从T中的一个数据，并且样的一个tlertler，就会把这两个数据的一个源头的数据。进行一个P算法的计算，得到一个较高的一个数，并且拿这样的一数更新这个真实的应用。啊，这就是我们E做弹性的一次工作的过程。然后刚才介绍。啊，那么。那么的跟它有什么差异点呢？

啊，我们在，呃，我们解决了他们的一些不足点，并且做了一些增强。社区的HP。遭到了弱化，你不能够直接去修改你的P配置，因为它会被被自动的修改。啊，并且呢，它这个控制流呢，在这个这个逻辑是非常复杂的啊，你是很难理解的，那么柯达它里面也支持的一个弹性。实理。呃，在come的一个周期之外啊，柯达的这个配会自动的把你的应用到一个副本。

啊，原因是因为。他把每一个都定义成了一个marix的一个定义。那么由于它的marix定义相不感知，就导致了它这个marix回只能设置为一。啊，因为它不能够去影响别的metric。呃，这就到此呢，比如说你对这个业务设置了一个规则，他每天八点到12点。这时候他需要扩容到十个副本。啊，但是呢，你没有想到的是。早晨点到晚上八点就是它的周期之的时间，它会自动的柯到一个。这样对于用户来讲，他其实是很难理解这样的一个行为，这样的一个意外，那么就会容易导致一个生产的故障。啊，E的chome呢。呃，尝试去解决了上面提到的这两个问题啊，我们的预测观测和周期性的这个出发策略，它是共同作用的啊，它会同时去计算，同时去考虑，最后取得取中间的一个较大值。

那么呃，之前提到的那个问题，我们也把它解决了啊，那么用户你配置的周期之内，那么就是你用你期望的这个配置，那么在苦望的周期之外，它的一个副本数能够保持跟当前的一个配置不变。不会自动的把它到一。那具体的这个实现的一个原理是怎么样的，大家如果感兴趣的话，也可以去看一下代码。那我们智能弹性的一个落地成效呢，这里跟大家汇报一下。我们的，呃，腾讯内部的一个安全的部门和腾讯器服在也经使用了我们的弹性。我们的一个弹性伸缩器。那么作为开源产品公司呢，它原来在生产上，由于它的一个业务呢，就业的规律非常明显，它的生产环境中原来已经全量使用了。

那么他在看到呢之后呢，他就把的H全量切换到了，并且环境已经全量使用。能够很好的解决它的一个弹性问题，并且提升它的一个平均使用率。那么嗯，平均的利用率的一个提升达到了10%。啊，这个是我们的一个这张图啊，我们在库生态环境。是的，一个marix图表。中间呢，介意这个蓝色的线呢，是我们预测的这个matrix。

啊，这个绿色的线呢，是它啊CPU实时的一个matrix容量。那么这一个黄色的线呢。就是我们使用我们eh之后，它的一个提前扩容的一个能力啊，这个条黄色的线呢，是它的一个。可以看到它在生产环境实现了一个提的扩容啊，帮助用户能够大规模的去落地的一个弹性力。好的啊，那么前面讲的这个智能推荐的能力和智能弹性能力呢，都是我们的开源项提供的工具。那么呢，也是一个非常活跃的啊，开源社区。呃，在这里呢，也是欢迎大家多了解人，也是欢迎大家我们我们一起共建人社区。今天的分享就到这里，谢谢大家。好的，非常感谢胡老师的精彩分享，从中我们了解到，开发人员为了保证业务全天候的稳定运行，通常会把容器的资源设置相对大一些，你应对一些突发情况，在其他流量小的时候，这些资源就浪费了。然后胡老师呢，又介绍了多种的解决方案，其中胡老师负责的这个开源解决方案，能较实时的根据业务的使用量来动态的伸缩扩容，保证业务的稳定运行。

今天的内容完全是干货啊，大家收藏我们当前的直播链接，回放地址呢，就是当前的直播地址，另外呢，我们在7月7日的晚上八点还会进行第三讲的直播，敬请期待，OK，那我们今天的直播到此结束，我们下期再见。