学习笔记01-系统架构设计师

第1章 绪论

系统架构（System Architechture）概述

• 定义：系统架构是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段

• 系统架构设计是成熟系统开发过程中的一个重要环节，它不仅是连接用户需求和系统进一 步设计与实现的桥梁，也是系统早期阶段质量保证的关键步骤。

• 系统架构设计的目的：对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现
• 架构设计的优劣决定了系统的健壮性和生命周期的长短。
• 架构设计的作用：
• 解决相对复杂的需求分析问题
• 解决非功能属性在系统占据重要位置的设计问题
• 解决生命周期长，扩展性需求高的系统整体结构问题
• 解决系统基于组件需要的集成问题
• 解决业务流程再造难的问题

• 什么是系统架构设计师？

系统架构设计师是承担系统架构设计的核心角色，链接用户需求和系统进一步设计与实现的桥梁，是系统开发早期阶段质量保证的关键角色。

系统架构师的主导地位
• 系统架构师就是项目的总设计师，他是一个既需要掌控整体又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的总体设计人员；
• 他要确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员；
• 他要掌握技术团队的能力需要，给出项目管理方法，采用合适生命周期模型，具备以 自身为核心形成团队的能力，并在项目进度计划和经费分配等方面开展评估，以预防项目风险。

• 软件架构（体系结构）是用来刻画软件系统整体抽象结构的一种手段，软件架构设计也是软件系统开发过程中的一个重要环节。

• 软件架构经历的四个发展阶段
1. 基础研究阶段（1986-1994年）
• 形成了以描述软件高层次结构为目标的体系，软件架构的雏形诞生
• 模块化开发方法被逐步采用，为后续软件架构的发展奠定了基础
• 思想：分而治之，系统被拆分为模块，每个模块可以独立开发与测试，最后再组装成一个完整软件
• 分解或得模块系统结构的方法有：
• 数据结构设计法
• 功能分解法
• 数据流设计
• 面向对象的设计
• 系统分解为模块时应遵循的规则：
• 最高模块内聚：模块内部的元素最大限度地关联，只实现一种功能（高内聚）
• 最低耦合：不同模块之间的关系尽可能弱，利于软件的升级和扩展
• 模块大小适度：颗粒过大维护困难，颗粒过小耦合增加
• 模块调用链的深度（嵌套层次）不可过多
• 接口简单，精炼，具有信息隐蔽能力
• 尽可能地复用已有模块
• 模块化思想的优点：
• 更具灵活性，通过抽象、封装、分解、层次化等方法，能做提高代码的重用水平；
• 基于模块化思想的面向对象服务架构思想，提供了一组基于标准的方法和技术，能够有效整合和重用现有的应用系统和各种资源实现服务组件化
• 基于服务组件能实现各种新业务应用的快速组装，有效平衡业务灵活性
2. 概念体系和核心技术形成阶段（1999-2000年）
• 2000年，IEEE 1471-2000标准的发布第一次定义了软件架构的形式化标准，标志着软件架构理论体系已基本建立
• 该阶段的最重要成果：软件组件化技术
• 组件具有可组装性和可插拔性
• 每个组件的运行仅依赖于平台或者容器，组件与组件之间不存在直接的耦合关系
• 组件与组件之间并非绝对独立
• 组件进过组装后可以与其他组件进行业务上的交互
• 组件化开发与模块化开发、应用集成的区别：
• 模块化开发只是在逻辑上进行切分，物理上（代码）没有真正意义的隔离
• 应用集成是将一些基于不同平台或者方案的应用软件有机地集成到一个无缝的、并列的、易于访问的单一系统中，以建立一个统一的综合应用
• 组件化比模块化更独立（物理上隔离），但比应用集成结合更加紧密
3. 理论体系完善与发展阶段（1996年至今）
• 随着基于组件软件架构理论的建立，与之相关的一些研究方向逐渐成为软件工程领域的研究重点，主要包括：软件架构描述与表示、软件架构分析、设计与测试；软件架构发现、演化与重用；基于软件架构开发方法；软件架构风格；动态软件架构等；
1. 软件架构描述与表示
目前存在多种软件架构描述语言
• 比较典型的是基于组件和消息的软件架构描述语言C2SADL
• 分布、并发类型的架构描述语言Wright
• 架构互换语言 ACME
• 基于组件和连接的架构描述语言UniCon
• 基于事件的架构描述语言 Rapide
• 以及其他比较有影响力的描述语言Darwin、MetaH、Aesop、Weaves、SADL、xADL等。
2. 软件架构分析、设计和测试
• 架构分析可以分为结构分析、功能分析和非功能分析
常用的方法：
软件架构分析方法SAAM、 架构权衡分析法ATAM、 成本效益分析法CBAM、 基于场景的架构再工程SBAR、 架构层次的软件可维护性预测ALPSM、 软件架构评估模型 SAEM等
• 架构设计师指生成一个满足用户需求的软件架构过程
常用的方法：
• 从工件描述中提取架构描述的工件驱动 (artifact-driven) 方法；
• 从用例导出架构抽象的用例驱动 (usecase-driven);
• 从模式导出架构抽象的模式驱动 (pattern-driven) 方法；
• 从领域模型导出架构抽象的域驱动 (domain-driven) 方法
• 以及从设计过程中获得架构质量属性需求的属性驱动设计(attribute-driven design) 方法等
• 架构测试着重于仿真系统模型、解决架构层的主要问题
• 根据抽象层次，架构测试策略分为单元、子系统、集成和验收测试等阶段的测试策略
• 测试方法主要包括：架构测试覆盖方法、组件设计正确性验证方法和基于CHAM的架构动态语义验证方法等
3. 软件架构发现、演化与重用
• 软件架构发现解决如何从已经存在的系统重提取软件架构的问题
• 属于逆向工程
• 软件架构演化即由于系统需求、技术、环境和分布等因素的变化而最终导致软件架构的变动
• 架构动态性：在运行时刻的架构变化
• 架构扩展：架构的静态修改
• 架构扩展和动态性都是架构适应性和演化的研究范畴
• 软件架构复用属于设计重用，比代码重用更抽象
• 架构模式是架构复用的一种成果
4. 基于软件架构的开发方法
• 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，给出了软件开发活动各个阶段之间的关系
• 软件开发模型可分为三种：
• 以软件需求完全确认为前提的瀑布模型；
• 在软件开发初期只能提供基本需求为前提的渐进式开发模型（eg：螺旋模型）；
• 以形式化开发方法为基础的变换模型
5. 软件架构风格
• 架构风格（架构模式）是针对给定场景中经常出现的问题提供的一般性可重用方案，反映了领域中众多系统所共有的结构和语义特征，并指导如何将各个模块和子系统有效地组成一个完整的系统
• 软件架构风格主要划分为五类
• 数据流风格
• 调用/返回风格
• 独立组件风格
• 虚拟机风格
• 仓库风格

1. 普及应用阶段（2000年至今）
• 1999年，第一节IFIP软件架构会议召开，成立了IFIP工作组2.0与全球软件架构师协会
• Open Group提出了ADML，一种基于XML的架构描述语言，支持广泛的架构模型共享
• 软件产品线成为软件架构的重要分支：软件产品线架构表示一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线架构进行定制，将可重用组件与系统独立的部分集成而得到的。
• 软件架构是软件生命周期中的重要产物，影响软件开发的各个阶段
• 需求阶段：把软件架构有的概念引入需求分析阶段，有助于保证需求规约和系统设计之间的可追踪性和一致性。
• 设计阶段：设计阶段是软件架构研究关注最早、最多的阶段，这一阶段的软件架构主要包括软件架构的描述、软件架构模型的设计与分析以及对软件架构设计经验的总结与复用等。
• 实现阶段：将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架构和需求分析的要求，从而得到满足设计需求的目标系统。
• 维护阶段：为了保证软件具有良好的维护性，在软件架构中针对维护性目标进行分析时，需要对一些有关维护性的属性(如可扩展性、可替换性)进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。

软件架构的常用分类及建模方法

1. 软件架构的常用分类：有分层架构、事件驱动架构、微核架构、微服务架构和云架构等五类典型架构模型，C/S、B/S、 管道-过滤器和 PAC等架构也是被广泛使用的软件架构
• 分层架构（Layered Architecture） ：最常见的软件架构，将软件分成若干水平层，每一层都有清晰的角色和分工，层与层之间通过接口通信
• 最常见的四层结构
• 表现层（Presentation Layer）：用户界面，负责视觉和用户互动
• 业务层（Business Layer）：实现业务逻辑
• 持久层（Persistence Layer）：提供数据，SQL语句放在这一层
• 数据层（Database Layer）：保存数据
• 服务层（Service Layer）：有的项目在逻辑层和持久层之间加了一个服务层 (Service)，提供不同业务逻辑需要的一些通用接口。
• 事件驱动架构（Event-driven Architechture）：事件是状态发生变化时软件发出的通知，事件驱动架构通过事件进行通信
• 构成的四个部分
• 事件队列（Event Queue）：接收事件的入口
• 分发器（Event Mediator）：将不同的事件分发到不同的业务逻辑单元
• 事件通道（Event Channel）：分发器与处理器之间的联系渠道
• 事件处理器（Event Processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
• 微核架构（Microkernel Architechture）：又称为插件架构（Plug-in Architecture），是指软件的内核相对较小，主要功能和业务逻辑都通过插件实现
• 内核（core）只包含系统运行的最小功能
• 插件是互相独立的，插件之间的通信应该减少到最低，避免出现互相依赖的问题
• 微服务架构（Microservices Architecture）：服务导向架构（Service-Oriented Architecture，SOA）的升级
• 每个服务是一个独立的部署单元，这些单元都是分布式的，互相解耦，通过远程通信协议（如REST、SOAP）联系
• 微服务架构分为三种实现模式
• RESTfulAPI模式：服务通过API提供，云服务就属于这一类
• RESTful应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
• 集中消息模式：采用消息代理（Message Broker）可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群
• 云架构（Cloud Architecture）：主要解决扩展性和并发的问题，易于扩展
• 高扩展性体现在将数据都复制到内存中，变成可复制的内存数据单元，然后将业务处理能力封装成一个个处理单元
• 访问量增加，就新建处理单元
• 访问量减少，就关闭处理单元
• 没有中央数据库，因此扩展性的最大瓶颈消失了，每个处理单元的数据都在内存里，需要进行数据持久化
• 云架构的组成：
• 处理单元（Processing Unit）：实现业务逻辑
• 虚拟中间件（Virtualized Middleware）：负责通信、保持会话控制、数据复制、分布式处理和处理单元的部署。虚拟中间件包含四个组件：
• 消息中间件（Messaging Grid）：管理用户请求和会话控制，当一个请求进来以后，它决定分配给哪一个处理单元
• 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步；保证某个处理单元都得到同样的数据
• 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
• 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元

2. 系统架构的常用建模方式
• 根据建模的侧重点不同划分为4类：结构模型、框架模型、动态模型和过程模型
• 结构模型：最直观、普遍的建模方法，以架构的构件、连接件和其他概念来刻画结构
• 力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质
• 研究结构模型的核心是架构描述语言
• 框架模型：侧重整体的结构，主要以一些特殊的问题为目标建立只针对和适应问题的结构
• 动态模型：是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质
• 例如：描述系统的重新配置或演化
• 动态指系统总体结构的配置、建立或拆除通信或计算的过程
• 过程模型：过程模型是研究构造系统的步骤和过程，其结构遵循某些过程脚本的结果
• 上述模型并不独立，通过有机结合才可形成一个完整的模型来刻画软件架构
• “4+1”视角模型：Philippe Kruchten在1995年提出
• 从5个不同的视角包括逻辑 (Logical) 视角、过程 (Process) 视角、物理 (Physical) 视角、开发(Development) 视角和场景 (Scenarios) 视角来描述软件架构。
• 每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件架构的全部内容。

软件架构的应用场景

• 管道-过滤器风格适用于将系统分成若干独立的步骤

• 主程序/子程序系统和面向对象的架构风格可用于对组件内部进行设计

• 虚拟机风格经常用于构造解释器或专家系统

• C/S和B/S风格适用于数据和处理分布在一定范围，通过网络连接构成系统

• 平台/插件风格适用于具有插件扩展功能的应用程序

• MVC风格被广泛应用于用户交互程序的设计

• SOA风格应用在企业集成等方面

• C2风格适用于GUI软件开发，用以构件灵活和可扩展的应用系统等

软件架构的发展未来

系统架构设计师（System Architecture Designer）概述

• 系统架构师的分类
• 从组织上划分
• 业务架构师（Business Architect）
• 主题领域架构师（Domain Architect）
• 技术架构师（Technology Architect）
• 项目架构师（Project Architect）
• 系统架构师（System Architect）
• 从关注领域的不同划分
• 企业架构师EA（Enterprise Architect）
• 基础结构架构师IA（Infrastructure Architect）
• 特定技术架构师TSA（Technology Architect）
• 解决方案架构师SA（Solution Architect）

架构设计师的定义、职责和任务

• 架构设计师、架构设计与架构之间的关系
• 架构设计师执行架构设计
• 架构设计师是系统开发的主要角色，通过执行一系列活动来实施架构设计
• 系统开发中架构设计师是整个系统的核心
• 架构设计师创建架构
• 架构设计通过生成过程形成最终的产品架构，架构设计师的成果是创建架构
• 架构设计生成架构

• 定义：架构设计师是系统或产品线的设计负责人，是一个负责理解和管理并最终确认和评估非功能性系统需求，给出开发规范，搭建系统实现的核心构架，对整个软件架构、关键构件和接口进行总体设计并澄清关键技术细节的高级技术人员

• 职责：技术领导，拥有进行技术决策的权威。
• 架构设计师必须非常关注交付的实际结果，并必须赋予项目在技术方面的驱动力，还必须能够进行决策并确保这些决策被传达、理解并始终被执行。
• 从技术角度：架构设计师的职责就是抽象设计、非功能设计和关键技术设计等三大任务

• 主要任务：
• 领导与协调整个项目中的技术活动（分析、设计和实施等）
• 推动主要的技术决策并最终表达为系统架构
• 确定系统架构，并促使其架构设计的文档化
• 包括需求、设计、实施和部署等“视图”

如何成为一名好的系统架构设计师

• Pat Kua (原ThoughWorks咨询师)提出：一个好的架构设计师是技术全面的，并给出了成为一个技术全面的架构设计师必须具备的6个角色特质
• 作为领导者
• 作为开发者
• 作为系统综合者
• 具备企业家思维
• 具备战略技术专家的权衡思维与战术思维
• 具备良好的沟通能力

• 从工程师到系统架构设计师的演化
• 工程师阶段：典型特征是“在别人的指导下完成开发”
• 高级工程师阶段：典型特征是“独立完成开发”
• 技术专家阶段：典型的特征是“某个领域的专家”
• 系统架构设计师(初级)：典型特征就是能够“独立完成一个系统的架构设计”
• 可以是从0到1设计一个新系统，也可以是将架构从1.0重构到2.0。
• 系统架构设计师(中级)：典型特征是“能够完成复杂系统的架构设计”
• 包含高性能、高可用、可扩展、海量存储等复杂系统
• 系统架构设计师(高级)：典型特征是“创造新的架构模式”
• 与中级相比，典型区别在于“创造性”，高级架构设计师能够创造新的架构模式，开创新的技术潮流