如何绘制有用的技术架构图
技术架构图提供了您组织的基础架构的鸟瞰图。 该图说明了系统中的组件如何在大型事物中相互交互。
有多种服务于不同目的的架构图。 通常，数字解决方案架构师会草拟高层架构图，以促进技术解决方案设计。 架构图有两个主要优点：
- 它们有助于理解-提供可用系统和交互的概述，这有助于轻松地从更改中评估影响。
- 它们改善了沟通与协作-跨项目和利益相关者调整实施计划，以减少沟通差距。 有用的架构图应在一定程度上满足利益相关者的每个需求。
在本文中，我将介绍五种架构图，这些架构图对我设计和实施数字解决方案非常有用。 他们是：
- 应用架构图
- 集成架构图
- 部署架构图
- DevOps架构图
- 数据架构图
快速说明：优秀的做法通常因组织而异。 我将从AWS云的角度分享在实施云基础架构解决方案方面对我有用的东西。
就像软件代码一样，在系统变得庞大和复杂之前，通常会忽略结构良好的架构的有用性。 有用的架构图将这三个组件结合在一起：
- 标准化的信息处理流程，例如 自上而下的读数-指示组件之间如何交互。
- 通过逻辑分组在组件中提供足够的信息-这表明约束位于何处，例如 网络边界。
- 包括带有更多信息的注释-稍微多一些细节的步骤，以促进解决方案的实施，例如 进度解析。
我将尝试提供一些上下文和示例，说明如何使用每个图表来帮助解决方案的设计和实现。
#1：应用程序架构图
应用程序架构图包括系统内组件和基本交互的高级概述，例如 微服务，数据库等
应用程序体系结构图主要解决与系统有关的"内容"。
此图的常见用法是通过评估升级，替换或合并现有应用程序的影响来促进计划和解决方案的实施。 随着新应用程序不断投放市场，并有望提高效率和降低成本(尤其是在集装箱化领域)，对系统中的应用程序进行概述至关重要。
例如，由于各种原因，您的应用程序可能驻留在多个容器集群中，即裸机Kubernetes，AWS ECS等。 并且您的任务是合并和合并应用程序以使用单个容器管理平台，例如 裸机Kubernetes可以优化成本并简化多云环境中的运营。 首先，您可能会想到以下一些问题：
- 每个群集中都有哪些类型的应用程序?
- 应用程序的依赖性和交互作用是什么?
- 架构的预期结果和预期状态是什么?
下面的示例图说明了应用程序体系结构的现状。 图的"逻辑层"中的组件解决了前两点。
> Sample Diagram by Author
解决了这些问题后，假设计划将AWS ECS集群应用程序合并到Kubernetes集群中，那么有几个操作项需要基于该图的各利益相关方的输入。
例如，您可以联系项目经理以检查合作伙伴集成的类型，例如 内部/外部，DevOps检查密钥和配置管理，以及系统工程师检查群集的组织方式等，以协助进行影响分析。
从各利益相关者那里获得相关信息后，您便可以根据重要考虑因素来建立所需的/将来的架构和实施计划状态。
该图中的有用组件：
- 将组件分为层次和有界的上下文-每个边界都可能暗示一个不同的利益相关者组，例如 数据层的数据工程师，公共/共享服务的核心平台团队等，提供了谁参与计划/讨论的想法。
- 带有附加信息的注释-提供有关如何管理和组织每个群集的更多详细信息，例如 基于应用程序的性质和安全性等方面的考虑，可能会包含一些内容以促进讨论。
- 应用程序详细信息和上下文-说明应用程序的名称和类型，以提供有关如何组织应用程序的想法
您可以在此处下载上图的样本。
#2：集成架构图
集成体系结构图与应用程序体系结构图非常相似，不同之处在于它特别强调了组件之间的集成协议，例如： 批处理，事件，REST / SOAP / XML等
集成架构图解决了系统中组件互连的"方式"。
此图的常见用法是促进合作伙伴或其他内部系统对外部系统的集成。 如今，随着企业通过生态系统建立新的合作伙伴关系来创造共同的价值，您可能经常需要与合作伙伴一起将系统集成在一起，例如 电子商务，付款，酒店预订，航班等
例如，有一个合作伙伴拥有一个旅行应用程序，该应用程序希望在其应用程序上列出您的产品目录，以增加其消费者的选择范围。 您的任务是与合作伙伴解决方案架构师合作，以促进系统集成以向您提供服务。 合作伙伴更喜欢通过REST API使用服务。
您可能会想到以下一些问题：
- 目前我的服务在内部/外部如何组织和公开?
- 合作伙伴如何与我的系统集成，例如 内部网络，协议等?
- 如何保护，跟踪和管理暴露服务的集成?
下面的集成图(高层)说明了组件之间的现有通信协议。 您还将看到如何通过逻辑层的外部API网关向第三方开发人员公开某些服务。
> Diagram by Author
从上图，您将意识到该系统被设计为由API驱动，因此易于集成。 几乎所有服务都是通过Web服务公开的，包括数据存储组件。
下一步是与合作伙伴一起检查他们所需的服务列表，例如集成方式。 内部或外部，并将需求与通过API目录公开的服务进行交叉引用。 还有一些后续操作项目，即与系统工程师一起确定公开服务的安全性和监视。
有时，可能存在需求缺口，例如合作伙伴希望在外部进行集成，但是您的服务仅在内部公开，或者缺少某些数据属性。 在这种情况下，必须考虑到满足要求的努力。 集成图必须突出显示详细信息，即内部服务/ API，API目录的链接等，以快速识别此类差距。
该图中的有用组件：
- 将组件分为层和有界上下文-内部/外部API网关和服务的指示
- 带有附加信息的注释-API目录的参考链接，可在其中获得详细的服务数据属性以评估差距
- 应用程序详细信息和上下文-对服务进行适当命名，以允许快速评估需求。 实际
您可以在此处下载上图的样本。
#3：部署架构图
部署架构图由网络边界和基础架构硬件/软件组件组成。 有时还会指定组件的大小和数量，以方便规划。
部署体系结构主要针对系统中的组件处理"位置"和"数量"。
此图的常见用法是促进应用程序和服务的升级，以处理额外的负载或优化资源。 随着时间的流逝，随着来自世界各地的更多用户开始使用您的应用程序和服务，您现有的资源可能无法处理规模和负载的增加。
例如，您的API网关当前部署在单个大型EC2实例(t2.xlarge)中，并且由于性能最近遇到了间歇性的服务中断。 您的任务是将API网关转换为具有多个可用区(AZ)的群集设置(使用新计算机)，以提高网关的可用性。 您可能会想到的一些问题是：
- 多少个AZ?
- 在哪里部署实例?
- 新实例有多大?
下面的部署体系结构说明了网络和组件的当前设置。 ap-southeast-1中具有API网关实例的当前应用程序有两个可用区。
> Diagram by Author
根据上图，您将能够获取有关API网关实例的现有尺寸的信息，例如 (t2.xlarge)，用作新实例大小调整的基准。 在同一可用性区域中，还有一个标记为API Gateway实例的对应数据库实例。
该图还可以促使人们进一步讨论新实例的位置，即私有子网2b或2c等，或者是否可能有进一步计划来整合AWS Core Platform上所有服务的中央API网关以集中API 管理。
下一步将基于各种实施计划(即集中式API管理或分散式管理等)估算影响，并向管理层和相关利益相关者提出评估建议。
通常有多种方法可以解决此类性能问题。 如果您在大型组织中，那么通过中央架构委员会调整方法以进行适当的架构管理非常重要。
该图中的有用组件：
- 网络边界-展示组件的隔离和潜在的连接影响。
- 实例大小确定—表示机器的大小确定，以便于根据性能要求对资源进行优化和基准测试。
- 显示外部集成的各个部分-展示系统对其他系统和网络的扩展(如果有的话)，以显示更大的图景，并促进资源精简(即公共/共享服务等)和协作机会的简化。
您可以在此处下载上图的样本。
#4：DevOps架构图
DevOps体系结构图通常包含系统组件，流程和环境。 该图类似于过程流程图，该过程流程图说明了将代码库/应用发布到生产环境的操作。
DevOps体系结构主要解决与流程和部署流程优化有关的"如何"和"什么"。
此图的常见用法是促进有关应用程序部署的流程的改进。 系统架构的不断变化和部署工具/方法的改进，例如 容器，无服务器等提示需要适应现有的DevOps体系结构和流程以适应时代的发展。
例如，应用程序管理，例如 您团队的配置等目前尚未跨平台标准化，您的任务是探索一种新工具(栖息地)的实施方式，以有效管理应用程序。 您可能会想到的一些问题是：
- 当前的流程是什么?
- 当前如何跨应用程序管理配置?
- 要部署的应用程序类型是什么?
下面的DevOps架构说明了跨环境将应用程序部署到Kubernetes集群中的流程。 对于不同的应用程序类型，该图可能有多种变体。
> Diagram by Author
根据上图，您将能够获取有关DevOps流程各个阶段的信息，以识别可通过新工具(例如， 配置管理或集成点以合并新工具。
各种应用程序类型的DevOps图表可能会促使进行进一步的讨论，以探索潜在的新流程和工具集，以满足团队的需求。
下一步将是让各利益攸关方参与，讨论流程和工具的改进以及实施人居署对现有业务的潜在影响，例如： 需要新的插件，等等。
对于大型组织而言，流程要复杂得多，并且要考虑整个环境的安全问题，从而严重限制了资源的部署。 还有许多遗留应用程序遵循旧的部署方法。 建议记录不同应用程序变体的流程，并从整体上看待它们，以提高效率。
该图中的有用组件：
- 在整个环境中展示流程-DevOps通常跨环境，并且显示应用程序升级流程通常很有用。
- 带有附加信息的注释-可以包括各个阶段和过程的更多详细信息，以促进讨论和规划。
- 决策网关和用户流程-DevOps不仅包括系统组件，而且还涉及很大一部分人为因素以建立良好的DevOps文化。 人为过程的组成部分不容忽视。
您可以在此处下载上图的样本。 另外，这是31种DevOps参考架构的列表。
#5：数据架构图
数据体系结构图包含系统内的组件，这些组件定义了如何收集，处理，存储和使用数据。 该图还说明了IT基础架构内跨系统组件的数据流。
数据体系结构图涉及与数据的处理，流和使用有关的"如何"和"在哪里"。
该图的用例之一是促进资源升级以优化数据收集和存储成本。 随着当今捕获的数据量的增加和数据存储成本的降低，企业的数据架构必然会不断调整。
例如，从API网关捕获的日志数据当前存储在MySQL数据库中，并在Web仪表板上可视化。 随着数据库中数据的不断积累，查询变得越来越慢，成本也越来越高。 您的任务是解决性能问题，并为将来来自其他应用程序的数据集的机器学习和分析功能奠定基础。 您可能会想到一些问题：
- 当前如何处理数据?
- 数据在哪里存储和使用?
- 我们在谈论多少数据?
下面的数据架构说明了从源到存储和可视化的数据流。 在某些情况下，在图表中包括新组件以显示更改以方便讨论可能会很有用。
> Diagram by Author
下一步可能是让利益相关者参与讨论实施细节，例如 数据保留期，绩效要求，业务目标和见解，数据结构和模型，成本估算等。
该图中的有用组件：
- 显示原样和将来的组件-快速概览更改，以评估影响并重点讨论要点。
- 数据增量率的指示-使利益相关者对数据规模有所了解，以进行估计和解决方案设计。
- 组件的逻辑分组-说明了各个阶段的组件目标，例如 处理，可视化等，以简化可读性。
您可以在此处下载参考图的样本。
总结
- 应用程序体系结构图提供了组件的高层概述，以基于升级，替换和合并应用程序的影响评估的形式促进规划。
- 集成体系结构图着重于应用程序组件之间的集成协议，以促进内部/外部合作伙伴系统的集成。
- 部署体系结构图突出显示了网络边界和基础结构组件的大小，以便于出于优化目的对应用程序和服务进行计划和升级。
- DevOps体系结构图说明了跨部署环境的涉及系统和人员的流程流，以促进流程改进和自动化。
这些图经常在数字解决方案设计中一起使用，因为它们相互补充，从而为利益相关者提供系统的图片。
但是，请记住，地图不是领土。 鉴于活动部件和变更的数量，几乎不可能记录系统的每个部件。 我遇到过许多实例，由于各种原因，这些更改和组件未在图中捕获。 准备应对这种情况。
另外，为满足不同的目的，有很多不同的架构图(基于Google图像)可以满足需要-没有固定的方式绘制架构图。 我在这里提供的是示例准则和原则，可帮助您更好地了解系统，以制定出可能的解决方案。