fix img

专栏/Serverless 技术公开课（完）/01 架构的演进.md.html

@@ -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>