软考复习笔记其二：案例和论文

目录

本文是各类软考复习资源中，案例和论文等主观题目的学习笔记。

案例分析 ⭐

• 历年考点总结（2022年及之前）：

  • 软件架构：
    • 19年之后：架构风格、质量属性
    • 19年之前：非功能性需求、架构风险、敏感点、权衡点、质量属性效用树
  • 系统开发：结构化分析（数据流图、ER图）、实体和类、用例图
  • 嵌入式：专业性很强
  • 数据库：同步异步、缓存、数据一致性、redis同步、内存淘汰机制、并发、k/v方案、布隆过滤器
  • Web应用：云平台应用、TCP/UDP、边缘计算、MQTT协议、非功能性需求、SSM框架

  推荐优先复习并选择系统开发、数据库、Web应用

• 考点分析

  • 软件架构设计：质量属性、架构风格、架构评估、MVC、面向服务的SOA/ESB/J2EE
  • 系统开发基础：UML图、关系识别、类图/用例图/活动图/状态图、设计模式的识别、数据流图、E-R图、信息安全技术、项目管理、进度管理、关键路径
  • 数据库：关系型、内存数据库、NoSQL、反规范化技术、主从复制、负载均衡

• 软件架构设计

  • 质量属性：

    • 质量属性效用树

    • 质量属性判断

    • 必背概念：软件架构风格、架构风险（架构设计中潜在的存在问题的架构决策所带来的隐患）、风险点和非风险点、敏感点、权衡点

      注1：质量属性效用树中也可以出现风险点/非风险点（当说明有影响，但不是质量属性点）、敏感点（单属性多个构件）、权衡点（多个质量属性）

      注2：可用性优先于可靠性

      注3：形如xxx授权必须99.9999%可用，是安全性。即优先考虑主语（本例中是“授权”）。

      注4：当出现异常情况的场景描述时，则优先考虑可用性。

      注5：如果实在没有可用性和可靠性，那么性能也可以替代这两者

  • 架构风格：
    • 5+2种大类：批处理、调用返回、独立构件、虚拟机风格、仓库风格、闭环-过程控制、C2风格
    • 风格对比

      风格	主要特点	主要优点	主要缺点	适合领域
      管道-过滤器	过滤器之间相对独立	功能模块可复用、独立性、可维护性、扩展性强、有并发能力	不适合交互性强的、对于存在依赖关系的数据流需要协调	可划分清晰模块，模块间相对独立，模块间接口清晰的系统
      面向对象	力争实现问题空间和软件系统空间结构的一致性	高度模块性;实现封装;代码共享灵活易维护，可扩充性好	增加了对象之间依赖关系	多种领域
      事件驱动	系统由若干子系统构成且称为一个整体;系统有统一的目标;子系统有主从之分;每一个子系统有自己的事件收集和处理机制	适合描写系统组;容易实现并发处理和多任务;可扩展性好;具有类层次结构；简化代码;	因为树型结构所以削弱了对系统计算的控制能力；各个对象的逻辑关系复杂	一个系统对外部的表现可以从它对事件的处理表征出来
      分层风格	各个层次的组件形成不同功能级别的虚拟机；多层相互协同工作，而且实现透明	支持系统设计过程中的逐求级抽象;可扩展性好:支持软件复用	不同层次之间耦合度高的系统很难实现	适合功能层次的抽象和相互之间低耦合的系统
      数据共享风格	采用两个常用构件中央数据单元和一些相对独立的组件集合	中央数据单元实现了数据的集中，以数据为中心	适合于特定领域	适合于专家系统等人工智能领域问题的求解
      解释器风格	系统核心是虚拟机	可以用多种操作来解释一个句子，灵活应对自定义场景	适合于特定领域	适合于模式匹配系统与语言编译器、可视化编程界面
      闭环控制风格	通过不断的测量被控对象，认识和掌握被控对象；将控制理论引入体系结构构建	将控制理论引入到计算机软件体系结构中	适合于特定领域	该系统中一定存在有目标的作用、信息处理闭环控制过程

    • 架构设计
      • MVC架构：强制性把应用的输入、处理、输出流程，按照视图（数据显示）、控制（用户交互）、模型（处理数据逻辑）的方式进行分离。
        • 优点：是一种分层架构，有助于管理复杂应用程序，设计和测试可以专注于一个方面，也简化了开发分组，不同开发人员可以同时开发三个部分。
      • J2EE：客户层、web层、业务层、信息系统层：JSP + Servelet + JavaBean + DAO，也可以是JSP + Servelet + Service + JavaBean + DAO。
        • 和MVC的关系：客户层JSP可以认为是视图V，web层Servlet可以认为是业务逻辑层控制器C，JavaBean和DAO一起构成了模型M（JavaBean做数据封装，DAO用于连接数据库并操作）
      • 面向服务架构SOA：一种设计理念，包含多个粗粒度服务，由ESB服务总线（服务注册，消息转换/传递/解释/路由等）串起来。
      • 层次结构风格可以认为是调用返回的一种

• 系统开发基础

  • 结构化特点：自顶向下、逐步分解、面向数据
  • 三大模型、功能模型（数据流图DFD）、数据模型（E-R图）、行为模型（状态转移图）。此外还有数据字典（条目和属性）。
  • 面向对象的分析方法
    • UML关系：关联（实线）、依赖（虚线实箭头）、泛化（实现空箭头）、实现（虚线空箭头）、聚合（实线空菱形）、组合（实线实菱形）
    • 重要考点：用例图（包含/泛化/扩展）、类图、活动图、状态图
    • 分析模型：用例模型（用例图）、分析模型（其他图）
  • 项目管理
    • 要点：预算、关键路径推导、Gantt图（活动并行关系）、PERT图（活动依赖关系）
  • 信息安全
    • 要点：加密技术应用，包括对称加密、非对称加密、信息摘要、数字签名、数字证书

• 数据库系统

  • 重点
    • 并发控制：三级封锁协议
    • 规范化：优点（数据冗余、修改异常、插入异常、删除异常）
    • 反规范化：优点（降低连接需求、降低外码和索引数量、减少表数、提高查询效率，一般在查询大于插入时考虑反规范化）、具体做法
    • 分布式数据库：定义、特点、优点
    • 数据仓库：特点、层次
  • 补充知识：

    • ORM：在关系型数据库和对象之间做一个映射，可以避免编写复杂的SQL代码，只需要进行对象操作即可。

      • 优点：降低使用门槛、减少代码量、不需要写SQL、避免SQL质量差带来的问题
      • 缺点：SQL性能比直接用要差、不太容易处理复杂查询语句

    • 关系型（建立在关系模型基础上）数据库、NoSQL（泛指非关系型数据库，为了解决大规模数据集和多种数据类型）、内存数据库（整体存储在内存中）

      • 对比

        特征	关系数据库	NoSQL
        并发支持	支持，效率低	性能高
        存储和查询	关系表存储、SQL查询	海量数据存储、查询效率高
        扩展方式	向上扩展（提高硬件）	水平扩展（分布式分库分表）
        索引方式	B树、哈希	键值索引
        应用领域	通用领域	特定应用领域
        数据一致性	实时一致性	弱一致性
        数据类型	结构化数据	非结构化
        事务	高事务性	弱事务性
        水平扩展能力	弱	强
        数据容量	有限数据	海量数据

        	数据模型	读写性能	存储容量	可靠性
        内存数据库	K-V模式	内存直接读写，性能高	内存存储，容量受限	恢复机制复杂、可靠性低
        关系数据库	关系模式	外存读写，性能相对低	基于磁盘存储，容量大	内建恢复机制、可靠性高

        	设计难度	数据冗余程度	数据架构	应用扩展性
        关系型数据库	针对特定应用系统设计，难度较大	遵守数据库范式、冗余较小	以数据库为中心组织，管理数据	数据库独立于应用系统，接口标准化，易于共享数据
        文件系统	针对特定应用系统设计，难度较小	可能在多个文件中，复制相同的数据属性，冗余较大	以应用为中心管理数据	符合特定应用系统设计的文件数据，很难在不同系统之间共享

    • 缓存技术

      • MemCache：高性能的分布式内存对象缓存系统、在内存中维护统一的巨大Hash表，可以存储各种格式的数据
      • Redis：开源的使用ANSI C编写、支持网络、可基于内存亦可持久化的日志型、KV数据库。分布式常见主从、Cluster模式。数据切片方式有客户端切片（客户端映射）和槽切片（k/v映射）。

        对比：相同点（都是内存数据库，都支持kv，memcache支持图片视频，redis支持list、set等）、不同点（Redis可以将部分数据交换到磁盘，且Redis支持一些数据库特性，有限事务，分布式存储，持久性；而Memcache只是一个简单的内存k/v缓存，但它有内存管理和多线程）

• Web应用开发

  • 要点

    • 架构视角：MVC、MVP、MVVM、REST（只用HTTP和XML进行Web通信的技术，降低开发复杂度）、WebService、微服务

      • REST的5个原则：网络上的所有事物都被抽象为资源、每个资源对应一个唯一资源标识、通过通用的连接件接口对资源进行操作、对资源的各种操作都不会改变资源标识、所有的操作都是无状态的（一次性返回）
      • 微服务架构：建议将大型复杂的单体架构应用划分为一组微小的服务。每个微服务提炼单一的业务功能，可以很容易的发布到生产环境中独立且隔离的进程内部。优势：解决复杂性问题、让每个服务独立开发、每个微服务独立配置、每个服务都可以独立调整。缺点（挑战）：如何分解转化成为服务、部署更加复杂、性能问题、数据一致性问题。

        	微服务	SOA
        拆分粒度	细粒度，能拆就拆	粗粒度，是整体的，能放一起放一起
        业务划分	纵向业务划分	水平分多层
        组织单位	由单一组织负责	按层级划分不同的部门负责
        服务内容	便于解释	复杂
        组件复杂度	组件小	存在复杂的组件
        业务逻辑位置	存在于每一个服务中	横跨多个业务领域
        服务总线	轻量级方式，如HTTP，无集中式总线，松散的服务架构	企业服务总线ESB，集中式的服务架构（但服务之间是松耦合）
        研发实施	团队级，自底向上开展实施	企业级，自顶向下开展实施
        集成难度	集成方式简单（HTTP/REST/JSON）	集成方式复杂（ESB/WS/SOAP）
        服务组件是否能独立部署	可以	相互依赖，难以独立

    • Web应用架构演化：从单机到最终的分布式

    • 缓存：MemCache、Redis、Squid

    • 并发分流：集群（负载均衡）、CDN

    • 各层的负载均衡技术

    • 数据库技术：主从、内存数据库、反规范、NoSQL、分区分表、视图

    • 数据编码：XML、JSON

    • Web应用服务器：Apache、WebSphere、Weblogic、Tomcat、JBOSS、IIS

    • 其他：有状态和无状态、响应式Web设计（根据用户行为和设备环境调整网络页面布局，流式布局和弹性化设计，响应式图片）

    • 有个印象：

      • 持久化：Hibernate、Mybatis
      • 分布式存储：Hadoop、FastDFS、区块链

• 嵌入式系统

  • 如果出现不熟悉的技术，不建议选择
  • 重点
    • 系统可靠性：系统在规定时间、环境条件下、完成规定功能的能力，即系统无故障运行的概率
    • 系统可用性：在某个给定时间点上系统能够按照需求执行的概率
    • 可靠度：系统在规定的条件、规定的时间内不发生失效的概率
    • 失效率（风险函数、条件失效强度）：指运行至此刻系统未出现失效的情况下，单位时间系统出现失效的概率
    • 软件可靠性和硬件可靠性的区别：复杂性（软件复杂度高）、物理退化（硬件存在的问题）、唯一性（软件唯一）、版本更新周期（硬件更新慢）
    • 提高系统可靠性的技术：避错/排错技术、容错技术
    • 冗余的定义、冗余技术

      	恢复块方法	N版本程序设计
      硬件运行环境	单机	多机
      错误检测方法	验证测试程序	表决
      恢复策略	后向恢复	前向恢复
      实时性	差	好

• 技巧：

  • 先看问题，带着问题看题干

• 题型示例

  • 必做
    • 质量属性问题：
      • 给出一系列需求说明，分析其对应的质量属性点，并填充到质量属性效用树上
      • 询问一些定义，并结合题干解释定义。或者是题干中哪些点符合定义。
    • 软件架构风格：
      • 询问软件架构风格定义，并说明采用某种风格的原因
      • 选择合适的架构风格，并说明采用该风格的设计过程
    • MVC架构、EJB构件
      • 定义
  • 选做
    • 系统开发
      • 填写题干内容到数据流图中
      • 填写题干内容到E-R图
      • 概念区别：实体（用于数据建模）和类（面向对象建模）的区别、

        题干内容和模型图内容并不一定一一对应，要注意甄别。

      • 进度分析、成本估算、赶工计算（优先压缩关键路径上的关键任务）
      • 项目计划应包含的内容：项目背景、项目人员（项目经理、客户方、实施方、各方领导）、总体技术方案、所选择的管理过程和执行水平、过程工具、技术和输入输出的描述、项目生命周期和关键阶段、最终目标和阶段性目标、进度计划、项目预算、变更流程和控制委员会、对于内容/范围/时间的关键评审计划
    • 数据库
      • 分析数据库选型
      • 给出数据迁移方案（保持一致性）
    • Web应用
      • 将术语和题干联系，并填入图中
      • 询问SOA、ESB的定义
    • 嵌入式
      • 解释系统可靠性中可靠度和失效率的定义
      • 分析冗余设计的可靠度
      • 说明常见的检错技术和处理方式

案例分析架构设计专题

• 重点：
  • 各类案例的架构图
• 信息系统架构设计
  • 基本概念：
    • 信息系统架构ISA：指对某一特定内容里的信息进行统筹、规划、设计、安排等有机处理的活动。
    • 定义点：架构是对系统的抽象、架构由多个结构组成、任何软件都存在架构、元素及其行为的集合构成架构的内容、架构具有基础性（关键重复问题的通用方案）、隐含着影响深远的决策
    • 分类：物理结构和逻辑结构两种
      • 物理结构：只抽象地考察硬件系统的空间分布
      • 逻辑结构：信息系统各种功能子系统的综合体
        • 横向综合：同一管理层次的各种职能综合在一起
        • 纵向综合：某种职能的各个管理层次组织在一起
        • 纵横综合：信息模型和处理模型综合，做到信息集中共享，提取通用部分，建立系统公用数据库和统一的信息处理系统
  • 常用的四种架构模型：单机应用、客户机/服务器（C/S、B/S、MVC）、面向服务SOA、企业数据交换总线
  • 总体框架
    • 需要考虑方面：第一层战略管理（战略系统），第二层战术管理（业务系统、应用系统），第三层运行管理（信息基础设施）
      • 战略系统：和企业战略制定、高层决策相关的管理活动和计算机辅助系统
        • 设立战略系统的含义：信息系统对高层决策的支持能力，表示企业战略规划对信息系统的建设需求
      • 业务系统：企业中完成一定业务功能的各部分组成的系统。
        • 设立业务系统：在企业战略指导下对现有业务系统、过程、活动进行建模，使用业务流程重组BPR原理方法进行业务过程优化重组
      • 业务系统：即应用软件系统，指信息系统中的应用软件部分，如TPC、MIS、DSS等。包含内部实现和外部显示界面部分。
      • 企业信息基础设施EII：共三部分，技术基础设施（硬件/软件/网络/协议）、信息资源设施（信息数据和处理方法）、管理基础设施（管理人员、办法）
  • TOGAF：一种开放式企业架构框架标准，为标准、方法论和企业架构专业人员之间的沟通提供一致性保证
    • 目标：确保从关键利益相关方到团队成员的所有用户都使用相同的语言、避免被锁定到企业架构的专有解决方案、节省时间和金钱并更有效地利用资源、实现客观的投资回报
    • 核心思想：模块化架构、内容框架、扩展指南、架构风格
    • 关键内容：架构开发方法ADM
      • 构成：由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段（十个）
      • 迭代级别：基于ADM整体迭代、多个开发阶段间的迭代、在一个阶段内部的迭代
      • 全生命周期的十个阶段：准备阶段、需求管理、架构愿景、业务架构、信息系统架构、技术架构、机会和解决方案、迁移规划、实施治理、架构变更计划
  • 信息化总体架构方法：
    • 信息化的六个要素：开发利用信息资源、建设国家信息网络、推进信息技术应用、发展信息技术产业、培育信息化人才、制定和完善信息化政策
    • 信息化内涵：信息网络体系、信息产业基础、社会运行环境、效用积累过程
    • 信息化建设：指品牌利用现代信息技术来支撑品牌管理的手段和过程
  • 信息化架构模式：数据导向架构、流程导向架构
  • 信息系统的生命周期的五个阶段：规划（做不做，产出可行性研究报告、系统设计任务书）、分析（做什么，系统说明书）、设计（怎么做，系统设计说明书）、实施（实施进展报告、系统测试分析报告）、运行和维护。
  • 价值驱动的体系结构：
    • 价值模型核心特征（价值驱动因素）：价值期望值（对某个特定功能的需求）、反作用力（实现价值期望值的难度）、变革催化剂（导致价值期望值发生变化的某种事件）
    • 限制因素：反作用力、变革催化剂
    • 体系结构挑战：因为一个或多个限制因素，使得满足一个或多个期望值变得更困难
    • 优化体系结构的权衡点：重要性、程度、后果、隔离
  • 架构案例分析
    • HL7
    • 以服务为中心的企业整合，Ramp Coordination
• 层次式架构设计
  • 软件层次式体系结构是最通用的架构，也被叫做N层架构模式。
  • 主流分类：表现层（展示层）、中间层（业务层）、数据访问层（持久层）、数据层
    • 表示层：使用XML设计
      • UIP框架：一个扩展的框架，用于简化用户界面和商业逻辑代码的分离的方法。
        • UIP框架下的表现层进一步分层：
          • User Interface Components：对应原本的表现层，用户看到和操作的组件，负责获取用户数据并返回结果
          • User Interface Process Components：用户协调用户界面的各部分，使其配合后台的活动，用户不可见，为UIC提供支持
        • 表现层动态生成设计：基于XML的界面管理技术可用实线灵活的界面配置（静态）、界面动态生成和界面定制（动态）
    • 中间层：
      • 组件设计：业务逻辑组件分为接口和实现类两部分。接口用于定义业务逻辑组件，用于解耦，面向接口编程。
        • 接口类型：过程定义导入导出接口、客户端应用程序接口、应用程序调用接口、工作流机协作接口、管理和监视接口
      • 工作流设计：业务流程的全部或部分自动化。
      • 实体设计：业务逻辑实体提供对业务数据和相关功能的状态编程访问。业务逻辑实体可用使用具有复杂架构的数据。
        • 实体创建：可以是从具有复杂架构的数据来创建
        • 表示方式：XML、通用DataSet、有类型的DataSet
      • 业务层组织方式：
        • 业务容器：降低业务层和相邻各层的耦合。容器中按照Domain Model（领域层业务对象）-Service（业务过程、功能单元）-Control（服务控制器）思想实现
    • 数据访问层
      • 数据访问模式：在线访问、Data Access Object（J2EE设计模式）、Data Transfer Object（DTO，跨进程或网络分享，经典EJB设计模式之一）、离线数据模式（以数据为中心，从数据源获取后存放在系统中）、对象/关系映射（ORM）
      • 工厂模式的应用：定义一个操纵数据库的接口DataAccess，根据数据库的不同，由类工厂决定实例化哪个类。
      • 事务处理设计：JavaBean中使用JDBC、微软使用ODBC。打开连接默认是auto-commit，每一次查询自动开一个事务。
      • 连接对象管理设计：通过资源池解决资源频繁分配、释放的问题
        • 步骤：建立静态连接池，自定义分配/释放策略、释放时根据是否会被复用决定关闭还是放回连接池
      • 数据库设计和XML设计融合：
        • XML文档分类：以数据为中心（结构规则）、以文档为中心（描述性信息，结构不规则）
        • XML文档的存储方式：基于文件的存储（原始文本形式存放）、基于数据库存储（存储结构化和半结构化，并获得数据库的性能优势）
  • 物联网层次架构设计
    • 物联网层次：感知层（底层、感知数据）、网络层（数据传输、预处理）、应用层（业务需求）
  • 架构案例分析
    • 电子商务网站及其架构演化
    • 基于物联网架构的电子小票服务系统
• 云原生架构设计
  • 云原生架构是基于云原生技术的一组架构原则和设计模式的集合，目标是将云应用中的非业务代码部分进行最大化的剥离，让云设施接管应用中的非功能特性（弹性、韧性、安全、可观测性、灰度等），让业务不再担心非功能性业务导致中断，具备轻量、敏捷、高度自动化的特点。
  • 代码部分：业务代码、三方软件、处理非功能特性的代码（实际上还不能剥离所有）。
  • 特点：最大程度利用云服务提升软件交付能力、高度自动化的软件交付、加快软件开发、代码结构有巨大变化、非功能特性大量委托
  • 原则：服务化原则（微服务架构、小服务架构）、弹性服务（部署规模随业务量自动伸缩）、可观测、韧性、所有过程自动化、零信任原则（对任何人/系统都应当进行认证）、架构持续演进原则
  • 主要架构模式：
    • 服务化架构：微服务、小服务。将代码模块关系和部署关系分离。
    • Mesh化架构：将中间件框架（RPC、缓存、异步消息）从业务进程中分离，业务进程只保留很薄的客户端部分
    • Serverless模式：将“部署动作”从运维中“收走”，开发者不需要关心应用的运行地点、操作系统、网络配置、CPU性能，将运行完全委托给云
    • 存储计算分离模式：各类暂存数据、结构化、非结构化持久数据都在云端存储
    • 分布式事务
    • 可观测架构：Logging（多级别信息跟踪，开发者主动提供）、Tracing（提供请求从前端到后端的完整调用链路跟踪，适合分布式场景）、Metrics（对系统量化的多维度度量）三个方面。
    • 事件驱动架构：应用/组件集成模式，用于服务解耦，提供隐式调用，增强韧性。
  • 相关技术：
    • 容器技术：
      • 容器是标准化的软件单元，将应用和依赖项打包，使应用不再受环境限制
      • 充分发挥云计算弹性优势，降低运维成本
      • K8s已成为容器编排的事实标准：资源调度、应用部署、自动修复、服务发现和负载均衡、弹性伸缩、声明式API、可扩展架构、可移植性
    • 云原生微服务：
      • 微服务设计约束：个体约束（业务域划分相互独立、低耦合、单一职责）、横向约束（可发现、可交互）、纵向关系（数据存储隔离）、全局视角下的分布式约束（故障发现的时效性和根因精确性）
      • 一些微服务：Apache Dubbo、Spring Cloud、Eclipse MicroPrifile、Tars、SOFAStack、DAPR
    • 无服务（Serverless）技术：
      • 特点：屏蔽服务器运维复杂度、全托管的计算服务、通用性（结合云BaaSAPI能力）、自动弹性伸缩、按量计费
      • 函数计算（FaaS）是最具代表性的产品形态。函数通过事件驱动的方式触发执行。
      • 关注点：计算资源弹性调度、负载均衡和流量控制、安全性
    • 服务网格（ServiceMesh）：中间件提供的服务由代理来完成调用
  • 架构案例分析
    • 某旅行公司云原生改造
    • 某汽车公司数字化转型实践
    • 某快递公司核心业务系统云原生改造
    • 某电商业务云原生改造

    引入云原生架构、应用容器化、微服务改造

• SOA架构设计
  • 在SOA架构中，服务的概念有一定的延伸，泛指系统对外提供的功能集。
  • 理解SOA：
    • 从应用角度：SOA是一种应用框架，将业务分为单独的业务功能和流程。使用户可以构建、部署、整合这些服务。
      • 业务流程：为了实现某种业务目的所进行的一系列流程或一系列动作。
      • BPEL
    • 从软件基本原理：SOA是一个组件模型，通过这些服务之间定义良好的接口和契约联系起来
  • SOA的微服务发展
    • SOA向更细粒度、更通用化程度发展。
    • 和微服务的区别：
      • 微服务特点
        • 微服务更加精细
        • 微服务接口更通用化，例如HTTP RESTful，语言平台无关
        • 微服务更倾向于分布式去中心化的部署。
      • SOA特点
        • 面向服务架构，系统拆分为多个独立的功能模块，模块之间松耦合，消息量大，但是通信频率低
        • 用企业服务总线连接各个子系统，是集中式的技术架构
        • 应用服务之间相互依赖，部署相对复杂
        • 应用服务之间使用远程通信，降低了响应速度
  • 典型参考架构
    • “关注点分离”规划架构元素：业务逻辑服务、控制服务（用户访问/流程编排/数据集成整合）、连接服务（企业服务总线）、业务创新和优化服务（BPM业务性能管理）、开发服务（开发平台）、IT服务管理
  • 主要规范和协议：UDDI（统一描述发现和集成协议）、WSDL（Web服务描述语言）、SOAP（基于XML在分散或分布式环境中交换信息的简单协议）
  • 设计标准：文档标准化、通信协议标准、应用程序统一登记与集成
  • 服务质量QoS：可靠性、安全性、策略、控制、管理
  • 设计原则：无状态、单一实例、明确定义的接口、自包含和模块化、粗粒度、服务之间的松耦合性、重用能力、互操作性/兼容和策略声明
  • 设计模式
    • 服务注册表模式：注册、位置、绑定
    • 企业服务总线：一种中间件，支持面向服务架构的基础软件平台。交互过程是由事件驱动的消息交互模式。
    • 微服务模式：
      • 聚合器微服务：聚合器调用多个微服务
      • 链式微服务：服务之间形成一条链条，最终返回经过合并处理的响应
      • 数据共享微服务：强耦合
      • 异步消息传递微服务：消息队列
  • SOA构建的注意点：原有系统架构中的集成需求、服务粒度控制和无状态服务的设计
  • SOA实施过程：选择能全局规划的方案、选择契合企业需求的、选择适合平台实施技术水平的
  • 业务流程分析过程：监理服务模型、建立业务模型
• 嵌入式系统架构设计
  • 典型架构模式：层次化模式架构、递归模式架构
    • 层次化设计思想：高层次抽象、低层次实现、封闭性或者开放性（是否只能和相邻层通信）、结构由元素（域包）和接口组成
    • 递归模式架构设计思想：将复杂系统进行分解、分解是可扩展的、自顶向下（从系统层级开始并标识结构对象）、自底向上（专注于域的构造，域中类和关系）
  • 嵌入式操作系统EOS
    • 系统组成、系统特点
    • EOS体系架构：整体结构、层次结构、C/S结构、面向对象结构
      • 整体结构也称为模块结构或无序结构，是基于结构化程序设计
    • 内核：操作系统的核心部分，管理系统各种资源
      • 宏内核、微内核（只包含最小的内核代码）
    • 任务管理：任务（task）是EOS调度的最小单位，类似于一般操作系统中的进程、线程
      • 实时系统中的实时调度方法分类：离线和在线调度（是否运行前获得调度信息）、抢占和非抢占调度、静态和动态（任务优先级的确定时间）
        • 典型的强实时调度算法：最早截止优先、最低松弛度优先（紧急程度）、单调速率调度算法（周期越短越优先）
    • 任务间关系：独立、竞争、同步、通信
      • 通信方式：共享内存、信号量（最快）、消息队列、Socket和远程调用、Signal（信号）
  • 嵌入式数据库
    • 特点：嵌入式、实时性、移动性、伸缩性
    • 分类：基于内存MMDB、基于文件FDB、基于网络NDB
      • MMDB：将实时系统和数据库系统有机结合，活动事务只与实时内存数据库的内存拷贝交互。eXtremeDB。
      • FDB：通过驱动对数据文件进行读写。SQLite，其服务器和客户端在一个进程。
      • NDB：基于4G/5G的移动通信基础之上的数据库系统。在逻辑上可以把嵌入式设备看作远程服务器的一个客户端（将远程数据库映射到本地数据库）。三部分组成：客户端、通信协议、远程服务器。
    • 数据库架构：和一般数据库服务器架构不同，嵌入式数据库不需要数据库驱动程序，直接将库文件链接到应用程序中，通过API访问，而不是TCP/IP。
      • 原因：嵌入式数据库只允许应用本身访问，数据和程序不分离，和应用程序一块发布。
    • 功能划分：数据库运行处理、数据库存取、数据管理、数据库维护、数据库定义
      • 设计问题：存储空间管理模块（嵌入式数据库普遍采用内存缓存，需要相应管理）、数据安全性、数据完整性、事务并发控制、实时数据转储、运行日志管理
  • 嵌入式中间件（不是Web意义上的中间件）
    • 中间件：平台 + 通信。对嵌入式应用屏蔽底层操作系统的异构性
    • 功能：网络通信、内存管理、数据处理。
    • 特点：通用性、异构型、分布性、协议规范性、接口标准化
    • 分类：企业服务总线中间件、事务处理监控器、分布式计算环境、远程过程调用、对象请求代理、数据库访问中间件、消息传递、基于XML的中间件
  • 设计方法：
    • 通常采用自顶向下的设计方法
      • 基于架构的软件设计ABSD
      • 属性驱动的软件设计ADD：把一组质量属性场景作为输入，利用对质量属性实现和架构设计之间的关系的了解对软件架构进行设计
        • 步骤：评审、选择驱动因子、选择系统元素、选择设计概念、实体化元素和定义接口、草拟视图、分析评价
      • 实时系统设计方法DARTS：加那个实时系统分解为多个并发任务，定义这些任务之间的接口。提供一些分解规则和一套处理并发任务的设计步骤。
        • 过程步骤：用RTSA开发系统规范（产出开发系统环境图SCD、状态转换图STD）、将系统划分为多个并发任务、定义任务间接口、设计每个模块、设计过程的成果
        • 优点：强调分解、详细定义接口、强调任务架构图STD、提供从RTSA到实时设计的转换
        • 缺点：依赖前一个阶段的工作
        • 其他
          • 实时结构化分析和设计方法RTSAD：是DARTS的起源
          • 实时结构化分析RTSA：对传统结构化分析方法扩充了行为建模部分。用任务架构图来显示系统分解为并发任务的过程
          • 实时结构化设计RTSD：利用内聚和耦合原则进行程序设计的方法
          • 任务结构化标准有助于将实时系统分解为并发任务
  • 架构案例分析
    • 鸿蒙操作系统架构案例分析：应用层、应用框架层、系统服务层、内核层
    • 面向安全攸关系统的跨领域GENESYS系统架构案例分析：分离计算和通信
• 通信系统架构设计
  • 网络形式：局域网、广域网、移动通信网
    • 局域网
      • 单核心架构：一台核心二层/三层交换设备充当网络的核心设备。简单便宜，但是存在单点故障的可能。
        • 接入交换设备一般是二层交换机，核心交换设备是三层及以上
      • 双核心架构：多个核心交换机。避免单点故障，还能提供VLAN功能。
      • 环形架构：多台核心交换设备连接成双RPR动态弹性分组环，构建网络的核心。投资高、实现难度较高。
      • 层次架构：核心层交换设备、汇聚层交换设备、接入层交换设备
    • 广域网属于多级网络，广域网负责连接局域网（此时局域网相当于终端设备）
      • 组成：骨干网、分布网、接入网
      • 单核心广域网、双核心广域网、环形广域网、半冗余广域网（核心路由设备至少有两条连接到其他路由设备）、全冗余广域网（任意两个核心路由设备有连接）、对等子域广域网（两个半冗余再连接到一起）、层次子域广域网（划分多个子域，子域间是层次关系，每个子域内是半冗余）
    • 移动通信网网络架构：
      • 5GS：5G System
        • 基本术语
          • 数据网络DN：为移动终端用户UE提供服务时，通常需要数据网络DN（蜂窝网络）。
          • N6：UPF连接数据网络DN的接口
          • 5GS和DN之间通过定义的N6接口互联，5GS和DN之间是一种路由关系。
          • UPF网元：为各种上网设备提供的用户面功能的设备组件
          • 5G网络：包括UPF、SMF（会话管理功能）、MG-RAN（接入网，接入用户设备）
        • UE接入DN方式
          • 透明模式：5GS通过N6接口直连到运营商特定的IP网络，然后通过防火墙或代理服务器连至DN（外部ip网络，如因特网）。5GS此时相当于隧道QoS流服务。网络访问在UE和目标（因特网）之间独立进行。
          • 非透明模式：5GS直接接入中间网，或通过代理接入中间网。
        • 5G网络的边缘计算（MEC）架构
          • 部署：支持在靠近终端用户UE的移动网络边缘部署5G UPF网元，结合边缘部署边缘计算平台，为垂直行业提供时间敏感、高带宽需求的业务的就近分流服务。
          • 运行：运营商或第三方应用AF，通过5GS提供的能力开放功能网元NET，触发5G网络为边缘应用提供本地分流恶略，由PCF将策略配置给相关SMF，并实现UPF分流规则。
  • 软件定义网络SDN
    • 分层思想下的结构分类：控制层、数据层
      • 控制层：可编程SDN控制器、网络控制逻辑中心
        • SDN控制器北向接口和应用通信、南向接口和转发设备通信、东西向和其他SDN控制器通信
      • 数据层：哑交换机（和普通二层不同，只进行数据转发）
      • 接口：两层之间通过开放的统一接口（如OpenFlow）进行交互。通过接口向转发设备下发统一标准的转发规则。
    • 网络从底至上分为：数据平面、控制平面、应用平面（基于SDN的网络应用）
  • 网络构建关键技术
    • 高可用性：网络部件、网络连接模型、网络协议等方面的可靠性。是一个系统级的概念。
    • 网络构建和设计方法：
      • 阶段：网络需求分析（形成网络需求规格说明书）、网络技术遴选及设计（局域网、广域网技术遴选，地址规划模型）、路由协议选择、层次化网络模型设计、网络高可用设计方法
    • 网络安全：防火墙、VPN、访问控制技术、网络安全隔离、网络安全协议、网络安全审计
  • 绿色网络设计原则：节能环保
    • 标准化、集成化、虚拟化、智能化
  • 架构案例分析
    • 高可用网络构建分析：接入层高可用、汇聚层高可用、核心层高可用
    • 5G网络应用：IoT
• 安全架构设计
  • 信息系统威胁：物理环境、通信链路、网络系统、操作系统、应用系统、管理系统
  • 具体的安全威胁：信息泄露、破坏信息完整性、拒绝服务、非授权使用、窃听、业务流分析、假冒、旁路控制、授权侵犯、特洛伊木马、陷阱门、抵赖、重放、计算机病毒。人员渎职、媒体废弃、物理侵入、窃取、业务欺骗
  • 安全架构：
    • 概述：安全架构是架构面向安全性方向的一个细分。
    • 安全防线：产品安全架构、安全技术体系架构、审计架构
  • 安全目标：控制和管理主体（用户和进程）对客体（数据和程序）的访问
  • 安全模型：准确的描述安全的重要方面及其与系统行为的关系
    • 安全策略：从安全角度为系统整体和构成它的组件提出基本的目标。即描述，目标应该做什么，不应该做什么，具备指导意义。
    • 状态机模型：描述一种无论处于何种状态都是安全的系统。用状态语言将安全系统描述成抽象的状态机，用状态变量表述系统的状态，用转换规则描述变量变化的过程。
    • 模型分类：机密性模型（DAC自主定义、MAC强制、RBAC角色）、完整性模型
    • Bell-LaPadula（BLP）模型：使用主体、客体、访问操作、安全级别这些概念。保证机密性，一般不保证完整性。
      • 简单安全规则：只能下读。读级别不比自己高的客体。
      • 星属性安全规则：只能上写。写级别不比自己低的客体。
      • 强星属性：不允许对其他级别写。
    • Biba模型：不关心机密性，关心完整性（不被未授权修改，保护不被越权修改，维持数据内外一致性）。
      • 星完整规则：只能下写。
      • 简单完整规则：只能上读。
      • 调用属性规则：主体不能调用级别更高的客体程序或服务
    • Clark-Wilson模型：将完整性目标、策略、机制融为一体的模型。
      • 概念
        • CDI：需要进行完整性保护的客体
        • UDI：不需要完整性保护的客体
        • IVP：完整性验证过程，确认限制数据项处于有效状态
        • TP：转换过程，数据项在有效状态之间的改变
      • 特点：职责隔离目标（用户完整性）、应用相关的完整性验证进程（数据完整性）、变换过程的应用相关验证（过程完整性）
      • 使用Subject/Program/Object三元素，Subject对Object访问必须经过Program。权限分离。
    • Chinese Wall：应用在多边安全系统中的安全模型。
      • 基础思路：用户访问的信息不会与当前他们可支配的信息产生冲突。即只能访问利益冲突组内的至多一个客体。
      • 距离：A公司为X、Y、Z提供服务，而X、Y、Z之间有竞争。此时A公司职员a，如果选择给X提供服务，则不能看到Y、Z的任何数据。
  • 安全技术体系架构：对组织机构信息技术系统的安全体系结构的整体描述。目标是建立可持续改进的安全技术体系架构的能力。
    • 实体对象：应用、存储、主机、网络、物理
    • 信息系统安全体系组成：技术体系、组织机构体系、管理体系
      • 技术体系：全面提供信息系统安全保护的技术保障系统
      • 组织体系：信息系统的组织保障系统，机构、岗位、人事
      • 管理体系：法律管理、制度管理、培训管理
    • 要点
      • 信息系统安全规划依托企业信息化战略规划
      • 信息系统安全规划需要围绕技术安全、管理安全、组织安全
      • 信息系统安全规划以信息系统和信息资源的安全保护为核心。
      • 规划工作开展围绕信息系统和信息资源的开发、利用、保护。包括蓝图、现状、需求、措施。
  • 信息安全整体架构设计
    • WPDRRC（Warning/Protect/Detect/React/Restore/CounterAttack）：预警、保护、检测、保护、恢复、反击。人员为核心，策略是桥梁，技术是保证。
    • 重点考虑：
      • 系统安全保障体系：安全区域策略的确定、统一配置和管理的防病毒系统、网络安全管理制度
      • 信息安全体系架构：物理安全、系统安全、网络安全、应用安全、安全管理
    • 分层：用户接入、展现层、功能层、数据处理层、数据源
  • 网络安全体系架构设计
    • OSI7层协议中，除了第5层（会话层），其他均能提供相应的安全服务。实际上，适合配置安全服务的是物理层、网络层、传输层、应用层。
    • 5类安全服务：鉴别、访问控制、数据机密性、数据完整性和抗抵赖性
      • 鉴别：防止其他实体占用和独立操作被鉴别实体的身份
      • 访问控制：决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。ACI（访问控制信息）、ADI（访问控制判决信息）、ADF（访问控制判决功能）、AEF（访问控制实施功能）
      • 机密性：依赖于所驻留和传输的媒体
      • 完整性
      • 抗抵赖：证据生成、证据传输、存储及恢复、证据验证和解决纠纷
    • OSI定义分层多点安全技术体系架构：多点技术防御、分层技术防御、支撑性基础设施。
  • 数据库系统的安全设计
    • 重点设计：数据库的完整性（正确性和相容性）
    • 完整性的作用：防止合法用户插入不合法（语义）的数据、用DBMS完整性控制来实现业务规则、兼顾完整性和效能、有助于尽早发现软件错误
    • 完整性基本设计原则：确定约束实现的系统层次和方式、实体完整性/引用完整性约束、慎用触发器、需求分析阶段制定完整性约束的命名规范、根据业务规则对数据库完整性进行细致的测试、专职的数据库设计小组、合适的CASE工具
  • 系统架构的脆弱性分析：
    • 漏洞来源：软件设计的瑕疵、软件实现中的弱点、软件本身的瑕疵、系统和网络的错误配置
    • 脆弱性4个特点：隐藏弱点本身无危害、自觉或不自觉引入、受系统环境差异影响、修补和纠正时可能引入新的脆弱性
    • 脆弱性阶段：引入阶段、产生破坏效果阶段、修补阶段
    • 分析角度：分析软件故障原因、分析软件开发、分析软件使用
    • 分析对象的分类：脆弱性数据、软件系统（软件架构和软件技术）
    • 软件的脆弱性分析
      • 分层架构的脆弱性：层间脆弱性（底层出错上层无法运行）、层间通信的脆弱性
      • C/S架构的脆弱性：分层的脆弱性、客户端软件脆弱性、网络开放性的脆弱性、网络协议的脆弱性
      • B/S架构的脆弱性：分层架构的脆弱性、HTTP协议的脆弱性
      • 事件驱动架构的脆弱性：组件的脆弱性、组件交换数据的脆弱性、组件间逻辑关系的脆弱性、事件驱动容易陷入死循环、高并发的脆弱性、固定流程的脆弱性
      • MVC架构脆弱性：分层架构的脆弱性、MVC复杂性的脆弱性、视图和控制器紧密联系的脆弱性、视图对模型数据的低效率访问的脆弱性
      • 微内核架构：难以进行良好的整体优化、进程间开销也比单一内核大、通信损失率高
      • 微服务架构：分布式系统的复杂结构、设计服务之间的通信机制、服务管理的复杂性
  • 架构案例分析
    • 电子商务系统的安全性设计：认证、授权、审计
    • 基于混合云的工业安全架构设计
• 大数据架构设计
  • 大数据挑战：处理非结构和半结构化数据、对大数据复杂性/不确定性特征的描述方法和系统建模、数据异构型和决策异构型对知识发现和管理决策的影响
  • 架构特征：鲁棒性和容错性、低延迟读取和更新能力、横向扩容、通用性、延展性、即时查询能力、最少维护能力、可调试性
  • Lambda架构：
    • 目的：提供一个能满足大数据系统关键特征的架构。
    • 整合离线计算和实时计算，同时计算
    • 架构分层：批处理层（离线，MapReduce，时延高）、加速层（实时在线，时延低，Spark/Storm）、服务层（存入HBase，由Hive等进一步创建视图）
    • 相关技术：Hadoop（运行在通用硬件行的分布式文件系统）、Spark（快速大规模数据处理的引擎）、HBase-Hadoop Database（高可靠高性能高伸缩性分布式数据处理）
    • 优点：容错性好、查询灵活度高、易伸缩、易扩展
    • 缺点：全场景覆盖带来的编码开销（离线在线都要开发）、重新部署和迁移成本很高
  • 事件溯源（Event Sourcing）架构：
    • 本质上是一种数据持久化方式：系统以事件为驱动、事件是核心、业务数据是事件产生的视图
    • 和Lambda架构在数据集的存储使用的概念与Event Sourcing中的思想完全一致。都是用统一的数据模型对数据处理事件进行定义。
    • 设计模式：事件驱动、事件溯源、CQRS
    • CQRS架构：分离对数据的读操作、写操作。
      • Lambda也有一定程度的读写分离，Lambda读数据是读视图，写操作是写视图。
  • Kappa架构：
    • 概述：仍以流处理为主，但在Lambda的基础上进行了优化，删除了批处理层，将数据通道以消息队列进行替代。只保留实时代码（Flink）。
    • 数据在数据湖层面存储，需要离线分析或者再次计算，则从数据湖中重新放入消息队列（存在数据回溯的性能瓶颈）
    • Kappa更适合实时，Lambda更适合离线
    • 演化：
      • Kappa+架构：流计算框架可以直接读HDFS的数仓数据，一并实现实时计算和历史数据计算
      • 混合分析系统的Kappa架构：针对Lambda和Kappa架构的表示层困难的问题，支持在Kappa基础上衍生数据分析流程，如利用Kafka对接组合ElasticSearch。
  • 架构对比

    对比内容	Lambda架构	Kappa架构
    复杂度与开发、维护成本	需要维护两套系统（引擎），复杂度高，开发、维护成本高	之需要维护一套系统（引擎），复杂度低，开发、维护成本低
    计算开销	需要一直运行批处理和实时计算，开销大	必要时进行全量计算，开销相对较小
    实时性	满足实时性	满足实时性
    历史数据处理能力	批式全量处理，吞吐量大，历史数据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理能力较弱

  • 架构案例分析
    • Lambda架构在某网奥运中的大数据应用：采集、集成、存储、计算、展现
    • Lambda架构在某网广告平台的应用和演进
    • 某证券公司的大数据系统
    • 某电商智能决策大数据系统

论文

• 概述
  • 四选一、2500字（摘要300、正文2200十段式）
  • 题目类型：
    • 软件架构：架构风格、面向服务的架构、架构评估、质量属性、DSSA、ABSD
    • 系统开发：需求分析、需求获取、系统建模、设计模式
    • 系统可靠性、安全性、容错性
    • 信息系统开发方法、开发模型、生命周期模型、企业应用集成技术
    • 其他：项目管理、数据库
  • 复习方式
    • 确定自己要写的项目，确定论文模板
    • 根据项目和模板，准备写几篇论文
  • 考卷样例
    • 论面向服务架构设计及其应用 企业应用集成(Enterpise Application Integration,EAI)是每个企业部必须要面对的实际问题面向服务的企业应用集成是一种基于面向服务体系结构(Service-Oriented Architecture,SOA)的新型企业应用集成技术，强调将企业和组织内部的资源和业务功能暴露为服务，实现资源共享和系统之间的互操作性，并支持快速地将新的应用以服务的形式加入到已有的集成环境中，增强企业IT环境的灵活性
      请围绕“SOA在企业集成架构设计中的应用”论题，依次从以下3个方面进行论述
      1. 概要叙述你参与管理和实施的企业应用集成项目及你在其中所担任的主要工作
      2. 具体论述SOA架构内容、特点，以及你熟悉的工具和环境对SOA的支持，在应用中重点解决了哪些问题。
      3. 通过你的切身实践详细论述SOA在企业应用集成中发挥的作用和优势
  • 软件架构历年真题（2020-2014）
    • 论企业集成架构设计及应用
    • 论软件系统架构评估及其应用
    • 论面向服务架构设计及其应用
    • 论软件架构风格
    • 论软件系统架构评估
    • 论软件系统架构风格
    • 论软件的可靠性设计
  • 写作原则
    • 技术细节适中，将书本理论和实际项目联系起来啊
    • 不要全局都列举1、2、3
    • 段落不宜太长
    • 字数分配：300摘要、500项目背景、300引出主题内容/回答题干相关问题、1200主体（总分结构）、500结尾
    • “某年某月，公司立项XXX，任命我为系统架构设计师”，“在项目开展过程中，我学到了XXX”，“客户一致满意”
    • 答题卡不需要
    • 写1、2个不足之处和解决方案
    • 不能写真实的名称，写某市某公司。资金不要写整数，可以估计一个大概，然后精确到个位，如575万（建议在500万左右）。
  • 搭建模板
    • 选题：大企业的ERP、OA，云计算、大数据等
    • 准备论文摘要：

      xxx年xx月，我参与了某项目的建设，并担任系统架构师。该系统包括XX、XX、XX模块。能够完成XXXX功能，从而能够XXXX。该项目总投入XXX，历时XX月。于XX月正式交付运行至今，受到了客户的一致好评。
      

    • 准备项目背景

          当前XXX中，存在XXXX问题。需要用到XXXX。（一定程度展开）
          我所在的公司成功中标该项目，我被任命为系统架构师。建设周期XXX。项目采用了XXX硬件，使用XXX开发（技术内容一定程度展开）。项目的建设内容主要包括几大模块：
      

    • 非核心论点：回答题干的问题，这部分是纯默写理论知识。
    • 正文写作：理论结合实际

          在架构设计开始阶段，我们便意识到XXXX。在公司总工程师的建议下，我们使用了XXXX、XXX、XX。其中XXXX是XXXX，···。以下正文将重点描述实施过程和效果。
          底层架构我们使用了XXX。这种方法能XXXX。主要的实现手段是···，我们使用了开源项目XXXX（展开一定的技术细节），这个项目的优点是···。
          ···（其他三到四段）
      

    • 准备结尾

          经过近XX个月的开发，改系统顺利投入使用，协助客户XXX，运行至今反馈良好。该系统由于XXX要求高，建设过程困难重重。但项目团队成员十分重视该项目的XXXX（紧扣论文题目），最终保证了该项目顺利交付。
          当然本项目中，还有一些不足，（写一点小问题）。经过后期的整改，（略微展开），并没有对项目产生什么影响。在后续的学习和工作中，我将不断的充电学习，和同行进行交流，提升自己的专业技术水平，更好的完成系统架构设计的工作。
      

    • 范文参考：
      • 论云原生架构及其应用