微服务架构图如何分清流量、治理、中间件和存储

万兴图示EdrawMAX

发布时间：2026年08月20日

分享文章：

这份微服务架构图采用自上而下的全栈分层：终端请求先经过代理与网关，再进入注册中心和服务集群，随后使用消息、缓存、数据库、搜索与分析能力，底部补充容器和持续集成工具。

读取微服务平台的纵向分层

最上方终端设备覆盖手机、平板、笔记本和桌面电脑，说明系统面向多种客户端。下一层代理以LVS和Nginx集群承担流量入口，再向下进入 Gateway 与 TSF 网关集群，形成从四层或七层接入到业务路由的示意。

网关区域列出请求过滤、转发、用户鉴权、服务熔断、动态路由和接口限流。正式图应把这些能力映射到具体网关或安全组件，并标明哪些在边缘代理执行、哪些在应用网关执行，避免职责重复。

可先用架构图制作工具建立终端、接入、网关、治理、服务、中间件、存储和交付支撑八个区域。每层只保留一种主要语义，旁侧能力通过关联线连接，不要把所有图标都塞进主调用链。

• 流量入口：LVS、Nginx与网关集群。
• 治理能力：鉴权、限流、路由、熔断与注册发现。
• 业务运行：服务集群、配置中心和第三方服务。
• 基础能力：消息、缓存、数据库、搜索、分析与容器交付。

梳理网关、注册和服务治理

注册中心区域通过 Consul 多节点互相注册和心跳检测，向下连接业务服务集群与配置中心。图中服务之间以微服务名相互发现，说明调用方不应依赖固定实例地址，而是通过注册信息找到可用节点。

服务中心包含多个 TSF 集群和 DEV、QA、ONLINE 等配置环境。实际项目要明确环境是否物理隔离、配置如何发布、服务实例如何扩缩，以及注册、配置和密钥是否由同一平台承担。

旁侧第三方服务包含邮件、短信和服务监控，另一侧还有链路追踪、资源访问管理、服务编排等能力。它们应通过清晰的接口或控制关系接入主架构，而不是仅作为装饰图标悬浮。

核对中间件与存储职责

中间件层列出 Kafka 消息队列，用于削峰、解耦、日志和事务等场景；Redis 区域示意 zset、geo 和 pipeline；数据库区域包含分库分表、TDSQL 与 MySQL。每项能力都应标注使用场景、数据责任和容错方式。

存储层展示 Redis 哨兵配置、MySQL 主从备、ES 日志存储和 EMR 数据洞察集群。缓存、事务数据库、搜索和分析的数据一致性要求不同，不能用一条无说明的箭头表示它们自动同步。

若要展开消息从生产到消费、数据从服务到缓存和数据库的过程，可用数据流图制作工具分别画业务流和数据流。架构总览保持清楚，关键数据链路另页注明延迟、重试、幂等和失败补偿。

在万兴图示中重建调用关系

在万兴图示中编辑时，先将示例组件与现有平台做映射，删除未使用的产品名。统一集群边框、节点数量标记和箭头方向，主请求链自上而下，控制与观测关系使用不同线型，减少读者把监控误看成业务调用。

底部持续集成和容器技术列出 Docker、Maven、K8s、蓝盾与 GitLab。应补充代码、构建、镜像、部署和回滚的关系，或者把它们移到独立交付架构图；只排列名称无法说明发布过程。

服务间调用顺序复杂时，可配合时序图制作工具绘制登录、下单或支付等典型链路，并在每个参与者名称中使用与架构图相同的服务名。这样能从总览快速追踪到具体请求。

1. 步骤1：盘点真实入口、平台组件、服务域和数据能力。
2. 步骤2：明确同步调用、消息、配置、注册和观测关系。
3. 步骤3：标注集群、环境、安全边界与容灾方式。
4. 步骤4：拆出关键时序和数据流，完成跨团队评审。

用于容量、安全和故障评审

容量评审可从入口并发开始，沿代理、网关、服务、消息和存储逐层检查峰值、队列堆积与扩缩容阈值。每个共享组件都要说明限额和隔离策略，避免一个业务高峰拖垮整个集群。

安全评审应关注外部入口、鉴权、服务间身份、配置密钥、第三方调用和数据访问。图中可用边界框标出互联网区、接入区、服务区与数据区，并注明跨区访问的控制点。

故障评审则选择网关、注册中心、消息、缓存、数据库或配置中心失效等场景，检查是否有多节点、超时、熔断、降级、重试和恢复路径。没有画出的故障关系通常也是设计中容易忽略的部分。

微服务架构图的目标不是组件越多越专业，而是让流量、治理、业务、数据和交付责任可追踪。把示例栈替换成真实平台并补充关系后，它才可用于设计决策和日常运维。