diff --git a/.vuepress/config.js b/.vuepress/config.js
index c5d3edf5..73736674 100644
--- a/.vuepress/config.js
+++ b/.vuepress/config.js
@@ -59,6 +59,7 @@ export default defineUserConfig({
             }
         ],
         sidebar: [
+            '/intro.md',
             '/noun.md',
             {
                 text: '第一章：云原生技术概论',
diff --git a/architecture/history.md b/architecture/history.md
index ff080b5e..da4d3251 100644
--- a/architecture/history.md
+++ b/architecture/history.md
@@ -1,6 +1,6 @@
 # 1.1 云计算的演进变革
 
-想了解一个新的事物为什么会出现，譬如云原生，最好的方法，就是去了解它出现的背景、发展的历史。回顾历史，重点不在于考古，而是借历史之名，理解每种技术出现的原因和淘汰的原因，为了更好地解决今天的现实问题，寻找出未来的技术/架构演进之路。
+想了解一个新的事物为什么会出现，譬如云原生，最好的方法就是去了解它出现的背景、发展的历史。回顾历史，重点不在于考古，而是借历史之名，理解每种技术出现的原因和淘汰的原因，为了更好地解决今天的现实问题，寻找出未来的技术/架构演进之路。
 
 那么介绍云原生之前，我们先看看过去几十年间，云计算领域的发展演进历程。
 
diff --git a/container/auto-scaling.md b/container/auto-scaling.md
index f5842459..fd75f2d0 100644
--- a/container/auto-scaling.md
+++ b/container/auto-scaling.md
@@ -10,7 +10,7 @@ Kubernetes 弹性伸缩组件可以从伸缩方向和伸缩对象两个维度进
 | Horizontal | Horizontal Pod Autoscaler（HPA，水平 Pod 垂直自动伸缩器）| Cluster AutoScaler | 
 
 
-先来看第一个 VPA 组件，它确保工作负载适配的方式是调整 Pod 资源上限而不是水平扩展它们。但这里有一个问题：增强型的 Pod 并不一定好，大多数情况下使用多个进程处理数据远比使用一个大且强的进程更高效。
+先来看 VPA 组件，它确保工作负载适配的方式是调整 Pod 资源上限而不是水平扩展它们。但这里有一个问题：增强型的 Pod 并不一定好。普适的观点是大多数情况下使用多个进程处理数据远比使用一个大且强的进程更高效。
 
 HPA 组件根据资源利用率或者自定义指标自动调整 Deployment、StatefulSet 或其他类似资源的扩展和缩减，实现部署的规模接近于实际服务的负载。HPA 最初的 v1 版本只支持 CPU 指标的伸缩，局限性明显。因为传统的指标如 CPU 或内存不一定就能代表服务的负载情况，比如事件驱动的应用程序 Kafka，传入 kafka 事件的数量才是确定负载的真实指标。在持续集成（CI）流水线中，当提交代码时，可能会触发一系列的流水线作业（镜像编译、应用打包、可用性测试），如果持续集成的作业出现瓶颈，这里的度量标准应该是等待执行的任务数，那么基于作业队列数量伸缩比仅仅观察 CPU 或者内存指标更有效。
 
diff --git a/intro.md b/intro.md
index 5cf11b64..6d6c0a0b 100644
--- a/intro.md
+++ b/intro.md
@@ -1,10 +1,10 @@
 # 前言
 
-既然翻开这本书，我猜测你大概率是个互联网从业者，我还能猜出这几年你大概率被这些层出不穷的概念包围：SOA、SRE、容器、容器编排、ServiceMesh、Serverless、可观测、大数据，当然不能遗漏了各种 Ops，DevOps、GitOps、AIOps、MLOps...
+既然翻开这本书，我猜测你大概率是个互联网从业者，我还能猜出这几年你大概率被这些层出不穷的概念包围：微服务、SRE、容器、容器编排、ServiceMesh、Serverless、可观测性，当然不能遗漏了各种 Ops，DevOps、GitOps、AIOps、MLOps 等等。
 
-这些概念全部围绕着构建大规模分布式架构的几个核心要素：稳定（不出任何问题）、效率（快速响应市场需求）、成本（充分有效的利用资源）。
+这些概念全部围绕着构建大规模分布式基础架构的几个核心要素：稳定（不出任何问题）、效率（快速响应市场需求）、成本（充分有效的利用资源）。
 
-分析这些激动人心的技术变革之前，暂且放下技术，透过表象发散思维，从宏观的角度思考驱使技术演进的驱动力是什么!
+分析这些激动人心的技术变革之前，让我们发散思维，思考引发这一泼技术浪潮的核心驱动力是什么!
 
 ## 软件在吞噬世界
 
@@ -20,10 +20,34 @@
 
 文中列出了被重塑的产业，具体有：最大的书店 Amazon、最多人订阅的 Video service Netflix、最大的音乐公司 iTunes、Spotify and Pandora 等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 Google、Groupon、Facebook 等、成长最快的电信公司 Skype 、成长最快招聘公司 LinkedIn。
 
-文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。互联网俨然已成为国民经济的高速公路，部分软件成为像水、电、媒一样的基础设施。
+文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。互联网俨然已成为国民经济的高速公路，部分软件成为像水、电、媒一样的基础设施。如果这些基础设施崩溃或者故障，请思考对社会的影响。
 
 ## 移动互联网在加剧变化
 
+作者展望互联网规模时，写道：“在接下来的 10 年里，我预计全球至少有 50 亿人拥有智能手机，每个人每天都可以随时随地使用手机充分利用互联网。”
+
+现在，我们已经可以确认 Mark Andreessen 的预测很正确，移动互联网时代的用户规模已经开始向人口基数看齐，开始出现各类亿级 DAU 规模的移动应用。而移动互联网如此巨大的用户规模会对软件开发有什么影响？
+
+<div  align="center">
+	<img src="./assets/ppt4.jpg" width = "450"  align=center />
+	<p>图 Netflix按照规模和变更速度对软件企业划分的总结</p>
+</div>
+
+在十年前乃至二十年前的互联网时代，大多数软件企业都位于图 1-8 左边的两个象限：规模或许有大有小，但是变更速度相对今天都不快。当企业发展壮大时，体现的也更多是在规模上，变更速度并不会发生质的变化。
+
+而今天的移动互联网时代，则都位于图 1-8 右边的两个象限：无论规模是大是小，变更速度都要求非常快。并且当企业逐步发展壮大，规模十倍百倍增长时，对变更速度的要求并不会降低，甚至会要求更快。
+
+在移动互联网时代，能够成长并发展起来的这些公司，他们的共同点是：
+
+- 快速变更，不断创新，随时调整
+- 提供持续可用的服务，应对各种可能的错误和中断
+- 弹性可扩展的系统，应对用户规模的快速增长
+- 提供新的用户体验，以移动为中心
+
+这样的背景下，对软件开发有了更高的要求，软件开发的方式也不得不跟随时代而变化，首当其冲的就是如何解决规模越来越大同时变更越来越快的难题。
+
+## 时代巨变，掀起技术浪潮
+
 软件对各行各业的渗透和对世界的改变，以及移动互联网时代巨大的用户基数下快速变更和不断创新的需求对软件开发方式带来巨大的推动力，我们可以清晰地看到如此波澜壮阔的技术浪潮：
 
 - 软件正在改变世界
@@ -32,17 +56,18 @@
 - 因为云计算以及相关技术的普及，软件上云成为趋势
 - 技术的形态持续在演进
 
+云计算的技术逐渐发展成为它本来该有的模样，以及与这样的云所匹配的软件架构，还有以及与这样的架构所匹配的开发流程与方法论。
 
 
 ## 沉淀底层的原理和方法论
 
-笔者也未曾花费精力去介绍某一种技术的 feature，看官方的手册比任何资料都详细、权威。所以，本书的宗旨是希望能说清楚这些问题的本质，解释清楚整个服务架构的发展历程, 走过了哪些弯路，以至于今天使用了哪些技术的缘由，讨论它们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。
-
+视角到转回微观个体，作为技术人员，我们如何应对宏观的世界变化？
 
-不管技术发展如何日新月异，其根本性变化并没有那么快，如果尝试理清它们脉络，总能找到若干贯穿其中的一些颠扑不破的底层原理、方法论，比如分布式系统演进方向是 CAP 定理的权衡选择，局限于时间与空间的法则。举个例子，Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化，只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
+所幸，不管技术发展如何日新月异，其根本性变化并没有那么快。尝试理清它们脉络，总能找到若干贯穿其中的一些颠扑不破的底层原理、方法论，比如分布式系统演进方向是 CAP 定理的权衡选择，局限于时间与空间的法则。举个例子，Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化，只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
 
+所以，本书的宗旨是希望能说清楚这些问题的本质，解释清楚整个服务架构的发展历程，走过了哪些弯路，以至于今天使用了哪些技术的缘由，讨论它们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。
 
-善于思考总结的人总会从历史的进程中得到相关的规律，所以，**过时的不是基础的技术原理和方法，而是人的思考能力以及没有跟上节奏的对技术的认知**。面对层出不穷的技术、唯有掌握底层的核心原理时，方能肚子里有货，从容不迫。
+善于思考总结的人总会从历史的进程中得到相关的规律，所以，**过时的不是基础的技术原理和方法，而是人的思考能力以及没有跟上节奏的对技术的认知**。
 
 ## 本书适合哪些读者
 
@@ -50,12 +75,13 @@
 
 阅读本书，最好了解一些请求/响应型（Web）系统原理，有一些后端开发经验，熟悉一些常见的网络协议（譬如 TCP、HTTP ），这将会对阅读有很大帮助，至于你熟悉何种编程语言倒没有太大关系。
 
+若以下条件适用你，可能会从本书收益：
+
+- 
+
+
 ## 勘误
 
 由于作者的认知局限，难免产生各种各样的错误。
 
 ## 致谢
-
-首先感谢我的家人，
-
-写作不是无中生有，
\ No newline at end of file