备考软考系统架构师这几个月，最大的感受就是：论文里不画架构图，基本等于白写。

但每次画图都头疼——手绘太丑，Visio 太重，PlantUML 还得装环境。上周末折腾了一个开源架构图生成工具，发现它生成的效果意外地好，暗色主题、组件语义化配色、连箭头和区域边界都给你安排得明明白白。

今天就拿它生成的微服务电商系统架构全景图为例，边看图边把软考高频考点串一遍。

架构全景图

这张图覆盖了 Spring Cloud Alibaba 全家桶：Nacos 注册中心、Sentinel 熔断、API Gateway、微服务拆分、数据库隔离、Redis 缓存、RabbitMQ 异步解耦——基本把软考微服务论文需要的素材全画进去了。

从上往下拆解

第一层：基础设施——Nacos + Sentinel

上面两个小框分别是 Nacos 注册中心和 Sentinel 控制台。

Nacos 干两件事：服务注册发现 + 配置管理。所有微服务启动时向 Nacos 注册自己的 IP 和端口，调用方从 Nacos 拿到可用实例列表。黄色虚线表示的就是注册/发现的通信链路。

Sentinel 是阿里开源的流量治理组件，提供熔断、降级、限流。红色虚线表示 Sentinel 对所有服务实施熔断保护——某个服务挂了不会拖垮整个系统，这就是软考里常考的"质量属性：可用性"的落地实现。

第二层：API Gateway——统一入口

所有外部请求先打到 SLB/ALB 负载均衡，然后进入 Spring Cloud Gateway。

Gateway 在这里干四件事：

1. 路由：根据 URL 前缀把请求转发到对应的微服务
2. 鉴权：JWT Token 校验，没登录的直接挡在门外
3. 限流：配合 Sentinel 做网关层限流
4. 日志：统一记录请求日志

软考论文写到网关的时候，这四个点就是现成的论点。

第三层：微服务——按业务拆分

三个服务各管一摊：用户服务管注册登录、订单服务管下单支付、商品服务管列表库存。

关键设计决策：每个服务有自己独立的数据库——这就是"Database per Service"模式。为什么这么做？因为共享数据库会导致服务间紧耦合，订单表改个字段可能把用户服务搞挂。

第四层：数据层——缓存 + 消息队列

Redis Cluster：做 Session 共享和热点数据缓存。分布式环境下，用户登录态不能存在单机内存里，必须扔到 Redis。软考里考点叫"共享 Session 方案"。

RabbitMQ：订单状态变更时发消息，商品服务异步更新库存。这解决了两个问题——一是服务解耦（订单服务不需要知道商品服务在哪），二是削峰填谷（秒杀时请求先扔队列慢慢消化）。

注意底部那个粉色虚线框——安全组，标记了数据库端口（3306/9200）仅微服务可访问。外部流量根本打不到数据库，这就是纵深防御。

软考论文怎么用这张图

系统架构师论文里画架构图，把握三个原则：

1. 分层清晰：网关层→服务层→数据层，评委一眼看懂
2. 标注关键组件：每个框上写清楚技术选型（Nacos / Sentinel / Gateway）
3. 连线说明交互：同步调用用实线（REST/Feign），异步用虚线（MQ），注册发现用短虚线

这张图里的箭头颜色和线型已经分好了——你写论文的时候直接照着讲就行。

写在最后

说实话，画架构图这件事，工具不是最重要的，知道该画什么才是关键。软考论文评分标准里，"图文并茂"是隐性加分项，但前提是你画的图能讲清楚你的设计决策。

这张图的完整 HTML 源文件我也放出来了，你可以直接在浏览器打开、截图、塞进论文。后面我打算再出几期：六边形架构、CQRS 事件溯源、OAuth 2.0 认证流程——都是软考高频考点。

你们备考架构师的时候，论文里的图都是怎么画的？评论区聊聊，有好的思路我直接画出来。