Appearance
软件架构设计
更新: 4/10/2025 字数: 0 字 时长: 0 分钟
架构基本概念（⭐⭐⭐）
软件架构 = 软件体系结构（学术界），处于需求分析和软件设计之间，填平了它们之间的鸿沟。
架构设计就是需求分配，即将满足需求的职责分配到组件上。
架构的本质
- 软件架构为软件系统提供一个结构、行为和属性的高级抽象。
- 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
架构的作用
- 软件架构是项目干系人进行交流的手段。
- 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
- 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
- 能够支持项目计划和项目管理等活动
提示
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
架构设计与生命周期
4+1视图
架构描述语言ADL（⭐）
ADL是一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。
- C2SADL：基于组件和消息
- Wright：分布、并发类型
- ACME：架构互换语言
- UniCon：基于组件和连接
- Rapide：基于事件
三个基本要素：
- 构件：计算或数据存储单元
- 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
- 架构配置：描述体系结构的构件与连接件的连接图
基于架构的软件设计方法（⭐⭐⭐⭐）
基于架构的软件设计（Architecture-Based Software Design，ABSD）方法是架构驱动，即由构成架构的业务【商业】、质量和功能需求的组合驱动。
三个基础：
- 功能的分解：使用已有的基于模块的内聚和耦合技术。
- 通过选择架构风格来实现质量和商业需求
- 软件模板的使用
ABSD相关概念：
- 设计元素：自顶向下，递归细化。最顶层系统被分为概念子系统和若干个模板；概念子系统又被分解为概念构件和附加软件模板。
- 视角与视图：描述软件架构。不同的视角会有不同的视图。
- 用例与质量场景：用例用来捕获功能需求；质量场景（刺激、环境、响应）用来捕获质量需求。
提示
架构复审【架构评估】的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。
架构需求与设计过程
架构文档化
主要输出2个文档：
- 架构规格说明书
- 测试架构需求的质量设计文档
文档的完整性和质量是软件架构成功的关键因素。
文档的注意事项：
- 文档需要从使用者的角度进行编写
- 必须分发给所有与系统有关的开发人员
- 必须保证开发者手上的文档是最新的，但更新不能太频繁
架构实现与演化过程
软件架构风格（⭐⭐⭐⭐⭐）
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
数据流风格
批处理
构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个单独的程序，每一步必须在前一步结束后开始，并且数据必须是完整的，以整体方式传递。
特点：大量整体数据、无需用户交互
| 优点 | 缺点 | 典型应用 |
|---|---|---|
|
|
|
管道-过滤器
一个处理步骤的输出是另一个处理步骤的输入，每个处理步骤由一个过滤器实现，其之间的数据由管道负责。构件是过滤器，连接件是管道。
特点：流式数据，弱用户交互，需要数据格式转换
调用/返回风格
将复杂系统分解为若干个子系统，分而治之，降低复杂度，并且增强可修改性。
主程序/子程序
把问题分为若干个处理步骤。构件为主程序和子程序，连接件为过程调用，充当交互机制。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
面向对象
构件是对象，对象是抽象数据类型的实例。数据的表示和它们的相应操作封装在一个抽象数据类型或对象上。
分层架构
构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上层提供服务，使用下层的服务，只能见到与自己相邻的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的层（通常只影响上层）。
特点：
- 各个层次的组件形成不同功能级别的虚拟机
- 多层相互工作，而且实现透明
优点：
- 良好的可重用性，只要接口不变可用在其它位置
- 可维护性好
- 可扩展性好，支持递增设计
缺点：
- 并不是每个系统都方便分层
- 很难找到一个合适的、正确的层次抽象方法：层次多了会影响性能，层次少了可能带来逻辑结构划分不清楚的问题。
- 不同层次之间耦合度高的系统很难实现
以数据为中心的风格
特点：数据共享
例子：操作系统的注册表
仓库体系结构
仓库是存储和维护数据的中心场所，即以数据为中心。
两种构件：
- 中央数据结构：说明当前数据的状态
- 对中央数据结构进行操作的独立构件
特点： - 数据存储在中心仓库，处理流程独立，支持交互。
- 数据与处理解耦合，可动态添加和删除处理组件；但这也导致需要加载数据，性能降低。
- 数据处理组件之间通常无依赖关系，支持并发调用。
例子：现代编译器的集成开发环境（包括代码编辑、语法高亮、代码编译、运行调试等），中心数据就是程序语法树。
黑板体系结构
包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板。黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介。
本身黑板系统可以用数据库系统实现，只是在数据库系统的基础上加了触发机制：黑板上的信息变动时会触发知识源做相应的处理。
适用于解决复杂的非结构化问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。
优点：
- 可更改性和可维护性
- 可重用的知识源
- 容错性和健壮性
缺点：
- 测试困难
- 不能保证有好的解决方案
- 难以建议好的控制策略
- 低效、开发困难
- 缺少并行机制
特点：在以数据为中心的基础上，使用中心数据触发业务逻辑部件。
典型示例：语音识别、模式识别、图像处理、知识推理
超文本系统
构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。
通常应用在互联网领域。
现代集成编译环境一般采用此架构风格。
虚拟机风格
人为构建一个运行环境，解析与运行自定义语言，提高架构的灵活性。
优点：可灵活应对自定义场景
缺点：复杂度较高
解释器风格
组成部分：
- 完成解释工作的解释器引擎
- 包含将被解释的代码存储区
- 记录解释器引擎当前工作状态的数据结构
- 记录源代码被解释执行的进度的数据结构
具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。缺点是执行效率较低。
适用于需要自定义规则的场景。
规则系统风格
以规则为中心，在解释器的基础上增加了经验规则（知识库），包括：
- 规则集
- 规则解释器
- 规则/数据选择器
- 工作内存
适用于人工智能领域、专家系统、DSS等。
独立构件风格
强调系统中的每个构件都是相对独立的个体，它们之间不直接通信以降低耦合度，提升灵活性。
特点：
- 系统由若干个子系统构成且成为一个整体
- 系统有统一的目标
- 子系统有主从之分
- 每一个子系统有自己的事情收集和处理机制
优点：
- 松耦合
- 良好的可重用性、可扩展性、可修改性
缺点：
- 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
- 数据交换的问题。
- 既然过程的语义依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
进程通信风格
构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程调用等。简单理解就是消息队列的模式。
事件驱动风格
又称隐式调用风格。构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。简单理解就是发布-订阅模式。
优点：为软件复用提供了强大的支持，为构件的维护和演化带来了方便。
缺点：放弃了对系统计算的控制。
例子：
- 编程环境中用于集成各种工具
- 数据库管理系统中确保数据的一致性约束
- 在用户界面系统中管理数据
- 编辑器中支持语法检查，监控断点事件等
相关技术：消息中间件的发布订阅功能，消息中间件是构件组装的常用手段。
汇总表：
| 体系结构风格 | 构件 | 连接件 |
|---|---|---|
| 批处理 | 独立的应用程序（计算单元） | 某种类型的媒介 |
| 管道-过滤器 | 过滤器 | 管道 |
| 主程序/子程序 | 主程序和子程序 | 过程调用 |
| 面向对象 | 对象（抽象数据类型的实例） | 过程调用 |
| 层次型 | 各层 | 由通过决定层间如何交互的协议来定义 |
| 仓库体系结构 | 中央数据结构及其操作 | 仓库与构件间的交互 |
| 进程通信风格 | 独立的进程 | 消息传递 |
| 事件系统风格 | 模块（过程或事件集合） | 以过程之间的隐式调用来实现 |
闭环控制架构【过程控制】
适用于嵌入式系统，用于解决简单闭环控制问题。
经典应用：空调温控，定速巡航
C2架构
了解即可，不必深究！
基本规则：
- 构件和连接件都有一个顶部和一个底部
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其它构件和连接件连接
- 当两个连接件进行直接连接时，必须由其中一个底部到另一个的顶部
MDA（⭐⭐）
Model Driven Architecture，模型驱动架构，是一种形式化方法。 MDA起源于分离系统规约和平台实现的思想。
- Model：客观事物的抽象表示
- Architecture：构件系统的部件、连接件及其约束的规约
- Model Driven：使用模型完成软件的分析、设计、构建、部署、维护等各开发活动
核心模型
- 计算无关模型【CIM】：CIM对系统中使用的重要的领域抽象进行建模，也称为领域模型。
- 平台独立模型【PIM】：具有高抽象层次、独立于任何实现技术的模型。如UML。
- 平台相关模型【PSM】：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
- 代码【Code】：用源代码对系统的描述（规约）。每个PSM都将被变换成代码
主要目标
- 可移植性（Portability）：先建立PIM，然后建立PSM，1个PIM可转换成多个PSM，要移植到另一个平台，只需将平台无关模型转成平台对应的相关模型即可。
- 互通性【互操作性】（Interoperability）：整个开发过程都是模型驱动，标准化程度很高。
- 可重用性（Reusability）
- 文档和代码的一致性：代码是由模型生成的，所以具有天然的一致性。
软件架构复用（⭐⭐）
软件复用是一种系统化的软件开发过程，通过识别、分析、分类、获取和修改软件实体，以便在不同软件开发过程中重复使用它们。
软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等。
软件复用发展线路：
软件复用基本过程：
可复用资产范围有多广？
需求、架构设计、元素、建模与分析、测试、项目规划、过程、方法和工具、人员、样本系统、缺陷消除
特定领域软件架构（⭐⭐⭐）
DSSA（Domain Specific Software Architecture）以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。
领域分类
- 垂直域：相同领域，深入
- 水平域：不同领域，平移
DSSA必备特征
- 一个严格定义的问题域和/或解决域
- 具有普遍性，使其可以用于领域中特定应用的开发
- 对整个领域的合适程度的抽象
- 具备该领域固定的、典型的在开发过程中可重用的元素
DSSA基本活动
- 领域分析：获得领域模型
- 领域设计：获得DSSA
- 领域实现：依据领域模型和DSSA开发和组织可重用信息
参与DSSA的人员
- 领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
- 领域分析人员：应由有具有知识工程背景的有经验的系统分析员来担任。
- 领域设计人员：应由有经验的软件设计人员来担任。
- 领域实现人员：应由有经验的程序设计人员来担任。
DSSA建立过程
建立过程是并发的、递归的、反复的、螺旋形的，其目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。
- 定义领域范围
- 定义领域特定的元素
- 定义领域特定的设计和实现需求约束
- 定义领域模型和架构
- 产生、搜集可重用的产品单元
三层次模型
软件产品线（⭐⭐⭐）
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
核心资产库是产品构造的基础，领域工程的所有结果的集合。
特征：过程驱动，以架构为中心的核心产品，特定领域的技术支持
成功实施产品线的主要因素：
- 对该领域具备长期和深厚的经验
- 一个用于构建产品的好的核心资源库
- 好的产品线架构
- 好的管理支持（软件资源、人员组织、过程）
构件（⭐⭐⭐）
构件的定义
定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。
构件系统架构特性：
- 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
- 构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时也是一组固定地作用域构件层次机制的策略。
- 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
- 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于：大多数原子构件永远都不会被单独部署（尽管它们可以被单独部署）。
- 一个原子构件是一个模块和一组资源。
- 模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
- 资源是一个类型化的项的固定集合。资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其它的资源。在”纯对象“的方法中，资源是外部化的不可改变的对象——不可改变是因为构件没有持久化的标志，而且复制不能被区分。
- 系统构件组装分为三个不同层次：定制、集成、扩展。
构件的复用
检索与提取构件
方法 特点 基于关键字的检索 树形或有向无回路图结构 刻面检索法 利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其它特征。如分多个刻面：应用领域、使用环境、功能 超文本检索法 按照人类的联想思维方式任意跳转到包含相关概念或构件的文档 理解与评价构件
- 要复用构件，准备地理解构件至关重要。特别是对构件修改使用时。
- 为达到目的，必须要求构件的开发过程遵循公共标准。
- 一般构件库的文档中全面而准备地说明以下内容：
- 构件的功能与行为
- 相关的领域知识
- 可适应性约束条件与例外情形
- 可以预见的修改部分及修改方法
修改构件
- 理想状态下是直接复用构件库中现成的构件，但大多数情况下，必须对构件进行或多或少的修改以应对新需求。
- 为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍然不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
- 构件库中若无修改使用的构件，则按新需求开发构件并存入构件库。
组装构件
组装的3种方式：
- 基于功能的组装：采用子程序调用和参数传递的方式将构件组装起来。
- 基于数据的组装：仍然是传统的子程序调用与参数传递，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法。例如：Jackson系统开发方法。
- 面向对象的组装：如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类以满足新系统的需求。
构件组装失配问题：
- 由构件引起的失配：包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
- 由连接子引起的失配：包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
- 由于系统成分对全局体系结构的假设存在冲突引起的失配等。
要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除。
构件分类
从构件的外部形态来看，构件可分为5类：
- 独立而成熟的构件：已在实际运行环境多次检验，该类构件隐藏了所有接口，用户只需要用规定好的命令进行使用。如：数据库管理系统、操作系统等。
- 有限制的构件：有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象程序设计语言中的基础类库等。
- 适应性构件：适应性构件进行包装或使用了接口技术，把不兼容、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如ActiveX等。
- 装配的构件：装配的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码就可以进行连接使用。目前一些软件商提供的大多数软件产品都属于这一类。
- 可修改的构件：对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的版本替换。这种构件在应用系统开发中使用得比较多。
构件标准
COBRA
- 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
- 对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便它们使用ORB内部的某些功能。
- 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户端不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
J2EE【EJB】
- 会话Bean：实现业务逻辑，负责完成服务端与客户端的交互
- 实体Bean：实现O/R映射，简化数据库开发工作
- 消息驱动Bean：处理并发与异常访问
已逐渐被轻量级微服务框架Spring Cloud所取代。
DNA 2000
微软发布的分布计算体系结构和规范。
| 优点 | 缺点 | |
|---|---|---|
| CORAB | 全面、互操作性和开放性好 | 庞大且复杂，接口标准更新慢 |
| EJB | 支持跨平台，提供了远程访问、持久化、安全和生命周期等机制 | 服务治理能力较弱 |
| DNA 2000 | 不支持跨平台 |
中间件（⭐⭐⭐）
中间件是一类构件，是一类系统软件。
特点：简化结构、屏蔽差异、利于复用。
采用中间件技术的优点：
- 面向需求：设计师集中精力于业务逻辑本身。
- 业务的分隔和包容性：应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
- 设计与实现隔离：构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关系其内部实现，这是设计与实现分离的关键。
- 隔离复杂的系统资源：架构很重要的一个功能是将系统资源与应用构件隔离，这是保证构件可复用甚至“即插即用”的基础，与中间件的意图也是一致的。
- 符合标准的交互模型：中间件实现了架构的模型，实现了标准的协议。
- 软件复用：中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
- 提供对应用构件的管理：基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。
中间件分类
| 分类 | 特点 | 示例 |
|---|---|---|
| 通信处理（消息）中间件 | 可靠、高效、实施跨平台通信。 | eLink、MQSeries |
| 事务处理（交易）中间件 | 事务分发、负载均衡 | Tuxedo |
| 数据存取管理中间件 | 为虚拟缓冲存取、格式转换、解压等带来方便 | |
| Web服务器中间件 | 有负载均衡、缓存、安全性等功能 | |
| 安全中间件 | 加密、认证 | |
| 跨平台和架构的中间件 | 解决跨平台问题 | CORBA |
| 专用平台中间件 | 为特定应用领域设计领域参考模式，建立相应架构 | |
| 网络中间件 | 功能包括网管、接入、网络测试、虚拟社区 和虚拟缓冲等。 |
层次型软件架构（⭐⭐⭐⭐）
软件架构贯穿于软件研发的整个生命周期内，具有三方面的重要影响：
- 利益相关人员之间的交流。
- 系统设计的前期决策。
- 可传递的系统级抽象。
C/S与B/S架构
层次架构是最通用的架构，常作为初始架构。其关注分离，即每层只负责本层的工作。
表现层
MVC
Model【模型层】：应用问题域中包含的抽象领域知识，即应用程序的主体部分。
模型表示业务数据和业务逻辑，一个模型可为多个视图提供数据，提高应用的可重用性。
View【视图层】：用户看到并与之交互的界面
接受用户输入数据，向用户展示数据。
Controller【控制层】：用户界面与Model的接口。
解释视图的输入，将其解释为系统能够理解的对象，同时识别用户运作，将其解释为对模型特定方法的调用。处理来自模型的时间和模型逻辑执行的结果，调用适当的视图为用户提供反馈。
特点：所有通信都是单向的。
MVC作为后端设计主要应用于web开发，将请求处理分为模型、视图和控制器部分。
如在J2EE体系中：
- 视图：JSP
- 控制层：Servlet
- 模型层：Session Bean等
MVP
MVP是MVC的变种，其优点如下：
- 模型和视图完全分离，可以修改视图而不影响模型
- 可以更高效地使用模型，因为所有交互都发生在一个地方内部（Presenter）
- 可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑
- 如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）
特点：各部分是双向通信的
主要应用场景：Android开发
MVVM
模型层和视图层同MVC，主要变化是控制层变为ViewModel。为解决MVP中UI种类变多导致接口也会不断增加的问题。
视图模型：封装的是视图的表示逻辑和数据，是对视图的抽象，包括视图的属性和命令，或视图的状态和行为。
特点：双向绑定
使用场景：数据驱动，数据操作特别频繁的场景。如vue和Angular框架
UIP框架
UIC（User Interface Componets）是原来的表现层，用户看到的和进行交互的都是这个组件。
UIP（User Interface Process Components）这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为UIC提供了重要的支持功能。
表现层动态生成设计思想：基于XML界面管理技术，包括界面配置、界面动态生成、界面定制三部分。
中间层
业务逻辑层工作流设计
业务逻辑层框架
访问层
数据访问模式
- 在线访问：每个数据库操作都会通过数据库连接不断地与后台的数据源进行交互。
- Data Access Object：底层数据访问操作与高层业务逻辑分离。
- Data Transfer Object：跨不同的进程或是网络的边界来传输数据。
- 离线数据模式：从数据源获取数据后，存放到本地处理。
- 对象/关系映射：应用系统中的对象与数据库中的数据表形成映射关系。
数据访问层设计
ORM（Object Relational Mapping）：对象与关系数据之间的映射。
映射关系表：
| 面向对象 | 关系数据库 |
|---|---|
| 类（class） | 表（table） |
| 对象（Object） | 记录（record，行数据） |
| 对象的属性（Attribute） | 字段（Field） |
Java ORM实现技术对比：
| 维度 | Hibernate | MyBatis |
|---|---|---|
| 简单对比 | 强大、复杂、间接、SQL无关 | 小巧、简单、直接、SQL相关 |
| 可移植性 | 好（不关心具体数据库） | 差（根据数据库SQL编写） |
| 复杂多表关联 | 不支持 | 支持 |
物联网分层架构
| 分层 | 描述 | 设备 |
|---|---|---|
| 应用层 | 解决信息处理和人机交互问题 | 应用服务、智能终端 |
| 平台层 | 操作系统、软件开发、设备管理平台、连接管理平台 | |
| 网络层 | 传递信息和处理信息 | 网络、通信标准/协议 |
| 感知层 | 解决数据获取问题 | 传感器、芯片、通信模组、感知类智能设备/装置 |
大数据分层架构
RIA架构（⭐⭐⭐⭐）
RIA（Rich Internet Applications，富互联网应用）架构是一种通过在客户端（通常是Web浏览器）上运行富客户端应用程序来增强用户体验和应用程序性能的Web应用架构。它旨在结合传统桌面应用程序的响应性和互动性与Web应用程序的可访问性和易更新性。
RIA架构的主要特点 
优点：反应速度快、易于传播、交互性强
典型例子：Google Docs，在浏览器上编辑Word文档、Excel等。国内的腾讯文档Web端应该也属于RIA架构。
面向服务的软件架构（⭐⭐⭐⭐）
SOA
Service Oriented Architecture, 面向服务架构
SOA的优点：
- 服务构件粗粒度，传统构件细粒度居多
- 服务构件的接口标准化（主要是WSDL接口），传统构件常以API形式出现
- 服务构件的实现与语言无关，传统构件绑定某种特定语言
- 服务构件可以通过构件容器提供Qos服务，传统构件完全由程序代码直接控制
ESB
Web Service
3种角色：服务注册中心、服务提供者、服务请求者
3种操作：发布、查找、绑定
3种技术：
- SOAP：通信协议，用于以服务的方式在互联网上发布有用的程序模块，SOAP = HTTP + XML
- WSDL(Web Services Description Language)：基于XML，用于描述WebService及其函数、参数和返回值等，为用户提供详细的接口说明。
- UDDI(Universal Description Discovery and Integration)：提供一种统一发布、查找和定位web服务的方法。
REST
REST（Representational State Transfer, 表述性状态转移）是一种通常使用HTTP和XML进行基于web通信的技术风格，可以降低开发的复杂性，提高系统的可伸缩性。
- 资源：每一个对象、实体或数据都被抽象为一个资源。例如，用户、文章等都可以作为资源。
- 表述：资源某一时间的状态，呈现形式有HTML、JSON、XML
- 状态转移：使用GET、POST等方法
- 超链接：通过超链接可与其它资源联系
5个原则：
- 网络上的所有事物都被抽象为资源
- 每个资源对应一个唯一的资源标识
- 通过通用的连接件接口对资源进行操作
- 对资源的各种操作不会改变资源标识
- 所有的操作都是无状态的
微服务
微服务属于面向服务架构（SOA）的一种，是在SOA基础上进一步发展的产物，体现在细粒度。主要用到容器技术。传统单体架构将所有功能放到一个进程中；而微服务每个功能放入一个独立进程中。
微服务的优点：
- 复杂应用解耦：小服务（聚焦于一个业务功能或需求），化整为零，易于小团队开发
- 独立性：独立开发、测试、部署以及独立运行（每个服务独立在其独立进程中）
- 技术选型灵活：支持异构（如每个服务使用不同的数据库）
- 容错：故障被隔离在单个服务中，通过重试、平稳退化等机制实现应用层容错。
- 易扩展：可根据需求独立扩展
面临的问题和挑战：
- 分布式环境下的数据一致性（更加复杂）
- 测试的复杂性（服务间依赖测试）
- 运维的复杂性
微服务架构模式方案：
微服务与SOA的区别：
| 微服务 | SOA |
|---|---|
| 能拆分就拆分 | 整体的，服务能放在一起的都放在一起 |
| 细粒度 | 粗粒度 |
| 使用轻量级的通信方式，如HTTP | ESB |
| 类似独立子公司 | 类似大公司里面划分了一些业务单元（BU） |
| 纵向业务划分 | 水平分多层 |
| 由单一组织负责 | 按层级划分不同部门的组织负责 |
| 两句话可以解释明白 | 几百字只相当于SOA的目录 |
| 业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域 |
| 组件小 | 存在较复杂的组件 |
微服务设计约束：
- 微服务个体约束：每个微服务都是独立的，修改一个微服务不能影响另一个微服务。
- 微服务与微服务之间的横向关系：通过第三方服务注册中心来满足服务的可发现性。
- 微服务与数据层之间的纵向约束：数据是微服务的“私产”，访问时需要通过微服务。
- 全局视角下的微服务分布式约束：高效运维整个系统。
云原生架构（⭐⭐⭐⭐）
云计算
云计算是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相对隔离的。
优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需付费、成本低（前期投入低，综合使用成本也低）
分类
按服务类型分类：
- SaaS【软件及服务】：基于多租户技术实现，直接提供应用程序。
- PaaS【平台及服务】：虚拟中间件服务器、运行环境和操作系统。
- IaaS【基础设施即服务】：包括服务器、存储和网络等服务。
按部署方式分类：
- 公有云：面向互联网用户需求，通过开放网络提供云计算服务。
- 私有云：面向企业内部提供云计算服务，提供对数据安全、服务质量和基础设施的最有效控制，能充分利用现有硬件资源和软件资源，不影响IT管理流程。
- 混合云：兼顾以上两种情况的云计算服务。
架构
- 管理层：提供对所有层次云计算的管理能力
- 用户访问层：方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。
- 应用层：提供软件服务。如：财务管理、客户关系管理、商业智能
- 平台层：为用户提供对资源层服务的封装，使用户可以自己构建自已的应用。
- 资源层：提供虚拟化的资源，从而隐藏物理资源的复杂性。如：服务器、存储等。
云原生架构
云原生是基于分布式部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
本质：Onclound ==> Inclound
云原生设计原则：
- 服务化原则：使用微服务
- 弹性原则：可根据业务变化自动伸缩
- 所有过程自动化原则：自动化交付工具
- 可观测原则：通过日志、链路跟踪和度量
- 韧性原则：面对异常的抵御能力
- 零信任原则：默认不信任网络内部和外部的任何人/设备/系统
- 架构持续演进原则：业务高速迭代情况下的架构与业务平衡
云原生架构模式：
- 服务化架构模式
- Mesh化架构模式
- Serverless模式：核心是Faas（Function as a Service）
- 存储计算分离模式
- 分布式事务模式
- 可观测架构
- 事件驱动架构
云原生架构反模式：
- 庞大的单体应用：需要多人开发的业务模块，考虑通过服务化进行拆分并让组织与架构匹配。
- 单体应用“硬拆”为微服务（服务拆分要适度）：小规模软件的服务拆分（为拆而拆）、数据依赖（服务间数据依赖）、性能降低
- 缺乏自动化能力的微服务：手动维护大量微服务是不现实的
容器技术
Docker容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。
| 对比项 | 虚拟机技术 | 容器技术 |
|---|---|---|
| 镜像大小 | 包含GuestOS，G量级以上 | 仅包含运行Bin/Lib，M量级 |
| 资源要求 | CPU与内核按核、按G分配 | CPU与内存按单核、低于G量级分配 |
| 启动时间 | 分钟级 | 毫秒级 |
| 可持续性 | 跨物理机迁移 | 跨操作系统平台迁移 |
| 弹性伸缩 | VM伸缩，CPU和内存手动伸缩 | 实例自动伸缩、CPU内存自动在线伸缩 |
| 隔离策略 | 操作系统，系统级别 | Cgroups，进程级别 |
Kubernetes【k8s】提供了分布式应用管理的核心能力：
- 资源调度：根据请求资源量在集群中选择合适的节点来运行应用。
- 应用部署与管理：支持应用的自动发布与应用的回滚。
- 自动修复：当宿主机或者OS出现故障，节点健康检查会自动进行应用迁移。
- 服务发现与负载均衡：结合DNS和负载均衡机制，支持容器化应用之间的相互通信。
- 弹性伸缩：可以对这个业务进行自动扩容。
- 声明式API：开发者可以关注于应用自身，而非系统执行细节。
- 可扩展性架构：所有k8s组件都是基于一致的、开放的API实现和交互。
- 可移植性：k8s通过一系列抽象如 LoadBalance Service【负载均衡服务】、CNI【容器网络接口】、CSI【容器存储接口】，帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。
传统应用与云原生应用：
传统开发与云原生开发对比：
边缘计算
边缘计算是指靠近物或源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。本质是计算处理职能的本地化。
边缘计算的类型：
- 云边缘：云服务在边缘侧的延伸
- 边缘云：在边缘侧构建中小规模云服务能力
- 边缘网关：以云化技术与能力重构原有嵌入式网关系统
边云协同的分类：
- 资源协同：边缘节点有基础设施资源的调度管理能力，可与云端协同。
- 数据协同：边缘节点采集数据并初步分析，再发给云端做进一步处理。
- 智能协同：分布式智能，云端做集中式模型训练，再将模型下发到边缘节点。
- 应用管理协同：边缘节点提供应用部署与运行环境，云端主要提供应用开发、测试环境。
- 业务管理协同：边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例；云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。
- 服务协同：边缘节点按照云端策略实现部分ECSaaS服务，通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务；云端主要提供SaaS服务在云端和边缘节点的服务分布策略，以及云端承担的SaaS服务能力。
大型网站架构演化（⭐⭐⭐⭐⭐）
| 维度 | 涉及技术 |
|---|---|
| 架构 | MVC、 MVP、 MVVM、 REST、 WebService、 微服务 |
| 并发分流 | 集群（负载均衡）、CDN |
| 缓存 | MemCache、Redis、Squid |
| 数据 | 主从复制、反规范化技术、NoSQL、分区技术、视图与物化视图 |
| ORM | Hibernate、Mybatis |
| 分布式存储 | Hadoop、FastDFS、区块链 |
| 数据编码 | XML、JSON |
| Web应用服务器 | Apache、WebSphere、WebLogic、Tomcat、JBOSS、ISS |
| 安全性 | SQL防注入 |
| 其它 | 静态化、有状态和无状态、响应式Web设计、中台 |
第一阶段：单体架构
第二阶段：垂直架构
第三阶段：使用缓存
常见缓存技术
- MemCache：一个高性能的分布式内存对象缓存系统，用于动态web应用以减轻数据库负载。Memcache在内存里维护一个统一的巨大的hash表，数据存在该表中。
- Redis：一个开源的使用C语言编写、可持久化的key-value数据库，支持多种数据类型，并提供多种语言的API。
- Squid：一个高性能的代理缓存服务器，支持FTP、gopher、HTTP和HTTPS协议。
| MemCache | Redis | |
|---|---|---|
| 数据类型 | 简单KV结构 | 丰富数据类型 |
| 持久性 | 不支持 | 支持 |
| 分布式存储 | 客户端哈希分片/一致性哈希 | 主从、哨兵、集群 |
| 多线程支持 | 支持 | 有限支持（5.0版本之前不支持） |
| 内存管理 | 私有内存池/内存池 | 无 |
| 事务支持 | 不支持 | 有限支持 |
| 数据容灾 | 不支持，不能做数据恢复 | 支持 |
缓存与数据库的数据一致性问题
数据读取步骤：
- 根据key从缓存中读取
- 若缓存中没有，则根据key在数据库中查询
- 读取到数据后，更新缓存
数据写入：常见步骤，没有完全统一的做法
- 根据key值写数据库
- 根据key更新缓存（或删除缓存）
Redis分布式存储方案
| 分布式存储方案 | 核心特点 |
|---|---|
| 主从模式 | 一主多从，故障时手动切换 |
| 哨兵模式 | 有哨兵的一主多从，主节点故障自动选择新的主节点 |
| 集群模式 | 分节点对等集群，分slots，不同slots的信息存储在不同节点 |
Redis集群分片
| 分片方式 | 核心特点 |
|---|---|
| 客户端分片 | 在客户端通过key的hash值对应到不同的服务器 |
| 中间件分片 | 在应用软件和Redis中间由中间件实现服务到Redis节点的路由分派 |
| 客户端服务端协作分片 | 客户端可采用一致性哈希，服务端提供节点的重定向到slot上。 不同的slot对应到不同服务器 |
| 分片方案 | 分片方式 | 说明 |
|---|---|---|
| 范围分片 | 按数据范围值做分片 | 例如按用户编号分片，1-99999映射到实例A； 100000-199999映射到实例B |
| 哈希分片 | 通过对key进行hash运算分片 | 可以把数据分配到不同实例，这类似于取余操作， 余数相同的放在同一个实例上 |
| 一致性哈希分片 | 哈希分片的改进 | 利于扩展节点，可以有效解决重新分配节点 带来的无法命中问题 |
在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。
一致性哈希算法虽然减少了数据迁移量，但是存在节点分布不均匀的问题。引入虚拟节点：不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有两层映射关系。
比如对每个节点分别设置 3 个虚拟节点：
- 对节点 A 加上编号来作为虚拟节点：A-01、A-02、A-03
- 对节点 B 加上编号来作为虚拟节点：B-01、B-02、B-03
- 对节点 C 加上编号来作为虚拟节点：C-01、C-02、C-03
节点数量多了后，节点在哈希环上的分布就相对均匀了。如果有访问请求寻址到「A-01」这个虚拟节点，通过「A-01」虚拟节点找到真实节点 A，这样请求就能访问到真实节点 A 了。
Redis数据类型
| 数据类型 | 特点 | 常见使用场景 |
|---|---|---|
| String | 存储二进制，任何数据类型，最大512M | 缓存；常规计数（如访问次数、点赞、转发、库存数量等）；分布式锁；共享session |
| List | 简单的字符串列表，按照插入顺序排序，可以从头部或尾部向 List 列表添加元素。 | 消息队列 |
| Hash | 无序字典，一个key对应一个对象 | 缓存对象 |
| Set | 无序集合；支持交/并/差集操作 | 共同关注；独立IP；标签 |
| ZSet | 有序集合，自带按权重排序效果 | 排行榜 |
| BitMap | 位图，是一串连续的二进制数组（0和1），可以通过偏移量定位元素。 | 二值状态统计场景：签到统计；判断用户登入态；连续签到用户总数 |
| HyperLogLog | 统计基数。基于概率，存在标准误差0.81% | 百万计网页UV计数 |
| GEO | 用于存储地理位置信息 | 经纬度范围查询 |
| Stream | 专门设计的消息队列（5.0新增） |
Redis过期删除策略
Redis过期删除策略：惰性删除 + 定期删除
Redis内存淘汰策略
| 策略 | 描述 |
|---|---|
| *-random | 随机淘汰键值 |
| volatile-ttl | 优先淘汰更早过期（ttl值越小）的键值 |
| *-lru | 优先淘汰最近未使用的键值 |
| *-lfu | 优先淘汰最少使用的键值 |
Redis持久化
Redis的持久化主要有两种方式：RDB和AOF。
- RDB：指定时间间隔将内存中的全量数据进行快照存储。（传统数据库快照的思想）
- AOF：把每条改变数据集的命令追加到AOF文件末尾，出问题时，重新执行AOF文件的命令来重建数据库。（传统数据库日志的思想）
| 对比维度 | RDB | AOF |
|---|---|---|
| 备份量 | 重量级的全量备份 | 轻量级的增量备份，一次只保存一个修改命令 |
| 保存间隔时间 | 长 | 短（默认1秒） |
| 还原速度 | 快 | 慢 |
| 阻塞情况 | 同步方式（save）阻塞； 异步（bgsave）方式和自动不阻塞 | 不阻塞 |
| 同等数据体积 | 小 | 大 |
| 安全性 | 低，容易丢失数据 | 高，根据策略决定 |
Redis常见问题
缓存雪崩
当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。
解决方案：
针对大量缓存数据同时过期的情况：
- 使用锁或队列：保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
- 为key设置不同的缓存失效时间：在固定的一个缓存时间基础上，再加上一个随机时间作为缓存失效时间。
- 二级缓存：设置一个有时间限制的缓存和一个无时间限制的缓存。避免大规模访问数据库。
针对Redis故障宕机的情况：
- 服务熔断或请求限流：服务熔断即暂停业务应用对缓存服务的访问，直接返回错误，不用再继续访问数据库，但这会导致业务不可用。为了减少对业务的影响，我们可以启用请求限流机制，只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。
- 构件Redis高可用集群。
缓存穿透
用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。
解决方案：
- 如果查询结果为空，直接设置一个默认值放到缓存，这样第二次到缓存中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
- 使用布隆过滤器。将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截，从而避免对底层存储系统的查询压力。
布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。可以用于检索一个元素是否在一个集合中。
优点：
- 占用内存小
- 查询效率高
- 不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势
缺点：
- 有一定的误判率：如果判断出元素不在集合中，那么一定不在；但如果判断出元素在集合中，元素不一定在集合中。
- 一般情况下不能从布隆过滤器中删除元素
- 不能获取元素本身
缓存预热
系统上线后，将相关需要缓存的数据加到缓存系统中。
解决方案：
- 直接写个缓存刷新页面，上线时手动刷新。
- 数据量不大时，可在项目启动时自动进行加载。
- 定时刷新缓存。
缓存更新
除了Redis自带的缓存失效策略外，常见采用以下两种方式：
- 定时清理过期的缓存。
- 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
缓存降级
降级的目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（如电商的购物流程等）；在进行降级之前要对系统进行梳理，哪些必须保护，哪些可降级。
第四阶段：使用服务集群提高并发处理能力
服务集群带来的问题：
- 用户的请求如何转发到具体的应用服务器？答：负载均衡
- 用户每次访问不同的服务器，如何维护session的一致性？答：Session共享机制
负载均衡
| OSI | 分类 | 描述 | 特点 |
|---|---|---|---|
| 应用层 | HTTP重定向 | 应用层的请求转发。用户请求其实已经发了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群。 | 实现简单，但性能差 |
| 反向代理服务器 | 在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器算法转发到具体的服务器。常见如Nginx、Apache都可用于反向代理服务器。 | 部署简单，但代理服务器可能成为性能瓶颈 | |
| 传输层 | DNS | 在用户请求DNS服务器获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。 | 效率比HTTP重定向高，减少维护负载均衡服务器成本。但应用服务器故障后不能及时通知DNS，而且DNS控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。 |
| NAT | 将一个外部IP地址映射为多个IP地址，对每次请求连接动态地转换为一个内部节点的地址。 | 技术成熟，一般在网关位置，可以通过硬件实现。如四层交换机。 |
负载均衡技术：
- 静态算法（不考虑服务器动态负载）
- 轮转：轮流调度
- 加权轮转：考虑不同节点的处理能力，处理能力强的权重大
- 源地址哈希：根据源IP地址进行哈希。稳定
- 随机算法：随机分配，简单但不可控
- 目标地址哈希（不常见）：根据请求目标IP地址（多个虚拟IP）进行哈希
- 动态算法（考虑服务器动态负载）
- 最小连接数：每个节点处理能力相同时，新请求分配给点当前活动请求数量最少的节点。
- 加权最小连接数：考虑节点处理能力不同，按最小连接数分配。
- 加权百分比：考虑节点的利用率、硬盘速率、进程数等，使用利用率来表现处理能力。
- 硬件负载均衡：F5
- 软件负载均衡：LVS、Nginx、HAproxy
Session共享机制
第五阶段：数据库读写分离
主从数据库特点：
- 一般是一主多从，也可以多主多从
- 主库写，从库读
主从复制步骤：
- 主库更新数据完成前，将操作写入binlog日志文件。
- 从库打开I/O线程与主库连接，获取binlog日志并将写入中继日志。
- 从库读取中继日志，并解析成具体的操作执行，保持与主库一致。
第六阶段：使用反向代理和CDN加速
内容分发网络（Content Delivery Network, CDN）：基本思路是尽可能避免互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。 
第七阶段：使用分布式文件系统和分布式数据库
第八阶段：使用NoSQL和搜索引擎
第九阶段：业务拆分
第十阶段：分布式服务
其它考点
Web应用服务器
Web应用服务器可以理解为两层意思：
- Web服务器：其职能较为单一，就是根据浏览器发过来的请求，响应HTML页面。
- 应用服务器：进行业务逻辑的处理。如：EJB、Corba、COM+等。
web相关服务器介绍：
- Apache：Web服务器，市场占有率60%左右。可以运行在所有Unix、Windows、Linux系统平台上。
- Nginx：Web服务器，性能高，支持负载均衡。
- Tomcat：基于Java的、开源、运行servlet和JSP Web的应用软件容器。
- Jetty：基于java的开源servlet容器。
- JBOSS：基于J2EE的开源应用服务器。一般与Tomcat和Jetty绑定使用。
- WebSphere：基于java的、功能完善、开放的web应用服务器，用于建立、部署和管理web应用程序。
- WebLogic：BEA WebLogic Server是一种多功能、基于标准的web应用服务器，为企业构件自己的应用提供坚实的基础。
- IIS：早期的Web服务器，目前很少用了。
响应式Web设计
一种网页设计布局，可智能地根据用户行为以及使用的设备环境进行相应地布局。
方法和策略：
- 流式布局和弹性布局：使用相对单位，设定百分比而非具体值的方式设置页面元素的大小。
- 响应式布局：如媒体查询
JWT
JWT（Json Web Token）是一种用于身份验证和授权的开放标准。它是一种轻量级的、基于Json的令牌，可以在客户端和服务器之间传递信息。
JWT由三部分组成：
- 头部：包含令牌类型和所使用的算法
- 载荷：包含用户信息和其他元数据
- 签名：用于验证令牌的完整性和真实性
JWT的应用场景：信息交换和授权。不需要服务器端存储状态，安全地传递非敏感信息。
中台
中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小中台”的组织和业务基础，供企业快速低成本的进行业务创新的企业架构。
业务中台：提供重用服务，例如学员中心、课程中心之类的开箱即用可重用能力。
数据中台：提供数据整合分析能力，帮助企业从数据中学习改进，调整方向。
必备的4个核心能力：
- 数据汇聚整合能力
- 数据提纯加工能力
- 数据服务可视化
- 数据价值变现
技术中台：提供技术重用组件能力，帮助解决基础技术平台的复用。如：中间件、分布式存储、AI、负载均衡等基础设施。
各种分类本质上是对企业通用能力在不同层面的沉淀，并对外开放。
Web系统分层
CAP理论
CAP理论是分布式系统设计中的一个重要理论，它指出在一个分布式系统中，无法同时完全满足以下三个核心需求：一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），系统设计者必须在这三者之间做出权衡。
- 一致性：分布式系统中数据的同步程度和准确性。在一个分区进行写操作后，所有分区数据都要保持一致。
- 强一致性：当一个写操作完成之后，后续的读操作总是能够读取到最新的数据。
- 弱一致性：系统在写操作后，可能需要经过一段时间延迟才能保证所有节点上的数据一致。
- 最终一致性：系统在经过一段时间后，所有节点上的数据最终会达到一致状态。
- 可用性：系统必须始终处于可用状态，即使出现网络分区故障。
- 分区容错性：指分布式系统在遇到任意网络分区故障时，仍然能够继续运行的能力。
由于在现代分布式系统中，网络故障是不可避免的，所以CAP理论的权衡主要集中在一致性和可用性。
- CP系统：在网络分区的情况下，优先保证数据的一致性，可能会牺牲部分可用性。
- AP系统：在网络分区的情况下，优先保证系统的可用性，可能会牺牲部分数据的一致性。