软考高级-软件系统架构师-03软件架构设计（重点）

1. 软件架构的概念

   1. 解释
      1. 之前是从需求分析-》软件设计，从业务方直接到了技术，导致有需求和实现之前有鸿沟。
      2. 所以产生了需求设计，将需求分解为不同的模块，分别实现不同的职责
   2. 价值
      1. 复用和传递
      2. 项目干系人交流的手段，能预测质量
      3. 演化变简单，有据可依、方便传承
   3. 发展史
      1. 无架构-汇编语言（机器语言-最低级-命令式）
      2. 萌芽-程序结构设计（有顺序、分支循环等基本结构-高级语言-c
      3. 初级-统一建模语言uml
      4. 高级-4+1视图
   4. 软件架构建模
      1. 结构模型
         1. 以架构的构件、连接件和其他概念刻画结构
      2. 框架模型
      3. 动态模型
         1. 系统的大颗粒的行为性质
      4. 过程模型
      5. 功能模型
      6. 4+1模型（重点）-与uml一一对应
         1. 为了把架构搞清楚，进行了视图的拆分，又考虑制作视图的工具
            1. 逻辑视图-用户：系统功能需求
            2. 开发视图-实现视图-编程人员：软件管理（源码、组件、dll)
            3. 进程视图-系统集成人员：性能、并发
            4. 物理视图-部署视图-系统工程人员：软件到硬件的映射关系，安装、通信等
            5. 场景-用例视图

2. 软件架构风格（超重点）

   1. 风格=模式
   2. 分类
      1. 数据流
         1. 数据一步步处理得到结果，数据处理+严格流程
         2. 子风格
            1. 批处理序列
               1. 数据必须完整以整体方式传递-下载完成后再播放
            2. 管道-过滤器
               1. 管道=机制、过滤器=函数、方法
               2. 数据流处理-边下载边播放
      2. 调用/返回
         1. 当前使用最广泛
         2. 子风格
            1. 主程序/子程序
            2. 面向对象
            3. 层次结构
               1. 分层，上层调用下层，比如调用main方法
               2. 特点
                  1. 优点
                     1. 复杂问题分成不同层次去解决-解耦合
                     2. 不同层次处于不同抽象层级-越底层抽象级别越高
                     3. 每一层最多只影响两层，只要给相邻层提供相同接口，允许每层方法不同。同时支持了复用
                  2. 缺点
                     1. 并不是每个系统能容易地分层
                     2. 分层过多效率会低，分层少耦合又高，所以很难找到合适的层次抽象方法。一般3～5层最合适
      3. 独立构件
         1. 出发点：封装成构件的同时保持构件独立性-引入中间层/事件触发机制，让两个构件之间不直接联系了（可以联想到观察者、中介模式）
         2. 包含
            1. 进程通信
               1. 构件是独立过程，连接件是消息传递
               2. 构件是命名过程，消息传递的方式可以点对点、异步、同步、远程方法调用
            2. 事件驱动系统（隐式调用）
               1. 调试过程中牵一发而动全身，图形用户界面是典型的解释器风格
               2. 构件不直接调用过程，而是触发/广播一个/多个事件
               3. 构件在一个/多个事件中注册，当时间被触发，系统会自动调用在事件中注册的所有过程
               4. 一个事件的触发就导致另一个模块中的过程调用
               5. 其中构件是匿名的，构件之间交互的连接件以过程之间的隐式调用来实现
               6. 支持软件复用，方便构件维护和演化；但是放弃了对系统计算的控制
      4. 虚拟机
         1. 跟解释器设计模式
            1. 思想相同，只是解释器是局部解释方案而虚拟机风格是全局性的，适用于有自定义需求的场景
            2. 解释器风格-任务的时序依赖性
            3. 特点
               1. 一次编写到处运行
               2. 模拟新操作系统的运行环境
         2. 基于规则的系统，包括规则解释器、规则集、规则/数据选择器和工作内存，用于人工智能和dss中
      5. 仓库风格/数据共享（以数据为中心的风格）
         1. 有一个中心仓库，有一堆处理部件，所有处理部件都对仓库中的数据进行处理
         2. 包含
            1. 数据库系统
               1. ==数据文件，数据库管理系统从文件中获取不同信息进行相应展示
            2. 黑板系统-语音识别系统（先验知识）
               1. 以数据库系统为基础做的，结构一致。黑板是个全局数据库，包含问题解决方法数据的全部状态
               2. 黑板是知识元相互作用的唯一媒介；通过黑板状态的变化来控制知识源-增量修改与处理
               3. 常应用于解决问题没有确定性算法的软件：信号处理、问题规划、编辑器优化）
            3. 超文本系统
            4. 现代集成编译环境一般采用仓库架构风格（黑板）解决编译问题
               1. 传统的编译器，直接经过一系列操作编译成可执行代码进行执行
               2. 现代编译器先构造语法树，各种处理部件围绕语法树，这一系列汇集起来打包成工具集，跟语法树进行对接-不同工具间的信息交互
      6. 其他风格
         1. 闭环控制架构
            1. 闭环-空调，空调制热后需要，温度反馈然后确定是否继续制热；开环-电视换频道，遥控器按完发指令即结束
            2. 适用于嵌入式系统，设计连续的动作和状态
         2. c2风格（理论研究阶段）
            1. 并行构件网络
            2. 基本规则
               1. 构件和连接件都有一个顶部和一个底部
               2. 构件顶部链接连接件底部，构件地步连接连接件顶部；
               3. 构件间不允许直连，连接件可以连接任意连接件和其他构件
               4. 两个连接件进行直连时，必须一个顶部一个底部
         3. 层次架构风格
            1. 演化
               1. 两层c/s
                  1. 局域网
                  2. 表示层，业务逻辑全在客户端完成处理，以一个软件（安装光盘）的方式装到客户方，更新维护麻烦、成本高
                  3. 后端数据层直接跟数据库对接，完成数据存储的职能
               2. >三层c/s
                  1. 剥离出来一层服务器进行逻辑处理，不再客户端上进行了
                  2. 更新维护便利了，但是还是要求用户要装客户端（安装app，然后app要求更新很烦）->小程序应运而生
               3. ->三层b/s
                  1. 特点
                     1. 不再需要装客户端
                     2. 缺乏对动态页面中支持能力，安全性难控，以页面为单位，数据动态交互性不强，应用系统的数据查询等响应速度低
                     3. 这些问题后续都进行了优化解决
                  2. 分层
                     1. 表现层mvc
                     2. 中间层（本身又可以拆分）
                     3. 数据访问层orm
                     4. 数据架构层（数据库系统）
         4. mvc架构风格
            1. 概念
               1. model 逻辑部分
               2. view 显示部分
               3. controller 交互部分
            2. 归属
               1. 大部分表现层
               2. 小部分中间层
            3. j2ee对应
               1. view--jsp：页面层级
               2. controller--servlet
               3. model--EJB
            4. 类型
               1. 主动mvc
                  1. 动作-》view->controller->model->view->反馈结果
               2. 被动mvc
            5. 特点
               1. 1层view和3层model直接对接了，不好控制，耦合度过紧。从而出现mvp-》解耦合1-3层，同时支持单元测试
            6. mvp架构风格
               1. mvc的变种，使v-m层解耦合（修改v不影响m）
               2. 更好地支持单元测试，业务逻辑在p中，脱离v来测试逻辑（一个p嫩用于多个v，而不改变p的逻辑
               3. v要处理界面事件（mvc中c处理界面事件）
            7. mvvm层架构
               1. 本质跟mvp没有区别
               2. vm层和v层承担更多责任
            8. 富互联网应用ria
               1. 解决网页版交互慢点问题
               2. 第一次缓存大量数据在客户端本地，第一次打开时慢，之后运行表现好
         5. 基于服务的架构soa
            1. 面向服务是面向对象的加强
               1. 标准化--从对象到构件的跨越
               2. 服务在构建基础上进一步做标准化
                  1. 服务做到标准化
                     1. 互相调用互联互通就容易
                     2. 可以把已有的遗留系统，用服务进行封装然后跟其他服务做对接
                     3. webservice对单个服务进行封装
                  2. 服务总线
                     1. 做中介
                     2. 对接各个服务进行信息的传递
                     3. 将复杂网状结构-》简化星型结构
                  3. 单个服务结构内部
                     1. 接口访问层-进行对接，可以做到跨平台、跨语言
                     2. 业务逻辑层、
                     3. 数据访问层
            2. 特点
               1. 松散耦合
               2. 粗粒度
               3. 标准化程度高
            3. soa的实现方式
               1. webservice
                  1. 三个角色
                     1. 服务提供者
                     2. 服务注册中心
                     3. 服务请求者
                  2. 步骤
                     1. 服务提供者对自己能提供的服务进行服务描述
                     2. 服务提供者将服务描述注册到服务注册中心
                     3. 服务请求者在注册中心进行查询，查到合适的提供者进行绑定然后对接
                  3. 绑定方式
                     1. 动态绑定
                        1. 不绑死
                     2. 静态绑定
                        1. 绑死
               2. 企业服务总线ESB
                  1. 企业级的集成方法论
                  2. 要集成不同的开发语言及协议标准不同，要企业服务总线进行协调
                  3. 加强版服务中心
               3. 服务注册表
                  1. 
               4. 关键技术
                  1. soap协议-传递信息
                     1. =http协议+xml格式
                  2. rest
                     1. 对http常用操作进行标准化
                     2. 
         6. 微服务
            1. 来源
               1. 拆解成小服务，每个服务只专注某个领域，轻量化机制，松散耦合部署。
               2. 优势
                  1. 技术异构性：不同的服务可以用不同的技术甚至配不同的数据库
                  2. 有弹性、易扩展、可组合性、可替代性的优化：可以将不同模块任意组合和增加
                  3. 与组织结构相匹配：不同人负责不同的模块并行开发
                  4. 在有了自动化部署后，简化部署
               3. 挑战
                  1. 分布式系统的复杂性：拆得很小又做分布式，那节点和节点间通信很复杂
                  2. 运维、部署、问题排查成本高
                  3. 自动化维护与组织结构间的匹配复杂
                  4. 服务间的依赖测试和管理的难度大
               4. 与soa的对比
                  1. 实际上soa是微服务的变种，且soa包含微服务，但理论上也有不同
                  2. 实现上的不同
         7. mda模型驱动架构
            1. 净室工程中产生的理论
            2. 自动根据模型用程序实现，不用人的参与

3. 架构描述语言ADL

   1. 构成部分-3基本元素
      1. 构件
      2. 连接件
      3. 架构配置
   2. 主要的架构描述语言-不考

4. 特定领域软件架构DSSA（2分选择）

   1. 基本活动
      1. 领域分析
         1. 建立领域模型
      2. 领域设计
         1. 获得DSSA
      3. 领域实现
         1. 开发和组织可复用信息
   2. 领域分析机制
   3. 建立过程
   4. 三个层级（重点）
      1. 领域开发环境
         1. 开发共性物
         2. 领域架构师
      2. 领域特定的应用开发环境
         1. 在共性物上定制开发
         2. 应用工程师
      3. 应用执行环境
         1. 操作员

5. 基于架构的软件开发ABSD

   1. 基本思想（选择）
      1. 捕获需求
         1. 用例捕获功能需求-用户需求
         2. 特定场景捕获质量需求-除功能外的需求，比如维护
         3. 特定场景
   2. 开发过程
      1. 需求
      2. 设计
      3. 文档
      4. 文档复审
      5. 实现
      6. 演化
         1. 整个系统开发并不是一次能完成的
         2. 可能使用过程中发现问题，又要从需求开始走一遍整个流程

6. 软件质量属性（超重点）

7. 软件架构评估（超重点）

   1. 三个要点
      1. 风险点
      2. 敏感点
      3. 权衡点
   2. 评估方式
      1. 调查问卷 主观
      2. 度量 客观
      3. 场景 中间
         1. 软件架构分析法SAAM（重点
            1. 分析架构可修改性，后扩展到其他属性
         2. 架构权衡分析法ATAM（重点
            1. 在SAAM的基础上，针对性能、可用（实用）性、安全性、可修改性，在系统开发前对质量属性进行评价和折中
            2. 四个阶段
               1. 场景和需求收集
                  1. 场景和需求都有优先级
                  2. 场景的优先级（投票决定场景的优先级）带来了质量属性的优先级
               2. 架构视图和场景实现
               3. 特定的属性实现（单一理论）
               4. 多个属性折中
            3. 评估工具-质量效用树
         3. 成本效益分析法CBAM

8. 软件产品线

9. 构件与中间件技术

   1. 构件的特性（选择）
   2. 中间件是构件的一种
   3. 构件的复用
      1. 检索和提取
      2. 理解和评价
      3. 修改
      4. 组装
   4. corba中间件-公共对象代理请求机制
      1. orb起了一个连接各方的角色
   5. 典型应用架构J2EE

10. Web架构设计（超重点）

    1. 分类
    2. 发展过程
       1. 单机系统
       2. 单机进行升级
       3. 数据库隔离出来，两台服务器
       4. 集群
          1. 访客过多，光把数据库隔离到另一台机器上，单独的一台机器也承载web应用的业务量，所以选择集群化
          2. 多服务器分担任务
             1. 首先web服务器由于用户过多需要多服务器分担，需要协调机制-负载均衡策略。
             2. 后web服务器的问题得到了解决，数据库再次成为瓶颈数据库需要多服务器，需要数据同步机制-主从
    3. 集群协调机制
       1. 负载均衡(调度）
          1. 用途
             1. 转发用户的请求到空闲服务器上
             2. 同一用户多次访问在不同的服务器上的会话要保持一致
          2. 工作方式
             1. 是否有状态
                1. 前后有关联关系则有状态，需要记录状态信息
                2. 先后的请求有关联，有依赖关系，就很麻烦。。所以最好做成无状态的
             2. 利用cookies
                1. cookies是存在客户端本地的信息包，跟域名进行绑定
                2. 每次发送页面请求时附属在请求中传到页面中去
                3. 将session信息存在cookies中存到本地，下次读取cookie会取到session
             3. 利用redis
                1. 每次需要时从redis里面去取
             4. 相互同步
                1. 每次每台服务器的会话都同步给其他服务器
          3. 分类
             1. 应用层负载均衡
                1. http重定向
                   1. 重定向到其他服务器当的应用层
                   2. 从服务端七层到客户端应用层共14层，每重定向一次都14层
                2. 反向代理负载均衡
             2. 传输层负载均衡
       2. 一主多从
          1. 读写分离
             1. 主数据库只进行写入， 多从数据库只进行读取
             2. i/o变成瓶颈
                1. 硬盘的效率
                   1. 机械硬盘速度低
                      1. 磁盘盘面存数据，磁头读取，常见5400r（笔记本）。
                      2. 台式机7200r。机械盘限制瓶颈
                   2. 换成ssd磁盘会快
                2. 高速缓存
                   1. 将数据存在内存中，提高读取效率。缓存
                   2. 常用
                      1. memcache
                         1. 运行于内存中
                         2. 存结果，只是简单的k/v存储
                         3. 高性能、分布式、比redis更简单
                      2. redis
                         1. 支持的范围比memcache广
                         2. 支持数据持久化，掉电后数据可以恢复
                         3. 难题
                            1. 缓存雪崩。
                               1. 定义
                                  1. 一个点出现问题迅速蔓延
                                  2. 大部分缓存失效，服务器崩
                               2. 解决方法
                                  1. 加服务器，高可用
                                  2. 数据备份
                                  3. 出故障进行降级处理，缓存承受不了压力的时候就减少接受请求
                                  4. 提前演练探查阈值，监控提前介入
                            2. 缓存穿透
                               1. 定义
                                  1. 缓存没有命中，直接去查数据库
                                  2. 给数据库带来很大压力
                               2. 解决方法
                                  1. 查到空值就返回控制
                                  2. 部署过滤器拦截筛选
                      3. squid