S:单 M:多
| 结构 | 控制部分 | 处理器 | 主存块 | 关键性 | 代表 |
|---|---|---|---|---|---|
| SISD | 单个 | 单个 | 一个 | 单处理系器统 | |
| SIMD | 单个 | 多个 | 多个 | 各处理器以异步的形式执行同一条指令 | 并行处理机、阵列处理机、超级向量处理机 |
| MISD | 多个 | 一个 | 多个 | 不存在 | 无 |
| MIMD | 多个 | 多个 | 多个 | 能够实现作业任务、指令等各级全面同步 | 多处理机系统、多计算机 |
快到慢：CPU -> Cache -> 内存（主存） -> 外存（硬盘）
阿姆达尔解决方案：性能提升倍数，可以通过假设解题。
进行
// \
就绪 —— 等待
就绪：所有资源就绪，就差分配CPU
运行：所有资源就绪，且分配CPU
等待：等待某个资源。
创建 ——> 就绪 ⇄ 运行 ——> 终止
↖ ↙
阻塞
就绪状态 -> 运行状态：根据系统的调度算法，处于就绪状态的进程获取到处理机资源（分派的时间片）。
运行状态 -> 就绪状态：
1.处于运行状态的进程用完了系统分配给它的执行时间片，需要让出处理机。
2.在可剥夺的OS中，当有更高优先级的进程就绪，调度算法会让更高优先级的进程先执行。
运行状态 -> 阻塞状态：当进程等待某一事件发生时，就会从运行状态切换到阻塞状态。
阻塞状态 -> 就绪状态：当进程等待的事件已经发生，就会从运行状态切换到就绪状态。
前驱图：用于描述所有活动执行的先后顺序的约束关系
进程的同步和互斥
互斥：同一时间只允许一个进程执行
同步：同一时间允许多少进程执行
P：S=S-1 当 S<0 阻塞
V：S=S+1 当 S<=0 阻塞
| 页号 | 页内地址 |
|---|---|
| 页号和块号不一定相同 | 逻辑地址和物理地址的页内地址是相同的，页面大小可以推出页内地址，例如 4k 大小，4k=2^12^，则页内地址是 12 位，高于 12 位则为页号；块号+页内地址=物理地址 |
| 方式 | 描述 |
|---|---|
| 最优算法 OPT | |
| 随机算法 | |
| 先进先出算法 FIFO | |
| 最近最少使用算法 LRU |
文件和树型目录结构 文件属性：R 只读文件属性、A 存档属性、S 系统文件、H 隐藏文件 文件名的组成：驱动器号、路径、主文件名、拓展名
空闲存储空间的管理 空闲区表法 空闲链表法 位示图法 成组连接法
程序控制方式
程序中断方式
DMA 方式
通道
输入输出处理机
外模式 （用户视图，可以有多个外模式）
|
外模式-概念模式映射
|
概念模式
|
概念模式-内模式映射
|
内模式（一个数据库只有一个内模式）
|
操作系统
|
物理数据库
数据库设计过程 需求分析（数据流图、数据字典、需求说明书） —> 概念结构设计（ER 模型） —> 逻辑结构设计（表结构设计、E-R 图转换为关系模式、规范、完整性约束、确定用户视图）—> 物理设计
ER 模型 实体—联系—属性；联系一般写在 1 的一边。
ER 图冲突分为： 属性冲突：包括属性域冲突和属性取值冲突。 命名冲突：包括同名异义和异名同义。 结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部 E-R 图中所包含的属性个数和属性排列次序不完全相同。
关系代数操作
并：合并所有 S1US2
交：取公共部分 S1∩S2
差：取我有的你没有的 S1-S2
笛卡尔积：S1xS2 保留所有字段和数据，数据条数 n = n1xn2
投影：π(1,2)S1 投影选择列
选择：σ(1=sno1)S1 选择行
联接：S1∞S2 字段重复只保留一份，自然联接默认取两表共同字段进行等值连接
y=x^2 x每个值推出唯一的y值，则x决定y或称y函数依赖于x; y的值不能推出唯一x的值,则y不能决定x;
主属性：候选键包含的属性
第一范式 （属性值都是不可拆分原子）
|
第二范式 （消除非主属性对候选键的部分依赖） 非主属性完全依赖候选键，不存在部分依赖，单属性主键必满足第二范式
|
第三范式 （消除非主属性对候选键的传递依赖）
|
BCNF范式 （消除主属性对候选键的传递依赖）所有函数依赖左边部分必须为候选键
1.非规范化的关系模式，可能存在的问题包括：数据冗余、更新异常、插入异常、删除异常；规范化理论可以解决这些问题。
2.规范化理论存在问题：拆分表过多，查询效率下降.
3.规范化的键：
超键：唯一标识元组，可能存在冗余
候选键：消除超键冗余，可存在多个
主键：只能设置一个
外键：别的关系的主键
4.关系代数式转成图示表达，找出入度为零的节点，尝试遍历所有节点，如果可遍历则为候选键。
1.增加派生性冗余列
2.增加冗余列
3.重新组表
4.分割表
事务：
1.原子性：
2.一致性：
3.隔离性：事务相互隔离，互不影响
4.持续性：事务结果是持续影响的
并发存在的问题：
1.丢失更新
2.不可重复
3.读"脏"数据
事务锁：
X锁: 读锁，读锁可以加其他锁
S锁: 写锁，写锁不能加其他锁
7.应用层：实现具体的应用功能
6.表示层：数据的格式与表达、加密、压缩
5.会话层：建立、管理和终止会话
4.传输层：端到端，TCP和UDP
3.网络层：分组传输和路由控制；交换机、路由器
2.数据库链路层：以贞为传输单位；网桥、交换机、网卡
1.物理层：以二进制传输；中继器（放大信息）、集线器（多条输入路线）
其他：
TCP/IP协议族：http、FTP、telnet、SMTP、POP3
UDP协议族：SNMP、DHCP、TFTP、DNS
DHCP：动态分配IP
当IP地址为169.254.x.x或0.0.0.0，有可能是DHCP服务器故障或连接不上DHCP
DNS:
本地域名服务器
根域名服务器
顶级域名服务器
权限域名服务器
查询方式：
迭代查询：效率比价高,主要采用方式
递归查询：刨根究底，效率低
概念：独立磁盘冗余阵列。RAID 系统由两个或多个并行工作的驱动器组成，这些可以是硬盘或者 SSD（固态硬盘）。
RAID0：基于数据条带化，数据流被分成多个段或块，每个块都存储在不同的磁盘上；性能最高，并行处理，无冗余，破坏无法恢复。
RAID1：使用数据镜像的概念，数据被镜像或克隆到一组相同的磁盘，这样如果其中一个磁盘出现故障，可以使用另一个；可修复，利用率只有50%。
RAID0+1: RAID0 和 RAID1长处结合，高效可靠。
RAID1+0: RAID0 和 RAID1长处结合，高效可靠。
RAID3：N+1模式，有固定校验盘，坏一个盘可恢复数据。
RAID5：N+1模式，无固定校验盘，坏一个盘可恢复数据。
RAID6：N+2模式，无固定校验盘，坏两个盘可恢复。
IPV6 地址长度为 128 位，地址空间增大了 2^96^倍。
概念：物联网是实现物物相连的互联网。 分层：
概念：云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需提供给计算机和其他设备。云其实是网络。
特点：
1. 集合了大量计算机，规模达到成千上万
2. 多种软硬件技术相结合
3. 对客户设备的要求低
4. 规模化效应
应用：
1. 存储服务
2. 搜索
3. 科学计算
4. 安全应用
5. 软件即服务
软件即服务（SaaS）
平台即服务（PaaS）
基础设施即服务（IaaS）
ERP 、CRM、SCM
电子数据交换（EDI） 发展历程：电报 -> 传真 -> EDI
企业应用集成
另一种分类：
电子商务
| 4 流 | 模式 |
|---|---|
| 信息流 | 企业对消费者（B2C) |
| 资金流 | 企业对企业（B2B） |
| 物流 | 消费者对消费者（C2C） |
| 商流 |
软件需求分析 -> 软件设计 -> 软件编码 -> 软件测试 -> 软件维护
各阶段的对应图 需求分析阶段：数据流图。 概要设计阶段：模块结构图、层次图和 HIPO 图。 详细设计阶段：程序流程图、伪代码、盒图。
1. 瀑布模型：结构化方法，需求明确或二次开发
2. 原型模型：迭代方法，快速获取需求，需求不明确。
3. 增量模型（RAD）：迭代方法，开始时不用投入大量人力资源，可以事先推出核心产品以稳定用户，可以有计划的管理技术风险。
4. 螺旋模型：迭代方法，以原型为基础沿螺线旋转、每转一圈都经过计划/风险分析/实施/评估等过程且得到相应新版本、经过若干次螺旋上升得到最终版本。
5. V 模型：开发与测试结合。
6. 喷泉模型：面向对象方法，复用好；喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。
7. 统一过程（RUP）：用例驱动，以构建为中心叠代和开发。
8. 敏捷开发: 强调人与人之间的沟通，轻文档（弱化文档，但不是不需要文档），客户需要全程参与，需求可以的变化。
现有系统 -> 逆向工程 -> 考虑新需求 -> 正向工程 -> 新系统 逆向工程：
是统一建模语言的简称，它是一种由一整套图表组成的标准化建模语言。 结构图
行为图
用例泛化、包含、拓展关系：
<<include>>）<<extend>>）
数据流图 数据流：数据流向。 加工：有输入就有输出。 数据存储：例如：数据库表、文件等 外部实体：系统之外
数据流图常见异常：
原则：
基本原则
概要设计和详细设计
1. 自顶向下，逐步求精
2. 信息隐蔽
3. 模块独立（高内聚、低耦合）
保持模块大小适中
尽可能调用的的深度
多扇入，少扇出
单入口，单出口
模块的作用域在模块之内
功能模块应该是可预测的
需求分析阶段：数据流图
内聚与耦合
面向对象开发方法
设计原则
设计模式
创建型模式
结构型模式
行为型模式
创建型设计模式：描述对象如何创建，是为了将对象的创建与使用分离。包括五种：单例、原型、工厂方法、抽象工厂、构建器。 结构型模式：描述类或对象如何组织成更大结构，包括 7 种：代理、适配器、桥接、装饰、外观、享元、组合。 行为型模式：描述类或对象之间如何协作完成任务，包括 11 种：模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器。
测试原则:
测试方法：
等价类划分
边界值分析
错误推测
因果图
基本路径测试
循环覆盖测试
逻辑覆盖测试
1. 语句覆盖（覆盖程度最低）
2. 判定覆盖
3. 条件覆盖
4. 条件判断覆盖
5. 修正的条件判断覆盖
6. 条件组合覆盖
7. 点覆盖
8. 边覆盖
9. 路径覆盖（覆盖程度最高）
易分析性
易改变性
稳定性
易测试性
改正性维护: 出现错误后纠正，叫做更正性维护。
适应性维护: 环境发生变化。若环境没发生改变，而对系统做出的改进不是适应性维护。
完善性维护: 基于用户对软件完善。
预防性维护: 预防，也就是说，目前尚可工作，为了预防而做出改变。
网络图 PDM
| ES | 持续时间 | EF |
|---|---|---|
| 活动编号 | ||
| LS | 总时差 | LF |
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。
数据流风格：以数据流动为主。
1. 批处理序列：构件为一系列固定的计算单元，构件之间只通过数据传递交互，每个处理步骤是个独立的程序，每一步必须在其前一步结束后才开始，数据必须是完整的，以整体的方式传递。
2. 管道-过滤器：不要求不前一步完成。
调用/返回风格：
1. 主程序/子程序：程序之间调用
2. 面向对象：显示调用，对象之间相互调用
3. 层次结构：层层间调用，上层调用下层
独立构建风格
1. 进程通信：独立构建
2. 事件驱动系统：隐式调用，注册事件，触发或广播触发
虚拟机风格
1. 解释器：
2. 基于规则的系统：
仓库风格（以数据为中心）
1. 数据库系统
2. 黑板系统
3. 超文本系统
表示层：数据输入、用户交互、业务处理都在客户端 客户端程序设计复杂
数据层：存储数据
在 B/S 基础上结合一些技术（例如 AJAX、Flash）增强交互性和反应速度。
例如：AJAX、Flash
服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。 优点：
实现方式：
运行期质量属性 性能 定义： 系统在处理请求时所需的时间（响应时间）和单位时间内能处理的请求数量（吞吐量）。 措施：
可用性 定义：系统在特定时间段内可正常提供服务的时间比例，常以“几个 9”来衡量（如 99.99%）。 措施：
可伸缩性 定义：系统通过增加资源来应对负载增长的能力。 措施：
安全性 定义：系统保护自身数据和资源免受未授权访问、修改和破坏的能力。 措施：
可维护性 定义：系统易于修改和修复缺陷的能力。这虽然也是开发期属性，但修改的动机往往来自运行期。 措施：
互操作性：与其它系统协同工作或交换信息的能力。
可靠性 定义：系统在指定条件下无故障运行的能力（注意区分可用性）。 措施：
MTBF（Mean Time Between Failures）：平均故障间隔时间，是系统在两个故障之间的平均正常运行时间。
MTTD（Mean Time to Detect）：平均故障检测时间，是检测到故障所需的平均时间。
MTTR（Mean Time to Repair）：平均修复时间，是修复故障所需的平均时间。
MTBR（Mean Time Between Repairs）：平均修复间隔时间，是修复后到再次发生故障的平均时间。
易用性：用户学习、操作、准备输入和理解输出的容易程度。 健壮性：在出现故障（硬件、软件、网络）时保持服务的能力。
开发期质量属性
可测试性 定义：软件能够被容易且有效地进行测试的程度。 措施：
可扩展性 / 灵活性 定义：系统能够容易地添加新功能或修改现有功能，而无需大幅修改现有代码。 措施：
可移植性 定义：软件能够从一个环境迁移到另一个环境（不同操作系统、云平台、数据库）的难易程度。 措施：
可复用性 定义：系统的模块或组件能够在其他项目中重复使用的程度。 措施：
基于调查问卷 基于度量方式 基于场景的方式(常用)
敏感点：变化对结果造成较大的影响，强调重要影响。 权衡点：会影响到多质量属性，强调多质量属性。 风险点：潜在危险（还未发生，可能会发生），需防范管理。 非风险点：影响较小，不需特别关注。
基于场景的评估方法
架构权衡分析法（ATAM）: 描述 ATAM 方法->描述业务动机->描述架构->确认架构方法->生成质量属性用例树->分析架构方法->
软件架构分析法（SAAM）: 针对最终架构而非详细设计进行评估。SAAM 的评估过程包括:场景开发、架构描述、单场景评估、场景交互评估和总体评估。
成本效益分析法（CBAM） 是一种在软件架构评估领域中具有重要价值的方法，它从经济视角出发，致力于构建包含成本、收益、风险和进度等多方面要素的软件经济模型 。
软件架构静态分析方法（SASAM）
1. 机密性：确保信息不暴露给未授权的实体或进程。
2. 完整性：只有得到允许的人才能修改数据，并且能够判别出数据是否已被篡改。
3. 可用性：得到授权的实体在需要时可访问数据，即攻击者不能占用所有的资源而阻碍授权者的工作。
4. 可控性：可以控制授权范围内的信息流向及行为方式。
5. 可审查性(不可否认性)：对出现的信息安全问题提供调查的依据和手段。
第一级：用户自主保护级
第二级：系统审计保护级
第三级：安全标记保护级
第四级：结构化保护级
第五级：访问验证保护级。
概念：净室软件工程（Cleanroom Software Engineering，CSE）是一种应用数学与统计学理论，以经济的方式生产高质量软件的工程技术。其核心思想是在软件开发过程中，通过严格的工程化过程，力图达到开发中的零缺陷或接近零缺陷。
步骤：
技术手段：
概念：构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程 方式：顺序组装、层次组装、叠加组装 接口不兼容问题：
分布式表示架构： 表示层和表示逻辑层在客户机，逻辑层、数据处理层，数据层在服务器。 分布式数据架构： 表示层和表示逻辑层、逻辑层在主机，数据处理层，数据层在服务器。 分布式数据和应用架构： 表示层和表示逻辑层在客户机，逻辑层在应用服务器，数据处理层，数据层在服务器。
4 种透明性
特点
概念：多模型数据库（Multi-Model Database, MMDB）是一种能够同时支持多种数据模型（如关系模型、文档模型、键值模型、图模型等）的数据库系统。这种设计使得数据库能够灵活适应不同应用场景下的数据处理需求，提高数据管理的效率和灵活性。
为什么要使用多模型数据库，解决什么痛点： 在多模型数据库出现之前，企业通常使用“多语言持久化”架构来解决复杂的数据需求。
核心优势：
概念 负载均衡是一种技术策略，其核心目标是将网络请求或数据流量智能地、均匀地分发到多个后端服务器上，以确保：
作用
实现：通过 Ngginx 搭建负载均衡服务器
概念 微服务架构是一种将单个应用程序作为一套小型服务集合来开发的方法，每个服务运行在独立的进程中，并通过轻量级的通信机制（通常是 HTTP/REST API）进行交互。 每个服务都围绕着具体的业务能力构建，并且可以独立部署、升级和扩展。
核心特性与优势
带来挑战
流程
为什么拆：必须明确业务痛点。是因为单体应用臃肿，无法快速迭代？还是因为某个模块压力大，需要独立伸缩？或是团队协作效率低下？ 拆后效果：部署率提升 10 倍，核心服务可用性可达 99.9%
怎么拆：推荐使用 领域驱动设计（DDD） 作为方法论。
架构设计，以 Spring Cloud Alibaba 作为核心技术体系（例如智慧电商平台）
技术选型与核心组件
难点
架构图
核心概念 云原生是一种构建和运行应用程序的方法论，它基于云计算的分布式、弹性、可扩展特性，旨在充分利用云的优势，在新型动态环境（如公有云、私有云和混合云）中，构建和运行可弹性扩展、容错性好、易于管理、便于观察的应用。 可以把它理解为一个指导思想，其最终目标是以更快的速度、更低的成本，交付高质量、高可用的软件。
四大核心要素
| 核心要素 | 核心思想 | 关键技术代表 | 解决的问题 |
|---|---|---|---|
| 容器化 | 将应用及其所有依赖（库、配置文件等）打包成一个标准化的、轻量的、可移植的运行时单元。 | Docker | 环境一致性、隔离性、轻量级、简化交付。 |
| 动态管理 | 自动化地部署、管理、扩展容器化应用，提供故障自愈、服务发现、负载均衡等能力。 | Kubernetes | 运维自动化、高可用、弹性伸缩、资源调度。 |
| 微服务 | 将单体应用拆解为一组小型、松散耦合、围绕业务能力构建的服务。 | Spring Cloud, Go Kit, Dubbo 等 | 敏捷开发与交付、技术异构性、独立伸缩。 |
| DevOps + 持续交付 | 一种文化与实践，通过自动化工具链，促进开发与运维团队的协作，实现软件的频繁、可靠发布。 | Jenkins, GitLab CI, ArgoCD | 缩短交付周期、提升软件质量、降低发布风险。 |
架构优势
相关技术 docker：提供容器化机制，用于封装和打包应用。容器包含应用和环境，可独立部署到不同操作系统 kubernetes(掌舵者)： 负责自动化容器的部署、扩展、负载均衡、故障恢复等工作，容器编排平台 服务治理 Istio 服务网格： 解决了“服务之间如何智能、可靠、安全地通信”的问题。将应用与网络解耦，Kubernetes 让你有能力运行微服务，而 Istio 让你有能力高效、可靠、安全地管理微服务之间的交互。 持续到交付层：GitOps 模式，代码提交 Git -> 触发 jenkins 流水线自动完成镜像构建、安全扫描并推送至 Harbor。随后，ArgoCD 监听镜像仓库变化，自动将应用同步部署到 K8s 集群，实现了部署过程的完全自动化和可审计。 可观测性：搭建了集成了 Prometheus（指标监控）、Grafana（数据可视化）、Loki（日志聚合）和 Jaeger（分布式追踪）的全栈监控系统，实现了对应用与基础设施的 360 度立体监控。
概念 事件驱动框架是一种通过事件的产生、传递和响应来组织和设计软件的架构模式。它的核心思想是通过事件**解耦系统中的各个组件**，使得系统更具灵活性和可扩展性。事件的发布者不知道也不关心哪些组件会处理这个事件，反之，处理者也不知道事件是谁发布的。它们只通过事件进行间接通信。
核心组件
实现方式
| 实现方式 | 核心思想 | 通信模式 | 关键技术举例 | 适用场景 |
|---|---|---|---|---|
| 消息队列 | 任务分发，一条消息一个消费者 | 点对点 | RabbitMQ, SQS | 异步任务、负载均衡 |
| 发布/订阅 | 一个事件通知所有订阅者 | 一对多 | Redis Pub/Sub, SNS | 系统解耦、一事件多响应 |
| 事件流处理 | 持久化的事件流，可重放 | 流式处理 | Apache Kafka, Kinesis | 实时大数据、复杂事件处理 |
| 事件源 | 用事件序列代表状态 | 状态重建 | EventStoreDB, Kafka | 审计、时间旅行、与 CQRS 搭配 |
面向服务的架构设计（SOA） 概念 面向服务的架构设计是一种将应用程序的不同功能单元（称为“服务”）通过定义良好的接口（标准高度统一）和契约联系起来，并允许这些服务在网络上进行通信的架构范式。例如通过服务化封装，一个用户认证服务可被 10+个不同系统复用。
核心原则 标准化服务契约、松耦合、服务抽象、服务可重用性、服务自治、服务无状态性、服务可发现性、服务组合性
关键组件
Web 服务栈 SOAP：一种基于 XML 的协议，用于在服务之间交换结构化信息。 WSDL：用于描述 Web 服务的 XML 格式，定义了服务的位置、操作和参数。 UDDI：用于注册和发现 Web 服务的目录服务。
SOA vs. 微服务架构
| 特性 | 面向服务的架构 | 微服务架构 |
|---|---|---|
| 核心组件 | 企业级可重用的服务 | 小型、单一职责、独立的服务 |
| 通信 | 通常使用重量级协议（如 SOAP/XML）和智能管道 | 通常使用轻量级协议（如 HTTP/REST, gRPC）和哑管道，智能端点 |
| 数据管理 | 通常共享全局数据库 | 每个服务拥有自己的私有数据库 |
| 治理 | 强调统一的规范和标准 | 更推崇去中心化的治理和技术多样性 |
| 核心中间件 | 企业服务总线 | API 网关、服务网格 |
| 目标 | 企业应用集成和业务功能重用 | 实现敏捷开发、快速交付和高度可扩展性 |
机器人操作系统（ROS）：是一个开源的框架，广泛应用于机器人研究和工业领域。它并不是传统意义上的操作系统，而是一个运行在操作系统（如 Linux）上的中间件，提供了分布式通信机制和模块化开发工具，帮助开发者高效地构建机器人应用。
核心概念 ROS 的核心思想是通过节点（Node）实现功能模块化，每个节点负责特定任务，节点之间通过消息（Message）进行通信。通信方式包括话题（Topic）、服务（Service）和动作（Action）。主节点（Master）负责管理节点间的通信。 ROS 提供了硬件抽象层、设备驱动、库函数以及工具链，支持多语言开发（如 C++ 和 Python）。其模块化架构允许开发者复用功能包（Package），实现松耦合和分布式计算。
ROS1 是早期版本，支持广泛但存在实时性和安全性不足的问题。ROS2 引入了更强的实时性能、跨平台支持（包括 Windows 和 macOS）、安全性和扩展性，适合多机器人系统和大规模部署。
摘要是正文的简单阐述，需要交代因素：项目背景、简单功能介绍、通过采取（技术、方法、工具、措施、手段）、总结（不足之处、特色之处、如何改进、发展趋势）、作者的工作角色（架构师师、项目经理）
1. 以“我”为中心：围绕自身角色和工作
2. 站在高级工程师的高度：过程没必要写得太细
3. 忠于论点
4. 条理清晰，开门见山
5. 标新立异，要有主见
6. 图文并茂，能收到奇效
7. 首尾一次
1. 跑题
2. 字数偏多，字数不够
3. 摘要缺乏归纳，缺少特色，泛泛而谈
4. 文章口语化太重，文章表达能力太差
5. 文章缺乏主题项目，项目年代久远
6. 文章结构不清晰，段落太长
黄金公式：本文以我与xxx年主持设计与实施“xxx”项目为背景，项目面向xxx用户提供xxx、xxx、xxx、等相关业务共功能。我在该项目中担任系统架构师，负责项目的架构设计与技术落地。本文以该项目为例，详细阐述了XXX(论文主题)的应用。项目存在的问题和挑战xxx、xxx、xxx，采用xxx技术/方法，通过xxx具体工作，最终取得了xxx（最好量化）成果。
项目背景
我的角色与职责
项目存在的核心问题和挑战
（引出主题） 为解决上述严峻挑战，经过团队多次技术论证，我们最终决定采xxx的核心指导思想。
正文第二部分（理论知识与技术选型）
阐述1引出的技术和方法的概念
为何选择（应对1中问题与挑战）
正文第三部分（具体实施过程）
总体思路与架构图
（分步骤描述 - 重点突出“我”做了什么）
1.
2.
3.
效果（量化）
不足点（列出1-2）
给出解决思路