Structurizr Cloud 将于 9 月 30 日关停：先把你的模型导出来

Structurizr 的云服务走到了生命周期的终点。他们的 end-of-life 页面把 "Structurizr cloud service (no replacement)" 与 Lite、CLI 和本地部署版并列，这些都将由新的整合工具取代。根据他们的终止服务公告，工作区已于 2026 年 7 月 1 日转为只读，剩余的月度订阅也在同一天停止，服务将于 2026 年 9 月 30 日关停。这份公告在 Patreon 后面，所以在依据这些日期做计划之前，请自己去核对一遍。

只读本身不是紧急情况。紧急的是只读掩盖住的那件事：你用来导出工作区的那些工具，本身就属于即将关闭的这项服务。 工作区编辑器里的 DSL 标签页、仪表盘上的导出链接、Web API。它们全都是云服务。到了 10 月 1 日，就没有标签页可点了。

所以第一个决定不是换到哪个工具，而是先把一个文件弄到自己的磁盘上。这只是每个工作区一次复制粘贴，不会让你承诺任何事情。而选择落脚点，这两点都不占。

把你的模型导出来

先做这一部分，在读下面任何内容之前。

你的工作区是只读，不是看不见。Structurizr 的云服务 FAQ 这样描述只读工作区："You can still view the workspace content (via the UI and web API) but no changes can be made" ——你仍然可以（通过 UI 和 Web API）查看工作区内容，但无法做任何修改。下面这些今天都还能用。

如果你是用 DSL 写、用 CLI push 的，你可能已经完成了。 你的 workspace.dsl 就在 Git 里。打开它，确认是最新的。唯一需要留意的一点：你在浏览器图编辑器里手工挪过的布局是存在云端副本里的，不在你的 DSL 里。如果这对你重要，那就把第 2 步的 JSON 导出也一并拿走。

如果你是在浏览器里写的，或者通过 Workspace API 写的，那你的模型只存在于 Structurizr 的数据库里。 按这个顺序来：

  1. DSL。 Structurizr 给现有用户的建议就是转成 DSL。来自他们的工作区编辑器帮助页："A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" ——你的工作区的 DSL 表示（不含文档）可以在 DSL 标签页中找到。工作区编辑器本身已于 2022 年 2 月停止维护，但仍可通过形如 https://structurizr.com/workspace/XXXXX/workspace-editor 的 URL 访问，其中 XXXXX 是你的工作区 ID。打开它，点击 DSL 标签页，全选复制，保存为 workspace.dsl。

    注意他们那句话里的括号。DSL 表示不包含文档。 如果你是把文档或 ADR 写进工作区里，而不是让 !docs 和 !adrs 指向仓库中的 Markdown 文件，那么 DSL 标签页不会把它们还给你。

  2. JSON。 Structurizr 的迁移说明会把你引向页面顶部的 "export your workspaces" 链接。它产出的是 workspace.json。即使你已经有 DSL，也把它拿上。它是 Structurizr 自家的 playground 和 local 都接受的格式，而且 local 会按 workspace.dsl、workspace.json 的顺序查找。

  3. 这两个文件漏掉的一切。 写在工作区里的文档、你上传的图片、带状态历史的决策记录。趁 UI 还在，在 UI 里打开工作区，把你在意的内容复制成 Markdown。

  4. 把两个文件都 commit 到一个仓库里。 不是笔记本上的某个文件夹。是一个仓库，紧挨着它们所描述的代码，放在下一个人能找到的地方。

每个工作区都重复一遍。如果你有十二个，那就一口气做完，别对自己许诺说以后会回来补。

有一件事我没能确认：关于 9 月 30 日工作区数据是被删除，还是只是变得无法访问，我没有在任何地方找到 Structurizr 的公开说明。 别假定十月还能要回来。也别假定要不回来。先把文件拿到手。

放到哪里去

四个诚实的选项。它们适合不同的团队，其中三个不是 archyl。

选项一：Structurizr 自家的工具

对比任何厂商博客会告诉你的，这对更多团队来说才是正确答案，而且它应该是你第一个去算成本的选项。

Structurizr 并没有消失，消失的是云服务。他们的 EOL 页面把旧产品映射到了新产品上：Lite 由 local 取代，CLI 由 pull / push / export 取代，本地部署版由 server 取代。如果你现在用的是 Lite 或 CLI，你面前同样有一次迁移，只是规模小得多。

  • local 在他们的文档里是这样描述的："the free and open source local command provides a way to view diagrams and modify their layout" ——免费开源的 local 命令提供了一种查看图并修改其布局的方式。它跑在你自己的机器上，绑定 localhost。他们的快速上手就是两条命令：docker pull structurizr/structurizr，然后 docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local。把它指向存放 workspace.dsl 的目录，打开 http://localhost:8080，编辑文件，刷新浏览器。
  • playground 是他们针对偶尔使用场景给出的建议：上传 workspace.dsl 或 workspace.json，看看图，关掉标签页。
  • server 才是接替云服务为你做的那件事的东西——把工作区发布给更大范围的读者。它有一个开源内核，只要你自己从源码构建就是免费的，带文件系统存储和 Lucene 搜索，没有认证。预编译的二进制包额外提供 SAML、基于角色的访问控制、私有分享令牌、S3 与 Azure Blob 存储、Elasticsearch 以及一套管理 API，并且需要许可证：1 到 20 个唯一用户每月 £300，21 到 50 个 £600，51 到 100 个 £900，按年计费。他们对唯一用户的定义会把任何看过图的人都算进去，包括通过 iframe 或嵌入图片看到的人，而不只是编辑者。

适合谁： 模型本来就是 Git 里的 DSL、读者是工程师、用云服务主要就是为了出图的团队。你的 DSL 原封不动地保留下来，我们自己的导入器会丢掉的 deployment 视图和动态视图你也都保留下来，而且这套工具是由发明 C4 模型的那个人写的。如果这说的就是你，读到这里就可以停了，去跑那条 Docker 命令吧。

不适合谁： 需要一百位非工程师在你不运维服务器的前提下浏览图的团队；以及觉得二十个阅读者每月 £300 比按编辑者收费的 SaaS 价格更难看的团队。还有一条，这篇文章其余部分都建立在它之上：自托管保住的是你的模型，而不是维护它。在云上放旧了的工作区，在 local 里同样会放旧。代码变了以后，没有人会回头重新跑一遍 DSL。

选项二：把 DSL 留在仓库里，不再为工具付费

最被低估的选项，也是最便宜的。

workspace.dsl 放在 Git 里，像其他任何东西一样在 Pull Request 里评审，谁真的需要一张图时再按需渲染。local 能在容器里渲染它，playground 也可以。如果你干脆想彻底离开 Structurizr 的语法，LikeC4 采用 MIT 许可，以仓库中的 .c4 文件来编写，并通过 Vite 插件、React 组件或 Web Components 发布，因此图可以嵌入到你本来就在运行的文档站点里。

适合谁： 图的受众就是几个看得懂 DSL 的工程师，而且对"到底多久有人打开一次这东西？"这个问题的诚实回答是"入职时和出故障时"的团队。你没有失去任何正在用的东西，而且持续成本归零。

不适合谁： 图的读者是那种不会去 clone 一个仓库的人。而这一点，如果你当初是在为云服务付费，可能恰恰就是你付费的原因。

选项三：另一个托管式 C4 工具

如果云服务确实在为你干活，那么用另一个托管工具来替代它是合理的选择，而且你应该多看几家。

IcePanel 是最接近的同类替代：一个视觉优先的 C4 工具，提供托管服务，免费档包含五个编辑者、不限数量的阅读者以及最多 100 个模型对象，付费方案按年计费、每个编辑者每月 $40 起。他们自己那篇对比 Structurizr 的文章写道："model objects can be imported from Structurizr, Backstage, and a REST API" ——模型对象可以从 Structurizr、Backstage 和一个 REST API 导入。我在能访问到的页面上没有找到关于所接受文件格式的文档说明，所以在你做决定之前，请把上一节里导出的那个文件原样上传上去，确认到底有多少东西活了下来。这条建议适用于本文提到的每一个工具，也包括我们自己的。

适合谁： 想要拖拽式编辑器、而且阅读者不是工程师的团队。

不适合谁： 当初正是因为模型是文本才转向 Structurizr 的团队。为了躲开一次云服务关停而放弃架构即代码，是一笔奇怪的交易，等到你第一次想 diff 一处改动时就会体会到。

选项四：archyl

我们做了一个 Structurizr DSL 导入器，所以这是我最熟悉的选项，也是你应该用最挑剔的眼光去读的选项。

带 workspace.dsl 来，不是 workspace.json。 archyl 解析的是 Structurizr DSL 文本，没有走工作区 JSON 的路径。如果导出链接只给了你 JSON，先看下面那一节再动手。

打开一个项目，在导入弹窗里选 Structurizr DSL，上传 .dsl 文件或者直接粘贴。能过来的东西：顶层的 person 和 softwareSystem，嵌套的 container 和 component，名称与描述，容器、组件以及关系上的技术字符串，逗号分隔的标签，任意深度的 group 块被拍平成 group:<name> 标签，以及文件中任何位置声明的关系——包括写在元素体内部的。容器类型和关系类型会从你的技术字符串和标签文本中推断出来。外部系统通过 External System 或 External 标签识别。这个导入器是拿 Simon Brown 本人的 Big Bank 示例工作区测试过的。

过不来的东西，这部分更重要：

  • 全部布局和样式。 views、configuration 和 styles 块会被跳过。archyl 会改用自动布局。手工布局正是 Structurizr 在卖的东西之一，所以这恰恰是你的旧工具最擅长的部分，而你正在放弃它。
  • !docs 和 !adrs。 这两个指令会被跳过。archyl 有 ADR 和文档功能，但 Structurizr 导入器不会去填充它们。
  • !include。 多文件的工作区必须在导入前先拍平，否则被 include 的内容根本就不在那里。
  • deployment 环境、deployment node 和 infrastructure node。 不导入。

其中大部分，导入器会在导入结果页上以警告列表的形式返回给你，用的是源文件本身的措辞：

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

对此有两点说明，因为一份你能信任的列表，比一份替我们贴金的列表更有价值。第一，deployment 环境和节点会被跳过：archyl 建模的是静态结构，不是部署拓扑。解析器会在警告列表里带行号点名，所以 deploymentEnvironment "Live" 块会以一行你能读到的记录出现，而不是事后才发现。第二，警告告诉你的是解析器拒绝了什么，它并不告诉你导入在其他方面就完美无缺。导入之后，请把模型读一遍。

为它付费而不是自己跑 local 的唯一理由： archyl 会拿模型和仓库重新对照，并给这个差距打分，于是一个开始与代码对不上的模型会自己说出来，而不是悄悄变成错的。这就是漂移分数，它是确定性的，而且不需要调用 AI 就能跑。如果在云端转为只读那天，你的 Structurizr 工作区是准确且最新的，那你不需要这个，我也不会试图卖给你。如果它已经陈旧了十八个月，那问题从来就不是工具，把它搬到别处也修不好。

两件你应该记在我们账上的事。 免费的 Developer 方案把一个项目限制在 100 个模型对象，所以一个有五十个系统及其容器的工作区根本装不下；而且 archyl 是云优先的，自托管只在 Custom 档位提供。Structurizr 在同一份载有日期的公告里给出的关停云服务的理由是：工程团队一直不太愿意把架构图发布到云上，使用量也在持续下滑。如果这说的正是你们的安全团队，那么选项一比我们更合适，而你不该在采购流程里花两周才发现这一点。

如果你手上只有一个 JSON 文件

仪表盘上的导出链接给你的是 workspace.json，而这也是大多数人最终会拿到的文件。它能落在哪里：

  • Structurizr local 和 playground 直接就能读。 不用转换。
  • archyl 读不了。 请改从 DSL 标签页拿 DSL，而且要在 9 月 30 日之前拿。如果这个工作区是通过 Workspace API 写的，DSL 标签页给不出可用的东西，还有两条退路：接上仓库，让 AI 发现从代码里提出模型；或者把一个编码 agent 指向那份 JSON，让它通过 MCP server 把模型写进来，具体做法在这里。
  • 其他任何地方： 先问清楚再迁移，别迁完了才问。

一段话做出选择

如果你的模型本来就是 Git 里的 DSL，读者又是工程师，那就跑 local，把省下的钱花到别处去。如果你需要一个可分享、有访问控制的实例，而且扛得住许可证费用，那 server 最接近云服务原本为你做的事。如果你想要可视化编辑器和非技术读者，去看看 IcePanel。如果你刚导出的那个工作区本来就已经过时了，而它过时的原因是手工更新它排在某个人优先级的第四位，那么需要被替换的就不是工具——而这正是 archyl 想说的。

无论你选哪一个：先把文件导出来。标签页会随着服务一起消失。

更多机制细节：导入 Structurizr、LikeC4 和 IcePanel 项目、Structurizr 迁移页面，以及一份 2026 年 C4 工具对比。如果你对这个模型本身还不熟悉，可以从 C4 模型和架构漂移开始。