如何做好架构设计，架构设计有章可循吗？

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

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

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

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

 

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