fix img

2025-11-17 14:43:43 +08:00 · 2022-09-06 22:30:37 +08:00
parent 66970f3e38
commit 3d6528675a
796 changed files with 3382 additions and 3382 deletions
--- a/技术公开课（完）/01
+++ b/技术公开课（完）/01
@@ -180,11 +180,11 @@ function hide_canvas() {
                        <div><h1>01 架构的演进</h1>
 <h3>传统单体应用架构</h3>
 <p>十多年前主流的应用架构都是单体应用，部署形式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地维护这台服务器，以保证服务的可用性。</p>
-<p><img src="assets/2020-07-13-091116.png" alt="1.png" /> ▲ 单体架构</p>
+<p><img src="assets/2020-07-13-091116.png" alt="png" /> ▲ 单体架构</p>
 <h4>单体应用架构面临的问题</h4>
 <p>随着业务的增长，这种最简单的单体应用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器出现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务量变大之后，一台服务器的资源很快会无法承载所有流量。</p>
 <p>解决这两个问题最直接的方法就是在流量入口加一个负载均衡器，使单体应用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体应用也具备了水平伸缩的能力。</p>
-<p><img src="assets/2020-07-13-091121.png" alt="2.png" /> ▲ 单体架构（水平伸缩）</p>
+<p><img src="assets/2020-07-13-091121.png" alt="png" /> ▲ 单体架构（水平伸缩）</p>
 <h3>微服务架构</h3>
 <h4>1. 微服务架构演进出通用服务</h4>
 <p>随着业务的进一步增长，更多的研发人员加入到团队中，共同在单体应用上开发特性。由于单体应用内的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，以及大量的 conflict merge 操作，研发效率直线下降。</p>
@@ -192,7 +192,7 @@ function hide_canvas() {
 <h4>2. 微服务架构给运维带来挑战</h4>
 <p>应用从单体架构演进到微服务架构，从物理的角度看，分布式就成了默认选项，这时应用架构师就不得不面对分布式带来的新挑战。在这个过程中，大家都会开始使用一些分布式服务和框架，例如缓存服务 Redis，配置服务 ACM，状态协调服务 ZooKeeper，消息服务 Kafka，还有通讯框架如 GRPC 或者 DUBBO，以及分布式追踪系统等。</p>
 <p>除分布式环境带来的挑战之外，微服务架构给运维也带来新挑战。研发人员原来只需要运维一个应用，现在可能需要运维十个甚至更多的应用，这意味着安全 patch 升级、容量评估、故障诊断等事务的工作量呈现成倍增长，这时，应用分发标准、生命周期标准、观测标准、自动化弹性等能力的重要性也更加凸显。</p>
-<p><img src="assets/2020-07-13-091129.png" alt="3.png" /> ▲ 微服务架构</p>
+<p><img src="assets/2020-07-13-091129.png" alt="png" /> ▲ 微服务架构</p>
 <h3>云原生</h3>
 <h4>1. 基于云产品架构</h4>
 <p>一个架构是否是云原生，就看这个架构是否是长在云上的，这是对“云原生”的简单理解。这个“长在云上”不是简单地说用云的 IaaS 层服务，比如简单的 ECS、OSS 这些基本的计算存储；而是应该理解成有没有使用云上的分布式服务，比如 Redis、Kafka 等，这些才是直接影响到业务架构的服务。微服务架构下，分布式服务是必要的，原来大家都是自己研发这样的服务，或者基于开源版本自己运维这样的服务。而到了云原生时代，业务则可以直接使用云服务。</p>
--- a/技术公开课（完）/03
+++ b/技术公开课（完）/03
@@ -203,7 +203,7 @@ function hide_canvas() {
 <li>去云厂商上买台云服务器运行站点，为了解决高可用的问题又买了负载均衡服务和多个服务器；</li>
 <li>采用静态站点方式，直接由对象存储服务（如 OSS）支持，并使用 CDN 回源 OSS。</li>
 </ul>
-<p><img src="assets/2020-07-27-022836.jpg" alt="2.JPG" /></p>
+<p><img src="assets/2020-07-27-022836.jpg" alt="png" /></p>
 <p>这三种方式由云下到云上，由管理服务器到无需管理服务器，即 Serverless。这一系列的转变给使用者带来了什么变化呢？前两种方案需要预算，需要扩展，需要实现高可用，需要自行监控等，这些都不是马老师当年想要的，他只想去展示信息，让世界了解中国，这是他的业务逻辑。Serverless 正是这样一种理念，最大化地让人去专注业务逻辑。第三种方式就是采用了 Serverless 架构去构建一个静态站点，它有其它方案无法比拟的优势，比如：</p>
 <ul>
 <li>可运维性：无需管理服务器，比如操作系统的安全补丁升级、故障升级、高可用性，这些云服务（OSS，CDN）都帮着做了；</li>
@@ -225,7 +225,7 @@ function hide_canvas() {
 <li>是否可以通过函数来实现轻量级微服务，依赖函数计算提供的负载均衡、自动伸缩、按需付费、日志采集、系统监控等能力；</li>
 <li>基于 Spring Cloud、Dubbo、HSF 等实现的微服务应用是否需要自己购置服务器部署应用，管理服务发现，负载均衡，弹性伸缩，熔断，系统监控等，还是可以将这些工作交给诸如 Serverless 应用引擎服务。</li>
 </ul>
-<p><img src="assets/2020-07-27-022839.jpg" alt="4.JPG" /></p>
+<p><img src="assets/2020-07-27-022839.jpg" alt="png" /></p>
 <p>上图右侧的架构引入了 API 网关、函数计算或者 Serverless 应用引擎来实现计算层，将大量的工作交给了云服务完成，让用户最大程度上专注实现业务逻辑。其中系统内部多个微服务的交互如下图所示，通过提供一个商品聚合服务，将内部的多个微服务统一呈现给外部。这里的微服务可以通过 SAE 或者函数实现。</p>
 <p><img src="assets/2020-07-27-5.JPG" alt="img" /></p>
 <p>这样的架构还可以继续扩展，比如如何支持不同客户端的访问，如上图右侧所示。现实中这种需求是常见的，不同的客户端需要的信息可能是不同的，手机可以根据位置信息做相关推荐。如何让手机客户端和不同浏览器都能受益于 Serverless 架构呢？这又牵扯出了另一个词——Backend for fronted（BFF），即为前端定做的后端，这受到了前端开发工程师的推崇，Serverless 技术让这个架构广泛流行，因为前端工程师可以从业务角度出发直接编写 BFF，而无需管理服务器相关的令前端工程师更加头疼的事情。更多实践可以参见：<a href="https://yq.aliyun.com/articles/752780">基于函数计算的 BFF 架构</a>。</p>
@@ -233,7 +233,7 @@ function hide_canvas() {
 <p>前面提到的动态页面生成是同步请求完成的，还有一类常见场景，其中请求处理通常需要较长时间或者较多资源，比如用户评论中的图片和视频内容管理，涉及到如何上传图片和处理图片（缩略图、水印、审核等）及视频，以适应不同客户端的播放需求。</p>
 <p><img src="assets/2020-07-27-6.JPG" alt="img" /></p>
 <p>如何对上传多媒体文件实时处理呢？这个场景的技术架构大体经历了以下演变：</p>
-<p><img src="assets/2020-07-27-022842.jpg" alt="7.JPG" /></p>
+<p><img src="assets/2020-07-27-022842.jpg" alt="png" /></p>
 <ul>
 <li>基于服务器的单体架构：多媒体文件被上传到服务器，由服务器处理，对多媒体的显示请求也由服务器完成；</li>
 <li>基于服务器的微服务架构：多媒体文件被上传到服务器，服务器处理转存到 OSS，然后将文件地址加入消息队列，由另一组服务器处理文件，将处理结果保存到 OSS，对多媒体的显示请求由 OSS 和 CDN 完成；</li>
@@ -262,7 +262,7 @@ function hide_canvas() {
 <p>事件触发能力是 FaaS 服务的一个重要特性，这种 Pub-Sub 事件驱动模式不是一个新的概念，但是在 Serverless 流行之前，事件的生产者、消费者以及中间的连接枢纽都是用户负责的，就像前面架构演进中的第二个架构。</p>
 <p>Serverless 让生产者发送事件，维护连接枢纽都从用户职责中省略了，而只需关注消费者的逻辑，这就是 Serverless 的价值所在。</p>
 <p>函数计算服务还集成其它云服务事件源，让你更方便地在业务中使用一些常见的模式，如 Pub/Sub、事件流模式、Event Sourcing 模式。关于更多的函数组合模式可以参见：<a href="https://yq.aliyun.com/articles/722461">函数组合的 N 种方式</a>。</p>
-<p><img src="assets/2020-07-27-8.JPG" alt="8.JPG" /></p>
+<p><img src="assets/2020-07-27-8.JPG" alt="png" /></p>
 <h3>场景 4: 服务编排</h3>
 <p>前面的商品页面虽然复杂，但是所有的操作都是读操作，聚合服务 API 是无状态、同步的。我们来看一下电商中的一个核心场景——订单流程。</p>
 <p><img src="assets/2020-07-27-9.JPG" alt="img" /></p>
--- a/技术公开课（完）/04
+++ b/技术公开课（完）/04
@@ -181,7 +181,7 @@ function hide_canvas() {
 <p>今天来讲，在 Serverless 这个大领域中，不只有函数计算这一种产品形态和应用类型，而是面向不同的用户群体和使用习惯，都有其各自适用的 Serverless 产品。例如面向函数的函数计算、面向应用的 Serverless 应用引擎、面向容器的 Serverless Kubernetes，用户可以根据自己的使用习惯、使用场景或者应用类型，去选择使用什么样的 Serverless 产品。下面通过本文给大家介绍一下，阿里云都有哪些可供大家选择的 Serverless 产品。</p>
 <h3>Serverless 产品及分层</h3>
 <p>众所周知，最早提出 Serverless 的是 AWS，其在 Serverless 领域的旗舰产品是 function compute。同样阿里云也有函数计算的产品，帮助用户构建 Serverless 函数。但 Serverless 不仅仅是函数，如下图所示，其实用户会期望在应用、容器等层面也能够享受到 Serverless 的好处，包括按量付费、极致弹性等，这样也更符合用户原有的使用习惯。</p>
-<p><img src="assets/2020-07-27-2.JPG" alt="image.gif" /></p>
+<p><img src="assets/2020-07-27-2.JPG" alt="png" /></p>
 <p>在上图中，大家能够看到，阿里云针对函数、应用和容器都推出了对应的 Serverless 产品，用户可以针对自己的使用场景选择不同的产品。</p>
 <h3>函数计算</h3>
 <h4>1. 函数计算介绍</h4>
@@ -189,7 +189,7 @@ function hide_canvas() {
 <p>上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。这个时候还不会产生费用，只有到被调用的时候才有费用。调用的方式可以是产品提供的 API/SDK，也可以通过一些事件源，比如阿里云的 OSS 的事件。比如用户往 OSS 里的某一个 bucket 上传了一个文件，希望这个文件被自动处理；比如上传一个 zip 包，希望能够自动解压到另外一个 bucket，这都是很典型的函数场景。</p>
 <p>另外，函数计算能够提供非常好的弹性能力，最终的费用是根据时长和内存数进行计费的，如果调用量小的话，只会有很少的费用。并且它在语言方面也非常丰富，常用的 nodejs、php、python、java 都直接支持。同时提供自定义的运行环境，可以支持任意的可执行的语言。</p>
 <h4>2. 函数计算典型场景</h4>
-<p><img src="assets/2020-07-27-7.JPG" alt="image.gif" /></p>
+<p><img src="assets/2020-07-27-7.JPG" alt="png" /></p>
 <p>从使用场景来说，主要有三类：</p>
 <ul>
 <li>Web 应用。可以是各种语言写的，这种可以使用 Serverless 框架新编写的程序，也可以是已有的应用。比如小程序后端、或者发布到 API 市场的 API 后端应用等。</li>
@@ -197,7 +197,7 @@ function hide_canvas() {
 <li>事件驱动型的应用。比如通过其他阿里云产品驱动的场景、Web Hook、定时任务等。函数计算已经与很多产品进行了打通，比如对象存储、表格存储、定时器、CDN、日志服务、云监控等，可以非常快速地组装出一些业务逻辑。</li>
 </ul>
 <h4>3. 函数计算核心竞争力</h4>
-<p><img src="assets/2020-07-27-10.JPG" alt="image.gif" /></p>
+<p><img src="assets/2020-07-27-10.JPG" alt="png" /></p>
 <p>函数计算对客户的一个最大的价值，就是能够让用户只关注自己的业务逻辑开发，完全不需要管理运维，诸如计算资源、网络设置等都不需要关心。在隔离性上提供 vm 级别的隔离，保证用户在运行时的数据安全、运行时安全等；在可用性方面默认提供 3az 的高可用架构，保证客户默认就是高可用的最佳实践架构；在弹性方面，可以做到毫秒级的弹性效率，满足客户突发的流量冲击；在计费方面也非常灵活，真正按照用户的请求情况进行收费，也支持对 long run 的应用更友好的预付费模式。</p>
 <h3>Serverless 应用引擎</h3>
 <h4>1. SAE 概述</h4>
@@ -205,7 +205,7 @@ function hide_canvas() {
 <p>SAE 是业内首款面向应用的 Serverless Paas 平台。这个产品以面向应用的视角，帮助用户在不做任何修改的前提下把存量应用上到云端。在资源层，用户不再需要自己管理和运维机器及集群，只需要关注自己应用所需要使用的规格以及实例数，不再需要关心底层是虚机还是容器。</p>
 <p>SAE 从资源层面提供计算资源、弹性、隔离性等能力，让用户只需要关注自己的应用。在应用层，SAE 提供了监控、日志、微服务治理等能力，帮助用户解决应用可观测性和治理需求。同时提供网络配置、流量控制能力，提供了和 CICD 良好的集成，用户可以使用已有 CICD 部署到 SAE，比如 jenkins、云效等，可以说覆盖了应用上云的完整场景。</p>
 <h4>2. SAE 典型场景</h4>
-<p><img src="assets/2020-07-27-13.JPG" alt="image.gif" /></p>
+<p><img src="assets/2020-07-27-13.JPG" alt="png" /></p>
 <p>SAE 有几个典型的使用场景，一个是存量业务上云，特别是微服务、java 应用，同时也支持其他语言的单体应用，都能够通过 SAE 这个平台运行在阿里云上，并且不需要做任何代码的修改。在行业方面，SAE 特别适合有比较大的流量波动的在线业务，比如电商大促、在线教育等行业的场景。另外 SAE 作为应用平台也可以被上层的行业 Saas 所集成，帮助用户更快地构建行业 Saas。</p>
 <h4>3. SAE 特性</h4>
 <p><img src="assets/2020-07-27-14.JPG" alt="img" /></p>
@@ -218,7 +218,7 @@ function hide_canvas() {
 <p>之后有了 K8s 来帮大家解决容器编排的问题。这种标准化的方式确实大大提高了大家的生产力。用户通过使用 deployment、service 等标准的 K8s 的方式进行编排，并进行部署。但 K8s 的运维和管理还是相对比较复杂的，技能要求比较高，用户需要运维 ECS 以及通过 ECS 构建出来的 K8s。另外一个痛点时 K8s 集群里的 ECS 是需要预先购买的，如果客户的负载有比较大的波动，就会出现比较多的资源浪费。虽然技术上也有解决方案，比如 worker node 的弹性，但这对于初级用户来说，还是有比较高的复杂度。</p>
 <p>那有没有一种方案可以让用户既能享受到 K8s 提供的容器编排能力，又能够不需要关心 ECS 和 K8s 的运维、管理和弹性问题呢？这就是 Serverless K8s 的方案。对应到阿里云的产品就是 ASK。在 ASK 的方案里，用户创建一个 ASK 集群，但不需要指定任何 ECS 节点，然后通过标准的 K8s 容器编排、deployment 等部署镜像。ASK 会根据用户的负载需求，自动在底层资源池构建需要的 POD 并进行弹性伸缩，用户不再需要关心容量规划、ECS 机器运维、资源限制等 LaaS 层的问题，非常便利。</p>
 <h4>2. ASK 典型场景</h4>
-<p><img src="assets/2020-07-27-16.JPG" alt="image.gif" /></p>
+<p><img src="assets/2020-07-27-16.JPG" alt="png" /></p>
 <p>那 ASK 主要用在哪些场景里呢？首先可以用来跑在线业务，部署模式灵活，可以是 deployment、helm chart 等所有的 K8s 原生模式，特别是能够很好地应对突发流量，极致弹性，可以在 30 秒完成 500 个容器实例的弹性。这样的弹性效率，可以很好地支撑大数据计算类的任务，比如 Spark、Presto 等，也可以在需要的时候即时获取资源，支撑 10000 以上 Pod 的规格，有效降低客户成本。</p>
 <p>另外一个非常适合的场景是用来构建随需启动的构建任务，比如在 ASK 中运行 jenkins、Gitlab-Runner 等。在有构建任务的时候，即时启动。没有任务的时候 0 消费，成本做到最低。这里只是列出了一些例子的场景，实际上基于 ASK 的这个特性，用户可以运行很多 K8s 原生的需要极致弹性的工作负载。</p>
 <h4>3. ASK 特性</h4>
--- a/技术公开课（完）/05
+++ b/技术公开课（完）/05
@@ -208,12 +208,12 @@ function hide_canvas() {
                        <div><h1>05 函数计算简介</h1>
 <h3>什么是函数计算</h3>
 <p>大家都了解，Serverless 并不是没有服务器，而是开发者不再需要关心服务器。下图是一个应用从开发到上线的对比图：</p>
-<p><img src="assets/2020-08-03-024851.jpg" alt="1.jpg" /></p>
+<p><img src="assets/2020-08-03-024851.jpg" alt="png" /></p>
 <p>在传统 Serverful 架构下，部署一个应用需要购买服务器，部署操作系统，搭建开发环境，编写代码，构建应用，部署应用，配置负载均衡机制，搭建日志分析与监控系统，应用上线后，继续监控应用的运行情况。而在 Serverless 架构下，开发者只需要关注应用的开发构建和部署，无需关心服务器相关操作与运维，在函数计算架构下，开发者只需要编写业务代码并监控业务运行情况。这将开发者从繁重的运维工作中解放出来，把精力投入到更有意义的业务开发上。</p>
-<p><img src="assets/2020-08-03-024852.png" alt="2.png" /></p>
+<p><img src="assets/2020-08-03-024852.png" alt="png" /></p>
 <p>上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时，开发者也无需手动扩容，函数计算会根据请求量毫秒级自动扩容，弹性可靠地运行任务，并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。</p>
 <h3>函数计算核心优势</h3>
-<p><img src="assets/2020-08-03-024854.png" alt="3.png" /></p>
+<p><img src="assets/2020-08-03-024854.png" alt="png" /></p>
 <h4>敏捷开发</h4>
 <ul>
 <li>使用函数计算时，用户只需聚焦于业务逻辑的开发，编写最重要的 “核心代码”；</li>
@@ -237,7 +237,7 @@ function hide_canvas() {
 <li>预付费模型根据业务负载估算提前预购计算力，单价更低，组合使用后付费和预付费方式将有效降低成本。</li>
 </ul>
 <h3>函数计算使用场景</h3>
-<p><img src="assets/2020-08-03-024854.jpg" alt="4.jpg" /></p>
+<p><img src="assets/2020-08-03-024854.jpg" alt="png" /></p>
 <p>从使用场景来说，主要有三类：</p>
 <ul>
 <li><strong>Web 应用：</strong> 可以是各种语言写的，这种可以是使用 Serverless 框架新编写的程序，也可以是已有的应用。比如可能是小程序后端，也可能是 Web API；</li>
--- a/函数计算是如何工作的？.md.html
+++ b/函数计算是如何工作的？.md.html
@@ -179,25 +179,25 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>06 函数计算是如何工作的？</h1>
 <h3>函数计算调用链路</h3>
-<p><img src="assets/2020-08-03-024856.png" alt="5.PNG" /></p>
+<p><img src="assets/2020-08-03-024856.png" alt="png" /></p>
 <p>上图展示了函数计算完整的请求和调用链路。函数计算是事件驱动的无服务器应用，事件驱动是说可以通过事件源自动触发函数执行，比如当有对象上传至 OSS 中时，自动触发函数，对新上传的图片进行处理。函数计算支持丰富的事件源类型，包括日志服务、对象存储、表格存储、消息服务、API 网关、CDN 等。</p>
 <p>除了事件触发外，也可以直接通过 API/SDK 直接调用函数。调用可以分为同步调用与异步调用，当请求到达函数计算后，函数计算会为请求分配执行环境，如果是异步调用，函数计算会将请求事件存入队列中，等待消费。</p>
 <h3>函数计算调用方式</h3>
-<p><img src="assets/2020-08-03-024858.jpg" alt="6.jpg" /></p>
+<p><img src="assets/2020-08-03-024858.jpg" alt="png" /></p>
 <p>同步调用的特性是，客户端期待服务端立即返回计算结果。请求到达函数计算时，会立即分配执行环境执行函数。</p>
 <p>以 API 网关为例，API 网关同步触发函数计算，客户端会一直等待服务端的执行结果，如果执行过程中遇到错误， 函数计算会将错误直接返回，而不会对错误进行重试。这种情况下，需要客户端添加重试机制来做错误处理。</p>
-<p><img src="assets/2020-08-03-024859.jpg" alt="7.jpg" /></p>
+<p><img src="assets/2020-08-03-024859.jpg" alt="png" /></p>
 <p>异步调用的特性是，客户端不急于立即知道函数结果，函数计算将请求丢入队列中即可返回成功，而不会等待到函数调用结束。</p>
 <p>函数计算会逐渐消费队列中的请求，分配执行环境，执行函数。如果执行过程中遇到错误，函数计算会对错误的请求进行重试，对函数错误重试三次，系统错误会以指数退避方式无限重试，直至成功。</p>
 <p>异步调用适用于数据的处理，比如 OSS 触发器触发函数处理音视频，日志触发器触发函数清洗日志，都是对延时不敏感，又需要尽可能保证任务执行成功的场景。如果用户需要了解失败的请求并对请求做自定义处理，可以使用 Destination 功能。</p>
 <h3>函数计算执行过程</h3>
 <p>函数计算是 Serverless 的，这不是说无服务器，而是开发者无需关心服务器，函数计算会为开发者分配实例执行函数。</p>
-<p><img src="assets/2020-08-03-024901.jpg" alt="8.jpg" /></p>
+<p><img src="assets/2020-08-03-024901.jpg" alt="png" /></p>
 <p>如上图所示，当函数第一次被调用的时候，函数计算需要动态调度实例、下载代码、解压代码、启动实例，得到一个可执行函数的代码环境。然后才开始在系统分配的实例中真正地执行用户的初始化函数，执行函数业务逻辑。这个调度实例启动实例的过程，就是系统的冷启动过程。</p>
 <p>函数逻辑执行结束后，不会立即释放掉实例，会等一段时间，如果在这段时间内有新的调用，会复用这个实例，比如上图中的 Request 2，由于执行环境已经分配好了，Request 2 可以直接使用，所以 Request 2 就不会遇到冷启动。</p>
 <p>Request 2 执行结束后，等待一段时间，如果这段时间没有新的请求分配到这个实例上，那系统会回收实例，释放执行环境。此实例释放后，新的请求 Request 3 来到函数计算，需要重新调度实例、下载代码、解压代码，启动实例，又会遇到冷启动。</p>
 <p>所以，为了减小冷启动带来的影响，要尽可能避免冷启动，降低冷启动带来的延时。</p>
-<p><img src="assets/2020-08-03-024902.jpg" alt="9.jpg" /></p>
+<p><img src="assets/2020-08-03-024902.jpg" alt="png" /></p>
 <p>使用预留实例可以完全避免冷启动，预留实例是在用户预留后就分配实例，准备执行环境；请求结束后系统也不会自动回收实例。</p>
 <p>预留实例不由系统自动分配与回收，由用户控制实例的生命周期，可以长驻不销毁，这将彻底消除实例冷启动带来的延时毛刺，提供极致性能，也为在线应用迁移至函数计算扫清障碍。</p>
 <p>如果业务场景不适合使用预留实例，那就要设法降低冷启动的延时，比如降低代码包大小，可以降低下载代码包、解压代码包的时间。Initializer 函数是实例的初始化函数，Initializer 在同一实例中执行且只执行一次，所以可以将一些耗时的公共逻辑放到 Initializer 中，比如在 NAS 中加载依赖、建立连接等等。另外要尽量保持请求连续稳定，避免突发的流量，由于系统已启动的实例不足以支撑大量的突发流量，就会带来不可避免的冷启动。</p>
--- a/函数计算的开发与配置.md.html
+++ b/函数计算的开发与配置.md.html
@@ -181,12 +181,12 @@ function hide_canvas() {
 <p><strong>导读：</strong> 在本篇文章中“基本概念”部分主要对函数计算最核心的概念进行详细介绍，包括服务、函数、触发器、版本、别名以及相关的配置；“开发流程”部分介绍了基于函数计算开发的完整开发部署流程。</p>
 <h3>基本概念</h3>
 <h4>1. 服务</h4>
-<p><img src="assets/2020-08-10-091917.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-091917.png" alt="png" /></p>
 <p>服务是函数计算资源管理的单位，同一个服务下有很多函数，这些函数共享服务的网络配置、权限配置、存储配置、日志配置。</p>
 <p>服务可以对应成一个“应用”，这个应用由很多函数共同组成，这些函数具有相同的访问权限、网络配置，日志也记录到相同的 logstore。这些函数本身的配置可以各不相同，比如同一服务下有的函数内存是3G，有的函数内存是 512M，有些函数用 Python 写，有些函数用 Node.js 写。</p>
 <p>当然，如果应用比较复杂，同一个应用也可以对应多个服务，这里没有强绑定关系。</p>
 <p><strong>1）服务配置</strong></p>
-<p><img src="assets/2020-08-10-091918.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-091918.png" alt="png" /></p>
 <p>接下来我们介绍服务的几个核心配置：</p>
 <p><strong>日志配置：</strong> 开发者的代码在函数计算平台运行，如何查看函数运行产生的日志呢？在Server 化的开发方式中，日志都打到统一的文件中，通过 Logstash/Fluentd 这种日志收集工具收集到 ElasticSearch 中，并通过 Kibana 这种可视化工具查看日志及指标。但是在函数计算中，运行代码的机器由函数计算动态分配，开发者无法自己收集日志，函数计算需要帮助开发者投递日志。日志配置就是起到这个作用，配置 LogConfig 设置日志服务的 Project 和 Logstore，函数计算会将函数运行中产生的日志投递到开发者的 Logstore 里。</p>
 <p>但是为了成功投递日志，单单配置 Logtore 还不够，函数计算是没有权限向开发者的 Logstore 投递日志的，需要用户授予函数计算向指定的 Logstore 写数据的权限，有了这个授权后，函数计算就可以名正言顺地向开发者的 Logstore 投递日志了。</p>
@@ -197,7 +197,7 @@ function hide_canvas() {
 <h4>2. 函数</h4>
 <p>“函数计算”中函数可谓是核心概念，函数是管理、运行的基本单元，一个函数通常由一系列配置与可运行代码包组成。</p>
 <p><strong>1）函数配置</strong></p>
-<p><img src="assets/2020-08-10-091919.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-091919.png" alt="png" /></p>
 <p>函数的配置如上图所示：</p>
 <ul>
 <li><strong>Runtime 是函数运行时的环境类型：</strong> 函数计算目前支持 Node.js/Python/Java/C#/PHP 等开发环境，同时也支持 Custom Runtime 自定义运行时；</li>
@@ -209,16 +209,16 @@ function hide_canvas() {
 <li><strong>InitializerTimeout 就是 Initializer 函数的最大运行时间。</strong></li>
 </ul>
 <h4>3. 触发器</h4>
-<p><img src="assets/2020-08-10-091921.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-091921.png" alt="png" /></p>
 <p>往期课程中介绍了函数计算支持的丰富的事件源类型，在事件驱动的计算模型中，事件源是事件的生产者，函数是事件的处理者，触发器提供了一种集中、统一的方式来管理不同的事件源。当事件发生时，如果满足触发器定义的规则，事件源会自动调用触发器所对应的函数。</p>
 <p>典型的使用场景包括对上传至 OSS 中的对象进行处理，比如图像处理、音视频转码、OSS zip 包解压，以及对 SLS 中的日志进行清洗、处理、转存，在指定时间触发函数执行等等。</p>
 <h4>4. 版本&amp;别名</h4>
-<p><img src="assets/2020-08-10-91922.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-91922.png" alt="png" /></p>
 <p>上文介绍了服务、函数、触发器，开发者就可以基于函数计算将应用搭建起来了，但又有一个新问题：<strong>开发者有了新需求需要更新代码，如何保证线上应用不受影响，平滑迭代上线呢？</strong> 为了解决这个问题，函数计算引入了版本和别名。</p>
 <p>版本相当于服务的快照，包括服务的配置、服务内的函数代码及函数配置。当您开发和测试完成后，就发布一个版本，版本单调递增，版本发布后，已发布的版本不能更改，您可以继续在 Latest 版本上开发测试，不会影响已发布的版本。调用函数时，只需要指定版本就可以调用指定版本的函数。</p>
 <p>那新问题又来了，版本名称是函数计算指定的单调递增的，每次发布版本，都会有一个新的版本，<strong>那每次发完版本后，客户端还要改代码执行最新的版本吗？</strong> 为了解决这个问题呢，我们引入了别名，别名就是指向特定服务版本的指针，发布后，只需要将别名指向发布的版本，再次发布后，再切换别名指向最新的版本，客户端只需要指定别名就可以保证调用线上最新的代码。同时别名支持灰度发布的功能，即有 10% 的流量指向最新版本，90% 理论指向老版本。回滚也非常简单，只需要将别名指向之前的版本即可快速完成回滚。</p>
 <h3>开发流程</h3>
-<p><img src="assets/2020-08-10-091923.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-10-091923.png" alt="png" /></p>
 <p>如上图所示，开发者首先创建服务，设置日志、权限等配置，然后创建函数，在当前版本（Latest 版本）下编写代码开发函数，测试通过后发布版本，第一次发布的版本为版本 1，创建别名 prod 指向版本 1，就可以对外提供服务了。</p>
 <p>客户端调用函数的日志会记录在开发者配置的 Logstore 里，函数计算提供完备的监控图表，应用上线后，开发者可以通过监控图表和日志查看应用的健康状况。</p>
 <p>当开发者有新需求时，继续在 Latest 版本更改代码开发函数，测试通过后发布版本，这次发布的版本为版本 2，切换别名流量 10% 到版本 2，即可实现应用的灰度发布，观察一段时间没有问题，就可以切换 100% 的流量到版本 2 了。</p>
--- a/技术公开课（完）/10
+++ b/技术公开课（完）/10
@@ -180,7 +180,7 @@ function hide_canvas() {
                        <div><h1>10 自动化 CI&amp;CD 与灰度发布</h1>
 <h3>环境管理和自动化部署</h3>
 <p>当我们从传统开发迁移到 Serverless 下，对于环境和部署的管理思路也会有所不同。当用户转到 Serverless ，可以轻松地提供更多的环境，而这个好处常被忽略。</p>
-<p><img src="assets/2020-09-14-095756.jpg" alt="1.jpg" /></p>
+<p><img src="assets/2020-09-14-095756.jpg" alt="png" /></p>
 <p>当我们开发项目时，通常需要一个生产环境，然后需要预发环境，还有一些测试环境。但通常每个环境都需要消耗资源和成本，以保持服务在线。而大多数时候非生产环境上的访问量非常少，为此付出大量的成本很不划算。</p>
 <p>但是，在 Serverless 架构中，我们可以为每位开发人员提供一个准生产环境。做 CI/CD 的时候，可以为每个功能分支创建独立的演示环境。</p>
 <p>当团队成员在开发功能或者修复 bug 时，想要预览新功能，就可以立即部署，而不需要在自己机器上模拟或者找其他同事协调测试环境的使用时间。</p>
@@ -189,7 +189,7 @@ function hide_canvas() {
 <p>后面的课程我们会了解到，借助于函数计算平台提供的 Funcraft 工具，开发人员可以用从前做不到的方式在准生产环境中轻松部署和测试代码。</p>
 <h3>灰度发布</h3>
 <p>由于 Serverless 提供的弹性机制，没有访问量的时候能自动缩容到零，极大地节约了部署的多环境的成本。然而在同一套环境内的多个不同的版本也可以受益于这套机制。</p>
-<p><img src="assets/2020-09-14-095757.jpg" alt="2.jpg" /></p>
+<p><img src="assets/2020-09-14-095757.jpg" alt="png" /></p>
 <p>传统应用虽然也支持在一个环境中并存多个版本，但相比于 Serverless 更加困难。首先每个版本都需要相对独立的运行环境，会消耗更多的资源。其次需要解决多个版本之间流量的分配问题。</p>
 <p>在 FaaS 上这些问题已经被版本和别名机制完美的解决。由于没有流量就不消耗计算资源，所以发布一个版本的成本极低，每次发布都可以形成一个版本。然后通过别名进行版本的切换和流量分配。</p>
 <p>基于 FaaS 的这套抽象，让灰度发布和 A/B 测试变得非常的简单。不再需要像 K8s 那样复杂的基础设置，开发者也能轻松地享受到平滑升级和快速验证的高级特性。</p>
--- a/函数计算的可观测性.md.html
+++ b/函数计算的可观测性.md.html
@@ -181,7 +181,7 @@ function hide_canvas() {
 <h3>概述</h3>
 <p>可观测性是什么呢？维基百科中这样说：可观测性是通过外部表现判断系统内部状态的衡量方式。</p>
 <p>在应用开发中，可观测性帮助我们判断系统内部的健康状况。在系统出现问题时，帮助我们定位问题、排查问题、分析问题；在系统平稳运行时，帮助我们评估风险，预测可能出现的问题。评估风险类似于天气预报，预测到明天下雨，那出门就要带伞。在函数计算的应用开发中，如果观察到函数的并发度持续升高，很可能是业务推广团队的努力工作导致业务规模迅速扩张，为了避免达到并发度限制触发流控，开发者就需要提前提升并发度。</p>
-<p><img src="assets/2020-09-14-095804.png" alt="1.PNG" /></p>
+<p><img src="assets/2020-09-14-095804.png" alt="png" /></p>
 <p>可观测性包括三个方面：Logging、Metrics、Tracing</p>
 <ul>
 <li>Logging 是日志，日志记录了函数运行中的关键信息，这些信息是离散且具体的，结合错误日志与函数代码可以迅速定位问题。</li>
@@ -211,7 +211,7 @@ function hide_canvas() {
 <li>**配置日志大盘：**日志大盘不仅可以看到函数计算提供的监控指标，而且可以与开发者日志关联，生成自定义的监控指标。</li>
 </ul>
 <h4>3. 链路追踪</h4>
-<p><img src="assets/2020-09-14-095805.png" alt="2.png" /> （请求在各个链路的延时瀑布图）</p>
+<p><img src="assets/2020-09-14-095805.png" alt="png" /> （请求在各个链路的延时瀑布图）</p>
 <p>链路追踪是分布式系统排查问题的重要一环，链路追踪可以分析分布式系统中请求在各个链路的时延。有以下几种情况：</p>
 <ul>
 <li>函数计算作为整个链路中的一环，可以看到请求在函数计算上的时延，时延包括系统启动的时间和请求真正的执行时间，帮助用户分析性能瓶颈。</li>
--- a/技术公开课（完）/13
+++ b/技术公开课（完）/13
@@ -197,14 +197,14 @@ function hide_canvas() {
 </ul>
 <h3>开发流程</h3>
 <h4>1. 登录函数计算控制台，创建应用</h4>
-<p><img src="assets/2020-09-21-60731.png" alt="3.png" /></p>
+<p><img src="assets/2020-09-21-60731.png" alt="png" /></p>
 <p>可以通过两种方式来创建应用，如果是已有的 Web 项目，可以选择上图中的第一种方式：“常见 Web 应用”；对于新项目则推荐使用第二种方式：“基于模板创建应用”。我们这里使用模板方式，选择基于 Python 的 Web 应用。</p>
 <p>模板可以当做应用脚手架，选择适合的模板，可以自动完成相关依赖资源的创建，如角色、OSS、域名网关等，降低开发成本。</p>
 <h4>2. 新建函数</h4>
-<p><img src="assets/2020-09-21-060733.png" alt="4.png" /></p>
+<p><img src="assets/2020-09-21-060733.png" alt="png" /></p>
 <p>在应用下，创建函数，我们是开发 WebAPI，所以选择“HTTP”函数，这种函数会将指定的 http 请求作为触发器，来调度对应函数的执行。</p>
 <p>函数新建好之后，是个返回 helloWorld 的 demo，我们在此基础上来开发我们的业务逻辑。</p>
-<p><img src="assets/2020-09-21-060734.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-21-060734.png" alt="png" /></p>
 <p>首先介绍下上图代码中的 handler 函数，这个函数是入口函数，http 触发器接收到调用后会通过这个入口来启动整个函数。函数有两个入参，environ 和 start_response：</p>
 <ul>
 <li>environ</li>
@@ -215,11 +215,11 @@ function hide_canvas() {
 </ul>
 <p>该参数主要用于生成 http 请求的 response。</p>
 <h4>3. 配置触发器，绑定域名</h4>
-<p><img src="assets/2020-09-21-060736.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-21-060736.png" alt="png" /></p>
 <p>在新建函数时会自动创建一个 http 触发器，这个触发器的路径是“aliyun.com”的一个测试路径，只能用于测试，真实的应用需要通过自定义域名将真实域名与函数绑定，这样访问指定域名时，对应函数就会被触发执行。</p>
 <h4>4. 日志与监控</h4>
 <p>在每个函数编辑页面，日志和监控服务，函数的每次执行都会生成唯一的 requestId，日志中通过 requestId 进行查询，看到本次函数执行的所有日志。</p>
-<p><img src="assets/2020-09-21-060739.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-21-060739.png" alt="png" /></p>
 <h3>操作演示</h3>
 <p>点击链接即可观看演示视频：<a href="https://developer.aliyun.com/lesson_2024_18999">https://developer.aliyun.com/lesson<em>2024</em>18999</a></p>
 </div>
--- a/技术公开课（完）/14
+++ b/技术公开课（完）/14
@@ -181,19 +181,19 @@ function hide_canvas() {
 <p>**导读：**Serverless Kubernetes 是以容器和 kubernetes 为基础的 Serverless 服务，它提供了一种简单易用、极致弹性、最优成本和按需付费的 Kubernetes 容器服务，其无需节点管理和运维，无需容量规划，让用户更关注应用而非基础设施的管理。我们可以把 Serverless Kubernetes 简称为 ASK。</p>
 <h3>Serverless 容器</h3>
 <p>首先从 Serverless 开始讲起，相信我们已经熟知 Serverless 理念的核心价值，其中包括无需管理底层基础设施，无需关心底层 OS 的升级和维护，因为 Serverless 可以让我们更加关注应用开发本身，所以应用的上线时间更短。同时 Serverless 架构是天然可扩展的，当业务用户数或者资源消耗增多时，我们只需要创建更多的应用资源即可，其背后的扩展性是用户自己购买机器所无法比拟的。Serverless 应用一般是按需创建，用户无需为闲置的资源付费，可以降低整体的计算成本。</p>
-<p><img src="assets/2020-08-26-031155.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031155.png" alt="png" /></p>
 <p>以上所讲的几种都是 Serverless 理念的核心价值，也是 Serverless 容器与其他 Sererless 形态的相同之处。然而，Serverless 容器和其他 Serverless 形态的差异，在于它是基于容器的交付形态。</p>
-<p><img src="assets/2020-08-26-031156.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031156.png" alt="png" /></p>
 <p>基于容器意味着通用性和标准性，我们可以 Build once and Run anywhere，容器不受语言和库的限制，无论任何应用都可以制作成容器镜像，然后以容器的部署方式启动。基于容器的标准化，开源社区以 Kubernetes 为中心构建了丰富的云原生 Cloud Native 生态，极大地丰富了 Serverless 容器的周边应用框架和工具，比如可以非常方便地部署 Helm Chart 包。基于容器和 Kubernetes 标准化，我们可以轻松地在不同环境中（线上线下环境），甚至在不同云厂商之间进行应用迁移，而不用担心厂商锁定。这些都是 Serverless 容器的核心价值。</p>
-<p><img src="assets/2020-08-26-031157.png" alt="image.png" /> （Serverless 容器产品 Landscape）</p>
+<p><img src="assets/2020-08-26-031157.png" alt="png" /> （Serverless 容器产品 Landscape）</p>
 <p>当下各大云厂商都推出了自己的 Serverless 容器服务，上图为 Gartner 评估机构整理的 Serverless 容器产品 Landscape，其中阿里云有 Serverless Kubernetes ASK 和 ECI；AWS 有 Fargate，基于 Fargate 有 EKS on Fargate 和 ECS on Fargate 两种形态；Azure 有 ACI。另外 Gartner 也预测，到 2023 年，将有 70% 的 AI 应用以容器和 Serverless 方式运行。</p>
 <h3>ASK/ACK on ECI 容器服务</h3>
 <p>下面介绍阿里云 Serverless 容器产品家族：ECI、 ACK on ECI 和 Serverless Kubernetes。</p>
 <h4>1. ECI</h4>
-<p><img src="assets/2020-08-26-031159.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031159.png" alt="png" /></p>
 <p>ECI 全称是“Elastic Container Instance 弹性容器实例”，是 Serverless 容器的底层基础设施，实现了容器镜像的启动。ECI 让容器成为和 ECS 一样的云上一等公民。ECI 底层运行环境基于安全容器技术进行强隔离，每个 ECI 拥有一个独立的 OS 运行环境，保证运行时的安全性。ECI 支持 0.25c 到 64c 的 CPU 规格，也支持 GPU，按需创建按秒收费。和 ECS 一样，ECI 也支持 Spot 可抢占式实例，在一些场景中可以节省 90% 的成本。ECI 实例的启动时间目前约是 10s 左右，然后开始拉取容器镜像。我们也提供了镜像快照功能，每次容器启动时从快照中读取镜像，省去远端拉取的时间。值得强调的是，ECI 和 ECS 共用一个弹性计算资源池，这意味着 ECI 的弹性供给能力可以得到最大程度的充分保障，让 ECI 用户享受弹性计算资源池的规模化红利。</p>
 <p>ECI 只可以做到单个容器实例的创建，而没有编排的能力，比如让应用多副本扩容，让 SLB 和 Ingress 接入 Pod 流量，所以我们需要在编排系统 Kubernetes 中使用 ECI，我们提供了两种在 Kubernetes 中使用 ECI 的方式。一个是 ACK on ECI，另外一个是 ASK。</p>
-<p><img src="assets/2020-08-26-031201.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031201.png" alt="png" /></p>
 <p>在与 Kubernetes 编排系统的集成中，我们以 Pod 的形式管理每个 ECI 容器实例，每个 Pod 对应一个 ECI 实例， ECI Pod 之间相互隔离，一个 ECI Pod 的启动时间约是 10s。因为是在 Kubernetes 集群中管理 ECI Pod，所以完全连接了 Kubernetes 生态，有以下几点体现：</p>
 <ul>
 <li>很方便地用 Kubectl 管理 ECI Pod，可以使用标准的 Kubernetes 的 API 操作资源；</li>
@@ -206,42 +206,42 @@ function hide_canvas() {
 <p>这些都是使用 Kubernetes 管理容器实例的价值所在。</p>
 <p>需要留意的是 Kubernetes 中的 ECI Pod 是 Serverless 容器，所以与普通的 Pod 相比，不支持一些功能（比如 Daemonset），不支持 Prividge 权限，不支持 HostPort 等。除此之外，ECI Pod 与普通 Pod 能力一样，比如支持挂载云盘、NAS 和 OSS 数据卷等。</p>
 <h4>2. ACK on ECI</h4>
-<p><img src="assets/2020-08-26-31202.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-31202.png" alt="png" /></p>
 <p>接下来我们看下在 ACK Kubernetes 集群中使用 ECI 的方式。这种方式适合于用户已经有了一个 ACK 集群，集群中已经有了很多 ECS 节点，此时可以基于 ECI 的弹性能力来运行一些短时间 Short-Run 的应用，以解决元集群资源不足的问题，或者使用 ECI 来支撑应用的快速扩容，因为使用 ECI 进行扩容的效率要高于 ECS 节点扩容。</p>
 <p>在 ACK on ECI 中，ECS 和 ECI Pod 可以互联互通，ECI Pod 可以访问集群中的 Coredns，也可以访问 ClusterIP Service。</p>
 <h4>3. Serverless Kubernetes</h4>
-<p><img src="assets/2020-08-26-031203.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031203.png" alt="png" /></p>
 <p>与 ACK on ECI 不同的是，ASK Serverless Kubernetes 集群中没有 ECS 节点，这是和传统 Kubernetes 集群最主要的差异，所以在 ASK 集群中无需管理任何节点，实现了彻底的免节点运维环境，是一个纯粹的 Serverless 环境，它让 Kubernetes 的使用门槛大大降低，也丢弃了繁琐的底层节点运维工作，更不会遇到节点 Notready 等问题。在 ASK 集群中，用户只需关注应用本身，而无需关注底层基础设施管理。</p>
 <p>ASK 的弹性能力会优于普通 Kubernetes 集群，目前是 30s 创建 500 个 Pod 到 Running 状态。集群中 ECI Pod 默认是按量收费，但也支持 Spot 和预留实例劵来降低成本。在兼容性方面，ASK 中没有真实节点存在，所以不支持 Daemonset 等与节点相关的功能，像 Deployment / Statefulset / Job / Service / Ingress / CRD 等都是无缝支持的。</p>
 <p>ASK 中默认的 Ingress 是基于 SLB 7 层转发实现，用户无需部署 Nginx Ingress，维护更加简单。</p>
 <p>同时基于 SLB 7 层我们实现了 Knative Serving 能力，其中 Knative Controller 被 ASK 托管，用户无需负担 Controller 的成本。</p>
 <p>与 ACK 一样，ASK 和 Arms / SLS 等云产品实现了很好的集成，可以很方便地对 Pod 进行监控，把 Pod 日志收集到 SLS 中。</p>
-<p><img src="assets/2020-08-26-31204.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-31204.png" alt="png" /></p>
 <p>这是 ASK 的整体架构，核心部分是 ASK-Schduler，它负责 Watch Pod 的变化，然后创建对应的 ECI 实例，同时把 ECI 实例状态同步到 Pod。集群中没有真实 ECS 节点注册到 Apiserver。这个 Nodeless 架构解耦了 Kubernetes 编排层和 ECI 资源层，让 Kubernetes 彻底摆脱底层节点规模导致的弹性和容量限制，成为面向云的 Nodeless Kubernetes 弹性架构。</p>
 <h3>ASK 典型功能</h3>
 <p>下面介绍 ASK 的几个典型功能：</p>
 <h4>1. GPU 实例</h4>
-<p><img src="assets/2020-08-26-031205.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031205.png" alt="png" /></p>
 <p>第一个是 GPU 实例，在 Serverless 集群中使用 GPU 容器实例是一件非常简单的事情，不需要安装 GPU 驱动，只需要指定 GPU Pod 规格，以及容器需要的 GPU 卡数，然后就可以一键部署，这对于机器学习场景可以极大提高开发和测试的效率。</p>
 <h4>2. Spot 抢占式实例</h4>
-<p><img src="assets/2020-08-26-031207.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031207.png" alt="png" /></p>
 <p>第二个是 Spot 抢占式实例。抢占式实例是一种按需实例，可以在数据计算等场景中降低计算成本。抢占式实例创建成功后拥有一小时的保护周期。抢占式实例的市场价格会随供需变化而浮动，我们支持两种 Spot 策略，一种是完全根据市场出价，一种是指定价格上限，我们只需要给 Pod 加上对应的 Annotation 即可，使用方法非常简单。</p>
 <h4>3. 弹性负载 Elastic Workload</h4>
-<p><img src="assets/2020-08-26-031208.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031208.png" alt="png" /></p>
 <p>第三个重要功能是弹性负载 Elastic Workload，弹性负载实现了 Deployment 多个副本调度在不同的单元上，比如 ECS、ECI 和 ECI-Spot 上，通过这种混合调度的模式，可以降低负载的计算成本。在这个示例中，Deployment 是 6 个副本，其中 2 个为正常的 ECI Pod，其他副本为 ECI-Spot 实例。</p>
 <h3>ASK 使用场景</h3>
 <p>上面我们已经对 Serverless Kubernetes 做了基本的产品和功能介绍，那么 ASK 适合在哪些场景中使用呢？**</p>
 <h4>1. 免运维应用托管</h4>
-<p><img src="assets/2020-08-26-031210.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031210.png" alt="png" /></p>
 <p>Serverless 集群最大的特点是解决了底层节点资源的运维问题，所以其非常适合对应用的免运维托管，让用户关注在应用开发本身。在传统 K8s 集群中的应用可以无缝部署在 Serverless 集群中，包括各种 Helm Chart。同时结合预留实例劵可以降低 Pod 的长计算成本。</p>
 <h4>2. ECI 弹性资源池</h4>
-<p><img src="assets/2020-08-26-031212.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031212.png" alt="png" /></p>
 <p>第二个场景是 ACK on ECI 的优势，我们可以选择把 ECI 作为弹性资源池，加到已有的 Kubernetes 集群中，当应用业务高峰来临时，通过 ECI 动态灵活地扩容，相比 ECS 节点扩容更有效率，这种比较适合电商或者在线教育这类有着明显波峰波谷的业务场景，用户无需管理一个很大的节点资源池，通过 ECI 弹性能力来降低整体计算成本。</p>
 <h4>3. 大数据计算</h4>
-<p><img src="assets/2020-08-26-031213.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031213.png" alt="png" /></p>
 <p>第三个场景是大数据计算，很多用户使用 Serverless 集群或者 ACK on ECI 来进行 Spark / Presto / AI 等数据计算或者机器学习，利用 ECI 可以轻松解决资源规划和不足的问题。</p>
 <h4>4. CI/CD 持续集成</h4>
-<p><img src="assets/2020-08-26-031214.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031214.png" alt="png" /></p>
 <p>第四个场景是 CI/CD 持续集成，将 Jenkins 和 Gitlab-Runner 对接 ASK 集群，按需创建 CI/CD 构建任务，构建完成后直接部署到 ASK 测试环境进行验证，这样我们无需为 Job 类任务维护一个固定资源池，按需创建极大降低成本，另外如果结合 Spot 实例还能进一步降低成本。</p>
 <p>以上就是 Serverless Kubernetes 集群的典型场景，另有快速使用链接、产品文档以及使用示例，供大家学习交流：</p>
 <ul>
--- a/应用部署及扩缩容.md.html
+++ b/应用部署及扩缩容.md.html
@@ -210,7 +210,7 @@ function hide_canvas() {
 <h3>集群创建及应用部署</h3>
 <h4>1. 集群创建</h4>
 <p>在对 Serverless Kubernetes 的基础概念有了充分了解之后，我们直接进入容器服务控制台（<a href="https://cs.console.aliyun.com/#/authorize">https://cs.console.aliyun.com/#/authorize</a>）进行集群的创建。</p>
-<p><img src="assets/2020-08-26-031145.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031145.png" alt="png" /></p>
 <p>在创建页面，主要有三类属性需要选择或填写：</p>
 <ul>
 <li>集群创建的地域和 Kubernetes 的版本信息；</li>
@@ -218,7 +218,7 @@ function hide_canvas() {
 <li>集群能力和服务：可以按需选择。</li>
 </ul>
 <p>属性完成后，点击“创建集群”即可，整个创建过程需要 1~2 分钟的时间。</p>
-<p><img src="assets/2020-08-26-031147.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031147.png" alt="png" /></p>
 <h4>2. 应用部署</h4>
 <p>集群创建完成后，接下来我们部署一个无状态的 nginx 应用，主要分成三步：</p>
 <ul>
@@ -226,14 +226,14 @@ function hide_canvas() {
 <li>容器配置：镜像、所需资源、容器端口、数据卷等；</li>
 <li>高级配置：服务、路由、HPA、POD 标签等。</li>
 </ul>
-<p><img src="assets/2020-08-26-031148.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031148.png" alt="png" /></p>
 <p>创建完成后，在路由中就可以看到服务对外暴露的访问方式了。</p>
-<p><img src="assets/2020-08-26-031150.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031150.png" alt="png" /></p>
 <p>如上图所示，在本地 host 绑定 <code>ask-demo.com</code> 到路由端点 <code>123.57.252.131</code> 的解析，然后浏览器访问域名，即可请求到部署的 nginx 应用。</p>
 <h3>常用功能介绍</h3>
 <p>我们一般会通过容器服务控制台和 Kubectl 两种方式，来使用 Serverless Kubernetes 的常用功能。</p>
 <h4>1. 容器服务控制台</h4>
-<p><img src="assets/2020-08-26-031151.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031151.png" alt="png" /></p>
 <p>在容器服务控制台上，我们可以进行以下功能的白屏化操作：</p>
 <ul>
 <li>基本信息：集群 ID 和运行状态、API Server 端点、VPC 和安全性、集群访问凭证的查看和操作；</li>
@@ -248,7 +248,7 @@ function hide_canvas() {
 </ul>
 <h4>2. Kubectl</h4>
 <p>除了通过控制台，我们还可以基于 Kubectl 来进行集群操作和管理。</p>
-<p><img src="assets/2020-08-26-031153.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031153.png" alt="png" /></p>
 <p>我们可以在云端通过 CloudShell 来使用 Kubectl，也可以在本地安装 Kubectl，然后通过将集群的访问凭证写入到 kubeconfig 来使用 Serverless Kubernetes 。</p>
 <h3>应用弹性伸缩</h3>
 <p>通通过上面的内容讲解，我们已经了解了应用的部署和集群的常用操作，下面为大家介绍一下如何为应用做扩缩容操作。</p>
--- a/技术公开课（完）/16
+++ b/技术公开课（完）/16
@@ -179,14 +179,14 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>16 使用 Spot 低成本运行 Job 任务</h1>
 <h3>成本优化</h3>
-<p><img src="assets/2020-08-26-031132.jpg" alt="1.jpg" /></p>
+<p><img src="assets/2020-08-26-031132.jpg" alt="png" /></p>
 <p>ECI 除了有秒级弹性、无限容量的优势之外，在一些特定场景下对成本的优化也是非常明显的，通过上图我们可以看到，相同规格的实例，在日运行时间少于 14 小时的时候，使用 ECI 会更加便宜。</p>
-<p><img src="assets/2020-08-26-031133.jpg" alt="2.jpg" /></p>
+<p><img src="assets/2020-08-26-031133.jpg" alt="png" /></p>
 <p>除了日运行时长小于 14 小时的情形，ECI 实例还支持多种计费类型，客户可以根据自身业务选择相应的计费模式：long run 类型的可以采用 RI 实例券；运行时长低于 1 小时可以选用 Spot 竞价实例；针对突发流量部分，采用按量实例。</p>
 <h3>Spot 实例概述</h3>
-<p><img src="assets/2020-08-26-031135.jpg" alt="3.jpg" /></p>
+<p><img src="assets/2020-08-26-031135.jpg" alt="png" /></p>
 <p>抢占式实例是一种按需实例，可以在数据计算等场景中降低计算成本。抢占式实例创建成功后拥有一小时的保护周期。抢占式实例的市场价格会随供需变化而浮动，我们支持两种 spot 策略，一种是完全根据市场出价，一种是指定价格上限，我们只需要给 pod 加上对应的 annotation 即可，使用方法非常简单。</p>
-<p><img src="assets/2020-08-26-031137.jpg" alt="4.jpg" /></p>
+<p><img src="assets/2020-08-26-031137.jpg" alt="png" /></p>
 <ul>
 <li>SpotAsPriceGo：系统自动出价，跟随当前市场实际价格（通常以折扣的形式体现）</li>
 <li>SpotWithPriceLimit：设置抢占实例价格上限</li>
@@ -195,16 +195,16 @@ function hide_canvas() {
 <li>用户价格 &gt;= ECI 按量实例价格，使用 ECI 按量实例价格来创建实例。</li>
 </ul>
 <h3>创建 Spot 实例</h3>
-<p><img src="assets/2020-08-26-031138.jpg" alt="5.jpg" /></p>
+<p><img src="assets/2020-08-26-031138.jpg" alt="png" /></p>
 <ul>
 <li>根据规格查看实例按量价格，<a href="https://www.aliyun.com/price/product#/ecs/detail">点击查询</a></li>
 </ul>
 <p>首先我们查询出【华北 2（北京）地域 ecs.c5.large 按量（小时）价格：0.62】，然后我们以此规格来创建 Spot 竞价实例。</p>
-<p><img src="assets/2020-08-26-031140.jpg" alt="6.jpg" /></p>
+<p><img src="assets/2020-08-26-031140.jpg" alt="png" /></p>
 <p>采用 Spot 实例来运行 CronJob，分别采用“指定最高限价”、“系统自动出价”的方式。随市场价的场景目前还没有办法直接看到真实的价格，只能根据实例 ID 查询账单信息。</p>
-<p><img src="assets/2020-08-26-031141.jpg" alt="7.jpg" /></p>
+<p><img src="assets/2020-08-26-031141.jpg" alt="png" /></p>
 <p>采用 Spot 实例运行 Deployment，在本次实验中我们采用指定最高限价的策略，并设置一个极低的小时价格，可以看到 2 个 Pod 都创建失败了，使用 kubectl describe 命令可以看到失败的详细原因为价格不匹配：The current price of recommend instanceTypes above user max price。</p>
-<p><img src="assets/2020-08-26-031142.jpg" alt="8.jpg" /></p>
+<p><img src="assets/2020-08-26-031142.jpg" alt="png" /></p>
 <p>如上图所示，当 Spot 实例运行超过 1 小时保护期后，有可能会因为库存不足，或者设置的价格小于市场价而触发实例释放，实例释放前 3 分钟会有事件通知。</p>
 <h3>应用场景</h3>
 <p>您可以在抢占式实例上部署以下业务：</p>
--- a/技术公开课（完）/17
+++ b/技术公开课（完）/17
@@ -181,22 +181,22 @@ function hide_canvas() {
 <h3>产品介绍</h3>
 <h4>阿里云弹性容器实例 ECI</h4>
 <p>ECI 提供安全的 Serverless 容器运行服务。无需管理底层服务器，只需要提供打包好的 Docker 镜像，即可运行容器，并仅为容器实际运行消耗的资源付费。</p>
-<p><img src="assets/2020-08-26-031216.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031216.png" alt="png" /></p>
 <h4>阿里云容器服务产品族</h4>
-<p><img src="assets/2020-08-26-031217.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031217.png" alt="png" /></p>
 <p>不论是托管版的 Kubernetes（ACK）还是 Serverless 版 Kubernetes（ASK），都可以使用 ECI 作为容器资源层，其背后的实现就是借助虚拟节点技术，通过一个叫做 Virtual Node 的虚拟节点对接 ECI。</p>
-<p><img src="assets/2020-08-26-031219.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031219.png" alt="png" /></p>
 <h4>Kubernetes + ECI</h4>
 <p>有了 Virtual Kubelet，标准的 Kubernetes 集群就可以将 ECS 和虚拟节点混部，将 Virtual Node 作为应对突发流量的弹性资源池。</p>
-<p><img src="assets/2020-08-26-031228.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031228.png" alt="png" /></p>
 <h4>ASK（Serverless Kubernetes）+ ECI</h4>
 <p>Serverless 集群中没有任何 ECS worker 节点，也无需预留、规划资源，只有一个 Virtual Node，所有的 Pod 的创建都是在 Virtual Node 上，即基于 ECI 实例。</p>
-<p><img src="assets/2020-08-26-031231.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031231.png" alt="png" /></p>
 <p>Serverless Kubernetes 是以容器和 Kubernetes 为基础的 Serverless 服务，它提供了一种简单易用、极致弹性、最优成本和按需付费的 Kubernetes 容器服务，其中无需节点管理和运维，无需容量规划，让用户更关注应用而非基础设施的管理。</p>
 <h3>Spark on Kubernetes</h3>
 <p>Spark 自 2.3.0 开始试验性支持 Standalone、on YARN 以及 on Mesos 之外的新的部署方式：<a href="https://spark.apache.org/docs/2.3.0/running-on-kubernetes.html">Running Spark on Kubernetes</a>，如今支持已经非常成熟。</p>
 <h4>Kubernetes 的优势</h4>
-<p><img src="assets/2020-08-26-031232.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031232.png" alt="png" /></p>
 <p>Spark on kubernetes 相比于 on Yarn 等传统部署方式的优势：</p>
 <ul>
 <li>统一的资源管理。不论是什么类型的作业都可以在一个统一的 Kubernetes 集群中运行，不再需要单独为大数据作业维护一个独立的 YARN 集群。</li>
@@ -207,11 +207,11 @@ function hide_canvas() {
 <li>大数据上云。目前大数据应用上云常见的方式有两种：1）用 ECS 自建 YARN（不限于 YARN）集群；2）购买 EMR 服务，目前所有云厂商都有这类 PaaS，如今多了一个选择——Kubernetes。</li>
 </ul>
 <h4>Spark 调度</h4>
-<p><img src="assets/2020-08-26-031234.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031234.png" alt="png" /></p>
 <p>图中橙色部分是原生的 Spark 应用调度流程，而 Spark on Kubernetes 对此做了一定的扩展（黄色部分），实现了一个 <strong>KubernetesClusterManager</strong>。其中 **KubernetesClusterSchedulerBackend <strong>扩展了原生的</strong>CoarseGrainedSchedulerBackend，**新增了 **ExecutorPodsLifecycleManager、ExecutorPodsAllocator 和 KubernetesClient **等组件，实现了将标准的 Spark Driver 进程转换成 Kubernetes 的 Pod 进行管理。</p>
 <h4>Spark submit</h4>
 <p>在 Spark Operator 出现之前，在 Kubernetes 集群提交 Spark 作业只能通过 Spark submit 的方式。创建好 Kubernetes 集群，在本地即可提交作业。</p>
-<p><img src="assets/2020-08-26-031237.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031237.png" alt="png" /></p>
 <p>作业启动的基本流程：</p>
 <ul>
 <li>Spark 先在 K8s 集群中创建 Spark Driver（pod）。</li>
@@ -222,14 +222,14 @@ function hide_canvas() {
 <p>直接通过这种 Spark submit 的方式，参数非常不好维护，而且不够直观，尤其是当自定义参数增加的时候；此外，没有 Spark Application 的概念了，都是零散的 Kubernetes Pod 和 Service 这些基本的单元，当应用增多时，维护成本提高，缺少统一管理的机制。</p>
 <h4>Spark Operator</h4>
 <p><a href="https://github.com/GoogleCloudPlatform/spark-on-k8s-operator">Spark Operator</a> 就是为了解决在 Kubernetes 集群部署并维护 Spark 应用而开发的，Spark Operator 是经典的 CRD + Controller，即 Kubernetes Operator 的实现。</p>
-<p><img src="assets/2020-08-26-031240.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031240.png" alt="png" /></p>
 <p>下图为 SparkApplication 状态机：</p>
-<p><img src="assets/2020-08-26-031242.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031242.png" alt="png" /></p>
 <h4>Serverless Kubernetes + ECI</h4>
 <p>那么，如果在 Serverless Kubernetes 集群中运行 Spark，其实际上是对原生 Spark 的进一步精简。</p>
-<p><img src="assets/2020-08-26-031247.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031247.png" alt="png" /></p>
 <h4>存储选择</h4>
-<p><img src="assets/2020-08-26-031248.png" alt="image.png" /></p>
+<p><img src="assets/2020-08-26-031248.png" alt="png" /></p>
 <p>对于批量处理的数据源，由于集群不是基于 HDFS 的，所以数据源会有不同，需要计算与存储分离，Kubernetes 集群只负责提供计算资源。</p>
 <ul>
 <li>数据源的存储可以采用阿里云对象存储 OSS、阿里云分布式存储 HDFS 等。</li>
--- a/机器学习开箱即用.md.html
+++ b/机器学习开箱即用.md.html
@@ -179,13 +179,13 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>18 GPU 机器学习开箱即用</h1>
 <h3>ECI GPU 简介</h3>
-<p><img src="assets/2020-09-27-030650.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030650.png" alt="png" /></p>
 <p>相较于普通的 ECI 实例，ECI GPU 实例为用户容器提供了 GPU 资源以加速机器学习等任务的运行，其典型架构如上图所示。ECI GPU 实例预装了 GPU 驱动，免去了用户安装和维护 GPU 驱动的麻烦。同时，ECI GPU 实例同普通的 ECI 实例一样兼容 CRI 接口，Kubernetes 也可以直接对 ECI GPU 实例进行调度和编排。此外，利用官方容器镜像，用户无需关心 CUDA Toolkit/Tensorflow/PyTorch 等工具和框架的搭建部署，只需要专注于具体业务功能的开发和实现。</p>
 <p>通过 ECI GPU 实例，用户可以一键式部署和运行经过 GPU 加速的机器学习等业务，简单方便。</p>
 <h3>ECI GPU 基本实现原理</h3>
 <p>大家知道，容器一般是通过内核接口访问主机上的资源。但是对于 GPU 资源，容器无法直接通过内核接口访问到，只能通过厂商驱动与 GPU 进行交互。</p>
 <p>那么，ECI GPU 实例是如何让用户容器实例访问到 GPU 资源的呢？本质上，ECI GPU 就是在用户容器创建时将 GPU 驱动的一些必要的动态库文件挂载到用户容器中，从而使得用户容器可以通过这些挂载的动态库文件访问到位于 Host 端的 GPU。</p>
-<p><img src="assets/2020-09-27-030655.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030655.png" alt="png" /></p>
 <p>ECI GPU 的基本实现框架如上图所示，图中所有方框代表的组件都运行在 ECI HostOS 侧。其中 ContainerAgent 是自研的一个组件，可以类比与 Kubelet，其接受来自管控的指令；右上角的 nvidia-container-runtime-hook 是 NVIDIA 开源实现的一个符合 OCI 标准的一个 prestart hook，prestart hook 用于在容器执行用户指定的的命令前执行一些自定义配置操作；右侧中间位置的 libnvidia-container 也是一个 NVIDIA 开源的一个组件，用于将 Host 侧 GPU 驱动的动态库挂载到指定容器中。</p>
 <p>简单介绍一下 ECI GPU 下的容器启动流程：</p>
 <ol>
@@ -195,17 +195,17 @@ function hide_canvas() {
 <li>容器创建完成后，用户容器进程通过上述挂载的动态库文件访问并使用 GPU 资源</li>
 </ol>
 <h3>ECI GPU 使用方式</h3>
-<p><img src="assets/2020-09-27-030656.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030656.png" alt="png" /></p>
 <p>目前在 ACK/ASK 集群中使用 GPU，只需要在 YAML 文件中指定两个字段即可，如上图标红处所示。</p>
 <p>第一个字段是 k8s.aliyun.com/eci-use-specs，该字段用于指定 ECI GPU 实例规格，当前阿里云上可用的 ECI GPU 实例规格已经列在左图的表格中了。</p>
 <p>第二个字段是 nvidia.com/gpu，该字段用于指定该容器所要使用的 GPU 数量。注意，spec 中所有容器指定要使用的 GPU 数量总和不能超过 k8s.aliyun.com/eci-use-specs 字段指定的 ECI GPU 实例规格所提供的 GPU 数量，否则容器会创建失败。</p>
 <h3>演示</h3>
 <p>视频演示过程请点击<a href="https://developer.aliyun.com/lesson_2025_19014">【视频课链接】</a>进行学习。</p>
 <p>最后简单演示一下如何在 ACK 集群中使用 GPU 加速执行机器学习任务。我们以在 ASK 集群中进行 MNIST（手写数字识别）训练任务为例：</p>
-<p><img src="assets/2020-09-27-030658.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030658.png" alt="png" /></p>
 <p>该任务由 YAML 文件定义，如上图所示。我们在 YAML 文件中指定了 ECI GPU 实例类型，该实例类型包含一颗 NVIDIA P4 GPU。然后我们指定了容器镜像为 nvcr.io/nvidia/pytorch，该镜像是由 NVIDIA 提供，内部已经封装好了 CUDA/PyTorch 等工具。最后，我们通过 nvidia.com/gpu 指定了要使用的 GPU 数量为 1。</p>
 <p>如上图所示，在 ASK 集群中，我们选择使用模板创建应用实例，然后在模板中输入右侧 YAML 文件的内容，最后点击创建即可创建一个使用 GPU 的容器了。</p>
-<p><img src="assets/2020-09-27-030659.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030659.png" alt="png" /></p>
 <p>容器创建完成之后，首先我们通过 kubectl 命令登录到我们创建的容器中，然后执行 nvidia-smi 命令确认 GPU 是否可用。如上图中的左上角截图所示，nvidia-smi 命令成功返回了 GPU 的信息，如 GPU 的型号的 P4，驱动版本号是 418.87.01，CUDA 版本为 10.1 等，这表示了我们创建的容器是可以正常使用 GPU 资源的。</p>
 <p>接着，如上图中的右侧截图所示，我们进入 /workspace/examples/mnist 目录下执行 python main.py 开始执行 MNIST 训练任务，MNIST 训练任务会先下载 MNIST 数据集，由于 MNIST 数据集较大可能下载时间会比较长。下载完数据集后，MNIST 训练任务会开始进行数据集的训练。</p>
 <p>当 MNIST 任务执行完之后，我们会看到训练结果打印在屏幕上，如上图中左下角截图所示。MNIST 测试集包含 10000 张测试图片，从结果图片我们可以看到其中由 9845 张手写数字图片都被正确识别了，精度已经是相当高。有兴趣的同学可以对比测试一下不使用 GPU 场景下的 MNIST 任务所用的训练时间。</p>
--- a/低成本部署在线应用，灵活自动伸缩.md.html
+++ b/低成本部署在线应用，灵活自动伸缩.md.html
@@ -179,7 +179,7 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>19 基于 Knative 低成本部署在线应用，灵活自动伸缩</h1>
 <h3>为什么需要 Knative</h3>
-<p><img src="assets/2020-09-27-030700.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030700.png" alt="png" /></p>
 <p>Serverless 已经是万众期待，未来可期的状态。各种调查报告显示企业及开发者已经在使用 Serverless 构建线上服务，而且这个比例还在不断增加。</p>
 <p>在这个大趋势下，我们再来看 IaaS 架构的演进方向。最初企业上云都是基于 VM 的方式在使用云资源，企业线上服务都是通过 Ansible、Saltstack、Puppet 或者 Chef 等工具裸部在 VM 中的。直接在 VM 中启动应用，导致线上服务对 VM 的环境配置有很强的依赖，而后伴随着容器技术的崛起，大家开始通过容器的方式在 VM 中部署应用。</p>
 <p>但如果有十几个甚至几十个应用需要部署，就需要在成百上千的 VM 快速部署、升级应用，这是一件非常令人头疼的事情。而 Kubernetes 很好地解决了这些问题，所以现在大家开始通过 Kubernetes 方式使用云资源。随着 Kubernetes 的流行，各大云厂商都开始提供 Serverless Kubernetes 服务，用户无需维护 Kubernetes 集群，即可直接通过 Kubernetes 语义使用云的能力。</p>
@@ -205,12 +205,12 @@ function hide_canvas() {
 </ul>
 <p>多个应用部署在同一个集群中，需要一个接入层网关对多个应用以及同一个应用的不同版本进行流量的管理。</p>
 <p>随着 Kubernetes 和云原生概念的崛起，第一直觉可能是直接在 Kubernetes 之上部署 Serverless 应用。那么，如果要在原生的 Kubernetes 上部署 Serverless 应用我们可能会怎么做？</p>
-<p><img src="assets/2020-09-27-030703.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030703.png" alt="png" /></p>
 <p>首先需要一个 Deployment 来管理 Workload，还需要通过 Service 对外暴露服务和实现服务发现的能力。应用有重大变更，新版本发布时可能需要暂停观察，待观察确认没问题之后再继续增加灰度的比例。这时就要使用两个 Deployment 才能做到。</p>
 <p>v1 Deployment 代表旧版本，灰度的时候逐一减少实例数；v2 Deployment 代表新版本，灰度的时候逐一增加实例数。hpa 代表弹性能力，每一个 Deployment 都有一个 hpa 管理弹性配置。</p>
 <p>这其中其实是有冲突的：假设 v1 Deploymen 原本有三个 pod，灰度的时候升级一个 pod 到 v2，此时其实是 1/3 的流量会打到 v2 版本上。但当业务高峰到来后，因为两个版本都配置了 hpa，所以 v2 和 v1 会同时扩容，最终 v1 和 v2 的 pod 数量就不是最初设置的 1/3 的比例了。</p>
 <p>所以传统的这种按照 Deployment 实例数发布的灰度策略和弹性配置天然是冲突的。而如果按照流量比例进行灰度就不会有这个问题，这可能就要引入 Istio 的能力。</p>
-<p><img src="assets/2020-09-27-030704.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030704.png" alt="png" /></p>
 <p>引入 Istio 作为 Gateway 组件，Istio 除了管理同一个应用的流量灰度，还能对不同的应用进行流量管理。看起来很好，但是我们再仔细分析一下存在什么问题。先梳理一下在原生 K8s 之上手动管理 Serverless 应用都需要做什么：</p>
 <ul>
 <li>Deployment</li>
@@ -222,43 +222,43 @@ function hide_canvas() {
 <li>Gateway</li>
 </ul>
 <p>这些资源是每一个应用维护一份，如果是多个应用就要维护多份。这些资源散落在 K8s 内，根本看不出来应用的概念，另外管理起来也非常繁琐。</p>
-<p><img src="assets/2020-09-27-030705.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030705.png" alt="png" /></p>
 <p>Serverless 应用需要的是面向应用的管理动作，比如应用托管、升级、回滚、灰度发布、流量管理以及弹性等功能。而 Kubernetes 提供的是 IaaS 的使用抽象。所以 Kubernetes 和 Serverless 应用之间少了一层应用编排的抽象。</p>
 <p>而 Knative 就是建立在 Kubernetes 之上的 Serverless 应用编排框架。除了 Knative 以外，社区也有好几款 FaaS 类的编排框架，但这些框架编排出来的应用没有统一的标准，每一个框架都有一套自己的规范，而且和 Kubernetes API 完全不兼容。不兼容的 API 就导致使用难度高、可复制性不强。云原生的一个核心标准就是 Kubernetes 的 API 标准，Knative 管理的 Serverless 应用保持 Kubernetes API 语义不变。和 Kubernetes API 具有良好的兼容性，就是 Knative 的云原生特性所在。</p>
 <h3>Knative 是什么？</h3>
-<p><img src="assets/2020-09-27-030707.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030707.png" alt="png" /></p>
 <p>Knative 主要解决的问题就是在 Kubernetes 之上提供通用的 Serverless 编排、调度服务，给上层的 Serverless 应用提供面向应用层的原子操作。并且通过 Kubernetes 原生 API 暴露服务 API，保持和 Kubernetes 生态工具链的完美融合。Knative 有 Eventing 和 Serving 两个核心模块，本文主要介绍 Serving 的核心架构。</p>
 <h4>Knative Serving 简介</h4>
-<p><img src="assets/2020-09-27-030708.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030708.png" alt="png" /></p>
 <p>Serving 核心是 Knative Service，Knative Controller 通过 Service 的配置自动操作 Kubernetes Service 和 Deployment，从而实现简化应用管理的目标。</p>
 <p>Knative Service 对应一个叫做 Configuration 的资源，每次 Service 变化如果需要创建新的 Workload 就更新 Configuration，然后每次 Configuration 更新都会创建一个唯一的 Revision。Revision 可以认为是 Configuration 的版本管理机制。理论上 Revision 创建完以后是不会修改的。</p>
 <p>Route 主要负责 Knative 的流量管理，Knative Route Controller 通过 Route 的配置自动生成 Knative Ingress 配置，Ingress Controller 基于 Ingress 策略实现路由的管理。</p>
 <p>Knative Serving 对应用 Workload 的 Serverless 编排是从流量开始的。流量首先达到 Knative 的 Gateway，Gateway 根据 Route 的配置自动把流量根据百分比拆分到不同的 Revision 上，然后每一个 Revision 都有一个自己独立的弹性策略。当过来的流量请求变多时，当前 Revision 就开始自动扩容。每一个 Revision 的扩容策略都是独立的，相互不影响。</p>
 <p>基于流量百分比对不同的 Revision 进行灰度，每一个 Revision 都有一个独立的弹性策略。Knative Serving 通过对流量的控制实现了流量管理、弹性和灰度三者的完美结合。接下来具体介绍一下 Knative Serving API 细节。</p>
-<p><img src="assets/2020-09-27-030709.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030709.png" alt="png" /></p>
 <p>上图展示了 Knative Autoscaler 的工作机制，Route 负责接入流量，Autoscaler 负责做弹性伸缩。当没有业务请求时会缩容到零，缩容到零后 Route 进来的请求会转到 Activator 上。当第一个请求进来之后 Activator 会保持住 http 链接，然后通知 Autoscaler 去做扩容。Autoscaler 把第一个 pod 扩容完成以后 Activator 就把流量转发到 Pod，从而做到了缩容到零也不会损失流量的目的。</p>
 <p>到此 <a href="https://knative-sample.com/20-serving/">Knative Serving 的核心模块和基本原理</a>已经介绍完毕，你应该对 Knative 已经有了初步了解。在介绍原理的过程中你可能也感受到了，要想把 Knative 用起来其实还是需要维护很多 Controller 组件、Gateway 组件（比如 Istio)）的，并且要持续地投入 IaaS 成本和运维成本。</p>
-<p><img src="assets/2020-09-27-030710.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030710.png" alt="png" /></p>
 <p>Gateway 组件假设使用 istio 实现的话，Istio 本身就需要十几个 Controller，如果要做高可用可能就需要二十几个 Controller。Knative Serving Controller 全都高可用部署也需要十几个。这些 Controller 的 IaaS 成本和运维成本都比较多。另外冷启动问题也很明显，虽然缩容到零可以降低业务波谷的成本，但是第一批流量也可能会超时。</p>
 <h3>Knative 和云的完美融合</h3>
 <p>为了解决上述问题，我们把 Knative 和阿里云做了深度的融合。用户还是按照 Knative 的原生语义使用，但底层的 Controller 、Gateway 都深度嵌入到阿里云体系内。这样既保证了用户可以无厂商锁定风险地以 Knative API 使用云资源，还能享受到阿里云基础设施的已有优势。</p>
-<p><img src="assets/2020-09-27-030711.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030711.png" alt="png" /></p>
 <p>首先是 Gateway 和云的融合，直接使用阿里云 SLB 作为 Gateway，使用云产品 SLB 的好处有：</p>
 <ul>
 <li>云产品级别的支撑，提供 SLA 保障；</li>
 <li>按需付费，不需要出 IaaS 资源；</li>
 <li>用户无需承担运维成本，不用考虑高可用问题，云产品自带高可用能力。</li>
 </ul>
-<p><img src="assets/2020-09-27-030713.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030713.png" alt="png" /></p>
 <p>除了 Gateway 组件以外，Knative Serving Controller 也需要一定的成本，所以我们把 Knative Serving Controller 和阿里云容器服务也进行了融合。用户只需要拥有一个 Serverless Kubernetes 集群并开通 Knative 功能就可以基于 Knative API 使用云的能力，并且用户无需为 Knative Controller 付出任何成本。</p>
-<p><img src="assets/2020-09-27-030714.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030714.png" alt="png" /></p>
 <p>接下来再分析一下冷启动问题。</p>
 <p>传统应用在没开启弹性配置的时候实例数是固定的，Knative 管理的 Serverless 应用默认就有弹性策略，在没有流量的时候会缩容到零。传统应用在流量低谷时即便没有业务请求处理，实例数还保持不变，这其实是浪费资源的。但好处就是请求不会超时，什么时候过来的请求都可以会很好地处理。而如果缩容到零，第一个请求到达以后才会触发扩容的过程。</p>
 <p>Knative 的模型中从 0 到 1 扩容需要 5 个步骤串行进行，这 5 个步骤都完成以后才能开始处理第一个请求，而此时往往都会超时。所以 Knative 缩容到零虽然降低了常驻资源的成本，但第一批请求的冷启动问题也非常明显。可见弹性其实就是在寻找成本和效率的一个平衡点。</p>
-<p><img src="assets/2020-09-27-030716.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030716.png" alt="png" /></p>
 <p>为了解决第一个实例的冷启动问题，我们推出了保留实例功能。保留实例是阿里云容器服务 Knative 独有的功能。社区的 Knative 默认在没有流量时缩容到零，但是缩容到零之后从 0 到 1 的冷启动问题很难解决。冷启动除了要解决 IaaS 资源的分配、Kubernetes 的调度、拉镜像等问题以外，还涉及到应用的启动时长。应用启动时长从毫秒到分钟级别都有。应用启动时间完全是业务行为，在底层平台层面几乎无法控制。</p>
 <p>ASK Knative 对这个问题的解法是通过低价格的保留实例，来平衡成本和冷启动问题。阿里云 ECI 有很多规格，不同规格的计算能力不一样，价格也不一样。如下所示是对 2c4G 配置的计算型实例和突发性能型实例的价格对比。</p>
-<p><img src="assets/2020-09-27-030717.png" alt="image.png" /></p>
+<p><img src="assets/2020-09-27-030717.png" alt="png" /></p>
 <p>通过上图可知突发性能实例比计算型便宜 46%，可见如果在没有流量时，使用突发性能实例提供服务不单单解决了冷启动的问题，还能节省很多成本。</p>
 <p>突发性能实例除了价格优势以外，还有一个非常亮眼的功能就是 CPU 积分。突发性能实例可以利用 CPU 积分应对突发性能需求。突发性能实例可以持续获得 CPU 积分，在性能无法满足负载要求时，可以通过消耗积累的 CPU 积分无缝提高计算性能，不会影响部署在实例上的环境和应用。通过 CPU 积分，您可以从整体业务角度分配计算资源，将业务平峰期剩余的计算能力无缝转移到高峰期使用（简单的理解就是油电混动）。突发性能实例的更多细节参见<a href="https://help.aliyun.com/document_detail/59977.html">这里</a>。</p>
 <p>所以 ASK Knative 的策略是在业务波谷时使用突发性能实例替换标准的计算型实例，当第一个请求来临时再无缝切换到标准的计算型实例。这样可以降低流量低谷的成本，并且在低谷时获得的 CPU 积分，还能在业务高峰到来时消费掉，用户支付的每一分钱都不会浪费。</p>
--- a/技术公开课（完）/20
+++ b/技术公开课（完）/20
@@ -179,7 +179,7 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>20 快速构建 JenkinsGitlab 持续集成环境</h1>
 <h3>ASK 介绍</h3>
-<p><img src="assets/2020-10-26-040914.png" alt="1.PNG" /></p>
+<p><img src="assets/2020-10-26-040914.png" alt="png" /></p>
 <p>首先，ASK 是什么？ASK 是阿里云推出的无服务器版 Kubernetes 容器服务。与传统的 Kubernetes 服务相比，ASK最大的特点就是通过虚拟节点接入 Kubernetes 集群，而 Kubernetes 的 Master 节点也完全由阿里云容器服务托管。因此，在整个 ASK 集群中，用户无需管理和运维真实节点，只用关心 Pod 资源即可，ASK 中的 Pod 则由阿里云弹性容器实例 ECI 承载。</p>
 <p><strong>ASK 的优势主要有以下几点：</strong></p>
 <ul>
@@ -197,7 +197,7 @@ function hide_canvas() {
 </ul>
 <h3>GitLab CI on ASK 的优势</h3>
 <p>说到 CI/CD，大家最熟悉的两个工具，一个是 Jenkins，另一个是 GitLab CI，随着 Devops 角色的流行，越来越多的企业采用 GitLab CI 作为持续集成的工具，下面给大家介绍下 GitLab CI on ASK。gitlab-runner 以 Pod 形式注册到 ASK 集群中，每个 CI/CD stage 也对应一个 Pod。</p>
-<p><img src="assets/2020-10-26-040920.png" alt="2.png" /></p>
+<p><img src="assets/2020-10-26-040920.png" alt="png" /></p>
 <p><strong>这么做的优势有以下几点：</strong></p>
 <ul>
 <li>服务高可用（Deployment+PVC）；</li>
@@ -220,15 +220,15 @@ function hide_canvas() {
 <ul>
 <li>在【<a href="https://cs.console.aliyun.com/?spm=5176.eciconsole.0.0.68254a9cNv12zh#/k8s/cluster/createV2/serverless">容器服务控制台</a>】创建标准 Serverless K8s 集群</li>
 </ul>
-<p><img src="assets/2020-10-26-040922.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040922.png" alt="png" /></p>
 <ul>
 <li>集群创建完成后，基本信息中有 API server 公网链接地址</li>
 </ul>
-<p><img src="assets/2020-10-26-040923.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040923.png" alt="png" /></p>
 <ul>
 <li>连接信息中有 ASK 集群访问凭证</li>
 </ul>
-<p><img src="assets/2020-10-26-040925.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040925.png" alt="png" /></p>
 <h4>2. 准备 PV/PVC</h4>
 <p>准备两个 nas 盘，一个做 gitlab runner cache，一个做 maven 仓库，请自行替换 nas server 地址和 path</p>
 <pre><code class="language-shell">kubectl apply -f mvn-pv.yaml
@@ -268,15 +268,15 @@ kubectl apply -f imagecache.yaml
 <h4>6. 部署 gitlab runner</h4>
 <pre><code class="language-shell">kubectl apply -f gitlab-runner-deployment.yaml
 </code></pre>
-<p><img src="assets/2020-10-26-040927.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040927.png" alt="png" /></p>
 <h4>7. 进行一个简单的 CI 任务</h4>
-<p><img src="assets/2020-10-26-040929.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040929.png" alt="png" /></p>
 <p>git repo 中的 .gitlab-ci.yml 类似 Jenkinsfile，定义了构建任务的工作流。我们修改 demo 项目中的 src/main/webapp/index.jsp 文件，然后 git commit -m &quot;change index info&quot; 提交。 gitlab 中的流水线任务即被触发，整个流程涉及到编译、打包、部署。</p>
-<p><img src="assets/2020-10-26-040930.png" alt="image.png" /></p>
-<p><img src="assets/2020-10-26-040931.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040930.png" alt="png" /></p>
+<p><img src="assets/2020-10-26-040931.png" alt="png" /></p>
 <h3>成本</h3>
 <p>使用 ASK 与一台预付费 ECS 的成本对比：</p>
-<p><img src="assets/2020-10-26-040932.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-26-040932.png" alt="png" /></p>
 <p>从上述成本计算可以看出，当您每天的 CI/CD 任务少于 126 个时，使用 ASK+ECI 会比购买一台包年包月的 ECS 更加划算。在享受按需付费的同时，也降低了运维成本，更加重要的是，当业务规模扩大、CI/CD 任务数量陡增时，不再需要担心 Node 节点的扩容。ASK+ECI 的方案，可以被认为是 CI/CD 持续集成场景的量身标配。</p>
 </div>
                    </div>
--- a/技术公开课（完）/21
+++ b/技术公开课（完）/21
@@ -189,32 +189,32 @@ function hide_canvas() {
 </ul>
 <h3>SAE 产品介绍</h3>
 <p>那么摆在 Serverless 技术落地面前的三座大山该如何解决呢？给大家分享一款低门槛，无需任何代码改造就能直接使用的 Serverless PaaS 平台（SAE），是企业在线业务平滑上云的最佳选择。</p>
-<p><img src="assets/2020-08-31-034527.png" alt="2.PNG" /></p>
+<p><img src="assets/2020-08-31-034527.png" alt="png" /></p>
 <p>SAE 提供了成本更优、效率更高的应用托管方案。底层基于统一的 K8s 技术底座，帮用户屏蔽复杂的 IaaS 层和 K8s 集群运维，提供计算资源、弹性、隔离性等能力，用户只需关心应用实例的规格和实例数。</p>
 <p>在应用层，除提供了生命周期管理、多发布策略外，还提供监控、日志、微服务治理能力，解决应用可观测性和治理需求。同时提供一键启停、应用编排等高级能力，进一步提效和降本。核心场景主要面向在线应用：微服务应用、Web 应用、多语言应用等。</p>
 <p>在开发者工具方面，和 CI/CD 工具做了良好的集成，无论是 Jenkins 还是云效，都能直接部署应用到 SAE，也可以通过 Cloud Toolkit 插件工具实现本地一键部署应用到云端，可以说 SAE 覆盖了应用上云的完整场景。</p>
-<p><img src="assets/2020-08-31-034529.png" alt="3.PNG" /> <img src="assets/2020-08-31-034531.png" alt="image.gif" /></p>
+<p><img src="assets/2020-08-31-034529.png" alt="png" /> <img src="assets/2020-08-31-034531.png" alt="png" /></p>
 <p>SAE 除了 Serverless 体验本身所带来的极致弹性、免运维、省成本等特性之外，重点在应用层给用户提供了全栈的能力，包括对微服务的增强支持，以及整合了和应用息息相关能力，包括配置、监控、日志、流量控制等。再加上用户零代码的改造，这也是 SAE 区别其它 Serveless 产品的重要优势，平滑迁移企业在线应用。</p>
-<p><img src="assets/2020-08-31-034532.png" alt="4.PNG" /></p>
+<p><img src="assets/2020-08-31-034532.png" alt="png" /></p>
 <p>SAE 有几个典型的使用场景：一个是存量业务上云，特别是微服务、Java 应用，同时也支持其他语言的单体应用快速上云/搬站，满足极致交付效率和开箱即用的一站式体验。在行业方面，SAE 特别适合有比较大的流量波动的在线业务，比如电商大促、在线教育等行业的场景。另外 SAE 作为应用 PaaS 也可以被上层的行业 SaaS 所集成，帮助用户更快地构建行业 SaaS。</p>
 <h3>产品核心指标</h3>
-<p><img src="assets/2020-08-31-034534.png" alt="5.PNG" /></p>
+<p><img src="assets/2020-08-31-034534.png" alt="png" /></p>
 <p>SAE 三个核心的指标：容器启动时长 20s（指标定义是从 pull image 到容器启动的耗时，不包括应用启动时间），接下来我们会通过各种技术优化把它优化到 5s 内，保证用户在突发场景下的快速扩容效率。最小规格支持 0.5core 1GiB，满足更细粒度的资源诉求。相比 ECS，SAE 部署一套开发测试环境的成本可以节省 47%～57%。</p>
 <h3>最佳实践</h3>
 <p>通过前文介绍， 我们了解了产品的特性、优势、适用场景，最后给大家详细介绍几个 Serverless 落地的最佳实践案例。</p>
 <h4>1. 低门槛微服务架构转型的解决方案</h4>
-<p><img src="assets/2020-08-31-034535.png" alt="image.gif" /> <img src="assets/2020-08-31-034536.png" alt="6.PNG" /></p>
+<p><img src="assets/2020-08-31-034535.png" alt="png" /> <img src="assets/2020-08-31-034536.png" alt="png" /></p>
 <p>随着业务的快速增长，很多企业都面临单体向微服务架构改造转型的难题，或者开源自建的微服务框架（Spring Cloud / Dubbo）能力不再能满足企业稳定性和多样化的需求。通过 SAE 提供开箱即用的微服务能力和稳定性兜底能力，已让这些企业低门槛快速完成微服务架构转型，支撑新业务快速上线，让企业专注于业务本身。</p>
 <p>可以说，SAE 是 Serverless 行业最佳的微服务实践，同时也是微服务行业最佳的 Serverless 实践。</p>
 <h4>2. 免运维、一键启停开发测试环境的降本方案</h4>
-<p><img src="assets/2020-08-31-034537.png" alt="7.PNG" /><img src="assets/2020-08-31-034539.png" alt="image.gif" /></p>
+<p><img src="assets/2020-08-31-034537.png" alt="png" /><img src="assets/2020-08-31-034539.png" alt="png" /></p>
 <p>中大型企业多套环境，往往开发测试、预发环境都不是 7*24 小时使用，长期保有应用实例，闲置浪费很高，有些企业 CPU 利用率都快接近 0，降本诉求明显。通过 SAE 一键启停能力，让这些企业得以灵活按需释放资源，只开发测试环境就能节省 2/3 的机器成本，非常可观。</p>
 <h4>3. 精准容量、极致弹性的解决方案</h4>
-<p><img src="assets/2020-08-31-034540.png" alt="image.gif" /><img src="assets/2020-08-31-034541.png" alt="8.PNG" /></p>
+<p><img src="assets/2020-08-31-034540.png" alt="png" /><img src="assets/2020-08-31-034541.png" alt="png" /></p>
 <p>电商类、安防行业等往往会有一些不可预期的突发流量高峰，之前他们都是提前预估峰值，按照峰值保有 ECS 资源，但经常出现容量预估不准（资源浪费 or 不足），更严重的甚至会影响系统的 SLA。</p>
 <p>采用压测工具 + SAE 的方案后，根据压测结果精准设置弹性策略期望值，然后和实时的监控指标比对，系统自动进行扩缩操作，再也无需容量规划，并且弹性效率能做到秒级，轻松应对峰值大考。</p>
 <h4>4. 构建高效闭环的 DevOps 体系</h4>
-<p><img src="assets/2020-08-31-034542.png" alt="9.PNG" /></p>
+<p><img src="assets/2020-08-31-034542.png" alt="png" /></p>
 <p>SAE 构建了高效闭环的 DevOps 体系，覆盖了应用的开发态、部署态、运维态的整个过程。中大型企业往往都使用企业级 CI/CD 工具 Jenkis / 云效部署 SAE 应用，完成从 Source Code - 构建 - 部署全链路。中小企业/个人开发者往往选择开发者工具 Maven 插件、IDEA 插件一键部署应用到云端，方便本地调试，提升开发者体验。完成部署后，即可进行运维态的治理和诊断，如限流降级、应用诊断，数据化运营分析等。</p>
 <h3>总结</h3>
 <p>总结一下，本文主要是围绕在线应用的 Serverless 落地实践展开的。开篇提到的几个落地挑战在 SAE 产品中基本都能得到很好的解决：</p>
--- a/技术公开课（完）/22
+++ b/技术公开课（完）/22
@@ -183,11 +183,11 @@ function hide_canvas() {
 <p><img src="assets/2020-09-07-110109.png" alt="img" /></p>
 <p>首先，简单介绍一下 SAE。SAE 是一款面向应用的 Serverless PaaS 平台，支持 Spring Cloud、Dubbo、HSF 等主流开发框架，用户可以零代码改造直接将应用部署到 SAE，并且按需使用、按量计费、秒级弹性。SAE 充分发挥 Serverless 的优势，为用户节省闲置资源成本；在体验上，SAE 采用全托管、免运维的方式，用户只需聚焦核心业务的开发，而应用生命周期管理、微服务管理、日志、监控等功能交由 SAE 完成。</p>
 <h4>2. SAE 应用部署方式</h4>
-<p><img src="assets/2020-09-07-105849.png" alt="image.gif" /><img src="assets/2020-09-07-105851.jpg" alt="2.jpg" /></p>
+<p><img src="assets/2020-09-07-105849.png" alt="png" /><img src="assets/2020-09-07-105851.jpg" alt="png" /></p>
 <p>在使用 SAE 时，您可以在控制台上看到 SAE 支持三种部署方式，即可以通过 WAR 包、JAR 包和镜像的方式进行部署，如果您采用 Spring Cloud、Dubbo、HSF 这类应用，可以直接打包上传，或者填入包的地址便可以部署到 SAE 上；对于非 Java 语言的场景，您也可以使用镜像直接来部署，后续我们也会支持其他语言直接上传包的形式进行部署。</p>
 <p>SAE 除上述控制台界面部署的方式之外，还支持通过 Maven 插件或者 IDE 插件的方式进行部署，这样您无需登录控制台，就可以执行自动化部署操作，同时可以集成如云效、Jenkins 等工具实现 CICD 流程。</p>
 <h3>Maven 插件部署</h3>
-<p><img src="assets/2020-09-07-110027.jpg" alt="3.jpg" /></p>
+<p><img src="assets/2020-09-07-110027.jpg" alt="png" /></p>
 <p>如何使用 Maven 插件进行部署？首先需要为应用添加 Maven 依赖 toolkit-maven-plugin，接下来需要编写配置文件来配置插件的具体行为，这里定义了三个配置文件：</p>
 <ul>
 <li><strong>toolkit_profile.yaml 账号配置文件</strong>，用来配置阿里云 ak、sk 来标识阿里云用户，这里推荐使用子账号 ak、sk 以降低安全风险。</li>
--- a/应用的落地实践.md.html
+++ b/应用的落地实践.md.html
@@ -179,12 +179,12 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>23 企业级 CICD 工具部署 Serverless 应用的落地实践</h1>
 <h3>背景知识</h3>
-<p><img src="assets/2020-09-07-105841.png" alt="1.png" /></p>
+<p><img src="assets/2020-09-07-105841.png" alt="png" /></p>
 <p>通过以往几节课程的学习，相信大家对于 SAE 平台已经有了一定的了解。SAE 为客户免除了很多复杂的运维工作，开箱即用、按用量付费；与此同时 SAE 提供了丰富的 Open API，可以很容易地与其他平台做集成；类似云效以及 Jenkins 的 CI/CD 工具是敏捷软件研发实践中的重要一环，可以自动化地将客户的代码编译、测试、打包并部署至各个环境，从而提升团队的研发效率。</p>
 <p>本篇文章分为两个部分，首先介绍使用云效平台实现从源码到 SAE 环境的持续集成，然后介绍使用 Jenkins 的情况下持续集成该如何配置。</p>
 <h3>使用云效部署到 SAE</h3>
 <p>云效（rdc.console.aliyun.com），是阿里云推出的企业级一站式 Devops 平台型产品，功能覆盖了从【需求-&gt;开发-&gt;测试-&gt;发布-&gt;运维-&gt;运营】全流程。对云效感兴趣的同学可以去【阿里云官网】搜索【云效】，本文只介绍与 CI/CD 相关的部分功能。</p>
-<p><img src="assets/2020-09-07-105843.png" alt="2.PNG" /></p>
+<p><img src="assets/2020-09-07-105843.png" alt="png" /></p>
 <p>如上图所示，图的上半部分是我们的配置流程，下半部分的流程图是我们所要执行的持续集成流程的示例。云效首先会从代码仓库中拉取相应的代码，然后进行代码检查以及单元测试，接着是代码编译构建，这一步会产出相应的生成物：在这里我们用一个 java 应用来举例，如果构建产出物这一步选择是 jar 类型，那么流水线在运行时运行 mvn package 命令产出对应的 jar 包；如果构建产出物类型是 Docker 镜像，那么在构建这一步在产出 jar 包后会继续执行 docker build 命令来构建对应的 Docker 镜像并上传到您所选择的 ACR 镜像仓库；流水线的最后两步是调用 SAE 的 Open API 将构建物（jar 包/Docker 镜像）部署分发到测试环境，根据我们预先的设置，在部署完测试环境这一步后流水线会停下来等待手动触发下一步操作；等待手动验证测试环境的部署一切正常后，手动触发流水线继续运行，这次将调用 <a href="https://help.aliyun.com/document_detail/126353.html">Open API</a> 部署到生产环境。</p>
 <p>操作步骤：</p>
 <ul>
@@ -195,7 +195,7 @@ function hide_canvas() {
 </ul>
 <h3>使用 Jenkins 部署 SAE</h3>
 <p>Jenkins 是被业界广泛使用的开源 CI/CD 平台，使用 Jenkins 可以将源码打包编译后部署至 SAE，其达成的最终效果与“通过云产品云效部署至SAE”类似，通过 Jenkins 将应用源码编译成为 jar 包，然后通过maven plugin 来调用 SAE 的 Open API 部署接口将应用部署至 SAE。</p>
-<p><img src="assets/2020-09-07-105846.png" alt="3.PNG" /></p>
+<p><img src="assets/2020-09-07-105846.png" alt="png" /></p>
 <p>操作步骤：</p>
 <ul>
 <li>代码库中有相应的打包配置，在使用 Jenkins 时我们打包的产出构建物是 jar 包，所以此处要求我们项目根目录下有对应的 maven配置文件 pom.xml；</li>
--- a/应用引擎产品的流量负载均衡和路由策略配置实践.md.html
+++ b/应用引擎产品的流量负载均衡和路由策略配置实践.md.html
@@ -179,21 +179,21 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>25 Serverless 应用引擎产品的流量负载均衡和路由策略配置实践</h1>
 <h3>流量管理从面向实例到面向应用</h3>
-<p><img src="assets/2020-10-19-032124.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032124.png" alt="png" /></p>
 <p>在 Serverless 场景下，由于弹性能力以及底层计算实例易变的特性，后端应用实例需要频繁上下线，传统的 ECS 场景下的负载均衡管理方式不再适用。</p>
 <p>SAE 产品提供给用户面向应用的流量管理方式，不再需要关心弹性场景以及发布场景的实例上下线，仅仅需要关心监听的配置以及应用实例的健康检查探针，将面向实例的复杂配置工作交给 SAE 产品。</p>
 <h3>单应用的负载均衡配置</h3>
-<p><img src="assets/2020-10-19-032125.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032125.png" alt="png" /></p>
 <p>对于单个应用，SAE 产品支持将应用服务通过公网或私网 SLB 实例监听暴露，目前支持仅支持 TCP 协议。考虑到传统的 HTTP 类型应用存在 HTTPS 改造的需求，SAE 还支持配置 HTTPS 监听，让 HTTP 服务器无需修改就能够对外提供 HTTPS 服务。</p>
 <p>公网 SLB 用于互联网客户端访问，会同时产生规格费与流量费用；私网 SLB 用于 VPC 内客户端访问，会产生规格费用。</p>
 <p>为了让 SAE 产品能够准确控制实例上下线时机，用户需要在部署时正确地配置探针，避免业务出现损失。</p>
 <h3>多应用的路由策略配置</h3>
-<p><img src="assets/2020-10-19-032127.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032127.png" alt="png" /></p>
 <p>大中型企业在实践中，常常会将业务拆分成不同的应用或者服务，例如将登陆服务、账单服务等关联度较高的部分，单独拆分为应用，独立进行研发以及运维，再对外通过统一的网关服务进行暴露，对用户来说就像使用单体应用一样。</p>
 <p>SAE 提供基于 SLB 实例的网关，将流量按照域名以及 HTTP Path 转发到不同的应用的实例上，从功能上对标业界的 Nginx 网关。</p>
 <p>公网 SLB 实例实现的网关用于互联网客户端访问，会同时产生规格费与流量费用；私网 SLB 实例实现的网关用于 VPC 内客户端访问，会产生规格费用。</p>
 <h3>自建微服务网关</h3>
-<p><img src="assets/2020-10-19-032128.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032128.png" alt="png" /></p>
 <p>对于微服务场景中常见的微服务网关，SAE 并没有提供产品化的支持，但用户依然可以自由发挥，在 SAE 中部署自建的微服务网关。</p>
 <p>实践中，微服务网关也可以作为一个应用，部署到 SAE 中。微服务网关会根据用户自定义的配置，将业务流量转发到提供微服务的实例中。微服务网关作为应用，也是可以通过 SLB 实例对公网以及私网暴露服务。</p>
 <h3>结语</h3>
--- a/技术公开课（完）/26
+++ b/技术公开课（完）/26
@@ -207,12 +207,12 @@ function hide_canvas() {
                        <p id="tip" align="center"></p>
                        <div><h1>26 Spring CloudDubbo 应用无缝迁移到 Serverless 架构</h1>
 <h3>背景</h3>
-<p><img src="assets/2020-10-19-032108.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032108.png" alt="png" /></p>
 <p>通过前面几节课程的学习，相信大家对于 SAE 平台已经有了一定的了解，SAE 基于 IaaS 层资源构建的一款 Serverles 应用托管产品，免除了客户很多复杂的运维工作，开箱即用、按用量付费；并且提供了丰富的 Open API 可以很容易地与其他平台做集成。</p>
 <p>本文将为大家介绍 SAE 在微服务方面的一些能力，SAE 产品把 Serverless 技术和微服务做了很好的结合，天然支持 Java 微服务应用的托管和服务治理，对 SpringCloud/Dubbo 微服务应用能够在只修改配置和依赖，不修改代码的情况下迁移到 SAE 上，并提供服务治理能力，比如基于租户的微服务隔离环境、服务列表、无损下线、离群摘除、应用监控以及调用链分析等。</p>
 <p>本次课程分为三部分来介绍，分别介绍微服务应用迁移到 SAE 的优势，如何迁移 SpringCloud/Dubbo 应用到 SAE 上，以及针对 SpringCloud 应用迁移的实践演示。</p>
 <h3>迁移到 SAE 的优势</h3>
-<p><img src="assets/2020-10-19-032114.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032114.png" alt="png" /></p>
 <p>在介绍迁移之前，先介绍下 SpringCloud/Dubbo 应用迁移到 SAE 的优势：</p>
 <ul>
 <li>**SAE 内置注册中心：**所有用户共享注册中心组件，SAE 帮助用户运维，这就节省了用户的部署、运维成本；在服务注册和发现的过程中进行链路加密，无需担心被未授权的服务发现。</li>
@@ -222,14 +222,14 @@ function hide_canvas() {
 </ul>
 <h3>SpringCloud/Dubbo 迁移方案</h3>
 <p>那如何迁移 SpringCloud/Dubbo 应用到 SAE 呢？我们只需要修改添加依赖和配置，就可以把应用部署到 SAE 上。</p>
-<p><img src="assets/2020-10-19-032116.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032116.png" alt="png" /></p>
 <p>Dubbo 应用需要添加 dubbo-register-nacos 和 nacos-client 依赖；SpringCloud 应用需要添加 spring-cloud-starter-alibaba-nacos-discovery 即可。</p>
 <h3>SpringCloud/Dubbo 应用迁移实战</h3>
 <p>Spring Cloud 提供了简化应用开发的一系列标准和规范。</p>
 <p>目前业界流行的 Spring Cloud 具体实现有 Spring Cloud Netflix、Spring Cloud Consul、Spring Cloud Gateway 和 Spring Cloud Alibaba 等。</p>
 <p>如果您熟悉 Spring Cloud 中的 Eureka、Consul 和 ZooKeeper 等服务注册组件，但未使用过 Spring Cloud Alibaba 的服务注册组件 Nacos Discovery，那么您仅需将服务注册组件的服务依赖关系和服务配置替换成 Spring Cloud Alibaba Nacos Discovery，无需修改任何代码。</p>
 <p>Spring Cloud Alibaba Nacos Discovery 同样实现了 Spring Cloud Registry 的标准接口与规范，与您之前使用 Spring Cloud 接入服务注册与发现的方式基本一致。</p>
-<p><img src="assets/2020-10-19-032119.png" alt="image.png" /></p>
+<p><img src="assets/2020-10-19-032119.png" alt="png" /></p>
 <p>接下来针对 SpringCloud 应用迁移过程进行演示，演示过程请点击视频课：https://developer.aliyun.com/lesson<em>2026</em>19003 进行观看。</p>
 </div>
                    </div>
--- a/应用分批发布与无损下线的最佳实践.md.html
+++ b/应用分批发布与无损下线的最佳实践.md.html
@@ -188,7 +188,7 @@ function hide_canvas() {
 </ul>
 <p>有时候，我们把发版安排在凌晨两三点，赶在业务流量比较小的时候，心惊胆颤、睡眠不足、苦不堪言。那如何解决上面的问题，如何保证应用发布过程稳定、高效，保证业务无损呢？首先，我们来梳理下造成这些问题的原因。</p>
 <h3>场景分析</h3>
-<p><img src="assets/2020-11-09-075020.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075020.png" alt="png" /></p>
 <p>上图描述了我们使用微服务架构开发应用的一个常见场景，我们先看下这个场景的服务调用关系：</p>
 <ul>
 <li>服务 B、C 把服务注册到注册中心，服务 A、B 从注册中心发现需要调用的服务；</li>
@@ -200,14 +200,14 @@ function hide_canvas() {
 <p>当服务 A 发布的时候，服务 A1 实例停机后，SLB 根据健康检查探测到服务 A1 下线，然后把实例从 SLB 摘掉。实例 A1 依赖 SLB 的健康检查从 SLB 上摘掉，一般需要几秒到十几秒的时间，在这个过程中，如果 SLB 有持续的流量打入，就会造成一些请求继续路由到实例 A1，导致请求失败；</p>
 <p>服务 A 在发布的过程中，如何保证经过 SLB 的流量不报错？我们接着看下 SAE 是如何做的。</p>
 <h4>南北向流量优雅升级方案</h4>
-<p><img src="assets/2020-11-09-075025.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075025.png" alt="png" /></p>
 <p>如上文所提，请求失败的原因在于后端服务实例先停止掉，然后才从 SLB 摘掉，那我们是不是可以先从 SLB 摘掉服务实例，然后再对实例进行升级呢？</p>
 <p>按照这个思路，SAE 基于 K8S service 的能力给出了一种方案，当用户在通过 SAE 为应用绑定 SLB 时，SAE 会在集群中创建一个 service 资源，并把应用的实例和 service 关联，CCM 组件会负责 SLB 的购买、SLB 虚拟服务器组的创建，并且把应用实例关联的 ENI 网卡添加到虚拟服务器组中，用户可以通过 SLB 来访问应用实例；当应用发布时，CCM 会先把实例对应的 ENI 从虚拟服务器组中摘除，然后再对实例进行升级，从而保证流量不丢失。</p>
 <p>这就是 SAE 对于应用升级过程中关于南北向流量的保障方案。</p>
 <h3>东西向流量</h3>
 <h4>东西向流量存在问题</h4>
 <p>在讨论完南北向流量的解决方案后，我们再看下东西向流量，传统的发布流程中，服务提供者停止再启动，服务消费者感知到服务提供者节点停止的流程如下：</p>
-<p><img src="assets/2020-11-09-075026.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075026.png" alt="png" /></p>
 <ol>
 <li>服务发布前，消费者根据负载均衡规则调用服务提供者，业务正常。</li>
 <li>服务提供者 B 需要发布新版本，先对其中的一个节点进行操作，首先是停止 java 进程。</li>
@@ -220,7 +220,7 @@ function hide_canvas() {
 </ol>
 <p>从第 2 步到第 6 步的过程中，Eureka 在最差的情况下需要耗时 2 分钟，Nacos 在最差的情况下需要耗时 50 秒。在这段时间内，请求都有可能出现问题，所以发布时会出现各种报错，同时还影响用户的体验，发布后又需要修复执行到一半的脏数据。最后不得不每次发版都安排在凌晨两三点发布，心惊胆颤，睡眠不足，苦不堪言。</p>
 <h4>东西向流量优雅升级方案</h4>
-<p><img src="assets/2020-11-09-075028.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075028.png" alt="png" /></p>
 <p>经过上文的分析，我们看，在传统发布流程中，客户端有一个服务调用报错期，原因就是客户端没有及时感知到服务端下线的实例。在传统发布流程中，主要是借助注册中心通知消费者来更新服务提供者列表，那能不能绕过注册中心，服务提供者直接通知服务消费者呢？答案是肯定的，我们主要做了两件事情：</p>
 <ol>
 <li>服务提供者应用在发布前后主动向注册中心注销应用，并将应用标记为已下线的状态；将原来的停止进程阶段注销服务变成了 prestop 阶段注销服务。</li>
@@ -230,10 +230,10 @@ function hide_canvas() {
 <h3>分批发布和灰度发布</h3>
 <p>上文介绍的是 SAE 在处理优雅下线方面的一些能力，在应用升级的过程中，只有实例的优雅下线是不够的，还需要有一套配套的发布策略，保证我们新业务是可用的，SAE 提供分批发布和灰度发布的能力，可以使得应用的发布过程更加省心省力；</p>
 <p>我们先介绍下灰度发布，某应用包含 10 个应用实例，每个应用实例的部署版本为 Ver.1 版本，现需将每个应用实例升级为 Ver.2 版本。</p>
-<p><img src="assets/2020-11-09-075029.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075029.png" alt="png" /></p>
 <p>从图中可以看出，在发布的过程中先灰度 2 台实例，在确认业务正常后，再分批发布剩余的实例，发布的过程中始终有实例处于运行状态，实例升级过程中依照上面的方案，每个实例都有优雅下线的过程，这就保证了业务无损。</p>
 <p>再来看下分批发布，分批发布支持手动、自动分批；还是上面的 10 个应用实例，假设将所有应用实例分 3 批进行部署，根据分批发布策略，该发布流程如图所示，就不再具体介绍了。</p>
-<p><img src="assets/2020-11-09-075030.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075030.png" alt="png" /></p>
 <p>最后针对在 SAE 上应用灰度发布的过程进行演示，点击即可观看演示过程：<a href="https://developer.aliyun.com/lesson_2026_19009">https://developer.aliyun.com/lesson<em>2026</em>19009</a></p>
 </div>
                    </div>
--- a/极致应用部署效率.md.html
+++ b/极致应用部署效率.md.html
@@ -182,7 +182,7 @@ function hide_canvas() {
 <p>接下来将介绍我们在应用创建、部署、重启等过程所做的效率优化工作。</p>
 <h3>应用创建</h3>
 <p>首先是应用创建。目前，用户界面可通过镜像或 war、jar 安装包的方式部署应用，最后在平台侧，以统一打包成容器镜像的方式进行分发，然后平台去申请计算、存储、网络等 IAAS 资源，再开始创建容器执行环境和应用实例。</p>
-<p><img src="assets/2020-11-09-075046.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075046.png" alt="png" /></p>
 <p>在这个过程中，涉及到调度、云资源创建和挂载、镜像拉取、容器环境创建、应用进程创建等步骤，应用的创建效率与这些过程紧密相关。</p>
 <p>我们很自然而然地能想到，这其中部分过程是否能并行，以减少整个创建的耗时呢？经过对每个过程的耗时分析，我们发现其中的一些瓶颈点，并且部分执行步骤之间是解耦独立的，比如云弹性网卡的创建挂载和应用镜像拉取，就是相互独立的过程。<strong>基于此，我们将其中独立的过程做了并行化处理，在不影响创建链路的同时，降低了应用创建的时耗。</strong></p>
 <h3>应用部署</h3>
@@ -199,7 +199,7 @@ function hide_canvas() {
 <p>摘流，将运行实例从 SLB 后端摘除 -&gt; 原地升级实例 -&gt; 接入流量</p>
 </blockquote>
 <p>原地升级后，应用实例仍保持原来的 ip。经过测试，对于 2 实例应用，部署效率将提升 4 倍，将部署时长从原来的将近 1 分钟缩短到十几秒。</p>
-<p><img src="assets/2020-11-09-075047.png" alt="image.png" /></p>
+<p><img src="assets/2020-11-09-075047.png" alt="png" /></p>
 <h3>应用重启</h3>
 <p>最后，简单介绍下我们即将推出的<strong>原地重启功能</strong>。</p>
 <p>重启实例在某些运维场合是必要的操作，说到应用重启，我们希望类似于 linux 系统一样，可以只执行一次 reboot，而不是重建实例。具体的做法是，我们在容器环境下，通过容器引擎 API 执行一次启停操作即可。原地重启相比原地升级，省去了镜像更新和执行环境创建的过程，并且相比 ECS，容器的重启更轻量，能达到秒级。</p>