Skip to content

Commit

Permalink
更新 ServiceMesh
Browse files Browse the repository at this point in the history
  • Loading branch information
isno committed Feb 18, 2024
1 parent f058fd2 commit 8202310
Show file tree
Hide file tree
Showing 11 changed files with 36 additions and 15 deletions.
1 change: 1 addition & 0 deletions .vuepress/config.js
Original file line number Diff line number Diff line change
Expand Up @@ -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',
Expand Down
5 changes: 3 additions & 2 deletions .vuepress/layouts/layout.vue
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@
</div>
<div class="last-updated" >
<span class="prefix" v-if="pageWords > 0">总字数:</span>
<span class="words" v-if="pageWords > 0">{{ pageWords}}</span>
<span class="prefix" v-if="pageWords > 0">字 </span>
<span class="words" v-if="pageWords > 0"> {{ pageWords}} </span>
<span class="prefix" v-if="pageWords > 0">字</span>
</div>
</div>
<CommentService :darkmode="isDarkMode" class="layout-comment" />
Expand Down Expand Up @@ -93,5 +93,6 @@
.words {
font-weight: 400;
color: #aaa;
padding: 0px 3px;
}
</style>
2 changes: 1 addition & 1 deletion Observability/What-is-Observability.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
2 changes: 1 addition & 1 deletion Observability/summary.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# 第九章:系统可观测性

可观测性(Observability)一词最早出现在控制论领域(最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念),有着几十年的历史。随着云原生时代的到来,2018 年,CNCF 率先将可观测性的概念引入 IT 领域,并称可观测性是云原生时代必须具备的能力。
可观测性(Observability)一词最早出现在控制论领域,是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念,已有着几十年的历史。随着云原生时代的到来,2018 年,CNCF 率先将可观测性的概念引入 IT 领域,并称可观测性是云原生时代必须具备的能力。

从生产所需到概念发声,加之包括 Google 在内的众多大厂一拥而上。至此,”可观测性“逐渐取代”监控“,成为云原生技术领域最热门的话题之一。
2 changes: 1 addition & 1 deletion ServiceMesh/MicroService-history.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 8.2 演化出 ServiceMesh 的驱动力
# 8.2 服务间通信的演化

TCP 协议之后分布式系统诞生,分布式系统催生出微服务,服务间的通信需求又催生出 ServiceMesh。理解服务间通信的本质之后,就会得到一个感性的结论 Service Mesh 是微服务时代的 TCP/IP 协议。

Expand Down
9 changes: 9 additions & 0 deletions ServiceMesh/ServiceMesh-and-Kubernetes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# 8.4 ServiceMesh 与 Kubernetes

Kubernetes 的本质是应用的生命周期管理,具体来说就是部署和管理(扩缩容、自动恢复、发布)。Kubernetes 为微服务提供了可扩展、高弹性的部署和管理平台。Service Mesh 的基础是透明代理,通过 sidecar proxy 拦截到微服务间流量后再通过控制平面配置管理微服务的行为。Service Mesh 将流量管理从 Kubernetes 中解耦,Service Mesh 内部的流量无需 kube-proxy 组件的支持,通过为更接近微服务应用层的抽象,管理服务间的流量、安全性和可观察性。

<div align="center">
<img src="../assets/ServiceMesh-and-Kubernetes.png" width = "450" align=center />
<p>图片来源于《云原生服务网格Istio》</p>
</div>

2 changes: 1 addition & 1 deletion ServiceMesh/The-future-of-ServiceMesh.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 8.4 ServiceMesh 的未来
# 8.5 ServiceMesh 的未来

基于 Istio 的 ServiceMesh 架构在互联网公司进行大规模线上部署的时候逐渐遇到以下问题:

Expand Down
15 changes: 13 additions & 2 deletions ServiceMesh/What-is-ServiceMesh.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 8.1 什么是 ServiceMesh
# 8.1 什么是服务网格

2016年,离开 Twiiter 的工程师 William Morgan 和 Oliver Gould 组建了一个小型的技术公司 Buoyant,不久之后他们在 Github 上发布了创业项目 Linkerd,业界第一款 ServiceMesh(服务网格)项目诞生。

Expand All @@ -12,7 +12,18 @@ Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职

:::

概览以下里程碑事件,我们看到 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的历程。
Service Mesh 目的是解决系统架构微服务化后的服务间通信和治理问题。Service Mesh 由 Sidecar 节点组成,这个模式的精髓在于实现了数据面(业务逻辑)和控制面的解耦。

服务之间通过 Sidecar 发现和调用目标服务,从而在服务之间形成一种网络状依赖关系,如果我们把节点和业务逻辑从视图剥离,就会出现一种网络状的架构,如图 1-23 所示,服务网格由此得名。

<div align="center">
<img src="../assets/service-mesh.png" width = "580" align=center />
<p>图1-23 服务网格形象示例</p>
</div>

从 Micro-Services 到 Service Mesh 承前启后和顺其自然,光看名字就能很形象地理解它所做的事情:把微服务的各个 Service(服务)节点,用一张 mesh(网格)连接起来。就这样,原本被拆散得七零八落的微服务们,又被 Service Mesh 这张大网紧密得连接到了一起,即使依然天各一方(进程间隔离),但也找回了当年一起挤在单体应用内抱团撒欢的亲密感(通信更容易)。

最后,概览以下里程碑事件,我们感受 ServiceMesh 从无到有、被社区接受、巨头入局、众人皆捧的历程。

- 2016年9 月,在 SF MicroServices 大会上,“ServiceMesh” 这个术语第一次在公开场合使用,这标志着 ServiceMesh 逐渐从 Buoyant 公司走向社区,并开始被广泛接受以及推崇。
- 2017年1月,Linkerd 加入 CNCF,项目类型被归类到 CNCF 新开辟的 “ServiceMesh” 分类。这代表着 ServiceMesh 理念被 CNCF 社区认同。
Expand Down
5 changes: 3 additions & 2 deletions ServiceMesh/conclusion.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# 8.5 小结
# 8.6 小结


Service Mesh 属于锦上添花的一种方案,而不是雪中送炭,所以业务运行良好,在惰性的情况下大家没什么动力去折腾。
Expand All @@ -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
- Pattern: Service Mesh,https://philcalcado.com/2017/08/03/pattern_service_mesh.html
- 《云原生服务网格Istio:原理、实践、架构与源码解析》
Binary file added assets/ServiceMesh-and-Kubernetes.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 3 additions & 5 deletions intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

这些概念其实全部围绕着构建大规模分布式基础架构的几个核心要素:稳定(不出任何问题)、效率(快速响应市场需求)、成本(充分有效的利用资源)。

分析这些激动人心的技术变革之前,让我们发散思维,思考引发这一泼技术浪潮的核心驱动力是什么!
分析这些激动人心的技术变革之前,我们思考引发这一泼技术浪潮的核心驱动力是什么?

## 软件在吞噬世界

Expand Down Expand Up @@ -33,11 +33,9 @@
<p>图 Netflix按照规模和变更速度对软件企业划分的总结</p>
</div>

在十年前乃至二十年前的互联网时代,大多数软件企业都位于图 1-8 左边的两个象限:规模或许有大有小,但是变更速度相对今天都不快。当企业发展壮大时,体现的也更多是在规模上,变更速度并不会发生质的变化。
在十年前乃至二十年前的互联网时代,大多数软件企业都位于图 1-8 左边的两个象限:规模或许有大有小,但是变更速度相对今天都不快。当企业发展壮大时,体现的也更多是在规模上,变更速度并不会发生质的变化。而今天的移动互联网时代,则都位于图 1-8 右边的两个象限:无论规模是大是小,变更速度都要求非常快。并且当企业逐步发展壮大,规模十倍百倍增长时,对变更速度的要求并不会降低,甚至会要求更快。

而今天的移动互联网时代,则都位于图 1-8 右边的两个象限:无论规模是大是小,变更速度都要求非常快。并且当企业逐步发展壮大,规模十倍百倍增长时,对变更速度的要求并不会降低,甚至会要求更快。

在移动互联网时代,能够成长并发展起来的这些公司,他们的共同点是:
移动互联网时代,能够成长并发展起来的这些公司,他们的共同点是:

- 快速变更,不断创新,随时调整
- 提供持续可用的服务,应对各种可能的错误和中断
Expand Down

0 comments on commit 8202310

Please sign in to comment.