文章目录
- 一、架构设计要素
- 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 | 功能性需求 | 功能具体描述 |
---|---|---|
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、如果给甲方做应用,还会出服务模型,服务能承载多少流量、什么服务器、部署方式、成本优势等等。