如何做好架构设计,架构设计有章可循吗?

原创
2023/12/05 18:00
阅读数 282

设计一个系统的过程,就是建造一座大厦的过程,架构设计的质量直接决定了大厦的质量。

我们进行系统的架构设计时,总是会遇到一系列的问题,比如一个大型系统的架构应该如何起步,从哪里开始设计?系统是否应该划分成多个模块,应该怎么划分模块才更加的合理?亦或是觉得产品提出的需求非常不合理,完全影响我们正常的架构设计!对于非功能性的需求,我们是否可以得过且过,不去重视?

这些问题,让我们在刚开始架构设计时手足无措,但是随着我们完成一个又一个的系统架构设计以后,发现架构设计是有章法可循的,只要我们学习这些章法和套路,并且在工作过程中不断的积累与沉淀,就会形成一个完整的架构设计方法论,面对新的大型系统架构设计,也会一步一步有节奏进行,最终完成整体的架构设计。


一、架构设计的原则

架构设计需要遵循一些原则:
1、架构设计需要方法体系
架构设计并不是一个”单一的方法“,直接拿来进行架构设计,而是多个各具特色的方法,组成的“方法体系”,并且这个体系随着新技术的发展还会不断进化。
2、架构设计是质疑驱动
架构设计是质疑驱动的过程,在”需求驱动“的基础上,我们需要不断的质疑我们架构设计的中间成果,进一步通过“质疑”,引入更多的“质量属性”及更多“功能场景”。
3、多阶段下的多视图
架构设计,是多阶段还是多视图?架构设计首先是“多阶段的”,我们将架构设计划分成多个阶段,在每个阶段中才会考虑”视图“这个维度。

架构设计的三个阶段

阶段一、 预备阶段
预备阶段的目标:全面理解需求,把握需求特点,确定架构设计驱动力。
在预备阶段,我们需要全面地梳理与理解需求,不放过任何一个需求细节。同时分析需求产生的各项质量属性与系统约束,同时兼顾这些约束进行架构设计,才能不遗漏重大的架构属性。
阶段二、 概念架构
概念架构,必须考虑包括功能、质量、约束在内的所有方面的需求。
阶段三、 细化架构
在细化架构阶段,我们从五个不同的角度出发,设计五个视图,完成整个系统全方位的设计。

架构设计的一个贯穿环节

对非功能需求的考虑 :非功能需求无法一蹴而就,因为在设计的过程当中,会有新的需求不断的被发现,即使设计完成,在开发阶段,都会有影响非功能需求的约束出现,所以在整个阶段,都应该注意非功能需求。


二、预备架构阶段分析

预备架构的最重要的目标,是建立需求大局观,把握需求特点,确定架构设计驱动力。 通过对需求的详细分析,有一个宏观的需求感知,同时还要兼顾系统的质量要求和约束对系统设计造成的制约条件。

需求结构化

需求是有结构的,而不是零散的需求点,只有将分析后的需求结构化,才能宏观的感知整个需求。可以借助ADMEMS二维矩阵,将架构影响因素,梳理脉络。
例如以下矩阵分析,将需求划分为多个维度,横向上从”广义功能“,”质量“,”约束“三个方面分析,广义功能是指需求需要满足的基本功能,及产品或业务人员的直接要求。质量维度则是系统设计时需要考虑的高并发,高可用,可拓展等技术设计维护,保证系统在满足基本需求的同时,同时对后续系统进化发展以及极端场景(例如:用户量激增,秒杀)等的满足。约束则是系统设计时的一些制约,例如上线日期,上线环境,开发人员技能水平等。纵向上划分为”业务级需求“,”用户级需求“,”开发级需求“三个维护,”业务级需求“是指产品或业务人员提出的基本要求,”用户级需求“则是从系统的使用用户角度出发,发现的例如用户电脑操作水平,用户使用习惯等潜在需求,而”开发级需求“,则是从研发人员角度出发,发现的例如可拓展,可测试,技术环境等不同维度的需求。
通过将需求结构化,我们可以全面地分析整体的需求,对需求进行整体的理解,同时也可以从不同的角度发现系统制约条件,在系统设计的最开始阶段就着手设计,防止遗漏重大约束导致架构设计失败。
分析约束影响
约束分析的几个方面:
1、来自产品或运营人员的约束性需求
  • 系统的非功能需求,例如:上线时间,预算,工期要求等
  • 业务领域 相关的限制,例如业务规则或业务限制,相关法律,专利等。
2、来自用户的约束性需求
  • 系统的用户,同样会产生约束性需求,比如用户的计算机水平,年龄段,使用偏好,国家等。
  • 例如用户计算机水平整体较弱的话,在开发交互方式时就不应太过复杂,同时要兼顾系统的鲁棒性,防止系统被用户搞挂。
  • 用户使 用产品时的外部环境同样可能产生约束条件,比如访问环境是内网或是外网,则决定了系统提供访问链接不同的网络权限。访问环境信号强度弱,则系统的性能要求则更高。
3、来自开发或运维人员的约束性需求
开发团队的技术水平,磨合程度,同样制约着系统的开发,如果开发人员均是高级研发人员且对当前技术栈有深入的了解,则开发进度就会更快,如果是新团队,且需要对技术栈进行学习才可以介入开发,则在工期或系统风险层面需要额外考虑。
4、业界当前技术环境
当前技术环境中间件的成熟程度,编程语言及流行度,优缺点等,都会对架构设计产生约束条件。
约束的分类:
1、直接约束
例如:系统运行于linux平台。
2、转换为功能需求的约束
对于这种约束,可以直接转换为功能需求
例如:供应商拥有自己的一套城市信息表  -> 引出的功能需求:需要进行城市转换
例如:供应商服务器性能差,tps最大10  ->  引出的功能需求:需要进行限流请求
3、转换为质量属性需求的约束
例如:系统使用者计算机水平不高
转换为质量属性:易用性(否则不会用),鲁棒性(系统被搞瘫)

确定关键质量

系统的关键质量是需要进行取舍的,需要确认业务人员更注重哪方面或在满足需求的基础上,确定哪些是必须的,哪些是可以适当忽略的。
我们需要首先确定架构重点支持哪些质量属性,然后对于相互矛盾的质量属性,进行权衡折中。例如当满足性能这个质量属性时,同时就会因为引入新的方案或组件,导致可维护性,可测试性降低;提高可拓展性时,就会对系统的性能和安全性产生影响等等,我们需要做的,就是在各个关键质量中进行取舍。
确定关键功能
确定关键功能的4个方面
1、核心功能
2、必做功能
3、高风险功能
4、独特功能        
其他常见系统不存在的功能
注意衍生需求:
从需求转入设计时,因方案制定过程的复杂,会产生大量的衍生需求,衍生需求是原始需求的数倍。
举例:
原始需求:定时拉取供应商数据。
衍生需求:
1、由于供应商数量较多,需要引入分布式定时任务,集群并发拉取
2、由于供应商数据量大,需要分库分表设计
3、需要快速搜索,引入存储引擎组件等等
 这些衍生需求我们必须要考虑,虽然业务需求没有体现,但却是架构设计的关键影响因素。
架构驱动力对比:
业务需求驱动架构:
 重大需求驱动架构:
由此可以看出,通过重大需求驱动的架构,更能考虑到更关键的部分,设计的架构更能满足需求的要求,架构设计成功的概率会更高。


三、概念架构阶段分析

概念架构阶段,对系统进行适当的分解,而不陷入细节
概念架构的过程是,先根据关键功能进行初步设计,然后对设计的系统进行高层分割,接下来考虑非功能性需求(关键质量和约束),然后修改自己的初步设计,循环往复,在不断的质疑和优化过程中,完善架构设计。
初步设计
初步设计的目标是发现职责,无需展开细节设计。基于关键功能,进行初步设计,基于主流程,关键流程,黄金流程等进行流转图设计,从而发现职责。

高层分割

切分复杂系统,为多个二级系统。或者直接切分为具体子系统。
高层分割的两种方式:
1、系统切分
切分的考虑点,包括系统功能、部署环境、语言、系统规模等
例如一个大型系统,切分为订单,商品,供应链等系统。
2、系统内切分
根据系统的职责、调用关系、通用性等,进行系统内部切分。
最常见的就是分层,例如一个系统,切分为网关层,服务层,搜索模块,man端等。
分层的角度
1、逻辑分层
逻辑分层重视职责的划分,职责直接常常是上层使用下层的关系,上层和下层,可以是分布在不同的机器,也可以分布在同一台机器。
2、物理分层
分布在不同机器上的软件单元。
3、通用性分层
通用性不同的,划分为不同的层,一般通用性越大,所处的层次越靠下。

考虑非功能需求

具体方法是:采用目标-场景-决策表,见下图:
架构设计是质疑驱动的,例如,质疑系统的可用性,考虑系统可能宕机,则引入集群部署设计,考虑下游接口可能超时或出现异常,则引入接口降级的设计等。
考虑场景的5个要素
1、影响来源,来自系统内部还是系统外部
2、如何影响的
3、受影响的对象
4、有什么问题或有什么价值
5、所处的环境为何
对场景的权衡因素:
价值,代价,开发难度,出现几率。对于某些场景,经过全面的权衡和思考,可以不支持,并不是所有的场景都要支持,否则可能存在过度设计。


四、细化架构阶段分析

逻辑视图

逻辑视图是对系统的不同部分职责的划分,根据职责不同,可以将系统进行细粒度的拆分,划分为多个子系统。
分层的细化
根据系统设计的需要,可以将系统的分层进行细化,例如展示层 -> 业务层 -> 数据层 可以细化为:展示层 -> 控制层 -> 接口层 -> 接口实现层 -> 数据层。 
分区的引入
分区的概念是业务流程相关的,分区的依据是:职责,比如结算流程可以作为一个分区,下单流程可以作为一个分区。将系统划分为多个分区,一方面可以支持并行开发,另一方面也将系统划分为多个子域,有利于业务概念和业务流程的收敛。
机制的提取
机制是指系统可以抽象的公共部分,例如公共工具,公共组件,公共流程等,提取这些公共部分,对于架构设计是至关重要的。
划分子系统的原则:
1、职责不同的单元,划分为不同的子系统
2、通用性不同的单元,划分为不同的子系统
3、需要不同开发技能的单元,划分为不同的子系统兼顾工作量,进一步切分太大的系统

开发视图

开发架构视图的任务,是将“逻辑职责”映射为“程序单元”,例如:要自主编写的“源程序”,可重用的库,框架等;同时进行开发技术选型,例如:开发语言,开发工具等,然后也需要确立程序单元间的关系,project划分,目录结构,编译依赖关系等。
运行视图
运行架构设计的工作内容,是确定引入哪些控制流:进程,线程等;确定每条控制流的任务,同时还要处理相关问题,例如控制流的创建,销毁,通信机制等,控制流之间的同步关系,是否有资源争用,是否需要加锁等也需要考虑。
物理视图
物理架构设计的3项任务
1、硬件的选择与物理拓扑
2、软件到硬件的映射关系
3、方案的优化
思维要点:“开销”和“争用”是核心,应避免争用,降低开销。

数据视图

数据视图是系统的数据存储设计,根据对系统的分析,确定一种或多种数据策略,常见的数据分布策略如下6种:
1、独立的Schema
不同系统应用,使用不同的数据schema,数据完全独立,一般界限清晰的不同系统可以采用这种方式。
2、集中
不同的系统应用,使用同一个数据库,一般具有关联属性的应用可以采用这种方式,比如一个系统分为服务端和管理端,但都属于一个系统,则可以使用同一个数据库。
3、分区
水平分区
水平分区即我们常见的分表方案,当一个schema无法满足我们的数据量要求时,可以划分为多个分区,每个分区存储一部分数据。
 垂直分区
垂直分区是分区策略的另外一个维度,当我们单库无法承载巨大的数据量时,也可以根据数据的类别,进行垂直分区。
4、复制
多个数据库保存相同的数据,根据制定的更新策略保证不同库之间的数据同步,我们常用的读写库分离,即为此方案,主库提供写能力,从库提供读能力,其中从库的数据是根据主库数据同步而来。
5、子集
根据一些特殊的场景要求,需要保存原数据的部分数据,例如application1保存全量订单,application2只需要部分出票成功的订单,进行后续分析操作,则可以使用子集的策略进行数据视图设计。
6、重组
通过多个不同的application作为数据来源,异构至其他application,用于数据的分析或后续流程使用。


五、总结

架构设计的三个阶段 预备架构阶段; 概念架构阶段; 细化架构阶段
架构设计的四个要素 :需求结构化;分析约束的影响;确定关键质量;确定关键功能
概念架构的三个步骤 :基于关键功能初步设计;系统高层分割;分析非功能需求
细化架构的五个视图 :逻辑视图;开发视图;运行视图;物理视图;数据视图
一个贯穿环节 :非功能需求的考虑

参考资料

[1] 《一线架构设计指南》

-end-

本文分享自微信公众号 - 京东云开发者(JDT_Developers)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部