2024年10月我参与了“故障功守道”项目的设计开发，该项目主要目标是实现机器监控为主、人工干预为辅的功能，项目中我担任系统架构设计师岗位，主要负责系统的架构设计工作。本文以该项目为例，论述了分布式架构的设计及其实现。该项目采用分布式架构，结合微服务架构、消息中间件（RocketMQ）、分布式容器化编排（k8s）和分布式缓存（Redis）等关键分布式技术。通过模块化的服务拆分、异步通信机制和自动化弹性伸缩，系统成功解决了在超强台风等极端天气下的告警洪峰处理问题，确保了业务连续性，验证了分布式架构在互联网大厂级应用中的卓越性能和价值。历经8个月的努力，项目最终成功上线，经受住超强台风的考验，获得客户肯定。
2024年10月，我参与了某公司启动的“故障功守道”平台的建设。该平台旨在实现对机器故障的实时监控与自动化处理，核心功能包括告警管理、告警标准化、告警预处理、工单预处理和性能统计等。该系统对高可用性和实时性有极高要求，特别是在面临如台风天气导致的瞬时告警量激增时，需保证系统不中断、不降级。在该项目中，我担任了系统架构设计师的职务，负责确定技术选型和整体架构模式，为了满足系统高可用、高并发和快速迭代的需求，最终确定采用分布式架构。根据业务流程和功能边界，主持了系统到独立微服务的拆分工作。负责分布式关键技术组件的选型（如消息中间件RocketMQ、缓存Redis、数据库NoSQL/MySQL）及核心业务模块（如告警预处理逻辑）的架构落地。设计了基于k8s的容器化部署和弹性伸缩方案，以确保系统在极端负载下的性能和稳定性。
分布式架构的设计和实现离不开一系列关键的分布式技术。这些技术共同作用，将原本集中式的职能分散到不同的节点上，从而实现系统的扩展性和容错性。以下是四种在“故障功守道”平台中应用的常见分布式技术：（1）微服务架构，微服务架构是一种将单一应用程序开发为一组小型服务的架构风格，每个服务运行在独立的进程中，服务间采用轻量级通信机制（如HTTP/gRPC）进行协作。每个服务围绕业务能力构建，可独立部署、独立扩展。（2）消息中间件，消息中间件是一种支持异步通信的分布式组件。它充当服务间的缓冲区，发送方将消息发送至队列，接收方从队列中获取并处理消息。它提供了服务的解耦能力、流量削峰能力以及最终一致性保证。（3）分布式容器化编排是将应用及其所有依赖打包成一个轻量级、可移植的独立运行单元。k8s则负责自动化部署、扩展和管理这些容器化应用。K8s通过自我修复、滚动更新、负载均衡和弹性伸缩机制，提供了强大的高可用性保障。
在“故障功守道”平台的设计与实现中，团队正是以高可用、高并发和快速迭代为目标，充分运用上述分布式技术，构建了一套弹性和可伸缩的系统。
采用微服务架构垂直拆分核心系统解决系统高可用及技术栈灵活选型
基于系统高可用的需求及考虑到可以灵活选择技术栈，团队将平台按照业务能力进行垂直拆分。团队将核心系统拆分为：告警管理服务， 负责告警接收、存储和查询；告警预处理服务，负责告警的清洗、标准化、去重和抑制；工单服务，负责将符合条件的告警转化为运维工单；性能统计服务， 负责数据的聚合分析和报表生成。这种拆分确保了每个服务都聚焦于单一的业务职能，并允许告警管理服务采用关系型数据库（MySQL）存储结构化告警信息，而性能统计服务则可采用时序数据库或NoSQL数据库（如MongoDB）存储性能数据，实现存储层的分布式优化。
通过消息中间件解决服务间耦合紧、突发高并发过载
为了实现服务间的松耦合，并应对突发的高并发流量，团队引入了消息中间件。团队选择 RocketMQ 作为核心通信组件。所有进入系统的原始告警数据，首先由告警管理服务发布至“原始告警”Topic。告警预处理服务APS服务作为消费者，异步拉取消息并进行处理。在超强台风来临时，即使告警量瞬间陡增至平时的数倍，RocketMQ也能将瞬间的高峰流量平滑地缓冲至队列中，防止告警预处理服务因过载而崩溃，从而实现了 “削峰填谷” 的效果。对机器监控中常见的“闪断”告警（瞬时产生又瞬间恢复），团队利用RocketMQ的延时队列功能。告警预处理服务不会立即处理所有告警，而是将告警发送到一个延时队列中。如果告警在预设的延时时间（例如3分钟）内没有被消除，才会被取出进行后续的工单生成和通知流程，这大大降低了无效处理量。
利用分布式容器化编排和K8s实现自动化运维和高可用目标
利用分布式容器化编排和K8s的编排能力，实现系统的自动化运维和高可用目标。所有微服务均构建为 Docker容器镜像，并部署在k8s集群上。监控CPU利用率和消息队列的消费堆积情况。在台风等极端场景下，当告警预处理服务的CPU利用率达到80%的阈值时，K8s会自动启动新的告警预处理服务实例进行扩容，及时分担计算压力，保证告警处理的实时性。当流量恢复正常，实例也会自动缩容，节省资源。如果某个告警预处理服务实例因内存溢出或程序错误而宕机，K8s会自动检测并重启或迁移该Pod到健康的节点，整个过程对上层业务无感知，有力保障了系统的99.99%高可用性。
分布式数据库解决实时告警高速写入、性能数据灵活存储及故障深度分析
为了应对实时告警的高速写入、复杂性能数据的灵活存储和深层次的故障关系分析，团队在数据持久化层和访问层采用了混合 NoSQL 解决方案。团队使用了 Redis集群、MongoDB集群和Neo4j三种分布式数据技术，各司其职：Redis集群用于存储告警预处理所需的规则配置、标准化定义等高频读取且变化不多的元数据，同时用于缓存热点告警数据和Session信息，通过将数据查询耗时从毫秒级降低到亚毫秒级，大幅减少了对后端数据库的并发压力，提升了系统的响应速度。MongoDB集群由性能统计服务采用，用于存储海量的性能指标数据、历史告警快照和非结构化的告警日志，MongoDB的文档模型具有极大的灵活性，能够适应不同类型机器和监控系统的动态数据结构，方便团队快速迭代数据格式，满足性能统计的复杂查询和聚合分析需求。其分布式特性保证了数据存储的横向扩展能力。Neo4j由告警预处理服务使用，用于构建和存储服务依赖关系图。Neo4j的图模型能够高效地存储“服务器-应用-业务”之间的复杂关联关系，并通过图查询实现分钟级的 根因分析，极大地提高了故障定位的效率和准确性。
总之，“故障功守道”项目历经八个月的努力，成功构建了一个以分布式架构为基础的信息系统，“故障功守道”平台成功实现了系统的高可用、高并发和快速迭代目标。在实际运行中，系统经受住了超强台风等突发高负载场景的严峻考验，通过K8s的自动扩容和RocketMQ的削峰缓冲，保障了核心业务的持续运行和实时处理，获得了客户的高度认可。虽然项目取得了成功，但在分布式架构的实现过程中，仍存在一些可改进之处：目前系统主要通过MQ实现最终一致性，但在涉及跨服务严格数据一致性的业务场景中，分布式事务的管理仍较为复杂和缺乏统一的解决方案。针对分布式事务问题，计划在后续版本中引入分布式事务模式。