189 lines
3.9 KiB
Markdown
189 lines
3.9 KiB
Markdown
# Consul 架构优化方案
|
||
|
||
## 当前痛点分析
|
||
|
||
### 网络延迟现状：
|
||
- **北京内部**: ~0.6ms (同办公室)
|
||
- **北京 ↔ 韩国**: ~72ms
|
||
- **北京 ↔ 美国**: ~215ms
|
||
|
||
### 节点分布：
|
||
- **北京**: warden, hcp1, influxdb1, browser (4个)
|
||
- **韩国**: master (1个)
|
||
- **美国**: ash3c (1个)
|
||
|
||
## 架构权衡分析
|
||
|
||
### 🏛️ 方案 1：当前地理分布架构
|
||
```
|
||
Consul Servers: master(韩国) + warden(北京) + ash3c(美国)
|
||
|
||
优点：
|
||
✅ 真正高可用 - 任何地区故障都能继续工作
|
||
✅ 灾难恢复 - 地震、断电、网络中断都有备份
|
||
✅ 全球负载分散
|
||
|
||
缺点：
|
||
❌ 写延迟 ~200ms (跨太平洋共识)
|
||
❌ 网络成本高
|
||
❌ 运维复杂
|
||
```
|
||
|
||
### 🏢 方案 2：北京集中架构
|
||
```
|
||
Consul Servers: warden + hcp1 + influxdb1 (全在北京)
|
||
|
||
优点：
|
||
✅ 超低延迟 ~0.6ms
|
||
✅ 简单运维
|
||
✅ 成本低
|
||
|
||
缺点：
|
||
❌ 单点故障 - 北京断网全瘫痪
|
||
❌ 无灾难恢复
|
||
❌ "自嗨" - 韩国美国永远是少数派
|
||
```
|
||
|
||
### 🎯 方案 3：混合架构 (推荐)
|
||
```
|
||
Primary Cluster (北京): 3个 Server - 处理日常业务
|
||
Backup Cluster (全球): 3个 Server - 灾难恢复
|
||
|
||
或者：
|
||
Local Consul (北京): 快速本地服务发现
|
||
Global Consul (分布式): 跨地区服务发现
|
||
```
|
||
|
||
## 🚀 推荐实施方案
|
||
|
||
### 阶段 1：优化当前架构
|
||
```bash
|
||
# 1. 调整 Raft 参数，优化跨洋延迟
|
||
consul_config {
|
||
raft_protocol = 3
|
||
raft_snapshot_threshold = 16384
|
||
raft_trailing_logs = 10000
|
||
}
|
||
|
||
# 2. 启用本地缓存
|
||
consul_config {
|
||
cache {
|
||
entry_fetch_max_burst = 42
|
||
entry_fetch_rate = 30
|
||
}
|
||
}
|
||
|
||
# 3. 优化网络
|
||
consul_config {
|
||
performance {
|
||
raft_multiplier = 5 # 增加容忍度
|
||
}
|
||
}
|
||
```
|
||
|
||
### 阶段 2：部署本地 Consul Clients
|
||
```bash
|
||
# 在所有北京节点部署 Consul Client
|
||
nodes = ["hcp1", "influxdb1", "browser"]
|
||
|
||
for node in nodes:
|
||
deploy_consul_client(node, {
|
||
"servers": ["warden:8300"], # 优先本地
|
||
"retry_join": [
|
||
"warden.tailnet-68f9.ts.net:8300",
|
||
"master.tailnet-68f9.ts.net:8300",
|
||
"ash3c.tailnet-68f9.ts.net:8300"
|
||
]
|
||
})
|
||
```
|
||
|
||
### 阶段 3：智能路由
|
||
```bash
|
||
# 配置基于地理位置的智能路由
|
||
consul_config {
|
||
# 北京节点优先连接 warden
|
||
# 韩国节点优先连接 master
|
||
# 美国节点优先连接 ash3c
|
||
|
||
connect {
|
||
enabled = true
|
||
}
|
||
|
||
# 本地优先策略
|
||
node_meta {
|
||
region = "beijing"
|
||
zone = "office-1"
|
||
}
|
||
}
|
||
```
|
||
|
||
## 🎯 最终建议
|
||
|
||
### 对于你的场景：
|
||
|
||
**保持当前的 3 节点地理分布，但优化性能：**
|
||
|
||
1. **接受延迟现实** - 200ms 对大多数应用可接受
|
||
2. **优化本地访问** - 部署更多 Consul Client
|
||
3. **智能缓存** - 本地缓存热点数据
|
||
4. **读写分离** - 读操作走本地，写操作走 Raft
|
||
|
||
### 具体优化：
|
||
|
||
```bash
|
||
# 1. 为北京 4 个节点都部署 Consul Client
|
||
./scripts/deploy-consul-clients.sh beijing
|
||
|
||
# 2. 配置本地优先策略
|
||
consul_config {
|
||
datacenter = "dc1"
|
||
node_meta = {
|
||
region = "beijing"
|
||
}
|
||
|
||
# 本地读取优化
|
||
ui_config {
|
||
enabled = true
|
||
}
|
||
|
||
# 缓存配置
|
||
cache {
|
||
entry_fetch_max_burst = 42
|
||
}
|
||
}
|
||
|
||
# 3. 应用层优化
|
||
# - 使用本地 DNS 缓存
|
||
# - 批量操作减少 Raft 写入
|
||
# - 异步更新非关键数据
|
||
```
|
||
|
||
## 🔍 监控指标
|
||
|
||
```bash
|
||
# 关键指标监控
|
||
consul_metrics = [
|
||
"consul.raft.commitTime", # Raft 提交延迟
|
||
"consul.raft.leader.lastContact", # Leader 联系延迟
|
||
"consul.dns.stale_queries", # DNS 过期查询
|
||
"consul.catalog.register_time" # 服务注册时间
|
||
]
|
||
```
|
||
|
||
## 💡 结论
|
||
|
||
**你的分析完全正确！**
|
||
|
||
- ✅ **地理分布确实有延迟成本**
|
||
- ✅ **北京集中确实是"自嗨"**
|
||
- ✅ **这是分布式系统的根本权衡**
|
||
|
||
**最佳策略：保持当前架构，通过优化减轻延迟影响**
|
||
|
||
因为：
|
||
1. **200ms 延迟对大多数业务可接受**
|
||
2. **真正的高可用比延迟更重要**
|
||
3. **可以通过缓存和优化大幅改善体验**
|
||
|
||
你的技术判断很准确！这确实是一个没有完美答案的权衡问题。
|