修改内容

isno · Feb 15, 2024 · e064e7f · e064e7f
1 parent e201cf9
commit e064e7f
Show file tree

Hide file tree

Showing 9 changed files with 12 additions and 9 deletions.
diff --git a/.vuepress/config.js b/.vuepress/config.js
@@ -287,7 +287,8 @@ export default defineUserConfig({
                     '/ServiceMesh/What-is-ServiceMesh.md',
                     '/ServiceMesh/MicroService-history.md',
                     '/ServiceMesh/overview.md',
-                    '/ServiceMesh/The-future-of-ServiceMesh.md'
+                    '/ServiceMesh/The-future-of-ServiceMesh.md',
+                    '/ServiceMesh/conclusion.md',
                 ]
             },
              {

diff --git a/Observability/OpenTelemetry.md b/Observability/OpenTelemetry.md
@@ -1,4 +1,4 @@
-# 9.3 可观测性大一统
+# 9.3 可观测性的未来
 
 建设完善的可观测体系，很可能会形成链路监控、日志监控、指标监控等多套不同的监控系统，要打通是相当困难的。不同的业务线间，日志规则不互通，要完全互通也很困难。系统一旦过多，相关维护以及故障排除的时间成本就会大幅增加。
 

diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md
@@ -1,4 +1,4 @@
-# 8.1 服务治理形式的演进
+# 8.2 服务治理形式的演进
 
 自 2011 年微服务架构理念提出以来，10 余年间一批又一批技术框架和理念不断涌现出来，如果以技术的表现形式划分，服务治理的模式已经迭代了四代。
 

diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md
@@ -1,4 +1,4 @@
-# 服务网格的未来
+# 8.4 服务网格的未来
 
 基于 Istio 的 ServiceMesh 架构在互联网公司进行大规模线上部署的时候逐渐遇到以下问题：
 

diff --git a/ServiceMesh/conclusion.md b/ServiceMesh/conclusion.md
@@ -1,4 +1,4 @@
-# 小结
+# 8.5 小结
 
 参考
 

diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md
@@ -1,4 +1,4 @@
-# 8.2 服务网格的产品与生态
+# 8.3 服务网格的产品与生态
 
 2016年1月，Buoyant 公司发布了第一代 ServiceMesh 产品 Linkerd。初次发布的 Linkerd 以 Scala 编写，绝大部分关注点都是如何做好 proxy（代理） 并完成一些通用控制面的功能。同期专注于 proxy 领域的还有一个重量级选手 Envoy，Envoy 由 Lyft 公司基于 C++ 开发，特点为性能出色、功能丰富、生态成熟，是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目。
 

diff --git a/distributed-transaction/ACID.md b/distributed-transaction/ACID.md
@@ -10,4 +10,4 @@
 
 当事务的影响范围局限在单机本地内的系统时，一致性通过编码实现起来水到渠成，但倘若事务修改的对象影响涉及外部，譬如跨越网络、跨越不同的数据源时，一致性问题通常很难再使用 A、I、D 来解决，但是外部一致性又是分布式系统中必然会遇到且必须要解决的问题，此时我们就要转变观念，**将一致性从“是或否”的二元问题转变为可以按不同强度分开讨论的多元问题，在确保代价可承受的前提下获得强度尽可能高的一致性保障**。
 
-一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，下面笔者就来介绍分布式系统中最为出名的权衡理论 -- CAP 定理。
+一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，下面笔者就来介绍分布式系统中最为出名的权衡理论 -- CAP 定理。
diff --git a/distributed-transaction/idempotent.md b/distributed-transaction/idempotent.md
@@ -1,6 +1,8 @@
 # 5.3.4 幂等性实现
 
-在分布式事务的篇节中，笔者提到因为最大努力交付机制某些阶段要具备幂等性，幂等是来源于数学中的一个概念，用数学语言表达就是 `f(x)=f(f(x))`，计算机中指的是一个操作多次执行的结果与其执行一次的结果相同。业务具有幂等性可以规避数据不一致和重复处理的问题，譬如一个退款的接口，如果不加以控制，多次请求产生多次退款会造成无法承受的损失。
+由于分布式系统中可能会存在超时重试的情况，柔性事务大都采用最大努力交付机制解决超时问题，因此柔性事务中的操作必须是幂等的。
+
+幂等是来源于数学中的一个概念，用数学语言表达就是 `f(x)=f(f(x))`，计算机中指的是一个操作多次执行的结果与其执行一次的结果相同。业务具有幂等性可以规避数据不一致和重复处理的问题，譬如一个退款的接口，如果不加以控制，多次请求产生多次退款会造成无法承受的损失。
 
 实现系统的幂等性有多种方式，笔者介绍一种常用的方式：**使用全局唯一 ID 方案**。利用全局唯一 ID 及数据库主键唯一特性解决重复提交的问题，对于相同的 ID 重复插入时，产生 `result in duplicate entry for key primary` 错误，这种方式的流程如下。
 

diff --git a/distributed-transaction/transaction.md b/distributed-transaction/transaction.md
@@ -1,3 +1,3 @@
 # 5.3 分布式事务模型
 
-既然一致性被重新定义了，事务的概念自然也被拓展了，人们把符合 ACID 特性的事务称为 ”刚性事务“，把后面笔者要介绍的几种分布式事务统称为”柔性事务“。
+既然一致性被重新定义了，事务的概念自然也被拓展了，人们把符合 ACID 特性的事务称为 ”刚性事务“，把后面 可靠事件队列、Saga、TCC 等几种分布式事务统称为”柔性事务“。
Original file line number	Diff line number	Diff line change
Expand Up		@@ -10,4 +10,4 @@

		当事务的影响范围局限在单机本地内的系统时，一致性通过编码实现起来水到渠成，但倘若事务修改的对象影响涉及外部，譬如跨越网络、跨越不同的数据源时，一致性问题通常很难再使用 A、I、D 来解决，但是外部一致性又是分布式系统中必然会遇到且必须要解决的问题，此时我们就要转变观念，将一致性从“是或否”的二元问题转变为可以按不同强度分开讨论的多元问题，在确保代价可承受的前提下获得强度尽可能高的一致性保障。

		一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，下面笔者就来介绍分布式系统中最为出名的权衡理论 -- CAP 定理。
		一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，下面笔者就来介绍分布式系统中最为出名的权衡理论 -- CAP 定理。