@[TOC]

一、架构设计要素

1、架构设计目标

目标：Do the right thing right，做正确的事，并且将它做对。

艺术家：艺术家的设计，通常是灵感突然一下子冒发出来，设计一款产品。其他人也许对这个产品有着不同的眼光、不同的看法，并不会被大众所认同，并且过几年后，艺术家再回过头来看当初的产品，有时候也会忘记或者无法理解当初是为什么这么设计的。

但是在IT领域，“艺术家”这种设计是行不通的，IT领域人员变动快，当你的思想无法传达给别人的时候，就会阻碍实际的项目落地。所以，把对的事情做对，就需要我们用匠人的思路，严格的要求产品质量，同时，设计出普适的、能广泛使用的、能广泛推广的架构设计。

2、架构设计模式

（1）分而治之

当一个需求没法实现的时候，我们还是贯穿我们整个架构设计的目标，当需求满足不了的时候，我们就分解它，分解到一定的力度，刚好能有一个产品来实现，或者有一套开源方案来实现，或者其他实现方式，这个时候就可以了。

但是分解的过程是适可而止的，分解的模块尽量使用商业化或者开源的方案来实现，实在不行就通过定制化的方法，通过少量的编程来实现。

就是在整个设计的过程中，一旦有无法实现的需求就进行切分，一直分到自己恰好能够实现位置，就不用再细分了。

（2）迭代式设计

架构设计最终完成之后，需要重新再去了解新的需求，不停的迭代你的设计，功能需求不停的去完善，把系统做的越来越好。

3、架构设计的输入

（1）概览

需要解决的目标：功能性需求。

实现的自由度：各种限制。

要做到什么程度：安全程度、可用性、扩展性、伸缩性等质量因素。

现有的手段：资产和技术。

（2）功能需求 - WH分析法

Who、Which、What、How；不要关心实现细节，而是要关心用户体验。

比如说宠物管理系统， Who：宠物管理员、店员、店长、宠物。这些都是系统的用户。 Which：对接的用户或者系统。 What：系统要做什么，比如给猫喂食、洗澡等动作。 How：功能互动，给猫喂食的细节等等。

（3）质量 - “怎么”分析法

怎么安全、怎么快、怎么稳定、怎么方便、怎么厉害……

比如运行时质量要求：支撑10万QPS、1万TPS、延时<1S

比如准备时质量要求：1分钟内可以扩展到10000节点。

所有质量通常结合功能需求的What来描述，对于不同的案例、功能，会提出不同的质量要求，所以通常每一个质量或挂在一个功能需求或者挂在一个系统需求上。

（4）限制 - 三角形分析法

范围、时间、资源。

业务、技术、法规。

4、架构设计的输出

（1）架构规划

任何一个架构师都是具有项目管理能力的，怎样去规划架构设计的一个个环节（开发测试、落地），也是架构师的一种要的职责。 通常用关系图、燃尽图。

（2）研发设计

架构设计图、架构设计文档都是在这一个环节产生的。

通过不同的视角，画出架构图。

（3）测试方案

架构师要考虑如何进行测试和验证。

（4）部署方案

把我们设计的代码和系统真正部署到环境中。

物理架构：服务器、网络、机房、云平台。 非功能性实现：容灾、多活、单元化、CDN缓存。 发布流程：应用、数据、网络、CI/CD。

（5）采购目标

一个大项目，通常不是简单的一个部门或者两个部门就能完成的，它必然牵扯到部门与部门之间，公司与公司之间，甚至有可能需要第三方的、外包的公司。

RFP招标需求的指定，必须由架构师来指定，它会指引如何来进行我们产品的验证。

二、架构设计方法论和思维

1、需求分析

（1）概述

需求是贯穿整个研发、架构设计生命周期的。

以下是架构的V型图，从左往右是从业务需求到架构设计，最底下是产品开发到逐层的功能验证。

当一个需求完成以后，我们会有新的需求进行迭代，然后不断地循环这个过程。

（2）实战：系统上下文

这张图，用来描述我要做的系统到底在做什么？跟哪些用户、哪些外围系统打交道？

如下如，例如我们的宠物寄存小屋系统，跟客户、宠物保姆、猫进行交互，并且后台跟供水供电、垃圾箱系统等外围系统进行交互。

（3）实战：用例模型

通过一张图或者一堆图加一堆文字，描述出这个系统里面具体做的“What”是什么？跟“Which”和“Who”又是怎样交互的？它们的实际交互内容又是什么？

系统上下文描述的是系统跟它外面的系统和用户之间的关系，而用例模型描述的是功能性需求，外围系统和用户还有系统之间打了哪些交道。

（4）实战：质量和限制

用word或者excel来展现，用描述性的语句描述出我们希望达到什么样的性能、高可用、可扩展、弹性伸缩、资金问题、时间问题、企业问题、监管要求等等。

质量需求：管理10个小动物、进行分割管理；洗澡水1分钟内完成；成本小于1000元……

2、核心方法论：架构立方体

（1）应用和技术

应用：这个视角是指你的代码是用什么样的语言开发，做了什么样的功能。

技术：支撑业务的基础架构（中间件、数据库、AAA等）跟业务本身无关系的技术视角。

比如说：开发一个商品中心，这就是应用。要为这个商品中心搭建一个商品库，这就是技术。

（2）功能和运行（重点）

功能：Who、How、What，将用例模型里面的所有问题实现，这就是功能视角。

运行视角：Where、When，什么时候运行，在哪运行。

比如说：开发商品信息CRUD功能，这就是功能视角。使用单元化、分布式部署运行，这就是运行视角。

（3）逻辑和物理

逻辑：技术定型、产品未定型。逻辑方案定型，但是还没有具体的产品。

物理：产品定型。现有产品。

比如说：OpenID身份认证系统（逻辑）、腾讯认证平台（物理）。

（4）多视角模型

以数据服务为例， 如果考虑它的使用场景，是给商品中心用还是用户中心用，这就是应用视角。 如果考虑用的是NoSQL数据库还是关系型数据库，这就是技术视角。 如果关注它的CRUD过程，这就是功能视角。 如果考虑跨机房分布式部署，这就是运行视角。 最后决定用SpringBoot+MongoDB自研，这就是逻辑视角。 如果用阿里云SDK+云数据库，这就是物理视角。

（5）需求驱动

大部分模型的重点，是功能性和运行性模型，需要把三种不同的需求用例模型产生的功能型需求、质量产生的非功能性需求和限制产生的非功能性需求，映射到这两大模型上。

大部分架构师都会将用例模型的功能性需求，映射到功能性模型上；质量和限制映射到运行性模型上。 而更优秀的架构师更是能综合分析，统一考虑进去。

3、功能性模型

（1）模块内聚

模块内聚性，应该高内聚，模块独立性应该更强。

（2）模块间耦合

模块间耦合应该低，并且独立性强。实现高内聚，低耦合。

（3）模块划分粒度

在架构设计里面，通常是设计复杂性架构，所以不适合设计的太细，大概到子域级别就可以，然后子域中的内容可以再划分为几个微服务。

（4）整体架构草图 - AOD

AOD草图第一次画的时候尽量快，尽量方便，任何画法任何工具都可以。

从左往右依次为，展现层、后台服务、记录交易处理层、传统系统的对接层。 从上到下依次为，用户层、应用层、网络层、中间件层、数据库层。

（5）模块关系图

模块关系图如图所示，《use》表示调用关系，《component》表示一个个的模块，在整个过程中，要考虑数据层、应用层、接口层等等一些层次化的关系，带着层次、子系统，把整个模块关系图画清楚。

（6）模块细化 - 思路

输入：用例模型。 中间过程：鲁棒图、实体关系ER图。 输出：时序图/模块交互图（模块的交互、行为的先后）

如果每一个用例模型，能够很方便的用时序图对组件的交互进行展现，那就完全可以跳过鲁棒图、ER图的阶段，直接进行功能模块的设计和开发。

（7）模块细化 - 鲁棒图

鲁棒图展现的结果跟功能模块关系图类似，但这个过程细节度不够，所以不建议所有的架构设计都涉及鲁棒图。 当你是在没有办法进入下一阶段，才可以用鲁棒图来进行一些衍生，否则就是浪费时间。

（8）模块细化 - 时序图

常用组件：

上图和下图哪一种更好？ 答：上图更好。因为下图增加了目录服务与数据服务的耦合，很多时候并联优于串联，但是具体场景具体分析。

（9）模块映射

功能性模型首先要定义，通过静态图定义出模块和模块之间的关系，然后进行模块时序图的描述实现模块的互动，然后就要进行模块映射了。

模块映射首先考虑购买，如果不能购买，可以选择自己搭建。

4、运行性模型

（1）运行关注点

系统监控、容量规划、可用性、安全性、性能、扩展性等等。

组织架构、服务治理、外包与采购、软件包和产品选择。

（2）单元分解 - 分而治之的最高境界

展现单元：跟用户的展现、用户的交互相关。 执行单元：跟实际的业务逻辑相关。 数据单元：跟数据的存放、管理相关。 安装单元：模块、数据的安装相关。

（3）实战：部署单元拆解

（4）运行性模型的思路

1、准备好DU部署单元。 2、将部署单元安装到合适的位置：地理位置、节点位置。 3、更换视角，调整组合方式（应用、技术、逻辑、物理视角，参考上面的架构立方体）。

（5）实战：应用逻辑运行图（ALOM）

定义场景和边界之后，摆放节点（部署单元），将节点通过网络连接起来。

（6）实战：逻辑运行图（LOM图）

把所有非功能性的内容加上去（质量、限制），通常会影响支撑平台（中间件）。 比如为了提高快速响应能力，提高稳定性，我们需要有一些监控手段、数据备份手段，为了实现高性能还会加缓存、做服务的拆解等等。 所以，我们的节点需要额外增加一些运维、管理工具，这些工具也应该在我们的LOM图中展现。

如下图，这样一个节点就从原来的应用逻辑节点，变成了一个应用加技术的，完整的逻辑节点。

（7）实战：物理运行图（POM）

确定软硬件产品的选型，确认软硬件规格和数量，关注节点和网路。

用户 - 网络（多运营商加速） - 防火墙 - 安全 - 路由器 - 负载均衡 - 应用服务器 - 负载均衡 - 数据库服务器。（此处省略了部分连线）

5、架构资产复用

方法资产： 架构基本原则（策略、规定，比如单一职责、开闭、依赖倒置等）。 架构模式（模板、风格，比如数据流风格，管道过滤器风格，调用返回风格，独立构建风格，虚拟机风格等）。 架构框架（框架、方法论）。 选用一种模式，自然也会有这种模式的架构参考标准，很方便的进行一些方法论的堆叠、衍生、改进来帮助我们进行架构设计。

工件资产： 软件（库、开源源码）。 工具（IDE、CICD工具，简化发布、部署过程）。 架构（参考架构、架构积木，比如架构参考图）。 用好资产，可以实现项目加速，用好避坑指南，也可以减少意见冲突，

6、架构决策

7、架构验证

（1）架构验证与评估过程

JAD联合架构设计：比较亲和的设计方法，会有产品经理、研发、运维等相关人员，配合起来反复来看架构师的前期设计，从开始到最后一直在关注着你。

ARB架构评审会：有些大企业会设立架构组，会成立一个评审会，每一段时间都会进行评审，反复在“挑刺”。要做到防止出现一些架构漏洞。

推荐使用第一种方式，如果项目比较大，也没必要从头到尾使用ARB的方式，可以在关键节点进行一些审核。

同时，单元测试、集成测试、系统测试、用户验收测试，一起完成架构的验证与评估。

（2）架构验证工件 - RAID

风险：已知风险是否缓解或规避，发现新的风险并考虑解决方案。

假设：前提假设是否正确，引入新的假设条件。（比如依赖于xxx资金，依赖于xxx原则，假设不成立会有可能导致项目失败）

问题：影响项目进展的问题，影响产品验收的问题。

依赖：业务和应用依赖，IT技术依赖。（需要减少依赖，服务a依赖于服务b，需要保证前置依赖不影响当前服务或熔断机制，或者增加一些反腐层来提前处理）

8、架构设计的误区

（1）实例1

下图设计的架构图，我们发现有两个问题： 误区一：只关注功能性需求，忽略非功能性需求。（质量、限制、网络、节点的联通、部署） 误区二：设计太围观，架构设计文档信息过度，没有高屋建瓴的总体架构图。（比如架构草图、网络框架图、总体需求总框图、系统上下文图）

架构设计通常是总分总或者总分的，先有总体设计，再有细节设计，如果只有细节设计，可能缺乏高屋建瓴的抽象设计。

（2）实例2

误区三：忽略关注点分离，X/Y/Z轴观点混杂。（有CDN、负载均衡器，看起来像是物理运行模型图，但是没有服务器、容器；又多了APP的名称、商城、订单、支付、用户等应该出现在组件图的东西）

（3）实例3

误区四：冷门技术（不容易找到替代品，不适合交流）、过度设计（设计的很精美，很难进行优化和迭代，无法应对多变的需求）、不适合未来需求变更和架构迭代。

（4）实例4

误区五：专注擅长的技术栈，忽略其他潜在选项。（比如说只考虑用自己擅长的哪些技术来实现，而忽略了用户的真实需求。这就要求我们在学习的过程中，学会更多的不同技术，根据用户的需求进行架构的选择）

三、动手绘制架构图

1、业务需求

一个点播公司：

利用当今热点技术（分布式、NoSQL、对象存储技术等）； 建立一个数字化、网络化、自动化、高效率的节目制作、采、编、播、存、管、发布一体化系统； 打造一个全方位的音视频资料服务的业务平台。

将原有的收录系统、转码系统、迁移系统、检索系统等相关渠道的有效整合。 解决多媒体数据资料的数字化存储、编目管理、检索查询、素材转码、资料发布等问题。 采用新的业务流取代已有工作模式和操作模式，从而满足各种新的业务需要。

2、系统上下文（System Context）

系统上下文图把整个系统当成一个黑盒，看一下系统跟哪些用户打交道、跟哪些外围系统进行对接的、中间传输的是什么样的内容。 只有明确了我们的系统谁在用，大概怎么用，我们才会进一步去分析它具体有什么样的功能。

3、用例模型（Use Case Model）

用例模型就是把系统上下文中的关键系统（媒资管理系统）展开，变成一个一个的功能，这些功能不是独立运行，必然是跟外部用户、系统对接。

我们以媒资管理员这个用户为例，实现用例模型。

用例模型需要表达清晰，通常会使用表格的形式，使用图文进行详细描述： 真正的一个文档可能会有几十个用例、四五十页的用例描述，此处只是做简单举例。

4、需求矩阵（Requirements Matrix）

需求矩阵用来进行架构验证。 需求矩阵有两大工件，一个叫功能性需求矩阵，一个叫非功能性需求矩阵。

ID	功能性需求	功能具体描述
FR01	API标准化	数据上传、迁移、下载、编目、搜索功能需要支持API接口，能完整的通过API进行调度、管理和控制
FR01	自动化编目、索引和检索	所有参与编辑的岗位都可以通过快速的上传快编、非编检索等虚拟化或自动化的形式，把海量的信息归档为中英文xml、doc的形式，并且和我们的实际内容进行一一绑定，能提供高效、全面、智能检索。
FR03	非结构化编目、索引和检索	……

需求矩阵其实就是用商业的话描述，不需要描述的很详细，但是能够满足所有的商业用户，还需要尽可能的转换成it人员也能看懂的描述语。

5、非功能性需求矩阵（Non-Functional Requirement）

ID	非功能性需求	功能具体描述
NFR01	安全性	所有的内容都需要支持用户认证授权、所有数据需要加密传输，采用零信任模型
NFR02	可靠性	网络抖动需要在秒级进行处理，采用集群、热备、容灾等等
NFR003	先进性	采用符合未来趋势的数据存储、业务管理方式，并且领先xxx三到五年的技术水平

6、整体架构草图（Architecture Overview）

偏用户交互的： 偏逻辑层次的： 这张图会为我们后面的组件关系图打好基础，因为是整体架构草图，每个人可以根据自己的风格进行绘画。

7、逻辑架构视图

架构草图和逻辑架构图的关系是总分的关系，总体来看的概括就是架构草图，细分成每一个模块就是逻辑架构图了。 逻辑架构图里面，是静（模块关系图）和动（时序图，又称模块交互图）的关系。

（1）模块关系图

有些严格分层的项目中是不允许出现跨层次调用的，但是很多项目经常能看到跨层次调用的影子。所以我们可以这样理解，如果出现了大量的跨层次调用，那就有可能这两层并不是严格意义上的上下层关系（例如图中的存储层），可以横着画也可以纵着画，但是尽量不要有回环（一旦出现回环，可以用接口/依赖反转/稳定依赖的技术，把回环打破）。

下图部分模块间省略虚线箭头和use标志：

（2）时序图

时序图动态的展现了模块之间的交互，从架构草图到模块关系图再到时序图，由总到分，由静到动，先抽象后详细，全方位的展现架构的设计。 用户上传数据时序图： 用户下载数据时序图：

8、数据架构视图

（1）ER图

ER图既是类图，也是数据库图，也是我们整个数据架构的核心图。

传统方式： 推荐方式：

9、运行架构视图

（1）运行部署单元

把所有功能模块进行进一步的分解，分解成一个个的可部署的单元。

（2）应用逻辑运行模型

（3）逻辑运行模型

（4）物理运行模型

单机房： 高可用物理运行模型：

10、总结

1、明确公司业务战略，明确业务需求和非业务需求。 2、了解行业标准、限制和质量要求。 3、搞明白公司目前IT状态和架构状况。（已有的架构图、设计文档、资产） 3、产出系统上下文。 4、产出用例模型。 5、找出公司/业内的所有资产（将狗资产、方法论的资产），输入到整个架构设计的环节中。 6、进一步分析非功能性需求。（可靠性、安全性、扩展性等）并落地需求矩阵。 7、以上所有内容作为输入，形成整体架构草图。 8、架构草图细化为功能模块图、多场景时序图。 9、数据架构视图落地。 10、运行性模型落地。 11、进行架构决策。 12、进行架构验证评估。 13、如果给甲方做应用，还会出服务模型，服务能承载多少流量、什么服务器、部署方式、成本优势等等。