潍坊专业网站制作公司营销,陕西建设厅官网首页,济南seo怎么优化,wordpress主题底部文章目录 一、架构设计要素1、架构设计目标2、架构设计模式#xff08;1#xff09;分而治之#xff08;2#xff09;迭代式设计 3、架构设计的输入#xff08;1#xff09;概览#xff08;2#xff09;功能需求 - WH分析法#xff08;3#xff09;质量 - “怎么”分… 文章目录 一、架构设计要素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整体架构草图 - AOD5模块关系图6模块细化 - 思路7模块细化 - 鲁棒图8模块细化 - 时序图9模块映射 4、运行性模型1运行关注点2单元分解 - 分而治之的最高境界3实战部署单元拆解4运行性模型的思路5实战应用逻辑运行图ALOM6实战逻辑运行图LOM图7实战物理运行图POM 5、架构资产复用6、架构决策7、架构验证1架构验证与评估过程2架构验证工件 - RAID 8、架构设计的误区1实例12实例23实例34实例4 三、动手绘制架构图1、业务需求2、系统上下文System Context3、用例模型Use Case Model4、需求矩阵Requirements Matrix5、非功能性需求矩阵Non-Functional Requirement6、整体架构草图Architecture Overview7、逻辑架构视图1模块关系图2时序图 8、数据架构视图1ER图 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过程这就是功能视角。 如果考虑跨机房分布式部署这就是运行视角。 最后决定用SpringBootMongoDB自研这就是逻辑视角。 如果用阿里云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、数据架构视图
1ER图
ER图既是类图也是数据库图也是我们整个数据架构的核心图。
传统方式 推荐方式
9、运行架构视图
1运行部署单元
把所有功能模块进行进一步的分解分解成一个个的可部署的单元。 2应用逻辑运行模型 3逻辑运行模型 4物理运行模型
单机房 高可用物理运行模型
10、总结
1、明确公司业务战略明确业务需求和非业务需求。 2、了解行业标准、限制和质量要求。 3、搞明白公司目前IT状态和架构状况。已有的架构图、设计文档、资产 3、产出系统上下文。 4、产出用例模型。 5、找出公司/业内的所有资产将狗资产、方法论的资产输入到整个架构设计的环节中。 6、进一步分析非功能性需求。可靠性、安全性、扩展性等并落地需求矩阵。 7、以上所有内容作为输入形成整体架构草图。 8、架构草图细化为功能模块图、多场景时序图。 9、数据架构视图落地。 10、运行性模型落地。 11、进行架构决策。 12、进行架构验证评估。 13、如果给甲方做应用还会出服务模型服务能承载多少流量、什么服务器、部署方式、成本优势等等。
