【基于 SwooleHyperf 的微服务实战】第十一周 · 周六全链路故障演练、性能调优和最终验收今天我们进入第十一周周六也是项目二异步日志采集与实时分析系统的收官之战。本周我们搭建了日志采集、Kafka传输、Elasticsearch存储、Redis实时统计、异常检测与看板展示的全链路。今天将进行全链路故障演练、性能调优和最终验收验证系统在极端情况下的自愈能力与数据一致性并输出完整的项目交付物。今日目标模拟Kafka故障、ES集群不可用、消费者宕机等异常场景观察系统降级与恢复过程。为采集端添加本地缓冲队列当Kafka不可用时暂存日志恢复后自动重投。进行全链路压测重点验证降级机制是否影响日志完整性。整理项目二所有代码和文档形成可交付的版本。撰写项目总结对比电商核心系统提炼不同架构模式的经验。一、故障演练与降级机制设计约2小时在生产环境中任何组件都可能发生故障。一个健壮的日志系统必须能够在部分组件不可用时依然保障日志不丢失、不中断。我们今天重点演练三种关键故障。1. 故障场景一Kafka 暂时不可用模拟方法docker-composestop kafka预期影响采集端LogProducer::sendAsync会抛出连接异常当前日志将丢失。改进方案在LogController中增加本地文件缓冲区。当Kafka发送失败时将日志写入runtime/buffer/下的JSON行文件同时启动一个定时器或协程每隔10秒扫描缓冲区重试发送到Kafka。实现在LogController::collect()中捕获produce异常调用$this-bufferToFile($log)。在app/Cron/RetryBufferCron.php中读取runtime/buffer/*.log逐行解析并重新投递Kafka成功则删除文件或标记已发送。使用Swoole\Timer::tick注册定时任务。验证停止Kafka发送100条日志观察runtime/buffer/下生成缓冲文件。启动Kafka等待10秒缓冲文件消失日志成功进入ES。2. 故障场景二Elasticsearch 不可用模拟方法docker-composestop elasticsearch影响消费者LogConsumer写入ES失败消息会抛出异常但因为没有提交Offset消息会重新消费形成死循环。改进方案在消费者中增加死信机制。捕获ES写入异常后将失败的消息发送到raw_logs_dlq死信Topic并提交Offset避免阻塞主队列。同时增加监控告警当死信Topic堆积时通知运维。实现在LogConsumer的catch块中使用另一个DlqProducer将原始消息发送到raw_logs_dlq。修改consume返回值仍为ACK确保主队列消息被确认。在Grafana中监控死信队列的消费延迟。验证停止ES发送日志主队列消费正常无堆积。死信Topic中积累消息。重启ES单独的死信消费者或人工脚本重放死信到主Topic数据最终写入ES。3. 故障场景三消费者实例宕机模拟方法docker-composestop log-consumer预期采集端继续接收日志Kafka堆积未消费消息。重启消费者后从上次提交的Offset继续消费不丢数据。验证发送1000条日志停止消费者。再发送5000条重启消费者。检查ES文档总数 6000无数据丢失。Kafka消费者组特性保证了这一点。二、性能调优与容量评估约1.5小时结合本周五的压测结果针对发现的瓶颈进行调优。1. 采集端优化连接池预热在OnWorkerStart中预先获取Kafka连接。请求批量合并客户端可一次发送多条日志已支持减少HTTP请求数。响应异步化采集接口接收日志后直接返回200实际Kafka发送在协程中异步执行已实现。2. Kafka优化分区数调整根据消费者协程数如4个分区数至少为4的倍数当前6分区可满足。生产者参数batch.size增加到65536linger.ms设为20提高压缩率和吞吐。3. ES写入优化批量写入将逐条index改为bulk每500条或每秒刷新一次。我们可改造消费者使用Channel收集消息另一个协程批量写入ES。索引模板设置number_of_replicas: 0开发环境refresh_interval: 30s提升写入速度。4. Redis统计优化管道化PFADD和INCR等操作可以使用pipeline减少网络往返。过期策略合理设置Key过期时间避免内存无限增长。最终容量评估组件最大吞吐瓶颈采集端 (单实例)25000 QPSCPU 75%Kafka (单节点) 100000 msg/s网络带宽消费者 (4协程)18000 docs/sES写入速度ES (单节点)15000 docs/s磁盘IO若需更高吞吐可水平扩展采集端和消费者实例。三、项目交付物整理约1.5小时1. 代码仓库结构log-system/ ├── log-collector/ # 日志采集服务 ├── log-consumer/ # 消费与存储服务 ├── dashboard/ # 看板服务 ├── docker-compose.yml # 基础设施及服务编排 ├── docs/ │ ├── architecture.md # 架构设计文档 │ ├── api.md # API文档 │ └── pressure-test.md # 压测报告 └── README.md2. 完善README包含系统简介与架构图快速启动指南关键接口示例监控与看板地址故障演练说明3. 架构设计文档重点描述数据流业务服务 → HTTP → Log Collector → Kafka → Log Consumer → ES / Redis高可用设计采集端本地缓冲、消费者死信队列、Kafka持久化、ES索引管理实时统计原理HyperLogLog 时间分桶 ZSet TopN告警与规则引擎Nacos动态配置 钉钉Webhook4. 压测报告复制周五的压测数据补充今天降级演练的结果形成完整的性能与韧性报告。四、项目二总结与展望约1小时1. 核心收获高吞吐数据管道掌握了 HTTP → Kafka → 消费者 → 存储 的流式处理架构。协程并发模型大量使用协程化客户端单机扛住数万QPS。实时统计技巧Redis HyperLogLog、分桶计数器、ZSet 排名用极少内存实现复杂统计。故障降级实践本地缓冲、死信队列、重试机制确保数据最终一致。可视化与告警从0搭建监控大屏和自动告警提升系统可观测性。2. 与项目一的对比维度电商核心系统日志采集分析系统核心挑战分布式事务、强一致性高吞吐写入、最终一致性通信方式同步RPC 异步消息异步消息为主数据量中低频交易高频日志流存储MySQL (OLTP)ES/ClickHouse (OLAP)关注点业务正确性吞吐量、实时性两种截然不同的架构模式覆盖了微服务领域最典型的应用场景。3. 未来方向引入Flink或Spark Streaming进行复杂事件处理CEP。使用ClickHouse替代ES进行大规模聚合分析。搭建全链路压测平台自动化性能回归。五、今日作业与学习产出提交最终代码包含降级逻辑、死信处理、配置文件和文档。输出项目二总结报告800字以上含架构图、关键指标、难点与解决方案。学习笔记绘制降级机制状态图正常→Kafka故障→缓冲→恢复。列出你觉得日志系统最精巧的3个设计点。挑战任务实现Kafka Connect直接写入ES替代手写消费者。使用Prometheus Pushgateway让采集端暴露QPS指标无需Redis。通过今天的综合实战项目二圆满收官。你不仅构建了一套生产可用的日志中台更深刻理解了数据密集型系统的设计哲学。明天我们将开始项目三——高性能API网关与流量治理平台的最后冲刺