大模型自动刻画项目架构链路图

零、背景

2025年04月02日，广州地域网络异常，听说很多服务不能使用了。

当时我关心的第一件事是我所在团队的哪些服务受影响了。

团队的小伙伴只能从是否手动告警来判断某些服务是否正常。
对于核心读写链路没有告警，只能去手动看下监控是否正常。

于是我便有了一个想法：需要刻画出团队所有服务的地域架构链路图。

现在大模型编程助手这么厉害，清明节假期的时候，我已经使用大模型帮我做了一个网站，记录在《编程助手 copilot 几分钟做一个网站？》。
所以我自然就想，通过 github copilot 来自动帮忙生成这个链路图。

一、需求分析

目标：画出团队的项目地域架构图。

实现方式：

1）获取项目的所有服务列表。
2）获取每个服务的地域信息和依赖关系。
3）根据服务的地域信息和依赖关系，生成 markdown 格式的地域架构图。
4）将 markdown 格式的地域架构图转换为图片格式。

Q：怎么获取服务列表呢？
A：手动去容器平台导出团队内服务列表。

Q：怎么获取服务的地域信息和依赖关系呢？
A：通过监控平台的API接口，获取相关的地域信息和依赖关系。

由于团队内已经有服务拉取监控平台的数据了，所以我只需要要到 API 文档 和 鉴权信息即可。

Q: 怎么生成 markdown 格式的地域架构图呢？
A：通过大模型编程助手，自动生成 markdown 格式的地域架构图。

Q: 怎么将 markdown 格式的地域架构图转换为图片格式呢？ A：可以使用工具 mermaid ，手动将 markdown 文件转换为图片格式。

这么一分析，实现起来也不复杂，马上开干。

二、材料准备

为了验证可行性，我先简化需求，去掉了地域。
这样只需要服务列表与服务的关系列表。

让大模型干活前，我需要先把我的需求以及材料准备好。

材料1：DB 设计

材料2：大致逻辑描述清楚。

1、读取 server.list 文件，得到 服务列表，假设服务名为 A
2、每个服务 A 读取 query_range 接口，得到 主调监控的被调服务列表
3、请求参数参考 readme 文档，每个服务追加前缀 “PCG-123.” 可以得到请求参数 target
4、返回的 data 数组中，label_set 字段里的 callee_server 是下游服务名 B， samples 里的 value 是访问量，求和代表日访问量
5、服务 A 与 服务 B 的二元组储存到数据库

材料3：提供接口文档

接口请求回包都是 json，所以分别贴两个 demo 样例即可。
如材料2里的描述，介绍清楚请求 json 需要替换哪些字段，回包 json 需要提取哪些字段。

三、大模型生成代码

步骤1）引导生成数据库

prompts： 参考 readme 的 数据库 小节，创建 t_service 和 t_service_rpc 表

步骤2）引导生成服务列表读取代码

prompts: 编写一个新的脚本 process_service.py， 按 readme 的 2.1 实现代码

步骤3）引导生成生成 markdown 格式的架构图。

prompts：生成 flowchart_service.py 脚本。要求：根据数据库的 点表 t_service 与边表 t_service_rpc 生成 flowchart， 其中 点的t_type 和 t_modules 继承 t_server 服务表的信息。

步骤4）将 markdown 格式的地域架构图转换为图片格式。

操作：将第三步生成的 markdown 文件复制到 mermaid 网站，导出图片即可。

如下图，生成的架构图还是很漂亮的，也很清晰。

四、加功能

由于一开始我简化了需求，没有加地域信息。
所以现在需要把地域信息加进来。

流程和之前的一模一样，补充DB信息，描述大致逻辑流程，一步步生成代码即可。

地域字体调大、模块字体调大，地域架构图看着还是很清晰的。
可以看到，大部分服务部署在深圳、不少服务在广州，南京、上海、天津、新加坡有部署，但是只有几个服务。

人力计算

大模型编程助手的确很强大，可以很快生成 MVP 的代码。

不过要实现完整的需求，还是需要投入不少时间来调试的。

看 git 备份记录，周三晚上我调试到凌晨 00:00:44 ，周四晚上我调试到 01:13:05。

prompts: git log 紧凑形式,显示Date，命令怎么写
命令：git log --pretty=format:"%h %ad %s"

扫描所有文件，根据文件的创建时间，可以知道我每天投入了多少时间。

prompts: 递归目录下所有文件的所有创建时间,时间相同时，只显示第一个文件, 最后算一下共投入多少时间

如上图，第一天投入 5小时58分钟， 第二天投入 12小时11分钟5秒，共投入 18小时9分钟的时间。

这个项目投入这么长时间，是由于不知道是否可以通过监控系统生成的架构图，所以想了 3 个策略，分别独立实现了这 3 个策略，来对比效果。
也就是每个项目大概投入了 6 个小时，还是挺长的。

五、总结

使用大模型生成系统架构图算是我使用大模型编程助手的第二个项目，虽然共投入 18 个小时，目前看效果还不错，我还是挺满意的。

画出架构图的过程中，也发现团队监控系统的很多不规范之处，大概如下。

1、部分系统还没切换到最新监控系统，每开启秒级监控与全链路trace。
2、对于定时器或者常驻进程场景，监控上报不规范。
3、消费 kafka 场景,监控上报不规范。
4、下游是非 rpc 服务即第三方组件场景，监控不规范。
5、部分服务需要区分业务时，自定义了监控名，导致监控不规范。
6、部分第三方组件的网络调研没有上报监控。
7、部分监控中无法区分下游地域信息。
8、所有第三方组件，无法获取组件实例ID。

是挺多的，后面需要制定一个监控上报的规范，推动团队治理一下监控上报。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号： tiankonguse
公众号ID： tiankonguse-code