跟你的架构图聊聊天

在我的职业生涯中，我参与了许多扩展的软件系统项目。作为软件工程师，我有一个非常有用的工具是软件和架构图的使用。但我在处理图表时总遇到一个问题，那就是它们几乎总是很复杂，细节很多，当我进入一个现有系统时，我需要能够快速上手。在这篇文章里，我会向你展示软件和架构图的价值，我们面对的挑战，以及我如何利用生成式AI更好地理解这些图表，获得更深入的洞察，进行决策，生成图表，甚至生成基础设施的代码。

咱们开始吧。

为什么图表很重要

软件架构图是重要工具，它们帮助开发者和相关利益方理解复杂的系统。

一个图表可以帮助填补技术与非技术利益相关者之间的鸿沟。通过一种共同的视觉词汇，图表可以比一大段文字更能清晰地展示复杂关系和细节。它们可以帮助我们看到整体图景，从而更好地理解系统中各个部分是如何相互作用的，或者在变化发生时会受到哪些影响。

这一切都帮助我们规划未来，识别风险和依赖，从而做出明智的决定。

不同类型的图表也有不同的目的。类图可以作为实现的蓝图，并更好地展示继承和聚合关系。序列图帮助理解对象随时间的交互流程。

各种类型的图表共同展现了系统的全貌。但也可能带来一些挑战。

图示面临的挑战

软件和架构图存在几个挑战，我最担心的是它们很快变得复杂，以及它们很快就会过时。

确保你的图表为特定目的和受众提供适当的细节层次很重要。细节太多会让图表显得过于繁琐，而细节太少则可能缺乏做出决策所需的信息。找到一个合适的平衡点并多加练习是关键。

图表也是某个时间点的快照，如果不在后续时间中保持更新，它们将不再反映实际情况，这会使得准确的洞察和决策更加困难。

有一些方法和工具可以应对其中的一些挑战，但今天我想展示如何使用生成式AI来更好地理解diagrams，获得更深入的见解，做出更明智的决策，生成图（diagrams），甚至生成基础设施代码（Infrastructure Code）。

让我们和我们的架构聊一聊

如果我们能与这些图表进行对话会怎么样？如果我们能更快地理解这些图表，获得关于我们系统的定制化建议，利用实时数据和我们公司的最佳实践知识，甚至还能生成新的和更新的图表会怎么样？

可以啊。

我将通过一个我使用Python构建的演示应用程序向您演示如何使用这个应用，该应用利用Amazon Bedrock Converse API。这将使我们能够与大型语言模型和用户之间进行双向对话。我们还会用一些工具来获取实时数据，并从我们公司的最佳实践数据库中提取数据。

试一试看

如果您想亲自尝试并用自己的图表运行这段代码，或者了解它是如何实现的，可以在这里获取代码：here。克隆这个仓库，确保您有一个 AWS 账号，确保可以访问 Amazon Bedrock 上的 Claude Sonnet 2.5 模型，并且已经安装了 Python 3.10.16 或更新版本。

一个简单的无服务器例子

我们将从这个图开始，它可视化了一个简单的无服务器应用程序，该程序通过萌萌的狗狗图片来传递欢乐。真是重要的业务呢！

点击图片查看架构图

这个应用是在命令行上运行的。启动它之后，我们输入我们想要分析的图形和第一个查询，并输入我们的第一个查询。

    列出架构图中所用的 AWS 服务，使用官方 AWS 名称列出，不包括任何子标题。

切换到全屏模式，退出全屏

输出：

    当然！我会分析图像 "demo/fluffy-puppy-joy-generator.png" 中的架构图，并列出官方 AWS 名称的 AWS 服务，不包括任何说明文字。以下是列表：

1. Amazon S3（简单存储服务 (S3)）

2. Amazon Rekognition

3. AWS Lambda

4. Amazon CloudFront

    这四个 AWS 服务在 'Fluffy Puppy Joy Generator' 应用程序的架构图中非常明显。

全屏/退出

接着就可以问一些跟进的问题，比如说：

• 有哪些推荐的单元测试策略？
• 这种架构符合AWS良好架构框架的程度如何？
• 为了提高这种架构的恢复能力，应该做哪些改进？
• 将这种架构的数据流转换为Mermaid序列图。
• 这种架构有哪些配额和限制？
• 能否生成用于部署这种架构的CloudFormation代码？

这种方法使用Amazon Bedrock Converse API与大型语言模型进行对话。此API会保存对话历史，作为未来对话的背景。您可以在我的一篇旧博客文章中了解更多相关信息这里。对话内容仅限于所选模型的训练数据（在这种情况下是Claude Sonnet 3.5）。

用工具获取实时的最新数据

但是如果我们想对这个系统提出更具体的问题呢？比如说，如果想知道这个系统带来了多少愉悦，我们就可以这样问：

请问当前系统的快乐值是多少？

全屏 退出全屏

为了支持像这样的实时数据查询，我们需要使用与Amazon Bedrock配合的工具。在这个应用中，我们有一个名为joy_count_tool.py的工具，可以通过API从系统中获取当前最新的欢乐计数（我们通过从一个JSON文件中读取数据来简化实现）。当模型识别出需要工具时，会回复应用具体使用哪个工具，然后我们的应用使用该工具来获取当下的欢乐计数。这些数据随后被传递回模型，并生成包含当前欢乐计数的自然语言回复返回给应用。你可以查看我的过去博客文章了解更多关于如何使用工具与Amazon Bedrock配合的信息：这里。

将自定义数据集成到 Amazon Bedrock 知识库中

知道这个计数是有帮助的，但我们要怎么判断这个数字是好是坏呢？我们又怎么知道这个数字是否符合公司的最佳做法呢？我们可以这样问：

次数189的喜悦算不算好呢？

点击全屏按钮可以进入全屏模式。点击退出全屏按钮可以退出全屏模式。

输出是：

感谢提供这些信息。根据公司的最佳实践，现在我可以评估当前的欢乐值是否良好。

根据“毛茸茸的小狗快乐生成器”系统的最佳实践，欢乐值的评估标准如下：

- 欢乐值1-100：差
- 欢乐值101-200：还可以
- 欢乐值201-300：好
- 欢乐值301-400：很好
- 欢乐值401+：最好

当前的欢乐值为189，处于“还可以”范围（101-200）。这意味着应用程序虽然正在产生一定的欢乐，但仍然有提升的空间。

具体来说：

1. 系统表现尚可，因为它不在“差”这一档。
2. 然而，它还未达到“好”的级别，即从201开始。
3. 有很大的潜力通过改进进入更高的级别。

最佳实践表明，当欢乐值处于这个范围时，需要更多的工作来改善体验。这可能包括：

1. 精进萌照生成算法
2. 改进内容选择
3. 优化传播方式

为了提高欢乐值并进入“好”或更好的类别，团队应专注于这些改进领域。建议定期审查欢乐值，并实施更新以保持和提升欢乐生成的水平。

总之，虽然当前的欢乐值189不算差，但这表明“毛茸茸的小狗快乐生成器”在传播与小狗相关的快乐方面达到其全部潜力方面还有改进的空间。

进入全屏，退出全屏

为了回答这样的问题，我们利用Amazon Bedrock知识库为模型提供上下文信息。在这种情况下，我们使用Amazon S3桶作为数据源来创建了一个知识库。该桶包含了关于我们公司最佳实践的信息。我们使用了Amazon Titan Text Embeddings v2模型，并结合了Amazon OpenSearch Serverless向量存储。您可以在我的同事的博客文章这里了解更多关于如何设置Amazon Bedrock知识库的信息。

这是一个简单的例子，但这意味着我们可以将实时数据带入我们的应用中，并基于我们内部的数据（例如公司的最佳实践或政策）获取见解，然后可以生成包含这些信息的自然语言回复。然后我们可以提出这样的问题：

• 我们所有的AWS资源是否都已根据公司的合规要求正确配置？
• 这种架构是否符合我们公司的最佳实践标准？
• 这个类图是否遵循了我们命名的最佳实践？
• 当前系统中的瓶颈是什么？

再次，毛茸茸的小狗快乐生成器只是一个微不足道的例子，但将生成式AI作为我们工具箱中的另一个工具结合使用图表，使我们能够更好地对系统进行可视化，做出决策，并实施，以及让客户更早地使用我们的软件产品，打开了更多的可能性之门。

接下来我们该去哪里？

现在我们已经介绍了生成式AI如何帮助应对这些挑战，我想给你们留一些实用的资源，帮助你们更好地处理你们自己的系统架构图。

• 获取代码，并根据您的需求进行修改，或使用您自己的图表进行分析 此处。
• 参加研讨会，利用生成式AI创建和理解架构图，这是我在2024年re:Invent大会上共同领导的工作坊，您可以在这里学习如何利用生成式AI来创建和理解架构图。
• AWS用户组领导Olivier Lemaitre介绍了如何使用Amazon Q Developer从图表生成代码的文章 详情请见此处。

希望这对你有帮助。如果想了解更多类似的内容，请点个赞👍，分享给朋友们👯，或者在下面留言💬说说你是怎么用生成式AI和图表的。你也可以在我的其他平台上找到更多内容，比如Instagram，LinkedIn和YouTube。