系统架构师案例分析（真题知识点整理、记忆）
目录
1. 软件架构风格与设计
1.1 MVC架构风格
1.2 系统负载均衡
1.3 企业服务总线（ESB）
1.4 软件架构风格
1.5 Web Service
1.6 C/S架构中的瘦客户端和胖客户端
2. 系统需求分析
2.1 数据流图
2.2 用例图
2.3 面向对象建模
3. 设计模式
3.1 分类
4. 系统设计
4.1 系统需求
4.2 UML的状态图和活动图
5. 软件系统建模
6. 软件架构评估
6.1 质量属性
6.2 质量效用树
7. 分布式系统设计
7.1 redis分布式缓存
7.2 分布式数据库（nosql)
8. 数据库系统设计
9. 系统可靠性分析和设计
9.1 可靠性
9.2 可靠性技术（容错技术）
9.3 可靠度和失效率
9.4 检错技术
10. 系统安全性设计
10.1 机密性和完整性
1.6 主程序-子程序（调用返回风格）
1.7 管道-过滤器风格（数据流风格）
11. Web应用架构设计
11.1 MVC软件架构
11.2 SOA面向服务的应用架构
11.3 响应式Web设计
11.4 3层C/S应用服务器
11.5 数据持久层
1. 软件架构风格与设计
1.1 MVC架构风格
MVC 架构风格：用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
MVC 架构将整个软件系统划分为模型、视图和控制器 3 个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中的业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。
MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。
MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。
1.2 系统负载均衡
-
基于 DNS 的负载均衡
在 DNS 服务器中为同一个主机名配置多个 IP 地址，在应答 DNS 查询时，DNS 服务器对每个查询将以 DNS 文件中主机记录的 IP 地址按顺序返回不同的解析结果，将客户端的访问引导到不同的节点上去，使得不同的客户端访问不同的节点，从而达到负载均衡的目的。
DNS 负载均衡的优点是经济、简单易行，并且节点可以位于 Internet 上任意的位置。但它也存在不少缺点，例如，为了保证 DNS 数据及时更新，一般都要将 DNS 的刷新时间设置得较小，但太小就会造成太大的额外网络流量，并且更改了 DNS 数据之后也不能立即生效；DNS 负载均衡采用的是简单的轮转算法，不能区分节点之间的差异，不能反映节点的当前运行状态，不能做到为性能较好的节点多分配请求，甚至会出现客户请求集中在某一个节点上的情况。另外，要给每个节点分配一个 Internet 上的 IP 地址，这势必会占用过多的 IP 地址。
-
反向代理负载均衡
反向代理负载均衡是将来自 Internet 上的连接请求以反向代理的方式动态地转发给内部网络上的多个节点进行处理，从而达到负载均衡的目的。反向代理负载均衡既能以软件方式实现，也能在高速缓存器和负载均衡器等硬件设备上实现。反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提高系统性能。另外，由于网络外部用户不能直接访问真实的节点计算机，反向代理负载均衡还具备额外的安全性。
-
基于NAT的负载均衡
1.3 企业服务总线（ESB）
ESB 是传统中间件技术与 XML、Web 服务等技术结合的产物，主要支持异构系统 集成。ESB基于
内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列的标准接口 。
ESB 的主要功能：
ESB的部署灵活性、系统耦合性和可扩展性：采用ESB作为集成框架，能够实现灵活的部署结构，包括CS结构、P2P结构等。采用ESB作为集成框架，待集成系统只需要和总线进行联系，彼此之间不需要互相通信，这样就大大降低了系统的耦合程度。采用ESB作为集成框架，在加入新的待集成系统时，只需要采用插件的方式实现传输协议和数据格式的适配即可，系统的可扩展性较强。
1.4 软件架构风格
软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。 软件架构风格描述了一个系统家族，即一个架构定义了一个词汇表和一组约束。
-
案例
解释器架构风格设计步骤：具体来说，需要：
- 为可视化编程元素及其拖拽关系定义某种语言，并描述其语法与语义；
编写解释器对该语言进行解释
- 生成对应的脚本语言程序。
采用隐式调用架构风格设计步骤：具体来说，首先
- 需要定义“断点在调试过程中命中”这一事件，并实现当断点命中后的屏幕定位函数
- 集成开发环境维护一个事件注册表结构，将该事件与屏幕定位函数关联起来形成注册表中的一个记录项
- 在调试过程中，集成开发环境负责监听各种事件，当“断点在调试过程中 命中”这一事件发生时，集成开发环境查找事件注册表，找到并调用屏幕定位函数，从而实现脚本语言编辑界面与调试代码的自动定位。
分析系统的用户交互性、系统扩展性、数据管理等方面来决策使用哪种架构风格。
1.5 Web Service
面向服务的架构和面向资源的架构对比：王工（面向服务）、李工（面向资源）
从数据获取方式看，王工的方案需要将现有的多个系统和异构的数据源包装为服务，采用 Web 服
务暴露数据接口，客户端需要通过服务调用获取数据，这种方法工作量大，复杂度较高。
李工的方案则绕开了复杂的功能封装，只需要明确数据的位置与标识，通过特定的网络协议(json,xml)直接使用标识定位并获取数据，与王工的方案相比工作量小，实现简单。
从数据交互方式看，王工的方案采用远程过程调用和异步 XML 消息等模式实现数据交互，这种方
式适合于系统之间功能调用时进行的少量数据传输，而在进行单纯的数据访问时效率不高，稳定性也较差。李工的方案则以数据资源为核心，在对数据资源进行标识的基础上，通过标识符直接对数据资源进行访问与交互，实现简单且效率较高。
从数据访问的上下文无关性看，王工的方案中数据访问是上下文有关的，具体表现在每次客户端进行数据请求都需要附加唯一的请求标识，并且服务端需要区分不同的客户端请求，效率较低。李工的方案中数据访问是上下文无关的，客户端通过全局唯一的统一资源标识符（URI）请求对应的数据资源，服务端不需要区分不同的客户端请求。
1.6 C/S架构中的瘦客户端和胖客户端
（a）无论胖还是瘦，要做到用户界面的个性化应该都没有问题，而且难说哪种更强。毕竟瘦的只是把业务逻辑从客户端放到了服务器上。
（b）胖和瘦无明显差异。
（c）胖客户端，在客户端的运算能力强一些。瘦客户端可以在服务端面用集群做支持。谁更强一点?（d）瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容，而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势。
（e）胖客户端的后端是数据库，没有业务逻辑，此时要做加密传输没有基础，但瘦客户端可以做到。（f）胖客户端做到2G数据缓存很容易，而瘦客户端不现实。
（g）瘦客户端与胖客户端均可做到。
（h）瘦客户端与胖客户端均可做到。
2. 系统需求分析
2.1 数据流图
绘制数据流图场景的错误：
2.2 用例图
EssentialUseCases可翻译为抽象用例，RealUseCases可翻译为基础用例。
他们是区别在于：基础用例是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的。抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。
2.3 面向对象建模
用例之间的关系: 泛化、包含、扩展 。
-
泛化：多个用例共同拥有一个类似的结构和行为，可以抽象成父用例和子用例
-
包含：可以从两个或多个用例中提取公共行为
-
扩展：一个用例混合了两种以上的不同场景，可以分为一个基本用例和多个扩展用例。
类之间的关系：泛化、实现、依赖、关联、聚合、组合 。
3. 设计模式
3.1 分类
4. 系统设计
4.1 系统需求
-
系统性能需求（PerformanceRequirements）：指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标可归为此类。
-
安全性需求（SecurityRequirements）：系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。
-
操作性需求（OperationalRequirements）：与用户操作使用系统相关的一些需求。
-
文化需求（CulturalRequirements）：带有文化背景因素的系统需求。
4.2 UML的状态图和活动图
状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。
活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。
两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。
5. 软件系统建模
6. 软件架构评估
6.1 质量属性
6.2 质量效用树
1、性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
代表参数：响应时间、吞吐量设计策略：优先级队列、资源调度
2、可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
代表参数：故障间隔时间设计策略：冗余、心跳线
3、安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
设计策略：追踪审计
4、可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
设计策略：信息隐藏、接口与实现分离。
此外风险点、非风险点、敏感点与权衡点要能正确区分：
系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
7. 分布式系统设计
7.1 redis分布式缓存
7.2 分布式数据库（nosql)
8. 数据库系统设计
9. 系统可靠性分析和设计
9.1 可靠性
可靠性（Reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。子特性：成熟性，容错性，易恢复性，可靠性的依从性。
9.2 可靠性技术（容错技术）
-
N版本程序设计
-
恢复块方法
-
防卫式程序设计
-
双机热备或集群系统
-
冗余设计
动态冗余又称为主动冗余，它是通过故障检测、故障定位及故障恢复等手段达到容错的目的。其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来替代它并重新运行。各备用模块在其待机时，可与主模块一样工作，也可以不工作。前者叫热备份系统（双重系统），后者叫冷备份系统（双工系统、双份系统）。
N 版本程序设计是一种静态的故障屏蔽技术，其设计思想是用 N 个具有相同功能的程序同时执行一项计算，结果通过多数表决来选择。其中 N 个版本的程序必须由不同的人独立设计，使用不同的方法、设计语言、开发环境和工具来实现，目的是减少 N 个版本的程序在表决点上相关错误的概率。
9.3 可靠度和失效率
可靠度就是系统在规定的条件下、规定的时间内不发生失效的概率。
失效率又称风险函数，也可以称为条件失效强度，是指运行至此刻系统未出现失效的情况下，单位时间系统出现失效的概率。
组合模型下可靠度的计算方法为：
串联系统：R=R1×R2×……×Rn；
并联系统：R=1-(1-R1) ×(1-R2) ×……×(1-Rn)；
9.4 检错技术
检错技术实现的代价一般低于容错技术和冗余技术 ，但有一个明显的缺点，就是不能自动解决故障，出现故障后如果不进行人工干预，将最终导致软件系统不能正常运行。
检错技术常见的实现方式：
-
最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理；
-
计算运行时间也是一种常用技术，如果某个模块或函数运行时间超过预期时间，可以判断出现故障；
-
还有置状态标志位等多种方法，自检的实现方式需要根据实际情况来选用。
检错技术的处理方式，大多数都采用“查处故障-停止软件运行-报警”的处理方式。但根据故障的不同情况，也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。
10. 系统安全性设计
10.1 机密性和完整性
1.6 主程序-子程序（调用返回风格）
主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。
1.7 管道-过滤器风格（数据流风格）
管道-过滤器架构风格中，每个构件都有一组输入和输出，构件接受数据输入，经过内部处理，然后产生数据输出。这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。
11. Web应用架构设计
11.1 MVC软件架构
MVC 是一种目前广泛流行的软件设计模式。MVC 强制性地把一个应用的输入、处理、输出流程按照视图、控 制、模型的方式进行分离，形成了三个核心模块：控制器、模型、视图。
（1）控制器（Controller）：控制器接受用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与 Model 的接口。一方面它解释来自于视图的输入，将其解释成为系统能够理解的对象，同时它也识别用户 动作，并将其解释为对模型特定方法的调用；另一方面，它处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。
（2）模型（Model）：模型是应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。由于同一个模型可以被多个视图重用，所以提高了应用的可重用性。
（3）视图（View）：视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。视图可以向模型查询业务状态，但不能改变模型。视图还能接受模型发出的数据更新事件，从而对用户界面进行同步更新。
EJB中的Bean:
Session Bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，Session Bean 和它的数据都将消失；
Entity Bean 描述了存储在数据库表中的一行持久稳固的数据，如果客户端终止或者服务结束，底层的服务会负责 entity Bean 数据的存储。
Message-driven bean 结合了 Session Bean 和 Java 信息服务（JMS）信息监听者的功能，它允许一个商业组件异步地接受 JMS 消息。
11.2 SOA面向服务的应用架构
SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
ESB作用与特点：
1、SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合；2、描述服务的元数据和服务注册管理；
3、在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；
4、发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
11.3 响应式Web设计
响应式web设计是指我们设计与开发的页面可以根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。
实现方式：
（1）流式布局
（2）弹性布局（如弹性图片）
（3）媒体查询
11.4 3层C/S应用服务器
应用服务器是指通过各种协议把商业逻辑曝露给客户端的程序。它提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器使用此商业逻辑就像调用对象的一个方法一样。简单的说能实现动态网页技术的服务器叫做web应用服务器。
1、若系统负荷很大，可以布署多台应用服务，多台应用服务器分担任务，以达到性能 要求。
2、应用服务器可以通过灵活的增加服务器完成扩展，所以可扩展性 很好。
3、应用服务器可长时间稳定运行。因为当一台应用服务器出现故障时，可以将当前运行的事务转移至正常应用服务器上完成执行，不影响业务正常执行，从而保障高可靠性与稳定性 。
11.5 数据持久层
数据持久层是一组软件服务，将应用程序与该程序所使用的数据源分离，为整个项目提供一个统一、安全、并发的数据持久机制。
好处：
1、程序代码重用性强，即使更换数据库，只需要更改配置文件，不必重写程序代码。2、业务逻辑代码可读性强，在代码中不会有大量的SQL语言，提高程序的可读性。
3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。
4、简化开发工作，让开发人员更关注于业务逻辑的开发。
5、通过对象/关系映射向业务逻辑提供面向对象的数据访问。
参考
- 《系统架构师考试》
关于作者：
犇叔，浙江大学计算机科学与技术专业，研究生毕业，而立有余。先后在华为、阿里巴巴和字节跳动，从事技术研发工作，资深研发专家。主要研究领域包括虚拟化、分布式技术和存储系统（包括CPU与计算、GPU异构计算、分布式块存储、分布式数据库等领域）、高性能RDMA网络协议和数据中心应用、Linux内核等方向。
专业方向爱好：数学、科学技术应用
关注犇叔，期望为您带来更多科研领域的知识和产业应用。
内容坚持原创，坚持干货有料。坚持长期创作，关注犇叔不迷路