软件架构的定义
- 架构是对系统的抽象，通过描述元素、属性和元素之间的关系来反映抽象。
- 架构由多个结构组成，结构是从功能的角度来描述元素间的关系。
- 任何软件都存在架构，但不一定有架构文档。
- 元素及其行为的集合构成架构的内容。
- 架构具有基础性，通常涉及解决各类关键的重复问题的通用方案，已经设计中的各项重要决策。
- 架构隐含决策，架构是架构设计师根据关键功能和非功能性需求进行设计与决策的结果。
架构的重要性
- 项目关系人间交流的平台，关系人关注不同特性，这些特性都有架构决定。
- 早期设计决策，明确了系统实现的约束条件，影响系统的质量属性。
- 较高层面的软件复用，架构是系统的抽象模型，可在多个系统间传递复用。
- 对开发的指导和规范，作为系统的总体设计，指导后续的详细设计和编码。
架构模型
- 结构模型：以架构的构件、连接件和其他概念来刻画结构，通过结构来反映系统额重要语义内容。包括配置、约束、假设等，其核心是架构描述语言。
- 框架模型：侧重整体结构，不太关注细节，建立针对问题的结构。
- 动态模型：研究系统中大模块的行为，如系统的结构配置、通讯处理或计算过程。
- 过程模型：构造系统的步骤和过程，其结构遵循某些过程的结构。
- 功能模型：认为架构是由一组功能构件按层次组成，下层向上层提供服务。
4+1试图模型
- 逻辑试图：主要支持系统的功能需求
- 开发试图：也叫模块试图，主要关注软件模块的组织和管理。
- 进程试图：主要关注系统的运行特征，非功能性试图，如性能和可用性。
- 物理试图：主要考虑软件和硬件的结合，如系统拓扑图，安装和通信等。
- 场景：系统主要活动的抽象，即需求的抽象，将4个试图进行有机的结合。
软件质量的属性
- 性能（Performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。
- 可用性（Availability）是系统能够正常运行的时间比例。
- 可靠性（Reliability）是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
- 健壮性（Robustness）是指在处理或环境中，系统能够承受压力或变更的能力。
- 安全性（Security）是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
- 可修改性（Modification）是指能够快速地以较高的性能价格比对系统进行变更的能力。
- 可变性（Changeability）是指体系结构经扩充或变更成为新体系结构的能力。
- 易用性（Usability）是衡量用户使用一个软件产品完成指定任务的难易程度。
- 可测试性（Testability）是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。
- 功能性（Functionality）是系统所能完成所期望工作的能力。
- 互操作性（Inter-operation）是指系统与外界或系统与系统之间的相互作用能力。
质量需求的描述
- 刺激源：产生刺激的实体，如人、计算机、其他系统。
- 刺激：刺激在系统中可能产生的影响，需要考虑和关注的情况，如异常、错误响应等。
- 环境：刺激在某种条件下发送，如系统过载时
- 制品：系统中受刺激的部分，如网络io、cpu、内存。
- 响应：刺激发送时采取的行动，如存储日志，重启、熔断。
- 响应度量：当响应发送时，应该有某种方式对响应进行度量，用于测试质量是否合格。如恢复时间。
质量的可用性战术
- 错误检测：通过请求响应、心跳和异常处理程序来判断系统构件是否正常
- 错误恢复：通过表决器、主动冗余、被动冗余、备件、状态再同步、检查点/回滚方式来恢复系统构件。
- 错误预防 ：通过删除错误进程、事物一致性处理、进程监视器来预防错误。
质量的可修改性战术
- 局部化修改：在设计时，把预期变更限制在一定范围内，降低修改成本。
- 防止连锁反应：防止模块相互依赖导致的连锁反应。
- 推迟绑定时间：具备运行时修改能力。
软件架构风格分类
- 数据流风格：如批处理序列、管道过滤器
- 调用、返回风格：主程序和子程序、面向对象、层次
- 独立构件风格：进程通信、事件处理
- 虚拟机风格：解释器、规则系统
- 仓库风格：数据库系统、超文本系统、黑板系统。
层次系统架构风格
- 二层及三层CS架构风格，二层分为服务端和客户端，三层表现层、功能层和数据层。
- BS架构风格：分为浏览器和服务器，浏览器展现，服务器包括功能和数据。
- MVC架构风格：模型model、试图view、控制器controller。view捕获用户交互发送给contriller，controller调用model处理业务，完成后返回给给view进行可视化展现。
- MVP架构风格：model、view、presenter。与MVC区别在于model和view交互只能通过presenter.
SOA面向服务架构定义
- 功能是独立的服务
- 服务具有明确的接口
- 接口安装定义好的顺序调用实现流程
SOA设计原则
- 明确的定义接口：服务一旦公布，不能随便修改。
- 自包含和模块化：服务封装了稳定、重复性的活动和构件，是完全独立的进行部署和管理。
- 粗颗粒度：服务数量不宜过多，依赖消息交互而不是远程调用，通常是消息多，服务间调用少。
- 松耦合：请求中只对接口可见，内部实现逻辑不可见也不关心。
- 相互操作性、兼容和策略声明：明确服务使用上的策略，防止不合理的调用。
SOA关键技术
- UDDI（统一描述、发现和集成技术）：提供了一种服务发布、查找和定位的方法，包含数据模型、API和注册服务。
- WSDL（web服务描述语言）：基于xml语法描述服务 ，包含服务实现定义和服务接口定义。
- SOAP（简单对象访问协议）：定义服务请求者和提供者之间的消息传输规范，用xml格式化消息，http传输消息。包括封装、编码规则、rpc表示、绑定。
- REST（表述性状态转移）：使用http和xml的web通信技术，降低复杂性，提高可伸缩性。
REST设计概念和准则
- 网络上所有事物都可以抽象为资源。
- 每个资源对应一个唯一的资源标识。
- 通过通用的连接件接扣对资源操作。
- 对资源的各种操作不会改变资源的标识。
- 所有操作都是无状态的。
SOA实现
- Web Service：分为服务提供者、服务请求者和服务注册中心
- 企业服务总线ESB：为进行连接服务提供标准化的通信基础结构，基于开放标准。优势有扩展的标准的链接、灵活、服务导向的应用组合、提高复用率和降低成本。减少市场反应时间和提高生产率。
- 服务注册表：包括服务注册、服务位置和服务绑定
微服务优势
- 技术异构性：每个微服务都是独立的，可以选择不同的技术来实现。
- 弹性：部分服务异常不会导致整个系统不可用。
- 扩展：需要扩展时，只需要对某个服务进行扩展。
- 简化部署：部署时，只需要重新部署修改的服务，而不用部署整个系统。
- 与组织结构相匹配：团队越大维护越困难，根据团队情况调整服务结构。
- 可组合性：系统变更时可以根据情况时有微服务进行组合使用，而不是整个系统的改造。
- 对可替代性的优化：单系统代码关联性较强，不易调整，微服务容易进行改造或重构。
微服务挑战
- 分布式系统的复杂度：分布式系统比单系统复杂度搞，服务间的资源管理更为复杂。
- 运维成本：每个服务都是独立的部署单元，都需要独立的配置、部署、监控、日志收集等功能。
- 部署自动化：微服务比单个服务部署周期和频率会高很多，需要自动化代替人工。
- DevOps与组织结构：与单系统团队职责划分明确不同，需要全能型团队。
- 服务间的依赖测试：因为将单系统拆分成了多个服务，需要对服务间的依赖关系进行测试。
- 服务间的依赖管理：微服务间相互协作，服务数量越多，相互的依赖也需要进行管理。
微服务与SOA区别
| 微服务 | SOA |
|---|
| 尽量拆分 | 是个整体，服务聚合 |
| 纵向业务拆分 | 水平分层 |
| 单一组织负责 | 按层级划分的组织负责 |
| 细粒度 | 粗粒度 |
| 可简单说明 | 需要复杂的系统说明 |
| 独立子公司 | 大公司的业务单元 |
| 组件小 | 复杂的组件 |
| 业务逻辑存在于每个服务中 | 业务逻辑需要横跨 |
| 轻量级通讯方式，如http | 企业服务总线ESB |
微服务与SOA实现对比
| 微服务架构实现 | SOA实现 |
|---|
| 团队级，自低向上开着实施 | 企业级，自顶向下开展实施 |
| 一个系统拆分成多个服务，粒度细 | 服务由多个子系统组成，粒度大 |
| 松散服务架构 | 集中式服务架构 |
| 集成方式简单 | 集成方式复杂 |
| 服务独立部署 | 相互依赖，部署复杂 |
架构模式
- 演变交付生命周期：从初步的需求分析开始逐步进行循环迭代。
- 属性驱动设计法ADD：将分解过程建立在必须满足的质量属性之上。输入为功能需求、限制条件和质量需求。
- 按架构组织开发团队：在架构的模块分解结构最初几层稳定后，使用工作试图按模块分给开发小组。松耦合，高内聚。
- 开发骨架系统：以架构为指导，开发一个可运行的原型，再在其上进行增量开发。
- 利用商业构件进行开发：针对需求特点，选用响应的模式设计架构，并用对应的商业构件进行软件开发，如EJB进行面向对象开发的分布式系统。
ADD步骤
- 选择要分解的模块：将系统进行逐步拆分。
- 根据步骤进行求精：从质量场景和功能需求中选择驱动因素，选择合适的架构模式，并根据战术创建模式，创建由模块组成的总体架构模式，用多个试图标识实例化模块和功能分配，定义子模块接口，验证用例和质量场景，拼进行求精，成为子模块限制。
- 对需要进一步分解模块重复上述步骤
软件架构评估方法
- 基于调查问卷或检查表的方式：设计问卷或检查表，获取对架构的评估，依赖评估人的主观判断。
- 基于场景的方法：通过分析架构对场景的支持程度，判断架构对场景所代表的的质量的满足程度。如架构权衡分析法ATAM和软架构分析法SAAM。
- 基于度量的方式：建立在软件架构度量基础上，建立质量属性和度量间的评估原则，然后从架构文档中找出度量信息，根据评估原则推导质量属性。能更客观和量化的评估质量，对评估人员使用的技术要求较高。
架构权衡分析法ATAM输出
- 一个简洁的架构表述：从架构文档中提炼出一个简洁、可理解、面向普通关系人的架构表述，要求1小时内可表述。
- 表述清晰的业务目标。
- 用场景集合捕获质量需求。
- 架构决策到质量需求的映射。
- 确定敏感点和权衡点集合：一些对质量属性有明显影响的架构决策，如备份数据库对可靠性有正面影响，对性能有负面影响。
- 有风险决策和无风险决策。
- 风险主题集合：可以找出风险主体相应的应对措施。
- 产生附属结果：产生的过程文档可以作为经验保持。
- 产生无形结果：团队、沟通和理解。
架构权衡分析法ATAM步骤
- ATAM方法表述：评估负责人向项目代表介绍ATAM步骤和评估结果。
- 商业动机表述：项目决策者从商业角度介绍系统的概况。
- 架构表述：对架构进行适当的介绍，需要描述满足需求的架构方法和模式，及技术约束条件和其他系统交互。
- 架构方法分类：研究架构文档和架构表述了解系统使用的架构模式和方法。
- 生成质量属性效用树：根据“根>质量属性>属性求精（细分）>场景（叶）”结构的树，精简重要场景（不宜超过50个），定义场景优先级（H高、M中、L低），再按难易度来确定优先级（H高、M中、L低），组成了重要和难度的优先级对。
- 分析架构方法：评估小组按优先级对效用树的场景进行分析（成文提问，设计师回答），获取实现场景的架构方法，并将相关的架构决策形成文档，并对有风险决策、无风险决策、敏感点、权衡点进行分类。
- 集体讨论确定场景优先级：要求项目关系人对场景优先级进投票，发现设计师与项目关系人之间的需求差距，判断是否有风险。
- 分析架构方法：根据集体讨论后的结果生成场景优先级。
- 结果表述：将上述步骤进行归纳总结，并呈现给相关关系人。包括架构方法文档、场景集合及优先级、效用树、有风险和无风向决策文档、敏感点和权衡点。
成本效益分析法CBAM
- 概念：从经济角度建立成本、收益、风险和进度等方面软件的”经济“模型。
- 思想：架构策略影响系统的质量属性，这些质量属性又会给项目关系人带来收益，协助项目关系人根据投资回报率ROI选择架构策略。
CBAM步骤
- 整理场景：整理ATAM中获取的场景，根据商业目标确定优先级，并多最高的三分之一进行分析。
- 场景求精：为每个场景获取最坏、当前、期望和最好的质量属性响应级别。
- 确定场景优先级：项目关系人基于场景期望响应值对场景进行投票，生成场景权值。
- 分配效用：根据场景的响应级别确定效用表。
- 架构策略设计那些质量属性和响应级别，形成相关的策略-场景-响应级别三这对应关系。
- 使用内插法确定期望的质量属性响应级别的效用，根据效用表和对应关系确定架构策略及其对应场景的效用表。
- 计算各架构策略的总收益，根据场景权值和架构策略效用表计算总收益得分。
- 根据受成本影响的ROI选择架构策略。根据开发经验评估架构策略成本和总收益计算ROI，并对架构策略进行排序。
基于产品线的架构
概念：针对一系列产品而设计的通用架构，并在这基础上将共用模块提现实现，提供重用。
产品线开发模型
- 前瞻性产品线：利用领域经验和市场及技术趋势判断进行产品线设计，反应企业的战略决策。是自上而下的方法。
- 反应性模型：根据已为产品构件产品家族，并根据新产品扩展架构和设计方案。是自下而上的方法。
软件视图分类
- 模块视图类型：为系统主要模块实现单元编档。
- 构件和连接件视图类型：为系统的构件和连接件执行单元编档。
- 分配视图类型：为软件的开发和执行环节之间的关系编档。
系统架构试视图
模块视图类型
- 元素：指模块，能提供内聚功能的软件单元。
- 关系：
- 部分关系：模块间部分与整体的关系，如分解关系。
- 依赖关系：如共享数据、调用等。
- 特化关系：特殊模块和一般模块间的关系，如面向对象的继承关系。
- 元素特征
- 必须遵守命名空间的名称
- 使用责任特性定义模块功能
- 实现信息
- 关系特征
- 部分关系具有相关的可见性特征，确定子模块和聚集模块之外是否可见。
- 依赖关系具有分配的约束条件，规定两个模块间的依赖关系。
- 特化关系具有实现特性，特殊模块继承一般模式的实现方案。
模块视图风格类型
- 模块分解风格：展示向模块分配责任的方式。
- 模块使用风格：能展现模块间的相互依赖关系。
- 分层风格：能将系统分割成一组虚拟机，通关关系相互管理，帮助实现可移植性和可修改性。
- 泛化风格：能展示一个模块如何成为另个模块的繁华或特化，使模块产生关联。
