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