一张好看又通俗易懂的架构图，往往能达到“一图抵千言”的效果，但有的时候，有很多技术人员无处可去面对画布困境时开始。 尽管画图工具五花八门，各种模板琳琅满目，但在实践中似乎已经脱离了架构图的本质。 如何用一张图来描述系统，让系统中的所有参与者一目了然？架构图的元素对于不同的人有何不同？如何练习建筑思维？前几天，技术交流群里就架构图的制作进行了热烈的讨论。本文将从架构图应该表达什么、如何绘制架构图、如何实践架构思维这三个部分进行梳理和探讨。明确架构图应该表达什么 什么是架构图？是对软件系统的总体轮廓、各组成部分之间的相互关系、软件系统的演进方向进行抽象表示的总体视图。简而言之，就是建筑在不同的抽象角度、不同的抽象层次上的表现。 站在公司的角度，从战略、业务架构到应用、数据、技术架构，都可以用架构图来表示。一个好的架构图可以帮助利益相关者理解架构决策，解决沟通障碍，最大限度地减少歧义，达成共识，提高协作效率。 不过在讨论中，大部分人都提到了工作中不同角色对架构图的要求不同。例如： 老板可能会把重点放在战略目标的实现上。如何直观展示资源整合情况和企业盈利方向是重点；职能部门的配合与赋能； 技术需要了解架构设计要求的高效、安全、稳定的实现，以及后续风险的规避和灵活调整。 因此，有人提出，如果只需要让架构图“看得懂”，其实并不复杂。 “产品要给出模型图，标注各部分功能。操作要给出电路图、路径和原理。开发要给出零件图，指标一定要清楚。” 但问题是，因为受众和分层逻辑不同，几乎不可能画出一个大家都看得懂的架构图。而对于个人来说，看图的人的工作经验和知识储备，架构图能做到的也只是让“看得懂的人一目了然，熟悉的人”。环境中存在的事物”。观点总结 【边城浪子】不同层次的交流，需要绘制不同的架构图。实际操作包括业务架构图、产品架构图、开发架构图、系统架构图。根据级别不同，可分为L0、L1、L2、L3等，并可根据场合细化。向领导和客户汇报，一般画业务架构图或产品架构图，整体设计或部署使用系统架构图，开发时使用开发架构图。 【Signx】看懂架构图首先要有一个架构思路，比如为什么要用逻辑分层和解耦，为什么有5大设计原则，为什么要搞设计模式。有了这种思路，看架构图就不会盲人摸象了。如果不了解这些基本思想，再高深的架构图也依然是一堆条条框框，同样阻碍了软件开发人员的发挥。常见架构图分类 软件开发的流程一般是：需求-开发-测试-发布。就其整个生命周期而言，绘制架构图本身就是一个设计工作，属于前期工作。绘图的目的是让相关的合作者有一个共同的具体参考，同时为后续的软件迭代提供有用的决策依据。 下图是一个简单单体应用架构的示意图。Tomcat包含所有逻辑和模块。通过这张图，可以快速了解用户的整体访问流程。 当然，架构千差万别，架构图的种类更是五花八门，比如业务架构、软件架构、调用架构、物理架构等等，每一种架构图都有其特殊的用途，针对不同的受众服务。架构图本身不需要固定成某种形式，但一定要画得清楚，解释清楚。常见的架构图类型包括： (1)用例图：主要用于描述系统参与者和功能用例之间的关系，反映系统的最终需求和交互设计。 (2)逻辑视图：用于描述系统软件功能拆解后各组件之间的关系，反映系统的整体构成和系统构建的过程。人群一般是架构师、技术负责人、业务人员，重点是如何结合技术实现业务蓝图。 (3)物理视图：用于描述系统软件与物理硬件之间的映射关系，如软件的哪一部分运行在哪些硬件上，用于指导软件系统的部署和实施过程。面向人群，一般是运维，重点是如何部署。 （4）过程视图：用于描述系统软件组件之间的通信时序、数据输入输出，反映系统的功能流程和数据流向，通常用时序图和流程图表示。主要面向开发人员，关注技术在业务流程下如何运作。 （5）开发视图：重点描述软件在其开发环境中的静态组织结构，包括系统应该分解成哪些模块和子系统，这些模块和子系统在代码库中是如何组织的？如何进行配置管理？主要面向开发者，反映系统的开发和实施过程。 需要注意的是，只是因为不同的图是针对不同的职位和工种的，所以不要要求画一张面面俱到的图，大家都看得懂，非常完美。 【PcGhost】看图的人也需要有相关的知识和经验。只能让“懂的人一目了然，熟悉环境中已有的东西”。不可能同时让产品、运营、开发都懂。 这是某公司的调用结构，有助于理解调用过程。不过，看不懂的肯定看不懂，而且如果脱离公司现有环境，这个架构图的现状就是坑坑洼洼的垃圾。。。 在讨论中，[PcGhost]提到很多次了，不是一直很期待能画出满分的架构图吗。架构图的目的是让“看图的人尽快了解现状”。需要它的人可以尽快提取信息，这是一个很好的画面。在他看来： 1。该体系结构涵盖了广泛的领域。不同公司在不同时期有不同的场景，图表也不一样。如果是同一家公司，应该从大到小画，细节可以适当做，不要画的太完整。不要把所有的细节都堆在一张图里，这样只会增加看图的成本。“就像画地图一样，不是为了好看，而是为了到达目的地。地标变了，地图怎么变？有树的地方有没有必要标出来。” 2。架构设计非常复杂，涉及上下多个部门，但实际上每个部门都有自己的地图，产品、开发、测试、运维、运营部门经常看到自己的“一亩三分地”土地”。另外，跨部门沟通协调困难，看图的人水平也参差不齐，抓图目标更实际。 3。业务需求总是动态变化的，架构也需要通过场景来检验。再好的架构方案，如果脱离实际业务需求，也是空谈。“花100万带来100个用户和花100块钱带来100个用户是天壤之别，用户就这么多，再高级的架构有什么用？好的架构师可以‘降低各种风险’，尤其是它可以做到‘符合预期+成本最优’，之后架构可以在符合当前场景的前提下逐步演进。”如何画好架构图 架构图很复杂，要画出一目了然的图，首先要善于拆解和抽象，能够整合业务和技术在一定程度上；其次，能够从各个维度梳理出结构的逻辑和思路，能够为人群画出合适的画面。对于观众来说，好的架构图应该是不言自明的；最后，架构图本身是由多种视觉元素组成的，无论是形状、颜色还是线条，都应该有清晰的语义表示，避免杂乱造成的语义混乱。 至于如何画好架构图，讨论中提到了各种方法论，其中比较典型的是“C4视图”。 【天思源】C4模型是SimonBrown提出的软件架构可视化模型。所谓C4指的是Context（上下文）、Containers（容器）、Component（组件）、Code（代码），指的是不同层次的架构图。这些图可用于描述不同缩放级别的软件架构。每个图表都针对不同的受众。 1。系统上下文图（SystemContextDiagram） Context就是系统上下文。这是最高层次的架构图，也是可以展示给所有人看的架构图，包括技术人员和非技术人员。 显示：谁是这个系统的用户，他们正在与哪些外部系统进行交互？而是从系统内部分离出来，把系统看成是一个黑盒子，从系统外部看，展示与用户和外部系统的关系。换句话说，这是一个缩小的视图，在不暴露系统内部细节的情况下显示系统的大图，因此重点应该放在用户和软件系统上，而不是技术和其他实现细节。 2。容器图（ContainerDiagram） 这里的“容器”概念不同于Docker容器，指的是软件系统中可以独立部署/运行的单元，可以是服务端的Web应用，单页应用、桌面应用、移动应用、数据库等。 展示的是：软件系统整体形态中的职责是如何分布的，容器之间是如何交互的示意图是“containerdiagram》@C4模型官网 如果说系统上下文图把系统看成一个黑盒，那么容器图就是打开黑盒。这时候可以看到系统中所有的容器，以及各个容器之间盘根错节的交互关系。它可以展示容器的主要技术栈以及容器之间如何通信。这是一个简单的、以技术为重点的图表，对软件开发人员、支持人员和操作人员很有用。 3。组件图（ComponentDiagram） ComponentDiagram是对某个容器进行放大和分解，展示容器是如何由多个“组件”组成的，每个组件是什么，它们的职责和技术/实现细节。 展示：系统由哪些组件/服务组成，阐明组件与依赖的关系《组件图》@C4模型官网 组件图主要给内部开发者看，代码如何组织和结构，提供了一个软件开发分解交付的框架。 4。代码/类图（Code/ClassDiagram） 代码层是将每个组件放大，展示它是如何作为代码实现的。理想情况下，该图将使用工具（例如IDE或UML建模工具）自动生成，您应该考虑只显示那些您想要显示的属性和方法。「代码图」图@C4模型官网 除了C4视图，还有“4+1视图”也是比较流行的分类方式。当然，脚本不一定有用，但至少这些经典观点为我们提供了一些常规的思路打开方式。意见总结 【席冬冬】在画好架构图之前，首先要弄清它的受众，然后想好你要向他们传达什么信息。因此，不要为了画物理视图而画物理视图。绘制逻辑视图要根据不同的受众、不同的要传达的信息，准确地用图表表达出来。 【无所谓的安然】画一个架构图可以分为四个步骤： 1、弄清楚要画的架构图的类型； 2、确定架构图中的关键元素（如产品、技术、服务）； 3、梳理关键要素之间的关系：遏制、支撑、同级并列等； 4、输出关联清晰的结构图。 【张业贵】架构图是一组从不同角度展示软件结构的图表。如果把它画成一幅复杂的整体图，只有建筑师才能看得懂。可以有一张整体结构图给大家，帮助大家快速了解基本信息。最难理解的是分层表示。各部分之间的关??系并不明确，就像原子中的电子一样。你知道它应该存在，但你要具体观察它在哪个轨道上。如何锻炼建筑思维 建筑图形成后，如何判断其好坏？ 就图表本身而言，阿里云产品生态资深技术专家肖毅曾讲过以下标准：内容术语一致、信息粒度一致、图例清晰、颜色类型统一、外观漂亮;图中的信息与对应的抽象层次相关，满足利益相关者（合作伙伴）的需求；好的架构图不需要多余的文字解释！观众是否得到了他们想要传达的信息？如果它提出的问题比它能解释的多，那么它就不是一个好的架构图；架构图应该帮助每个人看到大局并了解他们周围发生的事情，适当的上下文信息；架构图应避免“只见树木不见森林”。 但最终，真正的进步来自实践。只有开始画画，才有前行、悟道的可能。 当然，不管是画还是看架构图，想要加深理解，都需要锤炼自己的架构思维。在《史海峰：在时代节点上顺势而为是一种幸运 | 技术人访谈录》一文中，施海峰提到，培养结构化思维，要注意以下三点： 第一，抽象和归纳能力。简而言之，就是如何在深入理解一个复杂的系统之后，将其简化，并用相对简单的图表或语言描述清楚。然而，由于架构是系统的一个视图，这意味着它不是唯一的答案。站在不同的角度看架构，会有不同的理解和不同的设计。 其次，由于业务场景千变万化，在当前的架构设计中，往往需要在非常有限的资源条件下进行取舍，以完成相对明确的需求目标。因此，在衡量架构设计成败的时候??，往往没有定论。 第三，架构的本质一定要围绕业务目标。需要考虑核心业务目标和产品核心目标是什么。技术实现的时候，架构如何更好的满足这两点。同时，也要关注未来业务变化的趋势，不能只满足于在技术层面采用了哪些优秀的解决方案，“因为商业价值不是用技术难度来衡量的”。 最后希望以上内容能够对大家有所帮助。下次面对画布的时候，你会觉得自己好像在用精神写字。参考链接：https://zhuanlan.zhihu.com/p/451216794https://c4model.com/https://zhuanlan.zhihu.com/p/55185723
