软考高级系统架构设计师【第1章绪论】

Cc阿正

已于 2024-09-14 16:06:32 修改

阅读量983

点赞数 12

分类专栏：软考高级系统架构设计师文章标签：系统架构软件工程

于 2024-09-14 15:48:13 首次发布

本文链接：https://blog.csdn.net/Czh3616x/article/details/142251249

版权

软考高级系统架构设计师专栏收录该内容

1 篇文章 0 订阅

订阅专栏

第1章绪论

1.1 系统架构概述

1.系统架构的定义
这里的架构定义来源于IEEE1471-2000标准，主要针对软件密集系统进行架构描述，其对架构的定义如下：

架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则；
系统是组织起来完成某一特定功能或一组功能的组件集。系统用于完成其环境中的一个或多个任务；
环境或者上下文决定了对这个系统的开发、运作、政策以及会对系统造成其它影响的环境和设置；
任务是由一个或者多个利益相关者通过系统达到一些目标的系统的一个用途或操作。
2.系统架构的作用
系统架构是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分。架构设计的优劣决定了系统的健壮性和生命周期的长短。架构设计的作用主要包括一下几点：
解决相对复杂的需求分析问题；
解决非功能属性在系统占据重要位置的是设计问题；
解决生命周期长，扩展性需求高的系统整体结构问题；
解决系统基于组件需要的集成问题；
解决业务流程再造难得问题。
3.系统分解（模块化）
将系统分解成模块时，应该遵顼以下规则：
最高模块内聚。也就是在一个模块内部的元素最大限度地关联，只实现一种功能的模块是高内聚的，具有三种以上功能的模块则是低内聚的。
最低耦合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。
模块大小适度。颗粒过大会造成模块内部维护困难，而颗粒过小又会导致模块间的耦合增加。
模块调用链的深度(嵌套层次)不可过多。
接口简单、精炼(扇入扇出数不宜太大),具有信息隐蔽能力。
尽可能地复用已有模块。
4.软件架构分类
（1）分层架构
表现层：用户界面，负责视觉和用户互动；
业务层：实现业务逻辑
持久层：提供数据，sql语句就放在这一层；
数据库：保存数据。
有的项目在业务层和持久层之间加了一个服务层，提供不同业务逻辑需要的一些通用接口。
（2）事件驱动架构
事件是状态发生变化软件发出的通知。事件驱动架构是通过事件进行同行的软件架构，分为四个部分：
事件队列：接收事件的入口；
分发器：将不同的事件分发到不同的业务逻辑单元；
事件通道：分发器与处理器之间的联系渠道；
事件处理器：事件业务逻辑，处理完成后会发出事件，触发下一步操作。
（3）微核架构
微核架构又称为插件架构，是指软件内核相对较小，主要功能和业务逻辑都通过插件实现，内核通常只包含系统运行的最小功能，插件则是相互独立的。插件之间的通信应该减少到最低，避免出现互相依赖的问题。
（4）微服务架构
微服务架构是服务导向架构（SOA）的升级。每一个服务就是一个独立的部署单元。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST,SOAP）联系。微服务架构分成三种实现模式：
RESTful API模式：服务通过API提供，云服务就属于这一类；
RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通过是一个多功能的应用程序，常见于企业内部；
集中消息模式：采用消息代理可以实现消息队列，分在均衡，统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。
（5）云架构
云架构主要解决扩展性和并发问题，是最容易扩展的架构。它的高扩展性提现在将数据都复制到内存中，变成可复制的单元，然后将业务处理能力封装成一个个处理单元。若访问量增加，就新建处理单元；若访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈小时了。由于每个处理单元的数据都在内存里，需要进行数据持久化。云架构主要分为两部分，处理单元和虚拟中间件：
处理单元：实现业务逻辑；
虚拟中间件：负责通信、保持会话控制、数据复制、分布式处理和处理单元的部署。虚拟中间件包含四个组件：消息中间件（管理用户请求与会话控制，分配处理单元），数据中间件（数据同步），处理中间件（一个请求涉及不同类型的处理单元，其负责协调），部署中间件（负责处理单元的启动和关闭）。
5.软件架构的模型：分为4种：
结构模型：以架构的构件、连接件和其它概念来刻画结构。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。
框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
动态模型：动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质。
过程模型：过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。

1.2 系统架构设计师概述

1.架构设计师的定义
架构设计师是系统开发的主体角色，他们通过执行一系列活动来实施架构设计。架构设计通过生成过程形成最终的产品架构，架构设计是的成果是创建架构，是系统开发中整个系统的核心。架构设计师、架构设计和架构的关系
2.架构设计师的任务

领导与协调整个项目中的技术活动（分析、设计和实施等）
推动主要的技术决策并最终表达为系统架构
确定系统架构并促使其架构设计的文档化，这里的文档化应包括需求、设计、实施和部署等“视图”。
3.架构师应具备的专业素质
掌握业务领域的知识：当架构师理解软件开发但不理解业务模型时，可能会开发出一个不能满足用户需求而只能反映该架构设计师所熟悉内容分的解决方案，因此，熟悉业务也使得架构设计师能够预见可能发生的改变。
掌握技术知识：由于架构设计的某些方面明确需要技术知识，所以一个架构设计师应该拥有一定程度的技术水平。然而架构设计师不必是一个技术专家，它必须关注技术的重要因素。
掌握设计技能：设计过程师架构设计的核心内容，架构师关键设计决策的具体化，因此，架构设计师应该拥有很强的设计技能。关键设计决策是指关键结构设计决策、特定模型的选择和指导规格说明书等。
具备编程技能：项目开发人员是架构设计师必须与之打交道的最重要的团队成员，而项目的最终产品是可执行代码，只有架构师承认开发人员你的工作价值时，在架构设计师和开发人员之间的沟通才是有效的。
具备沟通能力：架构设计师的软技能中，沟通最重要。架构师应该具备有效的口头和书面表达能力。有效的沟通可以让开发组织充分理解架构师的思想，还有与利益相关方的沟通，对于理解他们的需求及与他们就架构达成并保持一致是非常重要的。
具备决策能力：决策是架构师必须具备的能力，尤其是在很多不很明确的情况下，而且没有充足的时间研究所有可能性时，架构设计师不能果断决策会延误项目，进而失去信任。
知道组织策略：不仅关心技术，还应对政治敏感并知道其在组织中的权力，利用这些知识与恰当的人进行沟通，确保项目在适当的周期中获得支持。
应是谈判专家：架构设计师需要与许多利益相关者进行交流，其中的一些交流需要谈判技巧。
4.架构师的知识结构
战略规划能力
业务流程建模能力
信息数据架构能力
技术架构设计和实现能力
应用系统架构的解决和实现能力
基础IT知识及基础设施、资源调配能力
信息安全技术支持与管理保障能力
IT审计、治理与基本需求的分析和获取能力
面向软件系统可靠性与系统生命周期和质量保障服务能力
对新技术与新概念的理解、掌握和分析能力
5.非功能性系统需求
可维护性
性能
复用性
可靠性
有效性
可测试性