文章目录

  • 一、架构设计要素
    • 1、架构设计目标
    • 2、架构设计模式
      • (1)分而治之
      • (2)迭代式设计
    • 3、架构设计的输入
      • (1)概览
      • (2)功能需求 – WH分析法
      • (3)质量 – “怎么”分析法
      • (4)限制 – 三角形分析法
    • 4、架构设计的输出
      • (1)架构规划
      • (2)研发设计
      • (3)测试方案
      • (4)部署方案
      • (5)采购目标
  • 二、架构设计方法论和思维
    • 1、需求分析
      • (1)概述
      • (2)实战:系统上下文
      • (3)实战:用例模型
      • (4)实战:质量和限制
    • 2、核心方法论:架构立方体
      • (1)应用和技术
      • (2)功能和运行(重点)
      • (3)逻辑和物理
      • (4)多视角模型
      • (5)需求驱动
    • 3、功能性模型
      • (1)模块内聚
      • (2)模块间耦合
      • (3)模块划分粒度
      • (4)整体架构草图 – AOD
      • (5)模块关系图
      • (6)模块细化 – 思路
      • (7)模块细化 – 鲁棒图
      • (8)模块细化 – 时序图
      • (9)模块映射
    • 4、运行性模型
      • (1)运行关注点
      • (2)单元分解 – 分而治之的最高境界
      • (3)实战:部署单元拆解
      • (4)运行性模型的思路
      • (5)实战:应用逻辑运行图(ALOM)
      • (6)实战:逻辑运行图(LOM图)
      • (7)实战:物理运行图(POM)
    • 5、架构资产复用
    • 6、架构决策
    • 7、架构验证
      • (1)架构验证与评估过程
      • (2)架构验证工件 – RAID
    • 8、架构设计的误区
      • (1)实例1
      • (2)实例2
      • (3)实例3
      • (4)实例4
  • 三、动手绘制架构图
    • 1、业务需求
    • 2、系统上下文(System Context)
    • 3、用例模型(Use Case Model)
    • 4、需求矩阵(Requirements Matrix)
    • 5、非功能性需求矩阵(Non-Functional Requirement)
    • 6、整体架构草图(Architecture Overview)
    • 7、逻辑架构视图
      • (1)模块关系图
      • (2)时序图
    • 8、数据架构视图
      • (1)ER图
    • 9、运行架构视图
      • (1)运行部署单元
      • (2)应用逻辑运行模型
      • (3)逻辑运行模型
      • (4)物理运行模型
    • 10、总结

一、架构设计要素

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功能性需求功能具体描述
FR01API标准化数据上传、迁移、下载、编目、搜索功能需要支持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、如果给甲方做应用,还会出服务模型,服务能承载多少流量、什么服务器、部署方式、成本优势等等。