从运维视角看wechat服务器在新加坡 的监控与容灾设计

1.

总体架构与设计目标

- 目标：保证WeChat服务在新加坡区域可用性>=99.95%，RTO<5分钟，RPO<15分钟。
- 架构原则：监控可观测、故障可恢复、切换可测试、最小化单点。
- 建议部署：至少2个可用区（AZ）内多活服务实例 + 跨区备份（同城冷备或异地备）。

2.

基础设施清单与准备

- 清单：应用服务节点（容器/K8s）、数据库主从（MySQL/MariaDB）、缓存（Redis）、消息队列（Kafka/RabbitMQ）、负载均衡（NGINX/HAProxy）、监控（Prometheus/Grafana）、日志（ELK/EFK）、备份存储（S3兼容）。
- 准备步骤：在新加坡机房或云账户开设VPC、子网、路由表，配置安全组和NACL，规划监控子网与备份子网。

3.

指标监控（Prometheus + node_exporter）

- 步骤1：在每台服务节点安装 node_exporter（系统指标），命令示例：systemctl enable --now node_exporter。
- 步骤2：部署Prometheus服务器（HA模式2实例），配置scrape_configs指向服务/容器/数据库端点；示例targets：/metrics端点或mysql_exporter、redis_exporter。
- 步骤3：为关键指标设置采集频率（默认15s或30s），并保存prometheus.yml版本化在Git。

4.

白盒/黑盒探活与SLA监测

- 黑盒探测：部署blackbox_exporter并配置TCP/HTTP探测用来检测wechat API、登录、消息接口；示例probe：http_2xx，POST登录流程采用合成交易脚本。
- 白盒探测：在应用内埋点（/healthz），返回依赖状态（DB、Redis、MQ、外部接口），Prometheus抓取并做ServiceLevel判断。

5.

日志与链路追踪（EFK + Jaeger/Tempo）

- 步骤1：部署Filebeat/Fluentd收集应用日志，发送到Elasticsearch或OpenSearch。
- 步骤2：按照请求ID（trace_id）在微服务中传递链路，部署Jaeger/Tempo用于分布式追踪，关联日志与指标。
- 步骤3：在Grafana中建立日志+trace变量联动，便于定位慢请求与错误率上升原因。

6.

告警策略与Alertmanager 配置

- 告警分级：P0（业务中断），P1（降级），P2（容量/性能），P3（信息）。
- Alertmanager：配置接收器（短信/电话/Slack/钉钉/邮件），通过routing分流不同等级到不同组；配置抑制规则避免告警风暴。
- 实操：alert.rules.yml示例：expr: sum(rate(http_requests_total[1m])) by (job) > 1000，annotations包含恢复步骤及runbook链接。

7.

数据库容灾设计（MySQL 多副本与备份）

- 同城高可用：master–>至少两个异步/半同步replica，使用MGR或MHA做主备切换自动化。
- 备份：使用mysqldump或xtrabackup做全量与增量备份，备份文件上传对象存储（S3）并保留策略（14天热、90天冷）。
- 恢复演练：定期在独立环境用备份做恢复演练并记录RTO/RPO。

8.

缓存与消息队列容灾

- Redis：使用主从+哨兵或Redis Cluster，配置自动故障切换并在Prometheus采集redis_exporter的role/lag指标。
- Kafka：部署多节点Broker，开启replication.factor>=3，配置preferred.leader选举和监控ISR滞后；发生产线配置幂等/重试策略。

9.

流量调度与DNS/GSLB 切换策略

- DNS：使用GSLB（如NS1/Alibaba GSLB/Cloudflare）配置低TTL（60s）并根据健康检查做流量调度。
- 演练切换：步骤—关闭主站健康探测->确认监控触发->GSLB将流量迁移->验证新流量通过。记录DNS切换时间并验证会话恢复策略（如sticky session）。

10.

故障处理运行手册（Runbook）

- 模板：故障类型、影响范围、确认命令、临时缓解、根因分析、恢复命令、回归验证。
- 示例命令：检查Prometheus规则 promtool check rules alert.rules.yml；重启服务 systemctl restart wechat-app；查看pod kubectl get pods -n wechat。每条runbook附带责任人和回滚点。

11.

自动化恢复与脚本

- 自动化脚本：基于Ansible/Terraform编写一键重建脚本（如重建应用容器、清空队列后重放）。
- 设计注意：所有自动化操作先在测试环境dry-run，执行前通过CI/CD审批并在监控面板观察变更影响。

12.

演练计划与验证（演习步骤）

- 周期：每季度一次完整切换演练，每月一次小范围灾备验证。
- 步骤实例：1) 预案发布；2) 在非高峰时段模拟主DB故障；3) 执行主备切换脚本；4) 验证应用请求成功率；5) 记录时间与问题并总结改进项。

13.

安全与合规注意事项

- 加密：备份数据传输与静态加密（SSE-KMS），数据库连接使用TLS。
- 访问控制：监控与运维账号实施最小权限，关键操作使用审批与二次确认（MFA）。

14.

监控与容灾日常运维清单

- 每日：检查Prometheus采集状态、告警队列、关键服务健康。
- 每周：备份检查与恢复验证、日志索引健康、磁盘使用报警阈值调整。
- 每月：演练、容量评估、权限审计。

15.

问：在新加坡机房发生单AZ全失能时，我应首先做什么？

答：首先触发应急响应等级（P0），打开Runbook执行“单AZ失能”流程：1) 确认监控（Prometheus）与NOC告警；2) 切换GSLB到可用AZ（低TTL）；3) 在目标AZ开启备用数据库读写主服务（或进行Promote操作）；4) 验证应用端点、登录、消息通路；5) 通知业务并进入回收阶段。

16.

问：如何快速验证MySQL切换后的数据一致性？

答：执行以下步骤：1) 校验最新binlog位置与备份时间戳；2) 使用pt-table-checksum或自定义校验脚本比对关键表行数/哈希；3) 检查应用层错误日志与trace中是否有重复/丢失消息；4) 若发现差异，使用binlog或备份回滚/补数据并记录恢复操作。

17.

问：如何在不影响线上业务的前提下做容灾演练？

答：采用“旁路演练+流量镜像”策略：1) 在非高峰时段创建与生产一致的隔离环境并导入近实时数据快照；2) 使用流量镜像（mirror）将少量非关键请求引导至演练集群验证；3) 对DNS/GSLB做灰度切换（小比例流量），观察监控指标；4) 所有操作在变更窗口并有回滚预案，必要时人工停止演练并恢复。

来源：从运维视角看wechat服务器在新加坡 的监控与容灾设计