diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index ed09b70a..73fb3ba1 100644 --- a/ServiceMesh/overview.md +++ b/ServiceMesh/overview.md @@ -1,15 +1,21 @@ # 8.3 服务网格的产品与生态 -初代的服务网格理念美好，但以 Sidecar 为核心还是存在不少缺陷：明显的资源消耗、额外的请求转发带来的性能影响，其次功能仅限于数据层面的代理时，当大量部署 Sidecar 后也没有充分考虑如何管理和控制这些 Sidecar。于是，第一代的服务网格产品（Linkerd、Envoy）刚开始被市场接受，第二代服务网格产品就已迫不及待入场。 +初代的服务网格理念美好，但以 Sidecar 为核心还是存在不少缺陷：明显的资源消耗、额外的请求转发带来的性能影响，其次功能仅限于数据层面的代理时，当大量部署 Sidecar 后也没有充分考虑如何管理和控制这些 Sidecar。于是，第一代的服务网格产品（Linkerd、Envoy）刚开始被市场接受，第二代服务网格产品匆忙入局。 ## Istio 入局 -2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的代表产品。Istio 最大的创新在于它为 ServiceMesh 带来前所未有的控制力： +2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为第二代服务网格的代表产品。 -- 以 Sidercar 方式部署的 ServiceMesh 控制服务间所有的流量 -- Istio 增加控制面板来控制系统中所有的 Sidecar。 +Istio 最大的创新在于它为服务网格带来前所未有的控制力。 -以此，Istio 便控制了系统中所有请求的发送，也即控制了所有的流量。 +- 以 Linkerd 代表的第一代服务网格用 Sidercar 方式部署，控制服务间所有的流量 +- 以 Istio 为代表的第二代服务网格增加控制面板，控制系统中所有的 Sidecar。 + +至此，Istio 便控制了系统中所有请求的发送，也即控制了所有的流量。 + +Istio 的架构如下图所示，对于一个仅提供服务与服务之间连接通信的基础设施来说，Istio 的架构算不上简单，但其中各个组件的理念得承认的确非常先进和超前。 + +- Pilot：负责部署在 ServiceMesh 中的 Envoy 实例的生命周期管理。主要职责是负责流量管理和控制，向 Envoy 发送服务发现信息和各种流量管理以及路由规则。Pilot 让运维人员通过 pilot 指定它们希望流量遵循什么规则，而不是哪些特定的 Pod/VM 应该接收什么流量。有了 Pilot 这个组件，就可以轻松实现 A/B 测试以及金丝雀 Canary 测试。
@@ -47,9 +53,7 @@ Istio 的数据面支持的特性如下： Outbound 特性是指服务请求侧的 Sidecar 提供的功能特性。而 Inbound 特性是指服务提供侧 Sidecar 提供的功能特性。类似遥测、分布式追踪需要两侧的 Sidecar 都提供支持。而另一些特性只要一侧提供支持即可，例如鉴权只需要在服务提供侧支持，重试只需要在请求侧支持。 ::: -对于一个仅提供服务与服务之间连接通信的基础设施来说，Istio 的架构算不上简单，但其中各个组件的理念得承认的确非常先进和超前。 -- Pilot：负责部署在 ServiceMesh 中的 Envoy 实例的生命周期管理。主要职责是负责流量管理和控制，向 Envoy 发送服务发现信息和各种流量管理以及路由规则。Pilot 让运维人员通过 pilot 指定它们希望流量遵循什么规则，而不是哪些特定的 Pod/VM 应该接收什么流量。有了 Pilot 这个组件，就可以轻松实现 A/B 测试以及金丝雀 Canary 测试。 ## Linkerd 2.0 diff --git a/architecture/arc.md b/architecture/arc.md index 37d66889..967b2ad7 100644 --- a/architecture/arc.md +++ b/architecture/arc.md @@ -1,8 +1,6 @@ -# 1.6 以解决问题为目的推进架构演进 +# 1.6 传统架构向云原生架构的演进 -理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，享受技术红利并解决现实问题。 - -首先，没有完美应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。 +好的架构不是设计出来的，是根据业务落地生根长期演化来。架构演进的目的一定是解决某一类问题，我们就从“解决问题”的角度出发，如图 1-38 所示，讨论传统架构向云原生架构的演进。
@@ -13,9 +11,11 @@ - 为了解决微服务间 “通讯异常问题”，使用治理框架 + 监控。 - 为了解决微服务架构下大量应用 “部署问题”，使用容器。 - 为了解决容器的 “编排和调度问题”，使用 Kubernetes。 -- 为了解决微服务框架的 “侵入性问题”，使用 Service Mesh。 -- 为了让 Service Mesh 有 “更好的底层支撑”，将 Service Mesh 运行在 Kubernetes 上。 +- 为了解决微服务框架的 “侵入性问题”，使用服务网格。 +- 为了让服务网格有 “更好的底层支撑”，将服务网格运行在 Kubernetes 上。 从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本是非常昂贵（很强的架构和运维能力）。 -为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。 +为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计。 + +最后，通过 yaml 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。 \ No newline at end of file