diff --git a/.vuepress/config.js b/.vuepress/config.js index 73736674..59ef7230 100644 --- a/.vuepress/config.js +++ b/.vuepress/config.js @@ -287,6 +287,7 @@ export default defineUserConfig({ children: [ '/ServiceMesh/What-is-ServiceMesh.md', '/ServiceMesh/MicroService-history.md', + '/ServiceMesh/ServiceMesh-and-Kubernetes.md', '/ServiceMesh/overview.md', '/ServiceMesh/The-future-of-ServiceMesh.md', '/ServiceMesh/conclusion.md', diff --git a/.vuepress/layouts/layout.vue b/.vuepress/layouts/layout.vue index 3c103e3d..386aaf88 100644 --- a/.vuepress/layouts/layout.vue +++ b/.vuepress/layouts/layout.vue @@ -8,8 +8,8 @@
总字数: - {{ pageWords}} - 字　 + {{ pageWords}} + 字
@@ -93,5 +93,6 @@ .words { font-weight: 400; color: #aaa; + padding: 0px 3px; } \ No newline at end of file diff --git a/Observability/What-is-Observability.md b/Observability/What-is-Observability.md index 679217b0..65aae02a 100644 --- a/Observability/What-is-Observability.md +++ b/Observability/What-is-Observability.md @@ -11,6 +11,6 @@ The information that you will use to determine whether an application is healthy 如果你在生活中观察仔细，观看火箭发射的直播时，能注意到发射指挥大厅内回响起一系列有条不紊的口令：“东风光学USB雷达跟踪正常，遥测信号正常”，软件领域的可测性以及系统遥测数据本质和火箭发射系统一致，就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情。 -所以，**可观测性本质上一门数据收集和分析的科学**，帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题。 +所以，**可观测性本质上一门数据收集和分析的科学**，帮助大家解决在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题。 [^1]: 参见 https://cloud.google.com/learn/what-is-opentelemetry diff --git a/Observability/summary.md b/Observability/summary.md index b322ad36..f549c6cc 100644 --- a/Observability/summary.md +++ b/Observability/summary.md @@ -1,5 +1,5 @@ # 第九章：系统可观测性 -可观测性（Observability）一词最早出现在控制论领域（最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念），有着几十年的历史。随着云原生时代的到来，2018 年，CNCF 率先将可观测性的概念引入 IT 领域，并称可观测性是云原生时代必须具备的能力。 +可观测性（Observability）一词最早出现在控制论领域，是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念，已有着几十年的历史。随着云原生时代的到来，2018 年，CNCF 率先将可观测性的概念引入 IT 领域，并称可观测性是云原生时代必须具备的能力。 从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。至此，”可观测性“逐渐取代”监控“，成为云原生技术领域最热门的话题之一。 \ No newline at end of file diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md index 52ef151a..35a26711 100644 --- a/ServiceMesh/MicroService-history.md +++ b/ServiceMesh/MicroService-history.md @@ -1,4 +1,4 @@ -# 8.2 演化出 ServiceMesh 的驱动力 +# 8.2 服务间通信的演化 TCP 协议之后分布式系统诞生，分布式系统催生出微服务，服务间的通信需求又催生出 ServiceMesh。理解服务间通信的本质之后，就会得到一个感性的结论 Service Mesh 是微服务时代的 TCP/IP 协议。 diff --git a/ServiceMesh/ServiceMesh-and-Kubernetes.md b/ServiceMesh/ServiceMesh-and-Kubernetes.md new file mode 100644 index 00000000..b11805e0 --- /dev/null +++ b/ServiceMesh/ServiceMesh-and-Kubernetes.md @@ -0,0 +1,9 @@ +# 8.4 ServiceMesh 与 Kubernetes + +Kubernetes 的本质是应用的生命周期管理，具体来说就是部署和管理（扩缩容、自动恢复、发布）。Kubernetes 为微服务提供了可扩展、高弹性的部署和管理平台。Service Mesh 的基础是透明代理，通过 sidecar proxy 拦截到微服务间流量后再通过控制平面配置管理微服务的行为。Service Mesh 将流量管理从 Kubernetes 中解耦，Service Mesh 内部的流量无需 kube-proxy 组件的支持，通过为更接近微服务应用层的抽象，管理服务间的流量、安全性和可观察性。 + +
+ +

图片来源于《云原生服务网格Istio》

+
+ diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md index 7f8aae93..f0489a91 100644 --- a/ServiceMesh/The-future-of-ServiceMesh.md +++ b/ServiceMesh/The-future-of-ServiceMesh.md @@ -1,4 +1,4 @@ -# 8.4 ServiceMesh 的未来 +# 8.5 ServiceMesh 的未来 基于 Istio 的 ServiceMesh 架构在互联网公司进行大规模线上部署的时候逐渐遇到以下问题： diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md index 93d15bbf..1df72513 100644 --- a/ServiceMesh/What-is-ServiceMesh.md +++ b/ServiceMesh/What-is-ServiceMesh.md @@ -1,4 +1,4 @@ -# 8.1 什么是 ServiceMesh +# 8.1 什么是服务网格 2016年，离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 Buoyant，不久之后他们在 Github 上发布了创业项目 Linkerd，业界第一款 ServiceMesh（服务网格）项目诞生。 @@ -12,7 +12,18 @@ Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职 ::: -概览以下里程碑事件，我们看到 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的历程。 +Service Mesh 目的是解决系统架构微服务化后的服务间通信和治理问题。Service Mesh 由 Sidecar 节点组成，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。 + +服务之间通过 Sidecar 发现和调用目标服务，从而在服务之间形成一种网络状依赖关系，如果我们把节点和业务逻辑从视图剥离，就会出现一种网络状的架构，如图 1-23 所示，服务网格由此得名。 + +
+ +

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

+
+ +从 Micro-Services 到 Service Mesh 承前启后和顺其自然，光看名字就能很形象地理解它所做的事情：把微服务的各个 Service（服务）节点，用一张 mesh（网格）连接起来。就这样，原本被拆散得七零八落的微服务们，又被 Service Mesh 这张大网紧密得连接到了一起，即使依然天各一方（进程间隔离），但也找回了当年一起挤在单体应用内抱团撒欢的亲密感（通信更容易）。 + +最后，概览以下里程碑事件，我们感受 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 6c980b68..8040dd9f 100644 --- a/ServiceMesh/conclusion.md +++ b/ServiceMesh/conclusion.md @@ -1,4 +1,4 @@ -# 8.5 小结 +# 8.6 小结 Service Mesh 属于锦上添花的一种方案，而不是雪中送炭，所以业务运行良好，在惰性的情况下大家没什么动力去折腾。 @@ -8,4 +8,5 @@ ServiceMesh 本身过于复杂（比传统侵入式框架还要复杂），只 参考 - William Morgan 的服务网格之战，https://softwareengineeringdaily.com/2019/05/31/service-mesh-wars-with-william-morgan/ -- Pattern: Service Mesh，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 +- 《云原生服务网格Istio：原理、实践、架构与源码解析》 \ No newline at end of file diff --git a/assets/ServiceMesh-and-Kubernetes.png b/assets/ServiceMesh-and-Kubernetes.png new file mode 100644 index 00000000..78be56ba Binary files /dev/null and b/assets/ServiceMesh-and-Kubernetes.png differ diff --git a/intro.md b/intro.md index 981831c4..fbecbbd0 100644 --- a/intro.md +++ b/intro.md @@ -4,7 +4,7 @@ 这些概念其实全部围绕着构建大规模分布式基础架构的几个核心要素：稳定（不出任何问题）、效率（快速响应市场需求）、成本（充分有效的利用资源）。 -分析这些激动人心的技术变革之前，让我们发散思维，思考引发这一泼技术浪潮的核心驱动力是什么! +分析这些激动人心的技术变革之前，我们思考引发这一泼技术浪潮的核心驱动力是什么？ ## 软件在吞噬世界 @@ -33,11 +33,9 @@

图 Netflix按照规模和变更速度对软件企业划分的总结

-在十年前乃至二十年前的互联网时代，大多数软件企业都位于图 1-8 左边的两个象限：规模或许有大有小，但是变更速度相对今天都不快。当企业发展壮大时，体现的也更多是在规模上，变更速度并不会发生质的变化。 +在十年前乃至二十年前的互联网时代，大多数软件企业都位于图 1-8 左边的两个象限：规模或许有大有小，但是变更速度相对今天都不快。当企业发展壮大时，体现的也更多是在规模上，变更速度并不会发生质的变化。而今天的移动互联网时代，则都位于图 1-8 右边的两个象限：无论规模是大是小，变更速度都要求非常快。并且当企业逐步发展壮大，规模十倍百倍增长时，对变更速度的要求并不会降低，甚至会要求更快。 -而今天的移动互联网时代，则都位于图 1-8 右边的两个象限：无论规模是大是小，变更速度都要求非常快。并且当企业逐步发展壮大，规模十倍百倍增长时，对变更速度的要求并不会降低，甚至会要求更快。 - -在移动互联网时代，能够成长并发展起来的这些公司，他们的共同点是： +移动互联网时代，能够成长并发展起来的这些公司，他们的共同点是： - 快速变更，不断创新，随时调整 - 提供持续可用的服务，应对各种可能的错误和中断