系统架构师-第10章-软件架构的演化和维护-学习笔记_消息演化

消息是顺序图中的核心元素，包含了名称、源对象、目标对象、时序等信息。

消息演化分为AddMessage( AM ) 、DeleteMc ssage ( DM ) 、SwapM 巳ssageOrder (S MO ) 、OverturnMc ssage (OM) ,ChangeMessageModule (CMM) 5 种

AM 增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。

DM 删除当前的一条消息，产生在需要移除某个交互行为的时候，是AM 的逆向演化。

SMO 交换两条消息的时间顺序，发生在需要改变两个交互行为之间关系的时候。

OM 反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。

CMM 战变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

消息与约束直接相关，消息的演化会直接影响到对象之间的交互行为，但不一定会违背约束

演化分为3 类。

第1类演化与当前约束无关 AM

第2 类演化与约束直接关联但不会违背约束 CMM

第3 类演化与约束直接关联并会边背约束 DM

消息是顺序图的核心内容， 消息演化是)顺序图演化的核心

复合片段演化

复合片段是对象交互关系的控制流描述，表示可能发生在不同场合的交互， 与消息同属于连接件范畴

复合片段的演化分为AddFragment (AF) 、DeleteFragment ( DF) 、FragmentTypeChange (FTC)
和FragmentConditionChange (FCC)

FCC 改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。
AF 在某几条消息上新增复合片段，发生在南耍增添新的控制流时。
DF 删除某个现有的复合片段，发生在需要移除当前某段控制流时。

DF 与AF 互为逆向演化过程。
FTC 改变复合片段的类型，发生在需要改变某段控制流时。

约束演化

AC (Add Constraint) 直接添加新的约束信息，会对架构设计产生直接的影响，需要判断当前设计是否满足新添加的约束要求。
DC (Delete Constraint ) 直接移除某条约束信息，发生在去除朵些不必要条件的时候， 一般而言架构设计均会满足演化后的约束。

软件架构演化方式的分类

3 种较典型的分类方法:
(1)按照软件架构的实现方式和实施粒度分类:

基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。

(2) 按照研究方法将软件架构演化方式分为4 类:

第1类是对演化的支持，如代码模块化的准则、可维护性的指示(如内聚和精合〉、代码结构:

第2 类是版本和工程的管理工具

第3 类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等

第4 类是架构演化的成本收益分析，决定如何增加系统的弹性。
(3) 针对软件架构的演化过程是否处于系统运行时期

静态演化( Static Evo lution )

动态演化( Dynamic Evolution)

前者发生在软件架构的设计、实现和维护过程中， 软件系统连未运行或者处在运行停止状态;         后者发生在软件系统运行过料中。

软件架构演化时期

设计时演化（Design-Time Evolution) 是指发生在体系结构模刷刷与之相关的代码编译之前的软件架构演化.

运行前演化( Pre-Execution Evolution) 是指发生在执行之前、编译之后的软件架构演化

有限制运行时演化（Constrained Runtime Evolution) 是指系统在设计时就规定了演化的具体条件，将系统置于"安全"模式下， i演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。

运行时演化CRuntime Evolution) 是指系统的体系结构在运行时不能满足要求时发生的软件架构演化，包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。

软件架构静态演化

软件架构静态演化指的是软件架构在时间上的变化，不涉及到运行时的行为。在软件开发过程中，软件架构可能会随着需求变化、技术进步、业务扩展等因素而发生改变。软件架构静态演化可以分为三个方面的变化：

1. 结构变化：指软件架构中各个组件之间的关系和连接方式发生变化。例如，一个新的组件被加入到系统中，原有的组件被修改或删除。

2. 接口变化：指软件架构中各个组件之间的接口发生变化。例如，接口参数、返回值等发生改变。

3. 外部依赖变化：指软件架构与外部系统、组件、库之间的依赖关系发生变化。例如，系统升级到新的操作系统，新的库被引入到系统中，旧的库被替换或删除等。

软件架构静态演化对于软件系统的健康发展和维护非常重要，因为它可以避免软件系统的腐化和技术债务的积累，保证系统的可扩展性、可维护性和可重用性。

1. 静态演化需求

(1)设计时演化需求。在架构开发和实现过程"，对原有架构进行调整，保证软件实现与架构的一致性以及软件开发过梧的顺利进行。
        (2) 运行前演化需求。软件发布之后由丁运行环境的变化，需要对软件进行修改升级，在此期间软件的架掏同样要进行演化。

2. 静态演化的一般过程

软件静态演化是系统停止运行期间的修改和更新，即一般意义上的软件修复和升级。

与此相对应的维护方法有3 类: 更新性维护、适应性维护和完善性维护。
        软件的静态演化一般包括如下5 个步骤。
                · 软件理解:查阅软件文档，分忻软件架构，识别系统组成元素及其之间的相互关系，提
                   取系统的抽象表示形式。
                · 需求变更分析: 静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改
                   变 等原因所引起的，市要找出新的软件需求与原有的差异。
                · 演化计划:分析原系统，确定演化范围和成本，选择合适的演化计划。
                · 系统草构:根据演化计划对系统进行重构，使之适应当前的南求。
                · 系统测试:对演化后的系统进行测试，查找其中的错误和不足之处。

3 . 静态演化的原子演化操作

一次完辑软件架构演化过程可以看作经过一系列原子演化操作组合而成。

所谓原子演化操作是指基于UML 模型表示的软件架构，在逻辑语义上粒度最小的架构修改操作。

与可维护性相关的架构演化操作

架构演化的可维护性度量基于组件图表示的软件架构，在较高层次上评估架构的某个原子修改操作对整个架构所产生的影响。

这些原子修改操作包括增加/删除棋块间的依赖、增加/删除模块间的接门、增加/删除模块、拆分/聚合模块等

• AMD/RMD : 棋块间的依赖关系体现了模块逻辑组织结构和控制关系，包含棋块对其他模块的直接依赖和间接依赖，对模块依赖关系的修改改变了模块的控制关系以及逻辑响应，从整体上影响了架构的组织结构， 可能导致架构的外部质量属性发生变化。
• AMl/RMI : 模块间的接口表示模块间的调用方式，模块通过接口直接提供相应可执行功能，对接口的修改可直接改变模块间的调用关系和调用方式， 并可能导致具体的执行事件的顺序和方式发生更改。
• AM/RM: 在架构中，模块封装了一系列逻辑稿合度高或部署紧密的子模块， 用来表达完整的功能。模块的增加、删除不仅仅表示软件功能的更改，该模块与其他棋块的稿合方式可能使得架构整体组织结构的变化，从而引入AMD和RMD操作。过多的精合会造成修改影响范围增大，不利于软件的维护以及持续演化。另外模块本身内部设计的正确性、合理性等问题将会影响软件潜在风险。
• SM/AGM : 拆分和聚合棋块通常发生在软件调整过程中，对模块的拆分和聚合可直接影响软件的内聚度和耕合度，从而影响软件整体复杂性。

与可靠性相关的架构液化操作

架构演化的可靠性评估基于用例阁、部署图和顺序图， 分析’在架构模块的交互过程中某个原子演化操作对交互场景的可路程度的影响。

这些原子修改操作包括增加/删除消息、增加/ 删除交互对象、增加/删除/修改消息片段、增加/删除用例执行、增加/删除角色等

AMS/RMS: 模块间的消息交互体现在UML顺序图中。消息变化包含增加消息、删除消息和修改消息。
AO/RO: 在顺序闺中增加或删除交互对象将引入AMS/DMS操作，即与该对象相关的消息将同时被增加或删除，同时，在部署图中还须将该模块添加到相关站点或从相关站点删除该模块。
AFIRF/CF: 消息片段为顺序图中一组交互消息的循环调用，消息片段的增加、删除或者调用次数的修改将影响交互过程的复杂度，从而影响该场景的执行凤险.
AU/RU : 为参与者增加或删除可执行用例，表示参与者执行权限的变化，般来说可执行用例越多的参与者其权限越高。
AA/RA: 增加I或删除某一参与者意味着执行权限的增加或减少，该操作将引人AU/RU操作。

4. 静态演化实例:正交软件架构( Orthogonal Software Architecture )

正交体系的演化过程概括如下:

①需求变动归类，使需求的变化和现有组件及线索相对应，判断重用情况:

②制订架构演化计划;

③修改、增加或删除组件:

④更新组件之间的相互作用:

⑤产生演化后的软件架构，作为系统更新的详细设计方案和实现基础。

软件架构动态横化

1. 动态演化的需求

架构的动态演化主要来自两类需求:

①软件内部执行所导致的体系结构改变，例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求;

②软件系统外部的请求对软件进行的重配置，例如，操作系统在升级时无须重新启动，在运行过料中就完成对体系结构的修改。

2. 动态演化的类型

1)软件动态性的等级

软件的动态性分为3 个级别

①交互动态性( Interactive Dynamism) ，要求数据在固定的结构下动态交互:

②结构动态性(Structural Dynamism) ，允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流:

③架构动态性(Architectura1 Dynamism) ，允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。

2. 动态演化的内容

根据所修改的内容不同，软件的动态演化主要包括以下4 个方面。
        · 属性改名: 目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义(如服务响应时间〕。
        · 行为变化: 在运行过程中，用户需求变化成系统自身服务质量的调节都将引发软件行为的变化。诸如，为了提高安全级别而更换加密算法; 将HTTP协议改为HTTPS协议;组件和连接件的替换和重新配置。
        · 拓扑结构改变:如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
        · 风格变化: 一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将架构风格变为其衍生风格，如将两层C/S结构调整为三层C/S结构或C/S与B/S 的说合结构，将" I 对1 " 的请求响应结构改为"1 对N" 的请求l响应结构，以实现负载的平衡.

实现软件架构动态演化的技术主要有两种:

采用动态软件架构( Dynamic Software Architecture, DSA )

进行动态重配置( Dynamic Reconfiguration, DR).

DSA 是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改;
DR 从组件和连按件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。

DSA 归结为架构动态性，将DR 归结为结构动态性

3. 动态软件架构

软件架构中最为重要的3 个研究方向，即软件架构风格、软件架构连接件和DSA .

DSA 指那些在软件运行时刻会发生变化的体系结构。

软件架构的动态’性指巾于系统需求、技术、环境、分布等因素的变化而导致软件架构在软件运行时刻的变化，主要地过软件架构的动态演化来体现。

DSA 的意义主要在于能够减少系统开发的费用和风险。DSA 能增强用户自定义性和可扩展性，并可为用户提供更新系统属性的服务.

1 )基于DSA 实现动态演化的基本原理

实现软件架构动态演化的基本原理是使DSA 在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来， 并且被整个运行环境共享，作为整个系统运行的依据。

动态演化实现起来比静态消化复杂得多，系统必须提供SA动态演化的一些相关功能。

首先，系统必须提供保存当前软件架构信息〈拓扑结构、组件状态和数日等)的功能:

其次，实施动态、演化还须设置一个监控管理机制， 对系统有无需求变化进行监视。

再者，还应保证演化操作原子性，即在动态变化过程中，如果其中之一的操作失败了，整个操作集都要被撤销，从而避免系统出现不稳定的状态。

DSA 实施动态演化大体遵循以下4 步:

①捕捉并分析需求变化:

②获取或生成体系结构演化策略:

③根据步骤2 得到的演化策略，选择适当的演化策略井实施演化:

④演化后的评估与检测。

完成这4 个步骤还需要DSA 描述语言和演化工具的支持。

2) DSA 描述语言

按照描述视角可将软件动态性建模语言分为3 类:

①基于行为视角的π-ADL 使用进程代数来描述具有动态性的行为;
②基于反射视角的Pilar，利用反射理论显式地为元信息建立模型;
③基于协调视角的LIME，注重计算和协调部分的分离，利用协调论的原理来解决动态性交互。

3) DSA 演化工具

动态演化的工具要支持系统在演化过程中与其软件架构的一致性检查，并能够对架构演化过程进行管理，主要街以下几种方法。
· 使用反射机制: 
· 基于组件操作: 此类工具用于支持基于组件的系统构架进行动态演化。
· 基于π演tt : π演算是在CCS ( Calculus of Communicating System ) 的基础上提出的、基于命名概念的进程代数并发通信行为演算方法，
· 利用外部的体系结构演化管理器:

4. 动态软件架构应用实例一PKUAS

基于Java虚拟机，PKUAS 将乎台自身的实体划分为如下4 种类础。
(1)容器系统
(2) 公共服务:
(3)工具:辅助用户使用和管理PKUAS 的工具集合，主要包括部署工具、配置工具与实时监控工具。其中部署工具既可热部署整个应用，也可热部署单个组件，从而实现应用的在线演化:配置工具允许用户配置整个服务器或单个应用:而实时监控工具允许用户实时观察系统的运行状态井做出相应调整。
(4) 微内核

5. 动态重配置

基于软件动态重配置的软件架构动态演化主要是指在软件部署之后对配置信息的修改

动态重配置可能涉及的修改有:
①简单任务的相关实现修改;
②工作流实例任务的添加和删除:
③组合任务流程中的个体修改:
④任务输入来源的添加和删除;
⑤任务输入来说的优先级修改;
⑥组合任务输出目标的添加和删除;
⑦组合任务输出目标的优先级修改等。

1 )动态重配置模式

4 种重配置模式。
(1) 主从(Master-Slave) 模式:在主从模式中，主组件接收容户端的服务请求，它将工作划分给从组件，然后合并、解释、总结或整理从组件的响应。
(2) 中央控制(Centralized Control) 模式: 中央控制模式广泛应用于实时系统之中。
(3) 客户端/ 服务器(Client Server ) 模式:客户端/ 服务器模式中的客户端组件前要服务器组件所提供的服务， 气者通过同步消息进行交互，在客户端/ 服务器南配置模式中， 当客户端发起的事务完成之后可以添加或删除客户端组件: 当顺序服务器(Sequential Server) 完成了当前的事务，或者井发服务器(Concurrent Server ) 完成了当前事务的集合，且将新的事务在服务器消息缓冲中排队完毕之后，可以添加或删除服务器组件。
(4) 分布式控制( Decentτalized Control ) 模式: 分布式控制模式下系统的功能整合在多个分布式控制组件之中。

2. 例子:可重用、可配置的产品线架构

3 )动态重配置的难点

动态重配置的4 个难点:
①约束定义困难;
②性能约束难以静态衡量， 需要在软件运行时进行评估:
③某些重配置方案能够解决性能约束的某一方面， 但是难以管理所有方面;
④重配置需要同时保证两个方面，即维持组件系统的完整性和重配置策略的正确和安全性。

软件架构演化原则

1. 演化成本控制原则
   · 原则名称: 演化成本;抑制（Evolution Cost Control, ECC ) 原则。
   · 原则解释: 演化成本提控制在预期的地回之内，也就是消化成本要明显小于新开发成本。
   · 原则用途: 用于判断架构演化的成本盐否在可控范围内，以及用户是否可接受.
   · 度量方案: CoE<<CoRD 。
   · 方案说明: CoE为演化成本， CoRD为重新开发成本， CoE远小于CoRD最佳。

2. 进度可控原则
   · 原则名称: 进度可控( Schedule Control ) 原则。
   · 原则解释: 架构演化要在预期时间内完成，也就是时间成本可控。
   · 原则用途:根据该原则可以规划每个演化过程的任务量;体现一种地代、递增(持续演化)的演化思想。
   · 度量方案: ttask=ITtask- T’taskl 。
   · 方案说明:某个演化任务的实际完成时间( Ttask) 和预期完成时间(T’task) 的时间差，时间差ttask越小越好。

3. 风险可控原则
· 原则名称: 风险可控( Risk ControJ) 原则。
· 原则解释: 架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
· 原则用途:用于判断架构演化过程中各种风险是否易于控制。
· 度量方案: 分别检验。
· 方案说明: 时间凤院、经济风险、人力风险、技术风险都不存在。

4. 主体维持原则
   · 原则名称: 主体维持原则。
   · 原则解释: 对称稳定增长( the Average Incremental Growth. AIG ) 原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增氏须保持平稳，保证软件系统主体行为稳定。
   · 原则用途:用于判断架构演化是否导致系统主体行为不稳定。
   · 度量方案: 计算AIG即可，A1G=主体规模的变更量/主体的规模。
   · 方案说明:根据度量动态变更信息(类型、总量、范围)来计算。

5. 系统总体结构优化原则
   · 原则名称:系统总体结构优化(Optimization ofWhole Structure ) 原则。
   · 原则解释: 架构梢化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。
   · 原则用途: 用于判断系统整体结构是否合理，是否最优.
   · 度量方案:检任系统的整体可靠性和性能指标。
   · 方案说明: 判断整体结构优劣的主要指标是系统的可靠性和性能。

6. 平滑演化原则
   · 原则名称: 平滑演化（Invariant Work Rate, IWR ) 原则.
   · 原则解释: 任软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版木的更新率相对间应.
   · 原则用途: 用于判断是台存在剧烈架构演化。
   · 度量方案:计算IWR 即可， IWR=变更总量/项目规模。
   · 方案说明:根据度结动态变旦信息(类型、总量、范围等)来计算。

7. 目标-致原则
   · 原则名称: 目标- 蚁( 0战jective COnfOmlanCe) 原则。
   · 原则解释:架构演化的阶段日标和最终目标要一致。
   · 原则用途:用于判断每个演化过程是否达到阶段目标，所有演化过相结束是否能达到最终目标。
   · 度量方案: otask=IOt出k-O’taskl 。
   · 方案说明: 阶段日标的实际达成情况（Otask ) 和预期忖标( O’task ) 的差，Otask越小越好。

8. 模块独立演化原则
   · 原则名称: 模块独立演化原则， 或称为修改局部化原则(Local Change ) 。
   · 原则解释: 软件中各模块(相同制品的模块， 如Java的某个类或包〉自身的演化最好相互独立， 或者至少保证对其他模块的影响比较小或影响范围比较小。
   · 原则用途: 用于判断每个模块自身的演化是否相互独立。
   · 度量方案: 检查模块的修改是否是局部的。
   · 方案说明: 可以通过计算修改的影响范围来进行度量。

9 . 影晌可控原则
· 原则名称: 影响可控( Impact Limitation) 原则。
· 原则解释: 软件中一个模块如果发生变更， 其给其他模块带来的影响要在可控范围内，也就是影响范围可预测。
· 原则用途: 用于判断是否存在对某个模块的修改导致大量其他修改的情况。
· 度量方案: 检查影响的范围是否可控。
· 方案说明: 可以通过计算修改的影响范围来进行度量。

10. 复杂性可控原则
    · 原则名称: 复杂性可控( Complexity Controllability )原则。
    · 原则解择: 架构演化必须要控制架构的复杂性，从而进一步保障软件的复杂性在可控范围内。
    · 原则用途: 用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。
    · 度量方案: CC<某个阙值: 方案说明; CC增长可控。

11. 有利于重构原则
    · 原则名称: 有利于重构( Useful for Refactoring ) 原则。
    · 原则解释: 架构演化要遵循有利于重构原则， 使得演化之后的软件架构更便于重构。
    · 原则用途: 用于判断架构易重构性是否得到提高。
    · 度量方案: 检查系统的复杂度指标。
    · 方案说明: 系统越复杂越不容易重构。

12. 有利于重用原则
    · 原则名称: 有利于重用( Usefu l for Reuse ) 原则。
    · 原则解释: 架构演化最好能维持， 甚至提高整体架构的可重用性。
    · 原则用途: 用于判断整体架构可重用性是否遭到破坏。
    · 度量方案: 检查模块自身的内聚度、模块之间的棋合度。
    · 方案说明: 模块的内聚度越高，该模块与其他棋块之间的稠合度越低， 越容易重用。

13. 设计原则遵从性原则
    · 原则名称: 设计原则遵从性（Design Principles Confonnance ) 原则.
    · 原则解释: 架构演化最好不能与架构设计原则冲突。
    · 原则用途: 用于判断架构设计原则是否遭到破坏( 架构设计原则是好的设计经验总结，要保障其得到充分使用）。
    · 度盘方案: RCP=ICDPI~DPI 。
    · 方案说明:冲突的设计原则集合C CDP ) 和总的设计原则集合C DP ) 的比较， RCP越小越好。

14. 适应新技术原则
    · 原则名称: 适应新技术( Tcchnology Independence, Tl)原则。
    · 原则解膀: 软件桌独立于特定的技术手段，这样才能够让软件运行于不同平台。
    · 原则剧途: 用于)~IJ 断架构演化是舌存在开j 某种技术依赖过强的悄况。

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。

本份面试集锦涵盖了

• 174 道运维工程师面试题
• 128道k8s面试题
• 108道shell脚本面试题
• 200道Linux面试题
• 51道docker面试题
• 35道Jenkis面试题
• 78道MongoDB面试题
• 17道ansible面试题
• 60道dubbo面试题
• 53道kafka面试
• 18道mysql面试题
• 40道nginx面试题
• 77道redis面试题
• 28道zookeeper

总计 1000+ 道面试题， 内容 又全含金量又高

• 174道运维工程师面试题

1、什么是运维?

2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?

3、现在给你三百台服务器，你怎么对他们进行管理?

4、简述raid0 raid1raid5二种工作模式的工作原理及特点

5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?

7、Tomcat和Resin有什么区别，工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义？

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
uid、Varinsh和Nginx有什么区别，工作中你怎么选择?

7、Tomcat和Resin有什么区别，工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义？

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！