feat(all): 完善文章

blog-site/content/posts/java/javaessay/分布式事务详解.md

@@ -177,11 +177,9 @@ XA方案需要本地数据库支持XA协议，资源锁需要等到准备阶段
 #### Seata方案
 Seata是由阿里中间件团队发起的开源项目Fescar，后更名为Seata，它是一个开源的分布式事务框架。
 
-传统2PC的问题在Seata中得到了解决，它通过对本地关系型数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。
-主要优点是性能较好，且不长时间占用连接资源，它以高效并对业务0入侵的方式解决微服务场景下面临的分布式事务问题，目前提供AT模式（即2PC）和TCC模式的分布式事务解决方案。
-
 Seata的设计目标其一是对业务零侵入，因此从业务无侵入的2PC入手，在传统方案2PC的基础上演进，并解决2PC方案面临的问题。
-Seata把一个分布式的事务理解为一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交事务，要么一起回滚失败。此外，通常分支事务本身就是一个关系型数据库的本地事务。
+Seata把一个分布式的事务理解为一个包含了若干分支事务的全局事务，它通过对本地关系型数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交事务，要么一起回滚失败。此外，通常分支事务本身就是一个关系型数据库的本地事务。
+主要优点是性能较好，且不长时间占用连接资源，它以高效并对业务0入侵的方式解决微服务场景下面临的分布式事务问题，目前提供AT模式（即2PC）和TCC模式的分布式事务解决方案。
 
 ![分布式事务-005](/iblog/posts/annex/images/essays/分布式事务-005.png)
 

blog-site/content/posts/java/javaessay/微服务治理详解.md

@@ -56,7 +56,7 @@ slug: "distributed-small-service"
 它不仅包括技术实现，还涉及设计规范和策略，目的是为了解决服务调用、资源分配和故障处理等关键问题。
 
 ### 服务治理治的是什么
-> 在进行城市交通规划之前首先要做的第一个事情是收集信息，要能够知道这个城市发生了什么，所以在各个路口需要安装采集探头，记录车来车往的信息。有了信息以后就需要对信息进行分析了，那么就需要可视化的图形界面，能够一眼就看出什么地方出了问题，通往哪个工厂的路坏了。发现了问题就要解决问题了，限制一下拥堵路段的流量，把去往一个公园的车辆导向到另外一个类似的公园。最后，如果把城市作为一个国家来考虑，那么每个进入这个城市的车辆都需要进行检查，看看有没有携带违禁品，最后给这些不熟悉道路的外地车规划路线。通过上面这个思考的过程，我们发现要对一个城市进行治理的时候，第一要采集信息，然后要能够对采集的信息进行监控和分析，最后根据分析的结果采取对应的治理策略。另外从整体安全的角度考虑还需要一个守门人
+> 在进行城市交通规划之前首先要做的第一个事情是收集信息，要能够知道这个城市发生了什么，所以在各个路口需要安装采集探头，记录车来车往的信息。有了信息以后就需要对信息进行分析了，那么就需要可视化的图形界面，能够一眼就看出什么地方出了问题，通往哪个工厂的路坏了。发现了问题就要解决问题了，限制一下拥堵路段的流量，把去往一个公园的车辆导向到另外一个类似的公园。最后，如果把城市作为一个国家来考虑，那么每个进入这个城市的车辆都需要进行检查，看看有没有携带违禁品，最后给这些不熟悉道路的外地车规划路线。通过上面这个思考的过程，我们发现要对一个城市进行治理的时候，第一要采集信息，然后要能够对采集的信息进行监控和分析，最后根据分析的结果采取对应的治理策略。另外从整体安全的角度考虑还需要一个守门人。
 
 我们也用同样的思路来思考服务治理，网关就是整个整体的守门人，日志采集，追踪工具，服务注册发现都是用来采集信息的，然后需要监控平台来展现这些采集的信息，并进行监控和分析。
 最后根据分析的结果采取治理策略，有的服务快撑不住了要限流，有的服务坏了要熔断，并且还能够及时的调整这些服务的配置。
@@ -459,19 +459,110 @@ Nacos 服务发现流程：
     ```
 4. 修改 Nacos 控制台中的配置，观察 SpringBoot 应用是否能够动态刷新配置；
 
-
 #### Sentinel
-[//]: # (写到了这里。。。。。。)
-随着微服务的流行，服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
+Sentinel 是阿里巴巴开源的一款流量防护和熔断工具，专为分布式系统设计，提供了限流、熔断降级、系统保护和实时监控等功能，适用于高并发、高可用的分布式微服务架构。
 
 Sentinel 具有以下特征:
 - 丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。
 - 完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
 - 广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 SpringCloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
 - 完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。
 
+Sentinel 的熔断机制通过实时监控接口的异常情况（如请求失败率、响应时间）来判断是否触发熔断，以避免系统雪崩。主要工作原理如下：
+1. 监控数据：对每个接口的请求量、错误率、响应时间等数据进行统计，基于滑动窗口收集短时间内的请求情况。
+2. 熔断触发：根据配置的熔断规则（如错误比例、响应时间等），当统计数据超过预设的阈值时，触发熔断。熔断期间该接口会拒绝请求，直接返回错误响应。
+3. 进入半开状态：经过一段时间后，系统进入“半开”状态，允许部分请求通过。若恢复正常，解除熔断；若依然异常，继续熔断。
+4. 恢复正常：在半开状态下请求正常时，熔断器关闭，接口恢复服务，以确保服务逐步回归稳定。
+
+假设有一个电商系统中的“下单”接口，为了保证系统稳定性，我们配置了以下熔断规则：当“下单”接口的错误率超过 50%，并且在 10 秒内调用量超过 100 时触发熔断，熔断持续时间为 5 秒。Sentinel执行流程如下：
+1. 正常监控：系统正常运行时，Sentinel 监控每次“下单”请求的成功与失败，统计错误率。
+2. 熔断触发：某个时段内由于后端数据库延迟，“下单”接口的错误率在 10 秒内达到了 60%（超过了配置的 50%），且调用量也超过 100。此时，Sentinel 自动触发熔断，拒绝所有“下单”请求，并直接返回错误信息给客户端。
+3. 进入半开状态：5 秒后，Sentinel 进入“半开”状态。此时允许一部分请求通过，如果这些请求成功率较高，系统恢复正常。
+4. 恢复或继续熔断：
+   - 如果在半开状态下的请求依旧失败较多，错误率较高，则熔断器重新进入熔断状态，拒绝请求并持续监控。
+   - 若通过请求的错误率明显下降，则熔断器关闭，接口完全恢复正常服务。
+
+#### Seata
+Seata是一款分布式事务解决方案，专为微服务架构而设计，主要用于解决分布式环境下的数据一致性问题。Seata 由阿里巴巴开源，具备高性能、易于扩展的特点，在微服务环境下提供简单可靠的分布式事务控制。
+
+Seata的设计目标其一是对业务零侵入，因此从业务无侵入的2PC入手，在传统方案2PC的基础上演进，并解决2PC方案面临的问题。
+Seata把一个分布式的事务理解为一个包含了若干分支事务的全局事务，它通过对本地关系型数据库的分支事务的协调来驱动完成全局事务，是工作在应用层的中间件。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交事务，要么一起回滚失败。此外，通常分支事务本身就是一个关系型数据库的本地事务。
+主要优点是性能较好，且不长时间占用连接资源，它以高效并对业务0入侵的方式解决微服务场景下面临的分布式事务问题，目前提供AT模式（即2PC）和TCC模式的分布式事务解决方案。
+
+
+![分布式事务-005](/iblog/posts/annex/images/essays/分布式事务-005.png)
+
+与传统2PC的模型类似，Seata定义了3个组件来协调分布式事务的处理过程：
+![分布式事务-006](/iblog/posts/annex/images/essays/分布式事务-006.png)
+- TM：`Transaction Manager`事务管理器，需要嵌入（jar包）应用程序中工作，负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。
+- RM：`Resource Manager`资源管理器，控制分支事务，负责分支事务注册，状态回报，并接收事务调节器的指令，驱动分支事务的提交和回滚。
+- TC：`Transaction Coordinator`事务协调器，它是独立的中间件，需要独立运行部署，它维护全局事务的运行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各个分支事务的提交回滚。
+
+以新用户注册送积分举例：
+![分布式事务-007](/iblog/posts/annex/images/essays/分布式事务-007.png)
+
+具体执行流程：
+1. 用户服务器的事务管理器向事务协调器申请开启一个全局事务，全局事务的创建成功并生成一个全局唯一XID。
+2. 用户服务器的资源管理器向事务协调器注册分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入XID对应全局事务的管辖。
+   > 在执行注册分支事务的时候，这里事务已经提交了，提交后可以释放资源，从而提升程序性能。
+3. 用户服务器执行分支事务，向用户表插入一条记录。
+4. 逻辑执行到远程分布式调用积分服务时，XID在微服务调用链路的上下文中传播。积分服务的资源管理器向事务协调器注册了分支事务，该分支事务执行增加积分的逻辑，并将其纳入XID对应的全局事务的管辖。
+5. 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
+6. 用户服务分支事务执行完毕。
+7. 事务管理器向事务协调器针对XID的全局提交或者回滚决策。
+8. 事务协调器调度XID下管辖的全部分支事务完成提交或回滚的请求。
+
+Seata实现2PC与传统2PC的差别：
+- 架构方面，传统2PC方案的RM实际上是在数据库层，RM本质上就是数据库自身，通过XA协议实现，而Seata的RM则是以jar包的形式作为中间件层部署在应用程序这一侧的。
+- 两阶段提交方面，传统2PC无论第二阶段的决策是`commit`还是`rollback`，事务性资源的锁都要保持到第二阶段才释放。而Seata的做法是在第一阶段就将本地事务提交，这样可以省去第二阶段持有锁的时间，提高整体效率。
+
+Seata两阶段提交协议的演变：
+- 一阶段：Seata会拦截，解析SQL语义，找到SQL要更新的数据，在业务员数据更新前，将其保存为`before image`，随后执行业务SQL。在业务数据更新后，将其保存为`after image`，插入`UNDO LOG`回滚日志；提交前向TC注册分支并生成行锁。
+  随后本地事务提交，将本地事务提交的结果上报给TC，由TC协调。
+  ![分布式事务-008](/iblog/posts/annex/images/essays/分布式事务-008.png)
+
+- 二阶段-提交：执行提交操作，说明SQL执行顺利，因业务SQL在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
+  ![分布式事务-009](/iblog/posts/annex/images/essays/分布式事务-009.png)
+
+- 二阶段-回滚：要执行回滚操作，说明SQL执行不顺利，Seata需要回滚一阶段已经执行的业务SQL还原数据。回滚方式是用`before image`还原数据，但是在还原前还要校验脏写，对比数据库当前业务数据和`after image`。
+  对比数据库当前业务数据和`after image`。
+  ![分布式事务-010](/iblog/posts/annex/images/essays/分布式事务-010.png)
+
+#### Skywalking
+SkyWalking 是一款开源的应用性能监控（APM）工具，专注于微服务、云原生应用和分布式系统的监控与管理。它能够通过链路追踪、指标收集和分析，帮助开发者定位和解决分布式系统中的性能瓶颈和故障。
+
+SkyWalking 适用于各类分布式系统，尤其是微服务架构的应用。它能够帮助开发和运维人员更好地监控和优化服务性能，并在故障发生时快速定位问题源头，适用于电商、金融等对系统可靠性要求较高的领域。核心功能如下：
+- 分布式追踪：SkyWalking 能够在微服务调用链路中记录请求的路径，包括请求的起点、经过的服务节点和终点等，帮助定位问题节点。
+- 应用监控：收集系统的各项性能指标，如 CPU、内存、请求量、延迟等，直观呈现应用的健康状况。
+- 报警与告警：支持阈值告警和自定义告警，当性能指标异常时自动触发报警，及时提醒运维人员。
+- 服务依赖分析：绘制服务间的调用关系图，展示微服务架构下的服务依赖，方便分析服务拓扑。
+
+注意事项：
+- 数据存储优化：SkyWalking 生成大量追踪数据，建议使用性能较好的存储方案（如 Elasticsearch）。对于高流量系统，存储方案的性能至关重要，否则会造成数据处理瓶颈。
+- 网络开销：SkyWalking 的探针会收集大量追踪数据并发送至后端，网络延迟可能影响监控的实时性。因此，确保服务与后端的网络连通性，尤其是跨数据中心部署的情况。
+- 性能开销：SkyWalking 的探针会增加一定的系统开销，尽管通常开销不大，但在高并发服务中，需关注探针对服务响应时间的影响，合理配置采样率。
+- 告警规则的合理配置：设置适合系统的告警阈值，避免频繁告警导致“告警疲劳”。建议针对关键性能指标（如响应时间、错误率等）制定精确告警规则。
+- 采样率：在高流量场景下，可以适当降低链路追踪的采样率，以平衡系统监控的全面性和性能。
+
+SkyWalking 分布式追踪的核心原理：
+1. 链路追踪的基本概念：
+   - Trace：追踪一个请求的全生命周期，它跨越多个服务节点，可以包含多个 span。
+   - Span：描述链路中的一次操作或请求，通常是一个服务的处理过程。一个 trace 由多个 span 组成，且 span 之间有顺序关系，表示请求流转的路径。
+
+2. 追踪数据的采集：
+   - 每当一个请求被发送到一个微服务时，SkyWalking 会在请求头中插入唯一标识符（如 Trace ID 和 Span ID）。这些标识符会随着请求在微服务间传递，保持请求的链路关系。
+   - 通过在服务端应用中安装 SkyWalking 的代理探针（Agent）或 SDK，SkyWalking 会自动捕获请求的相关信息，包括调用时间、请求的服务、处理的操作等。
+
+3. 追踪数据的传播：
+   - 在分布式系统中，每个微服务的处理请求都会携带 Trace ID 和 Span ID 信息。当请求从一个服务调用到另一个服务时，后续服务会继续传递这些 ID 信息，从而形成一个完整的调用链。
+   - SkyWalking 支持通过 HTTP、gRPC 等协议传递追踪信息，通常是通过 HTTP 请求头（如 X-B3-TraceId, X-B3-SpanId）来传递。
+
+4. 数据的收集与聚合：
+   - 每个微服务中的 SkyWalking Agent 会对本地的每个请求生成一个 Span，并在 Span 完成时将其发送到 SkyWalking 后端。
+   - 后端会对收集到的 Span 数据进行聚合，将它们组合成完整的 Trace。Trace 包含了所有跨服务的调用信息，并可以形成一个服务间的调用链。
 
 ### Dubbo体系
+[//]: # (写到了这里。。。)
 
 #### Dubbo
 Apache Dubbo 是一款易用、高性能的 WEB 和 RPC 框架，同时为构建企业级微服务提供服务发现、流量治理、可观测、认证鉴权等能力、工具与最佳实践。