更新 ServiceMesh 内容

ServiceMesh/MicroService-history.md

@@ -1,5 +1,7 @@
 # 8.2 服务治理形式的演进
 
+本篇引用的图片来源于 Phil Calçado 的博客《Pattern: Service Mesh》。
+
 自 2011 年微服务架构理念提出以来，10 余年间一批又一批技术框架和理念不断涌现出来，如果以技术的表现形式划分，服务治理的模式已经迭代了四代。
 
 在第一代微服务架构中，以 RPC 通信为代表，首要解决的是微服务之间的通信问题。技术框架代表如阿里 Dubbo，跨语言平台的框架 Thrift、gRPC...

ServiceMesh/What-is-ServiceMesh.md

@@ -12,7 +12,7 @@ Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职
 
 :::
 
-概览以下的里程碑事件，我们看到 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的过程。
+概览以下里程碑事件，我们看到 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的历程。
 
 - 2016年9 月，在 SF MicroServices 大会上，“ServiceMesh” 这个术语第一次在公开场合使用，这标志着 ServiceMesh 逐渐从 Buoyant 公司走向社区，并开始被广泛接受以及推崇。
 - 2017年1月，Linkerd 加入 CNCF，项目类型被归类到 CNCF 新开辟的 “ServiceMesh” 分类。这代表着 ServiceMesh 理念被 CNCF 社区认同。

ServiceMesh/conclusion.md

@@ -1,6 +1,7 @@
 # 8.5 小结
 
+
 参考
 
 - William Morgan 的服务网格之战，https://softwareengineeringdaily.com/2019/05/31/service-mesh-wars-with-william-morgan/
-- https://philcalcado.com/2017/08/03/pattern_service_mesh.html
+- Pattern: Service Mesh，https://philcalcado.com/2017/08/03/pattern_service_mesh.html

architecture/arc.md

@@ -1,6 +1,6 @@
 # 1.6 以解决问题为目的推进架构演进
 
-理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，解决切实的现实问题。
+理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，解决现实问题。
 
 首先，没有完美应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。
 
@@ -18,4 +18,4 @@
 
 从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本是非常昂贵（很强的架构和运维能力）。
 
-为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的“云”技术体系。
+为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。