综合练习

把本 track 串起来：为假想（或未来）拆分的 Spring Cloud 微服务设计 Istio 网格拓扑，涵盖入口、金丝雀、mTLS、超时熔断与可观测。不要求真集群上线，但 diagram 与 YAML 片段须 自洽、可核对。

学习目标

• 独立完成一张「北向 + 东西向」服务网格架构图
• 写出至少 VirtualService、DestinationRule、PeerAuthentication 各一段
• 交叉引用 spring-cloud-essentials、kubernetes-essentials、reliability-essentials、observability-essentials

场景：CodeRoadMap 微服务化

假设 backend 拆为：

服务	职责
user-service	用户、认证
course-service	课程、课时
progress-service	学习进度

部署在 K8s 命名空间 coderoadmap，入口经 Istio Ingress Gateway（前层可有 Nginx）。

任务清单

1. 架构图（必做）

绘制包含：

• Internet → Nginx / LB → Istio Gateway
• 三个 Deployment + Sidecar
• 服务间 mTLS 箭头
• Prometheus / Kiali（可选）抓 metrics

标注与 mesh-gateway 一致的 北向 vs 东西向。

2. 金丝雀发布（必做）

course-service v1 / v2：

• DestinationRule 定义 subset v1、v2
• VirtualService：90/10 权重，timeout 3s
• 说明回滚条件（错误率、P99，链 rel-slo）

3. 弹性与安全（必做）

• DestinationRule：outlierDetection + connectionPool（见 mesh-resilience）
• PeerAuthentication：STRICT mTLS
• 写一句：Feign fallback 与网格 timeout 如何配合（mesh-graceful）

4. 可观测（选做）

• 列出 3 个 Prometheus 查询或 Grafana 面板标题
• 金丝雀期间对比 v1/v2 的 trace 采样策略（obs-traces）

必走自检

• VirtualService host 与 K8s Service 名一致
• subset label 与 Deployment version label 一致
• 重试 未 在 Feign 与 VirtualService 双重放大（rel-retries）
• gRPC 服务若存在，deadline 与网格 timeout 对齐（grpc-error）
• 能向同事解释：哪些能力从 sc-gateway 迁到网格、哪些保留

交付物建议

docs/mesh-practice/
  topology.md      # 架构图（Mermaid 或 ASCII）
  istio/           # YAML 片段
  checklist.md     # 发布与回滚步骤

反思题

1. 若仅 3 个服务、单语言 Java，上网格的 ROI 是什么？
2. Sidecar 额外内存对你的节点规格影响多大？
3. 第一版你会开启 STRICT mTLS 还是 PERMISSIVE？为什么？

小结

拓扑清晰、策略分层、指标验收——网格落地的最小闭环。 本 track 完结；继续深入可结合 kubernetes-essentials 实验集群与 observability-essentials 搭 Prometheus/Grafana。