vault backup: 2026-05-15 16:26:14

hzh/MS/06-gRPC/01-协议与架构.md

@@ -150,12 +150,12 @@ graph LR
 >
 > 既然 gRPC 这么多优势，是不是所有场景都应该用 gRPC？什么情况下 HTTP/JSON 仍然更合适？
 
-答案见 [[02-服务治理/服务间通信]]。对外暴露 API 时，HTTP/JSON 仍然不可替代——因为浏览器的 Native Fetch 无法直接调用 gRPC，第三方接入者也不想安装 Proto 编译器。
+答案见 [[02-服务治理/05-服务间通信]]。对外暴露 API 时，HTTP/JSON 仍然不可替代——因为浏览器的 Native Fetch 无法直接调用 gRPC，第三方接入者也不想安装 Proto 编译器。
 
 ## 关联笔记
 
-- [[02-服务治理/服务间通信]] — gRPC 与 REST 的基础对比及选型建议
-- [[02-服务治理/容错模式/README]] — 基于此架构的重试、熔断等治理机制
+- [[02-服务治理/05-服务间通信]] — gRPC 与 REST 的基础对比及选型建议
+- [[02-服务治理/06-容错模式]] — 基于此架构的重试、熔断等治理机制
 - [[02-Proto设计]] — Proto 文件设计的进阶实践
 - [[03-RPC模式]] — 四种 RPC 模式的深度用法
 - [[04-拦截器]] — 切面编程和上下文传播

hzh/MS/06-gRPC/02-Proto设计.md

@@ -279,4 +279,4 @@ proto/
 
 - [[01-协议与架构]] — Proto 文件最终服务于协议栈中的 Generated Stub 层
 - [[07-最佳实践]] — Buf 代码生成流程和生产配置
-- [[02-服务治理/服务间通信]] — 不同序列化方案的性能对比
+- [[02-服务治理/05-服务间通信]] — 不同序列化方案的性能对比

hzh/MS/06-gRPC/04-拦截器.md

@@ -156,7 +156,7 @@ conn, _ := grpc.Dial(target,
 
 > [!keypoint] 为什么需要上下文传播
 >
-> 当一个请求穿越 5 个微服务时，如果没有上下文传播，你在日志系统中看到的是 5 条孤立的记录。有了 W3C Trace Context，每层服务自动将 `traceparent` 透传给下一跳——最终汇聚成一条完整的调用链路，这就是 [[02-服务治理/分布式追踪]] 的核心能力。
+> 当一个请求穿越 5 个微服务时，如果没有上下文传播，你在日志系统中看到的是 5 条孤立的记录。有了 W3C Trace Context，每层服务自动将 `traceparent` 透传给下一跳——最终汇聚成一条完整的调用链路，这就是 [[02-服务治理/03-分布式追踪]] 的核心能力。
 
 ## 拦截器最佳实践
 
@@ -172,5 +172,5 @@ conn, _ := grpc.Dial(target,
 
 - [[01-协议与架构]] — 拦截器位于 gRPC Framework 层，在 HTTP/2 之前处理请求
 - [[05-错误处理]] — 拦截器经常需要根据错误码决定重试或降级策略
-- [[02-服务治理/分布式追踪]] — Context 传播是实现分布式追踪的前提
-- [[02-服务治理/安全机制]] — 鉴权拦截器是安全机制在代码层的落地形式
+- [[02-服务治理/03-分布式追踪]] — Context 传播是实现分布式追踪的前提
+- [[02-服务治理/02-安全机制]] — 鉴权拦截器是安全机制在代码层的落地形式

hzh/MS/06-gRPC/05-错误处理.md

@@ -174,5 +174,5 @@ default:
 
 - [[04-拦截器]] — 拦截器根据错误码决定是否触发自动重试
 - [[07-最佳实践]] — 重试策略中与错误状态的配合配置
-- [[02-服务治理/容错模式]] — 熔断器在收到特定错误码后触发熔断
-- [[02-服务治理/分布式追踪]] — 错误链路在追踪系统中的标注方式
+- [[02-服务治理/06-容错模式]] — 熔断器在收到特定错误码后触发熔断
+- [[02-服务治理/03-分布式追踪]] — 错误链路在追踪系统中的标注方式

hzh/MS/06-gRPC/06-连接管理.md

@@ -151,5 +151,5 @@ Kubernetes 的 DNS 控制器会自动将 Service 的 Endpoints 更新到 DNS 记
 
 - [[01-协议与架构]] — Name Resolver 是架构图中连接管理层的第一环
 - [[07-最佳实践]] — Keepalive、负载均衡在生产环境的配合配置
-- [[02-服务治理/服务发现/README]] — 更深度的服务发现机制对比（Nacos / Consul / K8s）
-- [[02-服务治理/容错模式/README]] — 负载均衡 + 熔断的组合效果
+- [[02-服务治理/04-服务发现]] — 更深度的服务发现机制对比（Nacos / Consul / K8s）
+- [[02-服务治理/06-容错模式]] — 负载均衡 + 熔断的组合效果

hzh/MS/06-gRPC/07-最佳实践.md

@@ -216,5 +216,5 @@ resp, err := client.GetBigData(
 - [[04-拦截器]] — 重试策略可以通过 interceptor 实现更复杂的逻辑
 - [[05-错误处理]] — 重试策略根据错误状态码来决定是否重试
 - [[06-连接管理]] — Keepalive、负载均衡、Name Resolver 的详细配置
-- [[02-服务治理/安全机制]] — mTLS 与服务间身份认证的更深内容
-- [[02-服务治理/容错模式]] — 熔断器、限流器与重试策略的组合配置
+- [[02-服务治理/02-安全机制]] — mTLS 与服务间身份认证的更深内容
+- [[02-服务治理/06-容错模式]] — 熔断器、限流器与重试策略的组合配置

hzh/MS/06-gRPC/README.md

@@ -7,7 +7,7 @@ create time: 2026-05-07 16:30
 
 ## 概述
 
-本目录系统整理 **gRPC** 的核心知识点，从底层协议到生产实践，由浅入深覆盖 gRPC 的每一个关键领域。与 [[02-服务治理/服务间通信]] 中的入门对比不同，这里聚焦于「用了 gRPC 之后」—— 如何设计 Proto、如何编写拦截器、如何处理流式调用、连接怎么管、出错怎么查。
+本目录系统整理 **gRPC** 的核心知识点，从底层协议到生产实践，由浅入深覆盖 gRPC 的每一个关键领域。与 [[02-服务治理/05-服务间通信]] 中的入门对比不同，这里聚焦于「用了 gRPC 之后」—— 如何设计 Proto、如何编写拦截器、如何处理流式调用、连接怎么管、出错怎么查。
 
 ```mermaid
 graph LR
@@ -126,8 +126,8 @@ graph LR
 
 ## 关联笔记
 
-- [[02-服务治理/服务间通信]] — gRPC 与 REST 的基础对比及混合通信模式
-- [[02-服务治理/服务发现/README]] — Nacos / Consul / K8s Service 深度对比
-- [[02-服务治理/容错模式/README]] — 重试、熔断、限流、降级的完整治理
-- [[02-服务治理/分布式追踪/README]] — OpenTelemetry 链路追踪
-- [[02-服务治理/安全机制/README]] — mTLS、JWT、RBAC
+- [[02-服务治理/05-服务间通信]] — gRPC 与 REST 的基础对比及混合通信模式
+- [[02-服务治理/04-服务发现]] — Nacos / Consul / K8s Service 深度对比
+- [[02-服务治理/06-容错模式]] — 重试、熔断、限流、降级的完整治理
+- [[02-服务治理/03-分布式追踪]] — OpenTelemetry 链路追踪
+- [[02-服务治理/02-安全机制]] — mTLS、JWT、RBAC