制作软件架构图：工具和方法论

一、什么是软件架构

1.1 软件架构的定义

1.2 架构的核心要素

综合上述各种权威定义，软件系统的架构通常需要包含如下四类核心要素：

• 元素（elements）：将系统拆分为一组元素 - 模块、组件、结构体、子系统；
• 关系（relationships）：不同元素之间的关系 - 交互、依赖 、继承、组合、聚合；
• 属性（properties）：每个元素具备的属性 - 名称、职责、接口、实现限制等；
• 原理（principles）：为什么这么设计 - 拆分依据、设计原则、决策原因等。（理解后其实是重要的，比如这样设计的优劣、多个架构选择为什么选这一个）

二、为什么要进行架构设计？

2.1 架构是系统实现的蓝图

2.2 架构是沟通协作的基础

2.3 架构决定了产品质量

如何衡量一个软件产品的质量？上图是 ISO/IEC 25010 标准定义的软件产品质量模型，包括以下 8 个大类：

• 功能适合性：功能完整度、功能正确性和功能恰当性；
• 性能效率：时间表现（e.g. 响应时间）、资源利用和容量；
• 兼容性：共存能力（e.g. 多版本组件共存）和互操作性；
• 可用性：可学习性、可运维性、用户错误保护（e.g. 自动纠错）、UI 美观度、可访问性；
• 可靠性：成熟度、可用性、容错性、可恢复性；
• 安全性：机密性、完整性、不可伪造性、权威性和可审计；
• 可维护性：模块度、可复用性、可分析性、可修改性、可测试性；
• 可移植性：可适配性、可安装性、可替代性。

上述质量模型中列出的所有点，都是架构设计需要着重考虑的。其中除了功能适合性以外，其他所有点都属于非功能需求的范畴，这也是区分架构好坏的真正分水岭 —— 好的架构设计，不会停留在仅满足功能需求这一最基本的需求层次上（最坏的架构设计也同样能做到），更重要且更难以应对的是其他众多的非功能需求。

2.4 其他理由

①、架构包含系统所有最重要的早期决策

这些决策会进而影响后续所有决策；一旦决策有误，纠正的成本会非常高

②、康威定律：软件架构影响组织结构

软件架构反映了组织结构；反过来也成立，好的架构会让组织结构变得更高效

③、越庞大、越复杂的系统，架构越重要

好的架构可以控制、管理和最小化系统复杂度

三、如何设计一个好的架构

（比较复杂，不是本文档重点）

2.1 架构原则（principles）

SOLID原则是一套比较经典且流行的架构原则（主要还是名字起得好）

单一职责

开闭原则：

里氏替换

接口隔离：

依赖反转：依赖抽象类与接口，而不是具体实现；让低层次模块依赖高层次模块的稳定抽象，实现解耦。

此外，我们做架构设计时也会尽量遵循如下一些原则（与上述SOLID原则本质上也是相同的）

正交性

高内聚

低耦合

隔离变化

2.2 架构模式（patterns）

分层架构、SOA架构、Serverless架构、事件驱动架构、云原生架构、C/S架构、MVC架构、微服务架构、微内核架构、P2P架构 

自己注：以上原则，实际使用中也要注意取舍，比如依赖反转，门店装修以前就是依赖接口，但是很影响效率。

四、怎么描述你的架构设计？

4.1 架构描述的意义

①、梳理思路

架构是系统实现的蓝图。

有没有这种情况，画图前脑海中有一张清晰的图。但是实际开始画，这张图却又很模糊。画图的过程也是思考细化的过程。

②、方便沟通

架构是沟通协作的基础，不写下来其他人就看不到，那就失去了沟通和传播的唯一载体。

一图胜千言。

向上汇报，方便上级了解架构

向下传达，方便组内人员了解分工与边界。

横向沟通：明确自己的产品边界和技术边界，帮助不了解你产品的人快速的建立对你产品结构、功能、技术的认知。

③、防止遗忘

好记性不如烂笔头

每个系统都有架构，但不是每个系统都有足够好的架构描述。

4.2 架构描述的方式

①、文字Text

精确、详尽、编写方便、易于版本管理

②、图

直观、形象、表达能力强、一图胜千言

图文并茂：小孩子才做选择题，理想的架构图是图文并茂的。如果时间不充足，则考虑投入产出比（ROI），优先选择画图。

4.3  为什么你应该优先画图？

ROI is your friend — 不求多，但求精，尽量用最少的笔墨表达出最核心的内容。

从内容上说，ROI高的部分一般是偏顶层的整体架构或最核心的关键链路。

从形式上说，图是ROI更高的选择。

4.4 为什么你需要学习画图？

        要想制得一手既漂亮又可读的好图，还是需要经过持续学习与刻意练习的，很难仅凭直觉和悟性就能掌握其中的关键要领。

4.5 架构制图的目标

       工具是人类进化的阶梯，但如果理解和利用不当，则很容易反过来被工具所限制甚至奴役，忘了最初发明和使用工具的初心。对于架构制图而言，已经有那么多形形色色的方法与工具，使用它们的初心是什么呢？我认为本质上都是想把制图这个过程从一门自由的手艺变成一项科学的工程：系统、严谨、完整、标准化，同时能做到可重复、可持续和高效。

4.6 可以没有架构图吗？

可以。小规模系统可以没有架构图；很多老系统也没有架构图；新系统也可以没有、只要能说清，但是最好有。

4.7 什么时候画架构图？(When)

1、复杂项目架构设计时画架构图。

2、老的复杂项目进行维护改造时，这时候的架构图方便了解以前架构思路，在此基础上规划之后的架构。

3、空闲时。有时间了就画架构图，加深对系统的理解、方便发现问题。

五、架构制图方法与工具

本章节具体列举和描述一些典型的架构制图方法与工具

5.1 方法一、UML

• 结构图（Structural Diagrams）：通过对象、属性、操作和关系等方式，强调系统的静态结构，其中最常见的类型包括类图（Class Diagram）、组件图（Component Diagram）和部署图（Deployment Diagram）；
• 行为图（Behavioral Diagrams）：通过展示对象之间的协作关系以及对象内部的状态改变，强调系统的动态行为，其中最常见的类型包括用例图（Use Case Diagram）、活动图（Activity Diagram）、时序图（Sequence Diagram）和状态机图（State Machine Diagram）。

5.2 方法二、4+1 View Model

架构需要通过多种视图来描述，而这些视图是来源于不同项目干系人的视点（角度）；只有这样才能产生一整套全面、立体且客观的架构描述。

4+1视图的特点：

• 可以管理系统复杂性
• 可以关注系统的特定方面
• 方便和利益相关者进行交流

• 逻辑视图（Logical view）：描述系统为终端用户提供的功能，一般会通过UML中的类图和状态图来表示；
• 过程视图（Process view）：描述系统的动态行为，包括流程和交互等，一般会通过 UML 中的时序图、活动图和通讯图来表示；
• 开发视图（Development view）：从程序员的视角来阐述系统，也被称为“实现视图”，一般会通过 UML 中的组件图和包图来表示；
• 物理视图（Physical view）：从系统工程师的角度来描述系统，包括系统组件的物理拓扑、各组件之间的物理连接，也被称为“部署视图”，一般会通过 UML 中的部署图来表示；
• 场景（Scenarios）：通过一小组用例或场景来描述架构，包括系统中各种对象和进程之间的交互时序，也被称为“用例视图”。这些场景会被用于识别架构元素（architectural elements）以及阐述和验证整个架构设计，也可以被作为架构原型的测试起点。

5.3 C4 Model

C4 模型通过容器、组件、代码以及人这几个抽象来描述一个软件系统的静态结构，它的核心理念是希望像 Google Map 一样，通过不同层次的细节，为代码建立一种可以放大和缩小的导览图。它最关键的思想就是自顶向下对系统的静态结构进行逐级拆分，依次描述各层次对象的职责、关系和外部依赖。除了核心的层次化静态结构视图，它还可以包含动态视图、部署视图等补充视图。

 5.4 架构域的分类（TOGAF）

Togaf：The Open Group Architecture Framework，由国际标准权威组织The Open Group制定。对外系统的培训。

       为了做出清晰的、简化的架构描述，Togaf对架构做如下分类：业务架构、应用架构、数据架构、技术架构。

        首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。

5.4.1 业务架构（多种图）

一切系统设计原则都要以解决业务问题为最终目标。

业务架构：经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。

说明此产品解决什么问题（问题域）、用来解决谁的问题（产品用户）、如何解决这些问题（产品有哪些模块）

一种好的产品架构图，应该具备以下特点：

• 清晰的模块功能边界
• 功能经过抽象，做到标准化、互相独立
• 上下游产品功能边界清晰，架构分层明确合理，具备迭代优化的能力

5.4.2 应用架构

目标：定义支持业务和处理数据需要哪些应用系统。

应用架构是要说明支撑产品架构需要哪些应用系统，应用系统间是如何集成的，这就是应用架构或应用集成架构。（很像商家组层面画的架构图）

应用架构在产品架构的基础上考虑两件事：

• 子系统间的关系
• 考虑将客服用的组件或模块下沉，下沉到平台层。

        分布式应用架构图实质是产品内部所有应用在分布式环境下的调用关系。应用架构图的重点是体现应用之间的逻辑关系和通信关系，体现产品内部关系和外部关系。将产品的内外关系呈现在应用架构中，产品在整个业务中的定位和影响将变得清晰。

5.4.3 数据架构

数据架构解决三个问题：

• 1、系统需要什么样的数据？
• 2、如何存储这些数据？
• 3、如何进行数据架构设计（与下图不同，但是更准确）

数据架构重要的输出是数据-实体关系图，简称 ER 图。ER 图中包含了实体（数据对象）、关系和属性 3 种基本成分。

5.4.4 技术架构

         应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是承接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。   

        技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架选择、语言选择（这里以 JAVA 语言为主）、涉及到各自非功能性需求的技术点（安全、性能、大数据）。

        技术架构图是将系统的技术方案、技术选型通过视图的方式进行展现。技术架构图分为两类：

• 功能需求技术架构图（逻辑架构图），是描绘如何通过技术组件来实现系统产品功能的图。
• 非功能需求技术架构图（物理架构图），是描绘如何通过物理部署的来实现系统运行的图。

]

六、如何画架构图(How)

架构图也属于沟通的一种形式，所以要明确①、画图给谁看？②、给TA看什么？③、如何表达出想表达的意思？

6.1 画图给谁看&给TA看什么

        找准你制图的受众（audience）以及他们各自的关注点（concern）。常见的一些受众和关注点可包括：

• 研发：一般会关注很多实现相关细节，比如技术选型、实现可行性、可维护性等，毕竟他们是架构的最直接消费者；
• 运维：不太关心应用内的具体技术实现（当成黑盒），但很关心各个应用实例的物理部署方式、网络连通性、可运维性等；
• 安全：只关注系统是否有安全风险，例如是否可能被注入恶意代码、是否有权限漏洞等；如果经历过安全评审，应该很有体感；
• 产品：大部分情况下只关心项目能否按期上线，其他方面...可能表面上表示些许关心，实际上要么并不在乎要么真的不懂。

6.2 如何画

6.2.1 确定评判标准

• 准确（accurate）：错的图比没有图还糟糕；即使一开始是准确的，后面也需要定期更新校对；
• 完整（complete）：需要覆盖架构的核心要素和关键信息，为受众呈现一个没有残缺的完整架构设计；
• 清晰（clear）：制图时最好带上图例（形状、颜色、线型、箭头）；用图描述不清的地方，还可以加上文字标注做补充；
• 一致（consistent）：比如同一类型的图，最好使用相同的记号风格，以降低受众的理解成本；不一致往往还会带来混淆；
• 简洁（consise）：在满足以上 4 点基础之上，还需要让图更加简洁，一方面是更容易被人接受（没人读 = 没写)，另一方面更新维护成本也更低。

6.2.3 自顶向下、逐层细化

所有复杂系统都是层次化的。

自定向下沟通更符合人类的思维逻辑。

合理运用层次化（hierarchical）自顶向下逐层描述，蕴含了两个普适的原理：

• 分而治之：软件领域中，分而治之是控制和应对复杂系统的最有效方法。而层次化拆分，本质上就是一种分而治之手段：将系统按照从粗到细的粒度，一级一级地拆分成多个相对独立和低耦合的元素（子系统、应用、组件等）；
• 金字塔原理：这本书的核心观点就是，按照自顶向下的方式，先抛出主观点再依次用各个子观点去论证。这样的沟通方式更符合人类的思维逻辑，也更容易让读者接受。简单来说，就是要“先说重点”，帮助读者做归纳总结和划重点，而不是先抛出一大堆细枝末节的零散东西让读者自己去消化和推演。

6.2.3 使用多种架构视图

        作为现实世界的映射，软件系统也是多维和立体的，只用单一视图不可能覆盖所有关键的架构信息；即使强行把这些信息都塞在一张图里，那也一定会复杂到让人无法理解。

在架构设计领域，架构视图（architectural view）有专门的定义：针对系统架构某一个方面（aspect）的一种描述；每个视图都会覆盖项目干系人的一种或多种关注点。从上述定义可以看出来，不同的架构视图会有不同的侧重点，同时在描述自己所专注的方面时也会略去与当前视图无关的其他细节 —— 这其实也是一种与层次化拆分类似的分而治之思想，只不过这里是针对完整系统的维度分解，而层次化则是针对某一具体视图再做自顶向下的垂直下钻（drill-down）；两者是正交且可以相互配合的，例如前面说到的结构视图、部署视图甚至动态视图，都可以分别再进行层次化拆分。

6.2.4 标杆学习、遵循最佳实践

七、架构演进落地的关键点

        系统架构的演进过程，其实就是一个不断取舍/平衡的过程，要实际落地的话，会有三个关键问题需要处理，那就是业务、技术、团队协作之间这三者的平衡。

        业务，指的是实际业务场景与业务迭代诉求；技术，指的是技术选型与制定的技术方案；团队协作，指的是技术团队内部之间（基础架构团队、运维团队、业务开发团队等）、跨部门团队之间的沟通与协作。如果这三者之间的关系没有处理/协调好的话，就会出现一个严重的问题，那就是技术方案都制定/预研完成了，结果实际推广落地时，却很难推进，甚至因长时间推不动而最终不了了之。（实际工作中，技术架构的落地，除了技术本身的问题，人的问题往往更难搞）

八、架构师

名	图	是啥	精简理解
系统架构设计师		软考了解一下？ 全国计算机技术与软件专业技术资格（水平）考试 以考代评，高级职称 btw：软考和等考的区别	to啥：G 在校计算机系大学生闲着没事儿可以考考玩儿，证多不压身； 政府机关国企单位体制内人士为了职称应该考下，升职加薪、职称福利、积分落户。
TOGAF， 企业架构师		企业IT化架构方法论 国际认证和培训 提供一套流程和工具 我司IPU中TOGAF课程	to啥：B 可以作为进入世界500强外企的敲门砖； 在传统软件开发企业中，看CMMI等级和TOGAF人数； 忽悠产业信息化企业老板可能有用，在信息产业化类企业中
MTTC， 美团技术委员会		MTTC官方主页 MTTC章程	to啥：C、P 技术人才发展，包含技术人才引入、技术人才培养、技术人才职级评定； 技术方向和问题的讨论和达成共识，技术标准制定； 技术品牌建设

《软件架构师的 12 项修炼》一书中，有三个人文领域核心观点：

软技能比硬技能难：新手搞定事，老手搞定人。搞定事需要智商+勤奋，搞定人需要情商+阅历。特殊强调的是：老手都是从新手成长而来的，所以老手码农是成为架构师的必要不充分条件。

注重关系重于谁对谁错：思考下「微观经济学和宏观经济学」、「量子物理、经典物理、宇宙物理」。都是视角不同的例子。高一个视角看待就不是对与错的问题了，往往是「局部最优 | 全局最优」的效率度量与选择问题。

架构的政治性：大家不要对这两个字有偏见，有人的地方就有江湖，江湖=政治。政治是协调多团体整体决策的过程，是与他人协作并搞定事情的艺术。

我司对架构师的要求：广度、高度、深度、宽度

广度	广度指的是架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要很深入的了解，但必须知道每种技术的3W： 1，Why：每种技术的由来，为什么会出现这种技术，这个技术是用来解决什么问题的？ 2，What：每种技术是什么？技术的基本组成部分是什么？ 3，Which：解决同一问题的相同技术各自的优缺点是什么，更适合哪种场景？比如，ORM框架（Hibernate与IBatis），MVC框架（Struts与SpringMVC），大数据技术（Hadoop与Spark）它们各自的优缺点是什么，只有清晰认识同一类型技术的优缺点，才能在技术选型时能够使用更加合理的技术。广度的学习方法：对各主流技术一一通过搜索引擎了解其3W的内容。
高度	高度指的是架构师应具备对客观事物的“拔高”能力，能够从纷繁杂乱的信息中建立秩序，也就是我们一般所说的抽象能力。抽象能力包括： 1，业务抽象：能够软件和产品的复杂的需求中抽象核心业务实体，并给各业务实体建立合理的关系； 2，技术抽象：能够对复杂的技术架构进行分层抽象、服务抽象（微服务抽象）、组件抽象，并为各层和各服务之间的调用建立合理的“关系”；高度的学习方法：深入理解和学习面向对象、设计模式，琢磨优秀开源框架的设计原理和设计思想。
深度	深度指的是架构师能对主流技术有较为深入的理解，主要包括： 1，可以不了解源代码，但对主流技术的原理，运作机理有一个基本的理解； 2，至少对一种技术有深入的认识，是这种技术的专家，熟悉其源代码。 以上2点，1为必须，2为非必须深度的学习方法：上文已说。
宽度	宽度指的是架构师能够熟知当前的技术前沿和热点，能够使用新的技术解决问题。比如，微服务、大数据、云计算、人工智能等。宽度的学习方法：可以使用手机订阅相关的技术资讯了解，定期了解即可，对于跟所负责工作相关的技术进行进一步的了解。

结论：

广度决定了系统架构技术选型的合理性；

高度决定了系统架构设计的合理性；

深度决定了系统架构的优化能力；

宽度决定了系统架构的领先性，不至于三五年被淘汰

 参考文章之一：架构制图：工具与方法论-阿里云开发者社区