笔记-真题-综合知识（2020年系统架构设计师上午题）

学习第一步！先从历史题目的内容开始认识。2020年系统架构设计师题目中的知识点。

1. 前趋图

前趋图中，箭线代表前趋关系，节点代表进程。

2. 线程相关概念

• 在同一进程中的各个线程都可以共享该进程所拥有的资源，如访问进程地址空间中的每一个虚地址；
• 访问进程所拥有的已打开文件、定时器、信号量等，但是不能共享进程中某线程的栈指针。
• 已打开的文件是共享的；
• 线程的栈指针属于线程独享资源，不可被其他线程共享；
• 栈指针是T1线程独享的，不可以被T2和T3共享；

3. 位示图

位示图是利用二进制的一位来表示磁盘中的一个盘块的使用情况。一般把“1”作为盘块已分配的标记，把“0”作为空闲标志。根据题意系统中字长为32位，所以一个字可记录32个物理块的使用情况。若磁盘的容量为300GB，物理块的大小为4MB，那么该磁盘有300*1024/4=76800个物理块，所需的位示图的大小为76800/32=2400个字。

4. 实时操作系统

实时是指计算机对于外来信息能够以足够快的速度进行处理，并在被控对象允许的时间范围内做出快速响应。

实时操作系统是保证在一定时间限制内完成特定功能的操作系统。实时操作系统有硬实时和软实时之分，硬实时要求在规定的时间内必须完成操作，这是在操作系统设计时保证的；软实时则只要按照任务的优先级，尽可能快地完成操作即可。

5. 派生属性

派生属性是数据库中的衍生数据，是一种特殊属性。派生属性是指可以由其他属性进行计算来获得的属性，如年龄可以由出生日期和系统当前时间计算获得，是派生属性。

注意这里出生日期并不是派生属性，因为年龄和系统当前时间只能计算出生年份，不能准确地计算出日期。

6. 分布式数据库

在分布式数据库中有分片透明、复制透明、位置透明和逻辑透明等基本概念。

• 分片透明性：是指用户不必关心数据是如何分片的，它们对数据的操作在全局关系上进行，即如何分片对用户是透明的，因此，当分片改变时应用程序可以不变。分片透明性是最高层次的透明性，如果用户能在全局关系一级操作，则数据如何分布，如何存储等细节自不必关心，其应用程序的编写与集中式数据库相同。
• 复制透明：用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。在分布式数据库系统中，可以把一个场地的数据复制到其他场地存放，应用程序可以使用复制到本地的数据在本地完成分布式操作，避免通过网络传输数据，提高了系统的运行和查询效率。但是对于复制数据的更新操作，就要涉及对所有复制数据的更新。
• 位置透明性：是指用户不必知道所操作的数据放在何处，即数据分配到哪个或哪些站点存储对用户是透明的。因此，数据分片模式的改变，如把数据从一个站点转移到另一个站点将不会影响应用程序，因而应用程序不必改写。
• 局部映像透明性（逻辑透明）：是最低层次的透明性，该透明性提供数据到局部数据库的映像，即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换是由系统完成的。因此，局部映像透明性对异构型和同构异质的分布式数据库系统是非常重要的。

7. 段页式存储

段页式存储管理方式即先将用户程序分成若干个段，再把每个段分成若干个页，并为每一个段赋予一个段名，使用段页表来进行管理。

• 分区式管理：一个程序就是一段，使用基址极限对来进行管理；
• 页式管理：一个程序分为许多固定大小的页面，使用页表进行管理；
• 段页式存储：程序按逻辑分为多段，每一段内又进行分页，使用段页表来进行管理；
• 段式管理：程序按逻辑分成多段，用一组基址极限对来进行管理。基址极限对存放在段表里。

8. 分层结构的特点

首先根据分层的特点来看，分层架构是低耦合的，依赖关系非常简单，上层只能依赖于下层，没有循环依赖。所以底层错误将导致整个系统无法运行，而上层错误一般影响的是错误的这一部分，对整个系统的影响并不是完全的。

其次，系统的风险可以看作是威胁利用了脆弱性而引起的。其中，威胁可以看成从系统外部对系统产生的作用而导致系统功能及目标受阻的现象。脆弱性可以看成是系统内部的薄弱点。脆弱性是客观存在的，但它本身没有实际伤害。层与层之间引入通信机制势必造成性能下降是客观存在的系统薄弱点，是系统脆弱性的体现。

9. 区块链技术

比特币网络通过“挖矿”来生成新的比特币。所谓“挖矿”实质上是用计算机解决一项复杂的数学问题，来保证比特币网络分布式记账系统的一致性。比特币网络会自动调整数学问题的难度，让整个网络约每10分钟得到一个合格答案。随后比特币网络会新生成一定量的比特币作为区块奖励，奖励获得答案的人。

本质上，挖矿的过程就是计算哈希函数，并以此来确认交易的过程。哈希函数值具有不可篡改、不可逆性。但哈希函数输入的原始数据长度是不定长的，可以随意长度，而得出的摘要值是固定长度的。因此，存在一个可能，同样一个哈希值对应的不止一个数据串。这个现象就是哈希碰撞。

工作量证明机制（PoW）是我们最熟知的一种共识机制。工作量证明机制PoW就是工作越多，收益越大。这里的工作就是计算出一个满足规则的随机数，谁能最快地计算出唯一的数字，谁就能做信息公示人。

“双花”问题是指一笔数字现金在交易中被反复使用的现象。传统的加密数字货币和其他数字资产，都具有无限可复制性，人们在交易过程中，难以确认这笔数字现金是否已经产生过一次交易。在区块链技术中，中本聪通过对产生的每一个区块盖上时间戳（时间戳相当于区块链公证人）的方式保证了交易记录的真实性，保证每笔货币被支付后，不能再用于其他支付。在这个过程中，当且仅当包含在区块中的所有交易都是有效的且之前从未存在过的，其他节点才认同该区块的有效性。所以双花攻击解决的方法就是通过时间戳。用户发起的每一笔交易都有时间记录，“挖矿”行为不能防止双花攻击。

• 矿工“挖矿”取得区块链的记账权，同时获得代币奖励；
• “挖矿”本质上是在尝试计算一个Hash碰撞；
• “挖矿”是一种工作量证明机制；
• 用户发起的每一笔交易都有时间记录，“挖矿”行为不能防止双花攻击；

10. DNS的相关应用

当进行DNS解析的时候，需要系统指定一台DNS服务器，以便当系统要解析域名的时候，可以向所设定的域名服务器进行查询。在包括Linux系统在内的大部分UNIX系统中，DNS服务器的IP地址都存放在 /etc/resolv.conf 文件中。也就是说在图形方式配置网络参数的时候，所设置的DNS服务器就是存放在这个文件中的。用户也完全可以用手动的方式修改这个文件的内容来进行DNS设置。配置文件不会放在dev目录下。

在 /etc/resolv.conf 文件的每一行是由一个关键字和随后的参数组成的，常见的关键字有：

• Nameserver：指定DNS服务器的IP地址，可以有多行，查询的时候按照次序进行，只有当一个DNS服务器不能使用的时候，才查询后面的DNS服务器。
• Domain：用来定义默认域名（主机的本地域名）。
• Search：它的多个参数指明域名查询顺序。当要查询没有域名的主机，主机将在由Search声明的域中分别查找。Domain 和 Search 不能共存；如果同时存在，后面出现的将会被使用。

11. 网络相关知识

• 对等网络，即对等计算机网络，是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式。在对等网络中，由于采用总线式的连接，因此网络中的终端数量越多，终端所能够分配到的转发时隙就越小，所带来的延迟也就越大。
• 路由器一般采取存储转发方式，而交换机采取的是直接转发方式，相比存储转发方式，直接转发方式转发时延更小。因为存储转发方式需要对待转发的数据包进行重新拆包，分析其源地址和目的地址，再根据路由表对其进行路由和转发，而直接转发方式不对数据包的三层地址进行分析，因此路由器转发所带来的延迟要大于交换机。
• 数据在Internet中传输时，由于互联网中的转发数据量大且所需经过的节点多，势必会带来更大的延迟。
• 网络延迟=处理延迟+排队延迟+发送延迟+传播延迟。如果不考虑网络环境，服务器的延迟的主要因素是队列延迟和磁盘IO延迟。

12. 系统安全相关知识

系统监视的目标是为了评估系统性能，要监视系统性能，需要收集某个时间段内的3种不同类型的性能数据：

1. 常规性能数据。该信息可帮助识别短期趋势（如内存泄漏）。经过一两个月的数据收集后，可以求出结果的平均值并用更紧凑的格式保存这些结果。这种存档数据可帮助人们在业务增长时作出容量规划，并有助于在日后评估上述规划的效果。
2. 比较基准的性能数据。该信息可帮助人们发现缓慢、历经长时间才发生的变化。通过将系统的当前状态与历史记录数据相比较，可以排除系统问题并调整系统。由于该信息只是定期收集的，所以不必对其进行压缩存储。
3. 服务水平报告数据。该信息可帮助人们确保系统能满足一定的服务或性能水平，也可能会将该信息提供给并不是性能分析人员的决策者。收集和维护该数据的频率取决于特定的业务需要。

进行系统监视通常有3种方式：

• 一是通过系统本身提供的命令，如 UNIX/Liunx 中的 w、ps、last，Windows 中的 netstat 等；
• 二是通过系统记录文件查阅系统在特定时间内的运行状态；
• 三是集成命令、文件记录和可视化技术的监控工具，提供直观的界面，操作人员只需要进行一些可视化的设置，而不需要记忆繁杂的命令行参数，即可完成监视操作，如Windows的Perfmon应用程序。

▲：Linux 的 top 是基于命令行的，Linux 的 iptables 是基于包过滤的防火墙工具。
▲：已经有些厂商提供专业化的监视平台，将上面3种方式集成到一个统一的监控平台，进行统一监控，并提供各类分析数据和分析报表，帮助用户进行性能的评估和诊断。

13. 电子政务

电子政务主要3类角色：政府、企（事）业单位及居民。如果有第4类就是公务员。

• 政府对政府（G2G，Government To Government）：政府之间的互动及政府与公务员之间的互动。包括基础信息的采集、处理和利用，如人口/地理/资源信息等；各级政府决策支持；政府间通信。
• 政府对企业（G2B，Government To Business）：政府为企业提供的政策环境。包括产业政策、进出口、注册、纳税、工资、劳保、社保等各种规定；政府向企事业单位颁发的各种营业执照、许可证、合格证、质量认证等。
• 政府对公民（G2C，Government To Citizen）：政府对公民提供的服务。包括关于社区公安和水、火、天灾等与公共安全有关的信息等，还包括户口、各种证件的管理等政府提供的各种服务。
• 政府对公务员（G2E，Government To Employee）：政府与政府公务员即政府雇员。包括政府机构通过网络技术实现内部电子化管理（例如，OA系统等）的重要形式。
• 企业对政府（B2G，Business To Government）：企业纳税及企业为政府提供服务。包括企业参加政府各项工程的竞/投标，向政府供应各种商品和服务，企业向政府提建议，申诉。
• 公民对政府（C2G，Citizen To Government）：个人除了应向政府缴纳税费和罚款及按政府要求填报各种信息和表格外，更重要的是开辟居民参政、议政的渠道，使政府的各项工作不断得以改进和完善。政府需要利用这个渠道来了解民意，征求群众意见，以便更好地为人民服务。此外，报警服务（盗贼、医疗、急救、火警等）即在紧急情况下居民需要向政府报告并要求政府提供的服务，也属于这个范围。

14. 用户文档

软件系统的文档可以分为用户文档和系统文档两类，它是影响软件可维护性的重要因素。

14.1. 用户文档

用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。用户文档至少应该包括下述5方面的内容。

1. 功能描述：说明系统能做什么。
2. 安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。
3. 使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）。
4. 参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。
5. 操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。

14.2. 系统文档

系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

15. 需求工程

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

16. 软件开发工具

软件开发工具用来辅助开发人员进行软件开发活动，对应软件开发过程的各种活动，软件开发工具包括需求分析工具、设计工具、编码与排错工具、测试工具等。

16.1. 需求分析工具

需求分析工具用以辅助软件需求分析活动，辅助系统分析员从需求定义出发，生成完成的、清晰的、一致的功能规范。按描述需求定义的方法可以将需求分析工具分为基于自然语言或图像描述的工具和基于形式化需求定义语言的工具。

（1）基于自然语言或图形描述的工具：这类工具采用分解与抽象等基本手段，对用户问题逐步求精，并在检测机制的辅助下，发现其中可能存在的问题（如一致性），通过对问题描述的修改，逐步形成能正确反映用户需求的功能规范。比如结构化分析方法采用的数据流图。
（2）基于形式化需求定义语言的工具：基于形式化需求定义语言的工具大多以基于知识的需求智能助手的形式出现，并把人工智能技术运用于软件工程。这类工具通常具有一个知识库和一个推理机制。
（3）其他需求分析工具：可执行规范语言以及原型技术为需求分析工具提供了另一条实现途径，这些工具通过运行可执行规范或原型，将有关的结果显示给用户和系统分析员，以便进行需求确认。

16.2. 设计工具

设计工具用以辅助软件设计活动，辅助设计人员从软件功能规范出发，得到相应的设计规范。

16.3. 编码与排错工具

编码工具和排错工具用以辅助程序员进行编码活动。编码工具辅助程序员用某种程序语言编制源程序，并对源程序进行翻译，最终转换成可执行的代码，主要有编辑程序、汇编程序、编译程序和生成程序等。排错工具用来辅助程序员寻找源程序中错误的性质和原因，并确定其出错的位置，主要有源代码排错程序和排错程序生成程序两类。

16.4. 软件维护工具

软件维护工具辅助软件维护过程中的活动，辅助维护人员对软件代码及其文档进行各种维护活动。软件维护工具主要有版本控制工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等。

16.5. 软件管理和软件支持工具

软件管理过程和软件支持过程往往要涉及软件生存周期中的多个活动，软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质高效地完成。其中常用的工具有项目管理工具、配置管理工具、软件评价工具等。

17. 软件设计阶段的任务

软件设计包括体系结构设计、接口设计、数据设计和过程设计。

• 结构设计：定义软件系统各主要部件之间的关系。
• 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
• 接口设计（人机界面设计）：软件内部、软件和操作系统之间以及软件和人之间如何通信。
• 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

18. 质量属性

信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，并且尽可能少地暴露其内部的处理过程。通常会将困难的决策、可能修改的决策、数据结构的内部连接，以及对它们所做的操作细节、内部特征码、与计算机硬件有关的细节等隐蔽起来。通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代软件设计的一个关键性原则。

18.1. 1、性能

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

• 代表参数：响应时间、吞吐量
• 设计策略：优先级队列、资源调度

18.2. 2、可用性

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

• 代表参数：故障间隔时间
• 设计策略：冗余、心跳线

18.3. 3、安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

• 设计策略：追踪审计

18.4. 4、可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

• 主要策略：信息隐藏

18.5. 5、可靠性

可靠性（reliability）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面：容错、健壮性。

• 代表参数：MTTF、MTBF
• 设计策略：冗余、心跳线

19. 构件的基本概念

如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为5类：

（1）独立而成熟的构件。独立而成熟的构件得到了实际运行环境的多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用。例如，数据库管理系统和操作系统等。
（2）有限制的构件。有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象程序设计语言中的基础类库等。
（3）适应性构件。适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如 ActiveX 等。
（4）装配的构件。装配（ assemble ）的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码（ glue code ）就可以进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。
（5）可修改的构件。可修改的构件可以进行版本替换。如果对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的替换。这种构件在应用系统开发中使用得比较多。

20. 构件与中间件

中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。中间件可以：

1、负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
2、提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
3、提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
4、提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。
5、屏蔽硬件、操作系统、网络和数据库的差异。
6、提供一组通用的服务去执行不同的功能，避免重复的工作，使应用之间可以协作。

21. 软件开发模型

21.1. 瀑布模型

瀑布模型可以说是最早使用的软件生存周期模型之一。由于这个模型描述了软件生存的一些基本过程活动，所以它被称为软件生存周期模型。这些活动从一个阶段到另一个阶段逐次下降，形式上很像瀑布。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。

21.2. 螺旋模型

螺旋模型是在快速原型的基础上扩展而成的。这个模型把整个软件开发流程分成多个阶段，每个阶段都由4部分组成，它们是：
①目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。
②风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。
③开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。
④评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

21.3. 构件组装

构件组装模型通过重用来提高软件的可靠性和易维护性，程序在进行修改时产生较少的副作用。一般开发过程为：设计构件组装→建立构件库→构建应用软件→测试与发布。构件组装模型的优点如下：
（1）构件的自包容性让系统的扩展变得更加容易。
（2）设计良好的构件更容易被重用，降低软件开发成本。
（3）构件的粒度较整个系统更小，因此安排开发任务更加灵活，可以将开发团队分成若干组，并行地独立开发构件。

22. 敏捷开发方法

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

• 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
• 敏捷方法特别强调相关人员之间的信息交流。因为项目失败的原因最终都可以追溯到信息没有及时准确地传递到应该接受它的人。特别提倡直接的面对面交流，交流成本远远低于文档的交流。
• 按照高内聚、松散耦合的原则将项目划分为若干个小组，以增加沟通。

（1）敏捷开发方法是“适应性”（Adaptive）而非“预设性”（Predictive）。
（2）敏捷开发方法是“面向人”（people oriented）而非“面向过程”（process oriented）。

23. 自动化测试相关知识

自动化测试工具主要使用脚本技术来生成测试用例，测试脚本不仅可以在功能测试上模拟用户的操作，比较分析，而且可以用在性能测试、负载测试上。虚拟用户可以同时进行相同的、不同的操作，给被测软件施加足够的数据和操作，检查系统的响应速度和数据吞吐能力。

• 线性脚本，是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。
• 结构化脚本，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。
• 共享脚本，共享脚本是指可以被多个测试用例使用的脚本，也允许其他脚本调用。共享脚本可以在不同主机、不同系统之间共享，也可以在同一主机、同一系统之间共享。
• 数据驱动脚本，将测试输入存储在独立的（数据）文件中，而不是存储在脚本中。可以针对不同数据输入实现多个测试用例。
• 关键字驱动脚本，关键字驱动脚本是数据驱动脚本的逻辑扩展。它将数据文件变成测试用例的描述，采用一些关键字指定要执行的任务。

24. 软件架构相关知识 ？？

当考虑架构时，重要的是从不同的视角 perspective 来检查，这促使设计师考虑具体架构的不同属性。

• 展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。在ABSD（基于架构的软件设计）方法中，使用不同的视角来观察设计元素，一个子系统并不总是一个静态的架构元素，而是可以从动态和静态视角观察的架构元素。
• 将选择的特定视角或视图与Kruchten提出的类似，也就是逻辑视图、进程视图、实现视图和配置视图。
  • 使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能性能等。
  • 进程视图也称为并发视图，使用并发视图来检查系统多用户的并发行为。使用“并发”来代替“进程”，是为了强调没有对进程或线程进行任何操作，一旦这些执行操作，则并发视图就演化为进程视图。
  • 使用的最后一个视图是配置视图，配置视图代表了计算机网络中的节点，也就是系统的物理结构。
  • 开发视图又称为实现视图，显示的是源代码以及实际执行代码的组织结构。

25. 架构评估

• 敏感点是一个或多个构件（和/或构件之间的关系）的特性。
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
• 风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
• 非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

26. C/S架构风格

26.1. 二层C/S结构

C/S架构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。

C/S软件架构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。但随着企业规模的日益扩大，软件的复杂程度不断提高，传统的二层C/S结构存在以下几个局限：

1. 二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；
2. 软、硬件的组合及集成能力有限；
3. 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；
4. 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

26.2. 三层C/S结构

正是因为二层C/S有这么多缺点，因此，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三个部分。

26.2.1. 表示层

表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。

26.2.2. 功能层

功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。

26.2.3. 数据层

数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用SQL语言。

27. 设计模式的基本概念

设计模式是一套可以被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且提高代码的可靠性。设计模式的分类：

27.1. （1）根据目的分类

27.1.1. 创建型

创建型主要用于创建对象。有工厂方法模式（Factory Method）、抽象工厂模式（Abstract Factory）、建造者模式（Builder）、原型模式（Prototype）、单例模式（Singleton）共5种。

27.1.2. 结构型

结构型主要用于处理类和对象的组合。有适配器模式（Adapter）、桥接模式（Bridge）、组合模式（Composite）、装饰模式（Decorator）、外观模式（Facade）、享元模式（Flyweight）、代理模式（Proxy）共7种。

27.1.3. 行为型

行为型主要用于描述类或对象怎样交互和怎样分配职责。有职责链模式（Chain of Responsibility）、命令模式（Command）、解释器模式（Interpreter）、迭代器模式（Iterator）、中介者模式（Mediator）、备忘录模式（Memento）、观察者模式（Observer）、状态模式（State）、策略模式（Stratege）、模板方法模式（Template Method）、访问者模式（Visitor）共11种。

27.2. （2）根据作用范围分类

可分为类模式和对象模式。

• 类模式用于处理类和子类的关系，这种关系通过继承建立，在编译时就确定了，是一种静态关系。
• 对象模式处理对象间的关系，具有动态关系。

28. 设计模式

• Prototype（原型模式）：用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象。允许对象在不了解创建对象的确切类以及如何创建细节的情况下创建自定义对象。
• Abstract Factory（抽象工厂模式）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
• Builder（构建器模式）：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示。
• Singleton（单例模式）：保证一个类只有一个实例，并提供一个访问它的全局访问点。

29. 质量属性的理解和质量属性实现策略

• 对于题干描述：“网站在并发用户数量10万的负载情况下，用户请求的平均响应时间应小于3秒”，主要与性能质量属性相关，实现该属性的常见架构策略包括：增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
• “主站宕机后，系统能够在10秒内自动切换至备用站点并恢复正常运行”主要与可用性质量属性相关，通常可采用心跳、Ping/Echo、主动冗余、被动冗余、选举等架构策略实现该属性。
• “系统完成上线后，少量的外围业务功能和界面的调整与修改不超过10人/月”主要与可修改性质量属性相关，通常可采用接口-实现分离、抽象、信息隐藏等架构策略实现该属性。

30. SYN Flooding攻击原理

SYN Flood攻击利用TCP三次握手的一个漏洞向目标计算机发动攻击。攻击者向目标计算机发送 TCP 连接请求（ SYN 报文），然后对于目标返回的 SYN-ACK 报文不作回应。目标计算机如果没有收到攻击者的ACK回应，就会一直等待，形成半连接，直到连接超时才释放。攻击者利用这种方式发送大量 TCP SYN 报文，让目标计算机上生成大量的半连接，迫使其大量资源浪费在这些半连接上。目标计算机一旦资源耗尽，就会出现速度极慢、正常的用户不能接入等情况。攻击者还可以伪造 SYN 报文，其源地址是伪造的或者不存在的地址，向目标计算机发起攻击。SYN Flooding 攻击与 TCP 报文的处理过程没有很大的关系。

31. 数字证书相关应用

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机、服务器应用程序提供强大的认证服务。 Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）来执行认证服务的。Kerberos也能达到单点登录的效果，即当 Client 通过了 Kerberos server 的认证后，便可以访问多个 Real Server。

目前常用的密钥分配方式是设立密钥分配中心 KDC，KDC是大家都信任的机构，其任务就是给需要进行秘密通信的用户临时分配一个会话密钥。目前用得最多的密钥分配协议是 Kerberos 。Kerberos使用两个服务器：认证服务器AS、票据授权服务器TGS。在 Kerberos 认证系统中，用户首先向认证服务器AS申请初始票据，然后票据授权服务器（TGS）获得会话密码。

Kerberos可以防止偷听和重放攻击，保护数据的完整性。当客户向票据授予服务器（TGS）请求会话票据时会发送用于会话密钥加密的时间戳，以防止重放攻击；当客户使用从票据授予服务器获取的会话票据请求登录时，要附上用该会话票据加密的时间戳，以防止重放攻击。

32. 著作权法 ▲

《中华人民共和国著作权法》规定：作者的署名权、修改权、保护作品完整权的保护期不受限制。发表权的保护期限为作者终生及死后50年（第50年的12月31日），发行权和复制权的保护期限为作者终生及死后50年（第50年的12月31日），合作开发以最后死亡作者为准。

33. 知识产权人确定 ▲

根据题目描述，该软件公司的研发人员参与开发的该软件是职务作品，因此该软件著作权属于公司，且该研发人员将该软件中的算法和部分程序代码公开发表的行为涉嫌侵犯公司的软件著作权。

根据《合同法》的诚实信用原则和劳动者对单位的忠实义务，保守商业秘密的义务属于法定的义务，权利人与义务人即使没有约定保密期限，只要该项商业秘密未被公开，仍然具有经济价值，且权利人对其采取了合理的保密措施，属于法律意义上的商业秘密，则知悉该商业秘密的单位和个人就应当继续履行保密义务，直到该项商业秘密公开为止，即当事人保密义务的期限与商业秘密的存续期限相同。但当事人另有约定的，依约定。无论什么原因导致商业秘密被公之于众，其“秘密性”不复存在，也就不能作为商业秘密继续保护。因为该研发人员将该软件中的算法和部分程序代码公开发表了，其“秘密性”不复存在，也就丧失了这套应用软件的商业秘密权。

34. 盈亏平衡点的数学题

某厂生产的某种电视机，销售价为每台2500元，去年的总销售量为25000台，固定成本总额为250万元，可变成本总额为4000万元，税率为16%，则该产品年销售量的盈亏平衡点为（）台(只有在年销售量超过它时才能盈利)。

盈亏平衡点也称为零利润点或保本点，是全部销售收入等于全部成本时的产量。当销售收入高于盈亏平衡点时，表示企业是盈利的状态；当销售收入低于盈亏平衡点时，表示企业是亏损的状态。
▲ 可变成本每年不一样，但比例一样；

去年卖了25000台电视机，每台售价2500元，固定成本250万，可变成本4000万，税率16%。
==> 总营收：25000*2500=6250万
==> 固定成本：250万
==> 可变成本：4000万，占营收比例：64%（4000万/6250万=64%）。
==> 税不属于成本，但与可变成本性质相似，会随销量变化。

设盈亏平衡时的销售量为X台，则有：2500000+X*2500*64%+X*2500*16%=X*2500

500X=2500000，解得：X=5000

35. 系统设计

系统设计的目的是指定一种（ 应用体系架构 ），它定义了用于构建拟议信息系统的技术。此任务通过分析最初在（ 需求分析 ）期间创建的数据模型和流程模型来完成。（ 物理数据流图 ）用于跨网络建立物理过程和数据存储。为了完成这项活动，分析师可能会让许多系统设计师和（ 系统用户 ）参与这项活动，以帮助解决业务数据、流程和位置问题。这项任务的关键输入是从各种来源征求的事实、建议和意见，以及决策分析阶段获得的批准（ 系统建议书 ）。