feat: add infrastructure interview questions
Add comprehensive interview materials for: - Service Mesh (Istio, Linkerd) - RPC Framework (Dubbo, gRPC) - Container Orchestration (Kubernetes) - CI/CD (Jenkins, GitLab CI, GitHub Actions) - Observability (Monitoring, Logging, Tracing) Each file includes: - 5-10 core questions - Detailed standard answers - Code examples - Real-world project experience - Alibaba P7 bonus points Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
yasinshaw
605
questions/service-mesh.md
Normal file
605
questions/service-mesh.md
Normal file
@@ -0,0 +1,605 @@
|
||||
# 服务网格 (Service Mesh)
|
||||
|
||||
## 问题
|
||||
|
||||
**背景**：在微服务架构中，随着服务数量增加，服务间的通信管理变得复杂。服务网格作为基础设施层，负责处理服务间通信的流量管理、安全性和可观测性。
|
||||
|
||||
**问题**：
|
||||
1. 什么是服务网格？它解决了哪些问题？
|
||||
2. Istio 的核心组件有哪些？它们是如何协作的？
|
||||
3. Sidecar 模式的优缺点是什么？
|
||||
4. 请描述 Istio 的流量管理功能（灰度发布、蓝绿部署、熔断降级）
|
||||
5. Istio 如何实现 mTLS（双向 TLS）？
|
||||
6. 在生产环境中使用服务网格遇到过哪些坑？
|
||||
7. Linkerd 和 Istio 的区别是什么？如何选择？
|
||||
|
||||
---
|
||||
|
||||
## 标准答案
|
||||
|
||||
### 1. 服务网格概述
|
||||
|
||||
**定义**：
|
||||
服务网格是微服务架构中用于处理服务间通信的基础设施层，通常以轻量级网络代理的形式实现。
|
||||
|
||||
**核心功能**：
|
||||
- **流量管理**：路由规则、负载均衡、灰度发布
|
||||
- **安全性**：mTLS、JWT 验证、访问控制
|
||||
- **可观测性**：Metrics、Tracing、Logging
|
||||
|
||||
**解决的问题**：
|
||||
```
|
||||
传统微服务架构的痛点：
|
||||
├─ 服务间通信逻辑散落在每个服务中
|
||||
├─ 熔断、重试、超时等逻辑重复实现
|
||||
├─ 安全策略难以统一管理
|
||||
├─ 可观测性数据收集困难
|
||||
└─ 灰度发布、流量染色需要大量代码
|
||||
|
||||
服务网格的解决方案：
|
||||
├─ 将通信逻辑下沉到 Sidecar 代理
|
||||
├─ 控制平面统一配置管理
|
||||
├─ 数据平面透明代理流量
|
||||
├─ 自动收集可观测性数据
|
||||
└─ 声明式 API 管理流量
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Istio 核心组件
|
||||
|
||||
#### **架构图**：
|
||||
```
|
||||
┌─────────────────┐
|
||||
│ Control Plane │
|
||||
└─────────────────┘
|
||||
│
|
||||
┌─────────────────┼─────────────────┐
|
||||
│ │ │
|
||||
┌─────────┐ ┌──────────┐ ┌──────────┐
|
||||
│ Istiod │ │Pilot │ │Citadel │
|
||||
│ (统一) │ │(流量管理) │ │(证书管理)│
|
||||
└─────────┘ └──────────┘ └──────────┘
|
||||
│
|
||||
│ 配置下发
|
||||
│
|
||||
┌─────────────────────────────────────┐
|
||||
│ Data Plane │
|
||||
├─────────────────────────────────────┤
|
||||
│ │
|
||||
│ Service A Service B │
|
||||
│ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ Envoy │◄────►│ Envoy │ │
|
||||
│ │ Sidecar │ │ Sidecar │ │
|
||||
│ └─────────┘ └─────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
#### **核心组件详解**：
|
||||
|
||||
**1. Istiod（统一控制平面）**
|
||||
- **Pilot**：流量管理和配置下发
|
||||
- **Citadel**：证书管理和身份认证
|
||||
- **Galley**：配置验证和注入（Istio 1.13+ 已合并到 Istiod）
|
||||
|
||||
**代码示例 - Istiod 配置**：
|
||||
```yaml
|
||||
# istiod deployment
|
||||
apiVersion: v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: istiod
|
||||
namespace: istio-system
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: discovery
|
||||
image: gcr.io/istio-testing/pilot:1.19.0
|
||||
args:
|
||||
- "discovery"
|
||||
- "--monitoringAddr=:15014"
|
||||
- "--log_output_level=default:info"
|
||||
ports:
|
||||
- containerPort: 15012 # Pilot 服务的 xDS 端口
|
||||
name: grpc-xds
|
||||
```
|
||||
|
||||
**2. Envoy Sidecar（数据平面）**
|
||||
- 拦截所有进出流量
|
||||
- 执行流量规则（路由、负载均衡）
|
||||
- 收集 Metrics 和 Traces
|
||||
- 处理 mTLS 加解密
|
||||
|
||||
**Sidecar 注入示例**：
|
||||
```yaml
|
||||
# 自动注入 Sidecar
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-app
|
||||
annotations:
|
||||
sidecar.istio.io/inject: "true" # 启用自动注入
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
annotations:
|
||||
sidecar.istio.io/rewriteAppHTTPProbers: "true" # 重写 HTTP probes
|
||||
spec:
|
||||
containers:
|
||||
- name: app
|
||||
image: my-app:1.0.0
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Sidecar 模式
|
||||
|
||||
#### **优点**：
|
||||
1. **透明性**：业务代码无感知，无需修改
|
||||
2. **语言无关**：任何语言都能使用
|
||||
3. **统一管理**：集中配置，易于维护
|
||||
4. **渐进式采用**：可以逐步迁移
|
||||
|
||||
#### **缺点**：
|
||||
1. **资源开销**：每个服务都有 Sidecar，增加内存和 CPU
|
||||
```
|
||||
典型资源占用：
|
||||
- 内存：50-100MB per Sidecar
|
||||
- CPU：5-10% per core
|
||||
- 延迟增加：1-5ms
|
||||
```
|
||||
|
||||
2. **网络链路增加**：
|
||||
```
|
||||
请求路径（有 Sidecar）：
|
||||
Client → Sidecar A → Service A → Sidecar B → Service B
|
||||
|
||||
请求路径（无 Sidecar）：
|
||||
Client → Service A → Service B
|
||||
```
|
||||
|
||||
3. **调试复杂度**：多了一层网络代理
|
||||
|
||||
#### **优化方案**：
|
||||
```yaml
|
||||
# Sidecar 资源限制
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
containers:
|
||||
- name: istio-proxy
|
||||
resources:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
limits:
|
||||
cpu: 500m
|
||||
memory: 256Mi
|
||||
```
|
||||
|
||||
**Sidecar 资源配置模式**：
|
||||
```yaml
|
||||
# sidecar resources customization
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: istio-sidecar-injector
|
||||
data:
|
||||
values: |
|
||||
sidecarResources:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
limits:
|
||||
cpu: 500m
|
||||
memory: 256Mi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. 流量管理
|
||||
|
||||
#### **4.1 灰度发布 (Canary Deployment)**
|
||||
|
||||
**场景**：新版本 v2 发布给 10% 的流量
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
hosts:
|
||||
- reviews
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
x-canary:
|
||||
exact: "true" # 带特定 header 的流量走 v2
|
||||
route:
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v2
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v1
|
||||
weight: 90 # 90% 流量走 v1
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v2
|
||||
weight: 10 # 10% 流量走 v2
|
||||
---
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
host: reviews
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
```
|
||||
|
||||
#### **4.2 蓝绿部署 (Blue-Green Deployment)**
|
||||
|
||||
**场景**：一键切换全部流量到新版本
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
hosts:
|
||||
- my-app
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: my-app
|
||||
subset: blue # 所有流量指向 blue
|
||||
weight: 100
|
||||
# 切换到 green：修改 subset 为 green
|
||||
---
|
||||
# Kubernetes Deployment：同时存在 blue 和 green
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-app-blue
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
version: blue
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-app-green
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
version: green
|
||||
```
|
||||
|
||||
#### **4.3 熔断降级 (Circuit Breaker)**
|
||||
|
||||
**场景**：防止故障扩散
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: httpbin
|
||||
spec:
|
||||
host: httpbin
|
||||
trafficPolicy:
|
||||
connectionPool:
|
||||
tcp:
|
||||
maxConnections: 10 # 最大连接数
|
||||
http:
|
||||
http1MaxPendingRequests: 50 # 最大等待请求数
|
||||
http2MaxRequests: 100 # 最大并发请求数
|
||||
maxRequestsPerConnection: 2 # 每连接最大请求数
|
||||
maxRetries: 3 # 最大重试次数
|
||||
outlierDetection:
|
||||
consecutiveErrors: 5 # 连续 5 次错误
|
||||
interval: 30s # 每 30s 检查一次
|
||||
baseEjectionTime: 30s # 最小熔断时间
|
||||
maxEjectionPercent: 50 # 最多熔断 50% 的实例
|
||||
minHealthPercent: 40 # 最小健康实例比例
|
||||
```
|
||||
|
||||
**熔断状态图**：
|
||||
```
|
||||
Closed → Open → Half-Open → Closed
|
||||
↑ │ │
|
||||
└────────┴──────────┘
|
||||
```
|
||||
|
||||
#### **4.4 超时和重试**
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
hosts:
|
||||
- reviews
|
||||
http:
|
||||
- retry:
|
||||
attempts: 3 # 最多重试 3 次
|
||||
perTryTimeout: 2s # 每次重试超时 2s
|
||||
retryOn: 5xx,connect-failure,refused-stream # 重试条件
|
||||
timeout: 10s # 总超时时间
|
||||
route:
|
||||
- destination:
|
||||
host: reviews
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. mTLS (双向 TLS) 实现
|
||||
|
||||
#### **原理**：
|
||||
```
|
||||
Service A Service B
|
||||
│ │
|
||||
│ 1. 发送连接请求（无证书） │
|
||||
│ ─────────────────────────────────────►│
|
||||
│ │
|
||||
│ 2. 返回服务器证书 │
|
||||
│ ◄─────────────────────────────────────│
|
||||
│ │
|
||||
│ 3. 发送客户端证书 │
|
||||
│ ─────────────────────────────────────►│
|
||||
│ │
|
||||
│ 4. 验证通过，建立加密连接 │
|
||||
│ ◄────────────────────────────────────►│
|
||||
│ │
|
||||
│ 5. 加密通信 │
|
||||
│ ◄──────────────► │
|
||||
```
|
||||
|
||||
#### **配置示例**：
|
||||
|
||||
**全局启用 mTLS**：
|
||||
```yaml
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
name: default
|
||||
namespace: istio-system
|
||||
spec:
|
||||
mtls:
|
||||
mode: STRICT # 严格模式：必须使用 mTLS
|
||||
```
|
||||
|
||||
**按服务配置**：
|
||||
```yaml
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
name: my-app-mtls
|
||||
namespace: default
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: my-app
|
||||
mtls:
|
||||
mode: PERMISSIVE # 宽松模式：兼容 mTLS 和明文
|
||||
```
|
||||
|
||||
**服务授权**：
|
||||
```yaml
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: my-app-authz
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: my-app
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals: ["cluster.local/ns/default/sa/frontend"] # 只允许 frontend SA 访问
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET", "POST"]
|
||||
```
|
||||
|
||||
#### **证书管理流程**：
|
||||
```
|
||||
1. Citadel 工作负载证书
|
||||
↓
|
||||
2. 证书存储在 Secret 中
|
||||
↓
|
||||
3. Envoy Sidecar 启动时加载证书
|
||||
↓
|
||||
4. 定期轮换证书（默认 24 小时）
|
||||
↓
|
||||
5. 旧证书过期，使用新证书
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. 生产环境踩坑经验
|
||||
|
||||
#### **坑 1：Sidecar 资源占用过高**
|
||||
```yaml
|
||||
# 问题：100 个服务 × 100MB = 10GB 内存
|
||||
# 解决：按需启用 Sidecar
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-app
|
||||
annotations:
|
||||
sidecar.istio.io/inject: "false" # 禁用 Sidecar
|
||||
```
|
||||
|
||||
#### **坑 2：网络延迟增加**
|
||||
```
|
||||
问题：请求延迟从 5ms 增加到 10ms
|
||||
原因：
|
||||
- Sidecar 增加了一跳
|
||||
- mTLS 加解密开销
|
||||
|
||||
解决：
|
||||
1. 调整 Envoy 配置，减少日志级别
|
||||
2. 使用 PERMISSIVE 模式降级
|
||||
3. 增加超时时间配置
|
||||
```
|
||||
|
||||
#### **坑 3：配置下发延迟**
|
||||
```yaml
|
||||
# 问题：修改 VirtualService 后，流量未立即切换
|
||||
# 原因：Pilot 下发配置有延迟（默认 1s）
|
||||
|
||||
# 解决：减少配置刷新间隔
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: istio
|
||||
namespace: istio-system
|
||||
data:
|
||||
mesh: |-
|
||||
defaultConfig:
|
||||
proxyStatsMatcher:
|
||||
inclusionRegexps:
|
||||
- ".*" # 收集所有指标
|
||||
discoveryRefreshDelay: 1s # 配置刷新延迟
|
||||
```
|
||||
```
|
||||
|
||||
#### **坑 4：大规模性能问题**
|
||||
```
|
||||
问题：集群 1000+ 服务时，Istiod 性能瓶颈
|
||||
解决：
|
||||
1. 部署多个 Istiod 实例
|
||||
2. 使用 Namespace 隔离配置
|
||||
3. 启用配置压缩
|
||||
```
|
||||
|
||||
**多实例部署**：
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: istiod
|
||||
spec:
|
||||
replicas: 3 # 多副本
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Linkerd vs Istio
|
||||
|
||||
#### **对比表**：
|
||||
|
||||
| 特性 | Linkerd 2.x | Istio |
|
||||
|------|-------------|-------|
|
||||
| 代理 | Rust 实现（Linkerd2-proxy） | Envoy（C++） |
|
||||
| 性能 | 更低资源占用 | 资源占用较高 |
|
||||
| 功能 | 聚焦核心功能 | 功能更丰富 |
|
||||
| 集成 | Kubernetes 原生 | 支持多平台 |
|
||||
| 学习曲线 | 简单 | 复杂 |
|
||||
| 社区 | CNCF 毕业项目 | CNCF 孵化中 |
|
||||
| 多集群支持 | 弱 | 强 |
|
||||
| 流量管理 | 基础 | 高级（灰度、蓝绿等） |
|
||||
|
||||
#### **选择建议**：
|
||||
|
||||
**选择 Linkerd**：
|
||||
- Kubernetes 原生环境
|
||||
- 重视性能和资源占用
|
||||
- 需要简单易用的解决方案
|
||||
- 功能要求不高
|
||||
|
||||
**选择 Istio**：
|
||||
- 需要高级流量管理
|
||||
- 多集群/多云环境
|
||||
- 需要细粒度的安全控制
|
||||
- 团队有运维能力
|
||||
|
||||
---
|
||||
|
||||
### 8. 实际项目经验
|
||||
|
||||
#### **场景 1：电商系统灰度发布**
|
||||
```
|
||||
需求：新支付系统先给 5% 用户试用
|
||||
方案：
|
||||
1. 部署 payment-v2
|
||||
2. 配置 VirtualService，5% 流量走 v2
|
||||
3. 监控错误率和延迟
|
||||
4. 逐步增加流量比例：5% → 20% → 50% → 100%
|
||||
5. 出现问题立即回滚
|
||||
```
|
||||
|
||||
#### **场景 2：金融系统 mTLS 合规**
|
||||
```
|
||||
需求：所有服务间通信必须加密
|
||||
方案：
|
||||
1. 启用 STRICT mTLS 模式
|
||||
2. 配置 AuthorizationPolicy，只允许合法的 SA 访问
|
||||
3. 定期轮换证书（24 小时）
|
||||
4. 审计日志记录所有通信
|
||||
```
|
||||
|
||||
#### **场景 3：多集群容灾**
|
||||
```
|
||||
需求：主集群故障时自动切换到备用集群
|
||||
方案：
|
||||
1. 使用 Multi-Cluster Mesh
|
||||
2. 配置 ServiceEntry，指向备用集群
|
||||
3. 配置 DestinationRule，故障时自动切换
|
||||
4. 跨集群流量加密
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 9. 阿里 P7 加分项
|
||||
|
||||
**架构设计能力**：
|
||||
- 设计过大规模服务网格架构（500+ 服务）
|
||||
- 有多集群/多云服务网格实施经验
|
||||
- 实现过自定义 Control Plane（如基于 Istio API）
|
||||
|
||||
**深度理解**：
|
||||
- 理解 Envoy 内部机制（过滤器链、连接池、HTTP/2）
|
||||
- 熟悉 xDS 协议（CDS, EDS, LDS, RDS）
|
||||
- 有性能调优经验（减少延迟、优化资源占用）
|
||||
|
||||
**实际项目**：
|
||||
- 主导过从传统架构迁移到服务网格
|
||||
- 解决过生产环境的疑难问题（如网络分区、证书轮换故障）
|
||||
- 开发过自定义 WASM 插件扩展 Envoy 功能
|
||||
|
||||
**开源贡献**：
|
||||
- 向 Istio/Envoy 社区提交过 PR
|
||||
- 解决过社区 Issue
|
||||
- 编写过相关技术博客或演讲
|
||||
|
||||
**监控和可观测性**：
|
||||
- 设计过服务网格监控体系
|
||||
- 使用 Prometheus/Grafana 监控 Sidecar 性能
|
||||
- 实现过分布式追踪集成（Jaeger/Zipkin）
|
||||
|
||||
**安全实践**：
|
||||
- 实现过零信任网络架构
|
||||
- 有安全审计和合规经验
|
||||
- 设计过细粒度的 RBAC 策略
|
||||
Reference in New Issue
Block a user