From 6b393e2bc5ab1569deb322ae229d35fc06bfb195 Mon Sep 17 00:00:00 2001 From: isno Date: Thu, 15 Feb 2024 10:24:42 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=20ServiceMesh=20=E5=86=85?= =?UTF-8?q?=E5=AE=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ServiceMesh/MicroService-history.md | 2 ++ ServiceMesh/What-is-ServiceMesh.md | 2 +- ServiceMesh/conclusion.md | 3 ++- architecture/arc.md | 4 ++-- 4 files changed, 7 insertions(+), 4 deletions(-) diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md index 67c9ce07..2e236e1f 100644 --- a/ServiceMesh/MicroService-history.md +++ b/ServiceMesh/MicroService-history.md @@ -1,5 +1,7 @@ # 8.2 服务治理形式的演进 +本篇引用的图片来源于 Phil Calçado 的博客《Pattern: Service Mesh》。 + 自 2011 年微服务架构理念提出以来，10 余年间一批又一批技术框架和理念不断涌现出来，如果以技术的表现形式划分，服务治理的模式已经迭代了四代。 在第一代微服务架构中，以 RPC 通信为代表，首要解决的是微服务之间的通信问题。技术框架代表如阿里 Dubbo，跨语言平台的框架 Thrift、gRPC... diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md index 54cf6022..cc8a383e 100644 --- a/ServiceMesh/What-is-ServiceMesh.md +++ b/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 社区认同。 diff --git a/ServiceMesh/conclusion.md b/ServiceMesh/conclusion.md index f4a542db..f8c53b40 100644 --- a/ServiceMesh/conclusion.md +++ b/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 \ No newline at end of file +- Pattern: Service Mesh，https://philcalcado.com/2017/08/03/pattern_service_mesh.html \ No newline at end of file diff --git a/architecture/arc.md b/architecture/arc.md index 262a5a29..6b027e4b 100644 --- a/architecture/arc.md +++ b/architecture/arc.md @@ -1,6 +1,6 @@ # 1.6 以解决问题为目的推进架构演进 -理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，解决切实的现实问题。 +理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，解决现实问题。 首先，没有完美应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。 @@ -18,4 +18,4 @@ 从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本是非常昂贵（很强的架构和运维能力）。 -为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的“云”技术体系。 +为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。