如何做好架构设计,架构设计有章可循吗? | 京东云技术团队

原创
2023/11/22 10:22
阅读数 4.9K

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

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

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

架构设计的原则

架构设计需要遵循一些原则:

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.《一线架构设计指南》

作者:京东零售 冯晓涛

来源:京东云开发者社区 转载请注明来源

展开阅读全文
加载中
点击加入讨论🔥(3) 发布并加入讨论🔥
打赏
3 评论
39 收藏
2
分享
返回顶部
顶部