架构洞察

Archyl 的 AI 驱动分析可检测潜在的架构问题，并提供改善系统设计的建议。

Archyl 检测哪些洞察？

关键问题

高优先级

中优先级

低优先级

运行架构分析

单项目分析

1. 从侧边栏进入 洞察 部分
2. 选择您的项目
3. 点击 分析
4. 等待分析完成
5. 按严重程度审查发现

全组织分析

一次分析所有项目：

1. 从主导航进入 洞察
2. 点击 分析所有项目
3. 审查跨组织的汇总发现

理解洞察

每个洞察包括：

严重级别

• 关键：需要立即关注
• 高：应尽快解决
• 中：在可能时考虑解决
• 低：改善性改进

受影响的元素

洞察列出所有涉及的元素，并提供直接链接以在图表中查看。

建议

解决问题的可操作步骤：

建议：在 API 网关和数据库之间添加缓存层，
以减少直接数据库连接并提高弹性。

相关文档

相关最佳实践和架构模式的链接。

管理洞察

静默洞察

如果洞察是有意为之或误报：

1. 点击洞察以展开
2. 点击 静默此洞察
3. 可选择添加原因
4. 洞察将从主视图中隐藏

查看已静默的洞察

审查已静默的洞察：

1. 进入洞察部分
2. 切换 显示已静默
3. 审查并可选择取消静默

批量操作

选择多个洞察以：

• 静默所有选中的
• 分配给团队成员
• 导出为报告

最佳实践

定期分析

• 在重大架构变更后运行分析
• 在冲刺计划中包含洞察审查
• 跟踪洞察趋势

按影响优先

不是所有洞察都需要立即处理：

1. 首先关注关键和高严重级别
2. 优先考虑业务影响
3. 记录有意的偏差

与团队分享

• 导出洞察报告用于架构评审
• 将洞察分配给团队成员
• 在项目管理工具中跟踪解决情况

常见洞察和解决方案

单点故障

问题：一个服务处理所有认证。

解决方案：

• 添加冗余认证服务
• 实现断路器模式
• 使用分布式会话存储

高耦合

问题：前端直接调用 10+ 个后端服务。

解决方案：

• 引入 API 网关
• 实现 Backend for Frontend（BFF）模式
• 使用事件驱动通信

循环依赖

问题：服务 A 依赖 B，B 依赖 C，C 依赖 A。

解决方案：

• 将共享逻辑提取到新服务
• 使用事件驱动架构
• 重构以打破循环

孤立元素

问题：没有连接显示的数据库。

解决方案：

• 添加与使用它的服务的关系
• 如果不再使用则移除
• 关联解释用途的文档

自定义洞察规则

每个组织都有不同的架构标准。Archyl 让您自定义生成洞察的规则以匹配您团队的要求。

访问规则设置

1. 进入 洞察 部分
2. 点击 规则 选项卡
3. 调整每条规则的设置
4. 点击 保存 以应用更改

保存更改后，Archyl 会自动使用新配置重新分析您的架构。

可用规则

单点故障（SPOF）

检测具有过多入站依赖的元素，如果它们宕机可能导致系统范围的故障。

如果您的架构有意集中某些关注点，请提高阈值。关键基础设施（如数据库）无论阈值设置如何都会受到额外审查。

高耦合

识别在任一方向上具有过多连接的组件。

入站阈值捕获许多其他组件依赖的元素。出站阈值捕获依赖过多其他组件的元素。构建共享库的平台团队可能需要比产品团队更高的阈值。

过度连接的元素

标记总连接数（入站 + 出站合计）过多的元素。

这捕获的问题与高耦合不同：由于接触系统太多部分而难以理解的组件。

循环依赖

检测 A 依赖 B、B 依赖 C、C 依赖 A 的依赖循环。

循环依赖使测试变得复杂，创建初始化问题，并表明边界不清晰。大多数团队保持启用。

孤立元素

发现与其他组件没有连接的架构元素。

孤立元素可能表示文档差距或应该移除的已弃用服务。

安全问题

检测令人担忧的模式，如外部系统直接访问数据库。

这些发现属于关键严重级别，大多数团队希望立即了解。

缺少文档

报告没有描述的元素。

为避免在大型代码库上产生过多报告，组件的文档检查仅在总组件数低于此阈值时运行。系统和容器始终会被检查。

全组织设置

洞察规则适用于整个组织，而非按项目。这确保了所有团队和项目的一致治理标准。

重置为默认值

点击规则选项卡中的 重置为默认值 以恢复所有规则的原始配置。

后续步骤

• AI 驱动的发现 - 保持架构最新
• 文档 - 记录架构决策
• 导出 - 导出洞察报告