如何做好架构设计，架构设计有章可循吗？( 二 ) _架构设计

文章插图
分析约束影响
约束分析的几个方面：
1、来自产品或运营人员的约束性需求
系统的非功能需求，例如：上线时间，预算，工期要求等
业务领域相关的限制，例如业务规则或业务限制，相关法律，专利等。
2、来自用户的约束性需求
系统的用户，同样会产生约束性需求，比如用户的计算机水平，年龄段，使用偏好，国家等。
例如用户计算机水平整体较弱的话，在开发交互方式时就不应太过复杂，同时要兼顾系统的鲁棒性，防止系统被用户搞挂。
用户使用产品时的外部环境同样可能产生约束条件，比如访问环境是内网或是外网，则决定了系统提供访问链接不同的网络权限。访问环境信号强度若，则系统的性能要求则更高。
3、来自开发或运维人员的约束性需求
开发团队的技术水平，磨合程度，同样制约着系统的开发，如果开发人员均是高级研发人员且对当前技术栈有深入的了解，则开发进度就会更快，如果是新团队，且需要对技术栈进行学习才可以介入开发，则在工期或系统风险层面需要额外考虑。
4、业界当前技术环境
当前技术环境中间件的成熟程度，编程语言及流行度，优缺点等，都会对架构设计产生约束条件。
约束的分类：
1、直接约束
例如：系统运行于 linux 平台。
2、转换为功能需求的约束
对于这种约束，可以直接转换为功能需求
例如：供应商拥有自己的一套城市信息表 -> 引出的功能需求：需要进行城市转换
例如：供应商服务器性能差，tps 最大 10 -> 引出的功能需求：需要进行限流请求
3、转换为质量属性需求的约束
例如：系统使用者计算机水平不高
转换为质量属性：易用性（否则不会用），鲁棒性（系统被搞瘫）
确定关键质量
系统的关键质量是需要进行取舍的，需要确认业务人员更注重那方面或在满足需求的基础上，确定哪些是必须的，哪些是可以适当忽略的。
我们需要首先确定架构重点支持哪些质量属性，然后对于相互矛盾的质量属性，进行权衡折中。例如当满足性能这个质量属性时，同时就会因为引入新的方案或组件，导致可维护性，可测试性降低；提高可拓展性时，就会对系统的性能和安全性产生影响等等，我们需要做的，就是在各个关键质量中进行取舍。

文章插图
确定关键功能
确定关键功能的 4 个方面
1、核心功能
2、必做功能
3、高风险功能
4、独特功能
其他常见系统不存在的功能
注意衍生需求：
从需求转入设计时，因方案制定过程的复杂，会产生大量的衍生需求，衍生需求是原始需求的数倍。
举例：
原始需求：定时拉取供应商数据。
衍生需求：
1、由于供应商数量较多，需要引入分布式定时任务，集群并发拉取
2、由于供应商数据量大，需要分库分表设计
3、需要快速搜索，引入存储引擎组件等等

文章插图
??这些衍生需求我们必须要考虑，虽然业务需求没有体现，但缺失架构设计的关键影响因素。
架构驱动力对比：
业务需求驱动架构：

文章插图
??重大需求驱动架构：

文章插图
??由此可以看出，通过重大需求驱动的架构，更能考虑到更关键的部分，设计的架构更能满足需求的要求，架构设计成功的概率会更高。
概念架构阶段分析概念架构阶段，对系统进行适当的分解，而不陷入细节
概念架构的过程是，先根据关键功能进行初步设计，然后对设计的系统进行高层分割，接下来考虑非功能性需求（关键质量和约束），然后修改自己的初步设计，循环往复，在不断的质疑和优化过程中，完善架构设计。