diff --git a/Observability/summary.md b/Observability/summary.md index ac747f60..fd9613b7 100644 --- a/Observability/summary.md +++ b/Observability/summary.md @@ -1,8 +1,8 @@ # 第九章：系统可观测性 :::tip -given enough eyeballs, all bugs are shallow +given enough eyeballs, all bugs are shallow. -足够多的眼睛，就可让所有问题浮现 +足够多的眼睛，就可让所有问题浮现。 -- by Linus Torvalds ::: diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md index 9daf88e0..f6c15a51 100644 --- a/ServiceMesh/MicroService-history.md +++ b/ServiceMesh/MicroService-history.md @@ -1,7 +1,6 @@ # 8.2 服务间通信的演化 - -本节，笔者借用 Phil Calçado 的博客《Pattern: Service Mesh》的内容脉络，并加以我的理解，讨论 TCP 协议、分布式系统、服务间通信的因果关系，尝试说清楚 Service Mesh 诞生的必然性。本节内容图片来源于 Phil Calçado 的博客，在此统一注明，后面不再单独列出。 +本节，笔者借用 Phil Calçado 的博客《Pattern: Service Mesh》的内容脉络，并加以我的理解，尝试从服务间通信的本质层面说清楚 Service Mesh 诞生的必然性。本节内容图片来源于 Phil Calçado 的博客，在此统一注明，后面不再单独列出。 ## 原始的通信时代 diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md index cecb65ba..c7e5b975 100644 --- a/ServiceMesh/What-is-ServiceMesh.md +++ b/ServiceMesh/What-is-ServiceMesh.md @@ -2,8 +2,16 @@ 2016年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 Buoyant，不久之后他们在 Github 上发布了创业项目 Linkerd，业界第一款服务网格（ServiceMesh）项目诞生。 +先来感受服务网格从无到有、被社区接受、巨头入局、众人皆捧的历程。 -那么，什么是服务网格？服务网格的概念最早出自于 William Morgan 的博文《What’s a service mesh？And why do I need one?》，William Morgan作为服务网格的创造者和布道师，引用他的定义自然是最官方和最权威的。 +- 2016年9 月，在 SF MicroServices 大会上，“ServiceMesh” 这个术语第一次在公开场合使用，这标志着 ServiceMesh 逐渐从 Buoyant 公司走向社区，并开始被广泛接受以及推崇。 +- 2017年1月，Linkerd 加入 CNCF，项目类型被归类到 CNCF 新开辟的 “ServiceMesh” 分类。这代表着 ServiceMesh 理念被 CNCF 社区认同。 +- 2017年4月，Linkerd 发布 1.0 版本。Linkerd 实现了最重要的里程碑：被客户接受并在生产线上被大规模应用，ServiceMesh 从理念走向生产实践。 +- 2017年5月，Google、IBM、Lyft 联合发布 Istio 0.1 版本，以 Istio 为代表的第二代 ServiceMesh 产品开始登场。 +- 2018年7月，CNCF 社区发布的云原生定义中，将服务网格和微服务、容器、不可变基础设施等技术并列。这标志着服务网格已经超越了其原初的角色 —— 仅作为一种实现微服务的新方法，现在已经发展为云原生的又一个关键领域，被放在前所未有的高度。 + + +那么，什么是服务网格？服务网格的概念最早出自于 William Morgan 的博文《What’s a service mesh？And why do I need one?》，William Morgan 作为服务网格的创造者和布道师，引用他的定义自然是最官方和最权威的。 :::tip William Morgan 对服务网格的定义 @@ -13,23 +21,4 @@ ::: -从 Micro-Services 到 Service Mesh 承前启后和顺其自然，光看名字就能很形象地理解它所做的事情：把微服务的各个 Service（服务）节点，用一张 mesh（网格）连接起来。就这样，原本被拆散得七零八落的微服务们，又被 Service Mesh 这张大网紧密得连接到了一起，即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）。 - - -服务之间通过 Sidecar 发现和调用目标服务，从而在服务之间形成一种网络状依赖关系，如果我们把节点和业务逻辑从视图剥离，就会出现一种网络状的架构，如图 1-23 所示，服务网格由此得名。 - -
- -

图1-23 服务网格形象示例

-
- -感受服务网格从无到有、被社区接受、巨头入局、众人皆捧的历程。 - -- 2016年9 月，在 SF MicroServices 大会上，“ServiceMesh” 这个术语第一次在公开场合使用，这标志着 ServiceMesh 逐渐从 Buoyant 公司走向社区，并开始被广泛接受以及推崇。 -- 2017年1月，Linkerd 加入 CNCF，项目类型被归类到 CNCF 新开辟的 “ServiceMesh” 分类。这代表着 ServiceMesh 理念被 CNCF 社区认同。 -- 2017年4月，Linkerd 发布 1.0 版本。Linkerd 实现了最重要的里程碑：被客户接受并在生产线上被大规模应用，ServiceMesh 从理念走向生产实践。 -- 2017年5月，Google、IBM、Lyft 联合发布 Istio 0.1 版本，以 Istio 为代表的第二代 ServiceMesh 产品开始登场。 -- 2018年7月，CNCF 社区发布的云原生定义中，将服务网格和微服务、容器、不可变基础设施等技术并列。这标志着服务网格已经超越了其原初的角色 —— 仅作为一种实现微服务的新方法，现在已经发展为云原生的又一个关键领域，被放在前所未有的高度。 - - - +看服务网格（Service Mesh）这个名字起得多好：从 Micro（微小个体）Services 到 Service Mesh（网格连接），承前启后和顺其自然。原本被拆散得七零八落的微服务们，又被服务网格这张大网紧密得连接到了一起，即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）。 \ No newline at end of file diff --git a/ServiceMesh/summary.md b/ServiceMesh/summary.md index f4a47ec3..ac2a49d8 100644 --- a/ServiceMesh/summary.md +++ b/ServiceMesh/summary.md @@ -10,10 +10,4 @@ Kubernetes 的崛起标志着微服务时代的新篇章，通过基础设施层解决分布式架构问题，微服务服务治理也开启了全新的进化，并衍生服务间通信的基础设施层 ServiceMesh。当非侵入性的 ServiceMesh 技术从萌芽走向成熟，当 Istio 横空出世，人们才惊觉：原来微服务也并非只有侵入性一种“玩法”。 -2018年，Bilgin lbryam 在 InfoQ 发了一篇名为 《MicroService in a Post-Kubernetes Era 》的文章，文章虽然没有明确“ 后 Kubernetes 时代的微服务” 是什么，但从文章也能看出作者的观点是：在后 Kubernetes 时代，服务网格技术已经完全取代了通过使用软件库来实现网络运维的方式。 - -:::tip 后微服务时代 - -从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。 - -::: \ No newline at end of file +2018年，Bilgin lbryam 在 InfoQ 发了一篇名为 《MicroService in a Post-Kubernetes Era 》的文章，文章虽然没有明确“ 后 Kubernetes 时代的微服务” 是什么，但从文章也能看出作者的观点是：在后 Kubernetes 时代，服务网格技术已经完全取代了通过使用软件库来实现网络运维的方式。 \ No newline at end of file diff --git a/container/linux-vnet.md b/container/linux-vnet.md index 70ccd707..bd62bc77 100644 --- a/container/linux-vnet.md +++ b/container/linux-vnet.md @@ -4,8 +4,6 @@ Linux 网络虚拟化的主要技术是网络命名空间以及各类虚拟设备，例如 veth、Linux Bridge、tap/tun 等。虚拟化的本质是现实世界的映射，容器网络正是基于这些虚拟设备模拟现实世界中的物理设备彼此协作，将各个独立的网络命名空间连接起来，构建出不受物理环境约束的容器之间、容器与宿主机之间、乃至跨物理网络各类动态网络拓扑架构。 - - ## 网络命名空间 网络命名空间（Network Namespace）是 Linux Kernel 提供的用于实现网络虚拟化的核心，它能创建多个隔离的网络空间，该网络空间内的防火墙、网卡、路由表、邻居表、协议栈与外部独立，不管是虚拟机还是容器，当运行在独立的命名空间时，就像是一台单独的物理主机。 @@ -109,7 +107,7 @@ Linux Bridge 是 Linux Kernel 2.2 版本开始提供的二层转发工具，与 ## 网络 - VXLAN -有了各类虚拟设备之后，下一步就是要使用这些设备组成网络。传统的物理拓扑结构相对固定，很难支持云原生时代下逻辑拓扑结构频繁变动的要求，例如灾难恢复、业务迁移等敏捷需求，跨集群甚至跨多个计算中心的可迁移性。SDN（Software Definded Network，软件定义网络）在云计算和分布式时代下应运而生。 +有了各类虚拟设备之后，下一步就是要使用这些设备组成网络。传统的物理拓扑结构相对固定，很难支持云原生时代下逻辑拓扑结构频繁变动的需求，例如灾难恢复、业务迁移等敏捷需求，跨集群甚至跨多个计算中心的可迁移性。SDN（Software Definded Network，软件定义网络）在云计算和分布式时代下应运而生。 SDN 的核心思想是在物理网络之上，再构建一层虚拟化的网络，通过上层控制平面参与对网络的控制管理，以满足业务网络运维的需求。SDN 位于下层的物理网络被称为 Underlay，它着重解决网络的连通性，位于上层的逻辑网络被称为 overlay，它着重为应用提供与软件需求相符的传输服务和拓扑结构。由于跨主机的通信绝大多数都是 overlay 网络，所以在本节，笔者以 VXLAN 为例介绍 overlay 网络原理。