42.系统架构设计师论文提炼

2025年下半年系统架构设计师论文提炼

系统建模 2
软件架构设计 3
系统设计 18
分布式系统设计 35
系统可靠性分析与设计 38
系统安全性和保密性设计 39

系统建模

软件系统建模方法

（1） 结构化建模方法。

结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模方法。

（2）信息工程建模方法（或数据库建模方法）。

信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。信息工程建模方法所创建的模型被称为实体联系图（ERD）。主要用于数据建模。

（3） 面向对象建模方法。

面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML（统一建模语言）。UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统。是目前比较常用的建模方法。

（4） 功能分解法

功能分解法以系统需要提供的功能为中心来组织系统。首先定义各种大的功能，然后把功能分解为子功能，同时定义功能间的接口。比较大的子功能还可以被进一步分解，直到我们可以对它进行明确的定义。总的思想就是将系统根据功能分而治之，然后根据功能的需求设计数据结构。

软件架构设计

SAAM 评估方法

SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。

（1）评估目的

SAAM（Scenario-based Architecture Analysis Method）目的是验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。

（2）评估参与者

风险承担者、记录人员、软件体系结构设计师。

（3） 评估活动或过程

SAAM分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。

（4）评估结果

SAAM评估的主要有形输出包括

1）把代表了未来可能做的更改的场景与架构对应起来，显现出架构中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。
2）理解系统的功能，对多个架构所支持的功能和数量进行比较。

如果所评估的是一个框架，SAAM评估将指明框架中未能满足其修改性需求的地方，有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选架构进行比较，明确其中哪一个能够较好地满足质量属性需求，而且做的更改较少、不会在未来导致太多的复杂的问题。

ATAM 评估方法

ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。

（1）评估目的

ATAM（Architecture Tradeoff Analysis Method），即架构权衡分析方法的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出架构满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。

（2）评估参与者

1）评估小组。该小组是所评估架构项目外部的小组，通常由3~5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。
2）项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，架构设计师等。
3）架构涉众（stakeholders）。包括关键模块开发人员、测试人员、用户等。

（3） 评估活动或过程

整个ATAM评估过程包括九个步骤，按其顺序分别是介绍ATAM方法、描述商业目标、描述体系结构、标识体系结构步骤、产生质量属性树、分析体系结构步骤、讨论质量需求的次序、分析体系结构步骤、提交结果。

软件架构风格

Garlan和Shaw将软件架构风格分为五大类，数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。其中

（1） 数据流风格包括批处理序列架构风格和管道/过滤器架构风格；
（2） 调用/返回风格包括主程序/子程序架构风格、数据抽象和面向对象架构风格和层次结构架构风格；
（3） 独立构件风格包括进程通信架构风格和事件驱动的架构风格；
（4） 虚拟机风格包括解释器架构风格和基于规则的系统；
（5） 仓库风格包括数据库架构风格和黑板架构风格。

其他的还有特定领域软件架构、状态转移等以及分布式处理等。其中分布式架构风格中有客户机/服务器风格、浏览器/服务器风格、CORBA、DCOM、EJB。

每一种具体的软件结构风格的模型如下

数据流风格包括批处理序列和管道/过滤器架构风格。

（1） 批处理序列架构风格。组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
（2）管道/过滤器架构风格。每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，包括通过计算和增加信息丰富数据，通过浓缩和删除精炼数据，通过改变记录方式转化数据，递增地转化数据等。在输入被完全消费之前，输出便产生了。这里构件被称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

调用/返回风格包括主程序/子程序架构风格、数据抽象和面向对象架构风格以及层次结构架构风格。

（1） 主程序/子程序架构风格。单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
（2）数据抽象和面向对象架构风格。这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。对象具有封装性，一个对象的改变不会影响其他对象。对象拥有状态和操作，也有责任维护状态。这种结构风格中包含有封装、交互、多态、集成、重用等特征。 （3）层次结构架构风格。层次系统组织成一个层次结构。构件在一些层实现了虚拟机。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这个风格的特点是每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度。修改一层，最多影响两层，而通常只能影响上层。上层必须知道下层的身份，不能调整层次之间的顺序。

独立构件风格包括进程通信架构风格和事件驱动的架构风格

（1） 进程通信架构风格。构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点对点、异步和同步方式、以及远过程调用等。
（2） 事件驱动的架构风格。构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程的调用。这种风格中的构件是非命名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（Implicit Invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。

虚拟机风格包括解释器架构风格和基于规则的系统

（1） 解释器架构风格。一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率较低。
（2）基于规则的系统。基于规则的系统包括规则集、规则解释器、规则/数据选择器以及工作内存。

仓库风格包括数据库架构风格和黑板架构风格

（1） 数据库架构风格。数据库架构是仓库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态，另一个是多个独立处理元素，处理元素对数据元素进行操作。
（2） 黑板架构风格。黑板架构包括知识源、黑板、控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识，知识源响应黑板上的变化，也只修改黑板。黑板是一个全局数据库，包含解域的全部状态，是知识源互相作用的唯一媒介。知识源响应是通过黑板状态的变化来控制。黑板通常应用在对于解决问题没有确定性算法的系统中，例如信号处理、问题规划、编译器优化等软件系统的设计中。

无服务器架构

无服务器架构并不是不再需要服务器，只是开发人员不再需要担心基础设施，因为一切都由云提供商负责。使用这种方法，开发人员只需部署适当的代码，其他一切由云提供商自动管理。

在传统的Web应用程序架构中，你必须管理基础架构，并确保其满足可扩展性和安全性需求。例如，客户端在一边，服务器在另一边。客户端发送一个“请求”，服务器回复“响应”。但是，如果无法满足应用程序需求，则很快就要扩展服务器端了。

无服务器模型提供了完全不同的方法。与传统架构不同，无服务架构在无状态计算容器中运行，这些容器是事件触发的，短暂的（只能持续一次调用），并由第三方完全管理。就像一个“黑盒子”，这个服务你只需上传代码并实时自动处理。当一个请求进来时，就会运行你的 Lambda 功能的容器。

在成本方面，使用无服务器模型，通常仅支付服务请求和运行代码所需的计算时间。计费以100毫秒为单位进行计量，使其具有成本效益，并且易于自动从每天几个请求到每秒数千次都可以。

无服务器架构的优点包括

（1） 降低运营成本无服务架构本质上是一个外包解决方案。基础设施不会消失。然而，与常规云服务相比，事实上，只需要根据流量规模和形式支付需要的计算量，这可能会大大节省运营成本，特别是对于具有不同变化的早期和动态应用负载要求。
（2） 可扩展性强可扩展性强在云服务领域并不新鲜，但无服务架构将其提升到一个全新的水平。无服务架构的缩放功能不仅可以降低计算成本，还可以减少运行管理，因为缩放是自动的。使用无服务器，无需明确添加和删除实例到服务器阵列，并让供应商为你扩展应用程序。由于云计算提供商根据每个请求执行扩展，所以甚至不需要考虑在内存不足之前可以处理多少并发请求的问题。
（3） 分离问题无服务器几乎迫使你实时关注模型的分离，通过该分离将应用程序分成不同的部分，以使每个部分都解决一个单独的问题。
（4） 隔离进程在无服务器环境中，每个 Lambda 函数都完全隔离。如果其中一个功能关闭，它不影响其他功能，它不会导致服务器崩溃。

无服务器架构的缺点包括

（1）缺乏控制权通过任何外包策略，你都可以将某些系统的控制权给第三方供应商。由于系统停机，意外的限制，成本的变化，功能的丧失，强制的API升级等，这种缺乏控制可能会显现出来。此外，如果需要专门的服务器进行专门的流程，那么必须自己运行这个专门的服务器。一个无服务器架构，在大多数情况下，提供商业化的基础设施，将以广义的方式运行你的流程。
（2）长时间运行流程的高成本如果你的进程持续运行很长时间，则可能会需要运行自己的服务器。因为这不仅涉及成本，还涉及拥有的技能或者想要投入运行自己的服务器的专注；在评估这些解决方案时，请考虑所有这些方面。
（3）供应商锁定将基础架构管理完全外包给无服务器提供商，无疑将自己锁定到该供应商。每个供应商都有自己的标准和编程框架，不容易改变。在几乎每一种情况下，无论从供应商使用的无服务器功能，将由另一个供应商进行不同的实现。如果要切换供应商，几乎肯定需要更新操作工具（部署，监控等），可能还需要更改代码。

软件体系结构演化

软件体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下六个步骤

（1）需求变动归类 首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以应对这部分变化的需求。 （2）制订体系结构演化计划 在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。 （3） 修改、增加或删除构件 在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。 （4） 更新构件的相互作用 随着构件的增加、删除和修改，构件之间的控制流必须得到更新。 （5）构件组装与测试 通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。 （6）技术评审 对以上步骤进行确认，进行技术评审。评审组装后的体系结构是否反映需求变动，符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。

面向服务架构（SOA）

面向服务架构的主要技术有Web服务、ESB。涉及的标准有

1、UDDI协议

UDDI（统一描述、发现和集成协议）计划是一个广泛的、开放的行业计划，它使得商业实体能够（1） 彼此发现，（2） 定义他们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。UDDI 是这样一种基础的系统构筑模块，它使商业实体能够快速、方便地使用他们自身的企业应用软件来发现合适的商业对等实体，并与其实施电子化的商业贸易。

UDDI同时也是Web服务集成的一个体系框架。它包含了服务描述与发现的标准规范。UDDI规范利用了W3C和Internet工程任务组织（IETF）的很多标准作为其实现基础，比如扩展标注语言（XML）、HTTP和域名服务（DNS）等协议。另外，在跨平台的设计特性中，UDDI主要采用了已经被提议给W3C的SOAP（Simple Object Access Protocol，简单对象访问协议）规范的早期版本。

2、WSDL规范

WSDL（Web Services Description Language，Web 服务描述语言），是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言。它是 Web 服务的接口定义语言，由 Ariba、Intel、IBM、MS 等共同提出，通过 WSDL，可描述 Web 服务的三个基本属性

（1）服务做些什么——服务所提供的操作（方法）；
（2） 如何访问服务——和服务交互的数据格式以及必要协议；
（3） 服务位于何处——协议相关的地址，如URL。

WSDL文档以端口集合的形式来描述Web服务，WSDL服务描述包含对一组操作和消息的一个抽象定义，绑定到这些操作和消息的一个具体协议，和这个绑定的一个网络端点规范。

3、SOAP协议

SOAP（Simple Object Access Protocol，简单对象访问协议）是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议。它包括四个部分SOAP封装（Envelop），封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它，以及如何处理它们的框架；SOAP编码规则（Encoding Rules），用于表示应用程序需要使用的数据类型的实例；SOAPRPC表示（RPCRepresentation），表示远程过程调用和应答的协定；SOAP绑定（Binding），使用底层协议交换信息。

负载均衡技术

现有的负载均衡算法主要分为静态和动态两类。静态负载均衡算法以固定的概率分配任务，不考虑服务器的状态信息，如轮转算法、随机法等；动态负载均衡算法以服务器的实时负载状态信息来决定任务的分配，如最小连接法等。

（1） 轮询法

轮询法就是将用户的请求轮流分配给服务器，就像是挨个数数，轮流分配。这种算法比较简单，具有绝对均衡的优点，但是也正是因为绝对均衡，它必须付出很大的代价，例如它无法保证分配任务的合理性，无法根据服务器承受能力来分配任务。

（2）随机法

随机法是随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的，不需要维持上次的选择状态和均衡因子。但是随着任务量的增大，它的效果趋向轮询后也会具有轮询法的部分缺点。

（3） 最小连接法

最小连接法将任务分配给此时具有最小连接数的节点，因此它是动态负载均衡算法。一个节点收到一个任务后连接数就会加1，当节点发生故障时就将节点权值设置为0，不再给节点分配任务。最小连接法适用于各个节点处理的性能相似的情形。任务分发单元会将任务平滑分配给服务器。但当服务器性能差距较大时，就无法达到预期的效果。因为此时连接数并不能准确表明处理能力，连接数小而自身性能很差的服务器可能不及连接数大而自身性能极好的服务器。所以在这个时候就会导致任务无法准确地分配到剩余处理能力强的机器上。

企业集成架构

企业信息集成是解决“孤岛”问题的需要，技术发展的同时也推动了集成架构等相关的研究。构建企业集成平台的首要目的是实现数据集成，即为平台上运行的各种应用、系统或服务，提供具有完整性、一致性和安全性的数据访问、信息查询及决策支持服务。

1、数据集成包括以下3种模式数据联邦、数据复制和基于接口的数据集成。

数据联邦

数据联邦是指不同的应用共同访问一个全局虚拟数据库，通过全局虚拟数据库管理系统为不同的应用提供全局信息服务，实现不同的应用和数据源之间的信息共享和数据交换，其具体实现由客户端应用、全局信息服务和若干个局部数据源三部分组成。

数据复制模式

在数据复制模式中，通过底层应用数据源之间的一致性复制来实现（访问不同数据库的）不同应用之间的信息共享和互操作，其实现的关键是必须能够提供在两个或多个数据库系统之间实现数据转换和传输的基础结构（以屏蔽不同数据库间数据模型的差异）。

基于接口的数据集成模式

在基于接口的数据集成模式中，不同的应用系统之间利用适配器（或接口代理）提供的应用编程接口来实现相互调用。应用适配器或接口代理通过其开放或私有接口将业务信息从其所封装的具体应用系统中提取出来，进而实现不同的应用系统之间业务数据的共享与交换，接口调用的方式可以采用同步调用方法，也可以采用基于消息中间件的异步方法来实现。

2、应用集成

应用集成是指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的互相调用和互操作，应用集成模式包括适配器集成、信使集成、面板集成和代理集成4种。

适配器集成模式

采用在需要交互的系统之间加入适配器的解决方案来实现企业原有应用系统与新实施系统之间的互操作。在应用系统提供的API的基础上（在应用系统没有提供API的情况下，可以在其数据库表结构一致的条件下，直接完成对数据库的写入和读出），通过适配器完成不同系统间数据格式及访问方式的转换与映射，进而实现不同的系统之间业务功能及业务数据的集成。

信使集成模式

随着企业中业务应用系统个数的增多，应用系统间的接口问题变得越来越复杂。基于信使的集成结构中，系统之间的通信和数据交换通过信使（消息代理）来实现，每个应用只需要建立与信使集成之间的接口连接，就可实现与所有通过信使集成相联的应用系统间的交互，这种结构大大减少了接口连接数量，同时由于采用了信使（消息代理）作为信息交流的中介，可以将应用之间的交互对通信服务能力的依赖程度降到最低；另外，当某一系统发生改变时，只需要改变信使中相应的部分，从而降低系统维护工作量和系统升级的难度。

面板集成模式

面板集成模式和面向对象的软件设计方法中的面板模式很相似，它是从应用交互实现的层面来描述客户端应用和服务器端应用集成的一种方法。面板集成可以为一对多、多对一、多对多等多种应用提供集成接口，在这种模式中包含有一个或多个客户端应用、一个面板集成，一个或多个服务器应用，面板集成通过对服务器端应用功能的抽象和简化，为客户端应用访问与调用服务器端应用提供了一种简化的公共接口，面板集成在得到客户应用服务请求后，将客户的服务转换成服务器端应用能理解的形式，并将该请求提交给服务器端应用。

代理集成模式

面板集成模式实现了服务器应用交互逻辑的分离，在代理集成模式中，由于不存在很明显的客户端应用和服务器端应用的划分，它仅需要将待集成的应用间的交互逻辑从应用中分离出来，并对相应文件的交互逻辑进行封装，进而由代理集成来引导多个应用之间的交互。

3、企业集成

企业应用软件系统从功能逻辑上可以分为表示层、业务逻辑层和数据层三个层次，其中表示层负责完成系统与用户交互的接口定义，业务逻辑层主要是根据具体业务规则完成相应业务的数据处理，数据层负责存储由业务逻辑层处理或产生的业务数据，它是系统相对稳定的部分。

从企业集成运行的实现策略上看，EAI主要有如下三种实现模式

前端集成模式

所谓前端集成模式，是指EAI侧重于业务应用系统表示层的集成，它主要通过单一的用户入口，实现跨多个应用事物的运作，这种方式适用于用户启动的业务过程中，会产生多个跨应用的事物，而且这些事物都需要实时响应的情况（主要指B2C的环境）。另外，采用前端集成模式，还可以实现对已经运行的核心业务系统增加功能或特性的目的。

后端集成模式

后端集成模式主要侧重于应用系统数据层面的集成，它通过专门的数据维护及转换工具，实现不同业务应用或数据源之间的信息交换，维护企业整体业务数据完整性和一致性，后端模式就像是一个方便多个应用系统之间数据自动交互的数据管道。

混合集成模式

混合集成模式是前端集成模式和后端集成模式的组合，客户通过基于Web浏览器的客户端（瘦客户）实现对业务应用或EAI服务器的访问，服务请求可以由前端应用系统执行，也可以通过EAI服务器将服务请求路由到后端，由后端的业务应用来执行。这种模式几乎具有前端集成模式和后端集成模式的所有特征，主要应用于需要响应大量服务请求，又需要维护多个数据源的完整性和一致性的情况。

湖仓一体架构

湖仓一体是一种新型的开放式架构，打通了数据仓库和数据湖，将数据仓库的高性能及管理能力与数据湖的灵活性融合了起来，底层支持多种数据类型并存，能实现数据间的相互共享，上层可以通过统一封装的接口进行访问，可同时支持实时查询和分析，为企业进行数据治理带来了更多的便利性。湖仓一体可在数据入湖后原地进行数据处理与分析，能有效避免数据冗余及流动导致的算力、网络及成本开销，可以作为超大型ODS存储贴源数据，实现全量数据的实时处理。

湖仓一体架构在数据管理中主要具有以下几大关键特征

一是支持分析多种类型数据。湖仓一体架构可为多应用程序提供数据的入库、转换、分析和访问。数据类型包括结构化与非结构化类型，如文本、图像、视频、音频等，以及半结构化数据，如JSON等。

二是数据可治理，避免产生数据沼泽。湖仓一体架构可以支持各类数据模型的实现和转变，支持DW模式架构，例如星型模型、雪花模型等，可保证数据的完整性，同时具有健全的治理和审计机制，能够避免数据沼泽现象的出现。

三是事务支持。在企业中，数据库往往要为业务系统提供并发的数据读取和写入。湖仓一体架构对事务 ACID 的支持，可确保并发访问，尤其是 SQL 访问模式下的数据一致性、正确性。

四是BI支持。湖仓一体支持直接在源数据上使用BI工具，这样可以提高分析效率，降低数据延时。另外，相比于在数据湖和数据仓库中分别操作两个副本的方式，湖仓一体更具成本优势。

五是存算分离。湖仓一体采用存算分离架构，可使系统能够扩展到更大规模的并发能力和数据容量，能满足新时代对于分布式数据架构的要求。

六是开放性。湖仓一体采用开放、标准化的存储格式（例如行存、列存、块存），能提供丰富的API支持。因此，各种工具和引擎（包括机器学习和Python/R库）可以高效地对数据进行直接访问。

从落地性来看，湖仓一体技术架构落地目前有三种方式

第一个融合方向是基于Hadoop体系的数据湖向数据仓库能力扩展，湖中建仓，从数据湖进化到湖仓一体。湖仓一体结合了数据湖和数据仓库特点，直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。目前主要有Netflix等开源企业在探索此技术路线。

第二个是基于自身云平台或第三方对象存储（如OSS、S3、Ceph等），基于Hadoop或自研技术进行湖仓一体能力的搭建。探索此技术路线的通常是各大云厂商，如AWS、阿里云、华为云等。

第三个融合方向是以数据库技术为基础，自研分布式平台，从调度、计算到存储不依赖第三方平台，形成可以灵活在公有云、私有云、裸金属等场景独立部署使用的能力。技术方向上更注重于实时高并发场景及非结构化数据治理，并逐步向更广泛的分析场景发展，主要厂商以 Snowflakes、Databricks、巨杉数据库等为代表。

三个技术方向均是厂商依托自身技术优势进行的架构融合，均有自身优劣势及技术特性，能够满足不同场景下的客户需求。

湖仓一体架构未来的发展趋势一是随着企业对海量大数据的实时处理需求越来越迫切，湖仓一体架构将成为越来越多用户的主流选择，助力各行各业数字化转型；二是以人为本的数据开发和优化，将越来越难以满足企业实际需求，届时人工智能技术将介入数据库的自动调优、自动整理过程，助力提升湖仓一体架构的智能化。

Lambda 架构

Lambda架构可分解为三层，即批处理层、加速层和服务层。

（1） 批处理层（Batch Layer） 存储数据集, Batch Layer 在数据集上预先计算查询函数, 并构建查询所对应的 View。Batch Layer 可以很好地处理离线数据, 但有很多场景数据是不断实时生成且需要实时查询处理, 对于这种情况, Speed Layer 更为适合。 （2）加速层（Speed Layer）Batch Layer处理的是全体数据集，而Speed Layer处理的是最近的增量数据流。Speed Layer为了效率，在接收到新的数据后会不断更新Real-time View，而Batch Layer是根据全体离线数据集直接得到Batch View。
（3）服务层（Serving Layer）Serving Layer用于合并Batch View和Real-time View中的结果数据集到最终数据集。

Lambda架构优缺点

1、优点

（1） 容错性好。Lambda 架构为大数据系统提供了更友好的容错能力，一旦发生错误，我们可以修复算法或从头开始重新计算视图。
（2） 查询灵活度高。批处理层允许针对任何数据进行临时查询。
（3）易伸缩。所有的批处理层、加速层和服务层都很容易扩展。因为它们都是完全分布式的系统，我们可以通过增加新机器来轻松地扩大规模。
（4） 易扩展。添加视图是容易的，只是给主数据集添加几个新的函数。

2、缺点

（1） 全场景覆盖带来的编码开销。
（2）针对具体场景重新离线训练一遍益处不大。
（3） 重新部署和迁移成本很高。

边缘计算

边缘计算模型区别于传统的云计算模型、网格计算模型、分布式计算等模型，是一种新型的计算模型。

（1）从资源配置看

边缘计算是调动全局的资源为其所用，是集中心侧、边缘侧资源整合整体优势进行相应的处理，完成全局的最优。也就是说，边缘计算并不是孤立的计算模型，需要整体考虑资源的配置和调度。

（2）从协同模式看

边缘计算具备中心侧和边缘侧两方的资源，因此需要进行协同，本地能处理好的事情，就近处理，解决不了的事情交予中心侧或其他协同方的资源进行处理。因此，边缘计算模型是一种协同计算模型，与各个边缘侧、中心侧都有关联，需要统一的协调和资源调配，达到资源利用的最大化。

（3） 从智能程度看

边缘计算需要优势互补，需要协同并进、需要感知用户场景、需要优化配置资源，而这些势必需要机器智能，因此边缘计算涵盖一种智能化的、自动化的资源配置方式。事前简单的用户配置、参数定义，不能有效满足用户侧的效用需求。用户侧需要实时地感知配置资源，以便就近提供高带宽、高可靠、高性能的服务。

（4） 从体系结构看

边缘计算是在靠近网络边缘侧大规模部署智能终端设备，和传统的云、网、端三层模型具有一致性，但是亦有区别。原因在于，云、网、端只是基础设施的布局，是静态的一种结构，而边缘计算本质是一种动态的、自动化的资源配置方式，从而区别于以上静态结构。更确切的讲，边缘计算是云、网、端、智四位一体的模型，智能纵向涵盖云、网、端，从上到下均涵盖。因此边缘计算是一种具备智能的云、网、端结构，智能化是其重要的特征之一。

（5）从异构处理看

参与边缘计算的设备众多，设备的异构是边缘计算的一大特征。传统的云计算往往通过设备的虚拟化、形成众多的虚拟机来进行统一管理。而边缘计算的设备异构型不能简单的虚拟化来解决，其复杂程度要远远高于云计算。例如不同类型、不同指标、不同参数、不同用途、不同厂商、不同功能的设备需要互联，需要统一处理相应的问题。设备间的互联互通将是边缘计算模型中不可或缺的组成部分，是目前该技术面临的一大挑战。

（6） 从服务模式看

云计算具有三层服务模式，即IaaS、PaaS、SaaS，而边缘计算将对此模式进行改变或补充。边缘计算不具有典型的三层模式，边缘计算无需统一屏蔽底层的差异，而是根据应用需求进行把控。边缘计算模型需要考虑问题是如何和云计算三层模型进行有效的对接和协同，而不是进行统一。因此，边缘计算具有其差异性和特殊性，不是典型的三层服务模型。

边云协同是边缘计算与云计算深度融合的重要模式，通过资源、数据、智能等维度的协同实现高效分布式计算。以下是六种边云协同模式的核心含义

资源协同通过云端的全局调度能力与边缘端的实时响应能力结合，实现计算、存储、网络资源的动态分配。

典型场景云端统一编排边缘节点资源，根据业务负载动态调整边缘服务器算力配置。

数据协同建立边缘数据预处理与云端深度分析的协同机制，形成“边缘清洗-云端建模-边缘推理”的数据闭环。

典型场景工业设备在边缘端进行异常数据过滤，云端构建预测模型后下发至边缘实时监测。

智能协同实现AI模型在云端的集中训练与边缘端的分布式推理协同，形成“云训练+边缘部署”的智能体系。

典型场景自动驾驶系统通过云端训练高精度模型，经轻量化处理后部署到车载边缘计算单元。

应用管理协同构建统一的DevOps体系，支持应用在云端开发测试与边缘端灰度发布的协同管理。

典型场景物联网应用在云端完成容器化开发，通过分级发布策略逐步推送到边缘节点。

业务管理协同实现业务流程在云端策略制定与边缘端执行优化的双向互动，形成闭环业务决策机制。

典型场景零售企业云端制定智能补货策略，边缘系统根据门店实时销售数据动态调整执行方案。

服务协同通过服务网格构建跨边云的微服务体系，实现服务发现、流量管理、故障转移的端到端协同。

典型场景视频直播服务根据用户位置动态选择最近的边缘节点处理，异常时自动切换云端备用服务。

这六种协同模式相互关联，共同构建了从基础设施到上层应用的完整边云协同架构，体现了“集中管控”与“分布式执行”的有机统一，已成为数字化转型的重要技术范式。

云上自动化运维

CloudOps的定义与主要衡量指标

CloudOps是传统IT运维和DevOps的延展，通过云原生架构实现运维的再进化，充分帮助企业降低IT运维成本、提升交付速度和系统灵活敏捷度、增强系统可靠性，构建更加安全可信开放的业务平台。

DevOps已经在组织文化、产品、流程和工具有比较详细的定义，即通过敏捷组织和高效的持续集成持续发布，实现业务高质量的快速交付。

下面从公共云上如何进行自动化运维和自助服务的角度，着重梳理了衡量CloudOps成熟度的五大维度

自动化能力

云计算核心就是自动化的运维能力，通过软件定义计算、存储、网络，来实现高级的可编程能力，从而避免人工配置的错误，充分实现可定制的自动化能力。而公有云的服务模式要求云厂商提供的云产品和云服务都必须是统一标准的，即所有云产品和云服务都可以通过OpenAPI进行调用从而实现完全自动化的能力。

弹性能力

云计算另外一个巨大技术红利就是弹性能力，针对计算、网络、存储、安全等基础资源，充分的发挥资源池化和分时复用的价值，通过弹性能力帮助客户应对业务的高峰，充分降低社会成本和企业运营的IT成本，提升资源的利用率，可以极速实现资源到应用的水平或者垂直升级，通过秒级到分钟级扩缩容能力，完成计算力的创建和释放。

高可用能力

云计算天生就是为提升可靠性和可用性而设计的通过大规模数据中心、多数据中心技术，实现数据中心同城灾备，通过对硬件层的虚拟化，来降低和规避物理硬件故障对客户的影响，通过成熟高可用的服务来降低系统的复杂性。为了进一步提升应用的可观测性和问题的排查能力，云平台还会提供比较多的自助服务来做问题的排查和解决。

安全和合规能力

云上的安全涉及多方面，包括底层技术设施和应用层的。这里主要讨论跟底层资源相关的。首先第一个便是网络安全。区别于传统的DC，云计算为了对租户进行隔离，一般会构建私有网络或者专有网络，通常我们称为VPC（Virtual Private Cloud）。VPC相较传统网络有更好的灵活性、易用性和安全性，并且暴露了更多的能力来提升网络扩展性。它允许用户按需规划、定义自己的网段划分和路由规则，将传统的路由器交换机抽象成软件，并暴露给最终用户使。VPC良好的扩展性，让用户能够构建简单可信的网络配置，实现企业级复杂的网络环境。对于VPC的规则设置和配置，都将大大影响网络安全性。

另外，DevOps中操作审计和追踪是非常重要的能力，在CloudOps中亦然，云计算平台一般也会提供相应的为您提供面向资源和操作的配置历史追踪、配置合规审计等能力，帮助客户轻松实现基础设施的自主监管，确保持续性合规。

成本和资源量化管理

云提供了大规模的资源创建和变配策略，也提供了多种多样的付费和计费手段以及方便灵活的变配方法，如何选择合适的资源规格和付费方式是非常重要的，由于其方便灵活的特性，往往会有类似停机不收计算类资源费用，以及折扣非常低的抢占式实例，特别是按需创建资源和关停不需要的计费资源，需要我们有良好的成本和资源量化管理习惯和能力。

模型驱动架构设计方法

模型驱动架构设计是一种用于应用系统开发的软件设计方法，以模型构造、模型转换和精化为核心，提供了一套软件设计的指导规范。在模型驱动架构环境下，通过创建出机器可读和高度抽象的模型实现对不同问题域的描述，这些模型独立于实现技术，以标准化的方式储存，利用模型转换策略来驱动包括分析、设计和实现等在内的整个软件开发过程。

1、模型驱动架构能够为软件开发带来的好处

（1） 模型驱动架构将开发人员的注意力转移到了平台无关模型中，可以避免陷入到具体的实现细节当中去，从而简化了系统开发的工作量，提高了软件的开发效率；
（2）对于多种流行平台，很多工具会支持从平台无关模型到平台相关模型的转换；对于将来可能出现的新技术和平台，确定了平台表示及公共中间件的概念和功能，利用转换规则快速实现平台无关模型到新技术平台的迁移，提高了系统的可移植性；
（3）利用模型驱动架构中基于平台无关模型的桥接器，实现了多个平台相关模型之间跨平台的相互通信，加强了互操作性；
（4） 对于系统变更，通过修改平台无关模型并重新生成平台相关模型和代码，能够降低系统维护的成本；
（5）平台无关模型帮助团队成员之间提高沟通效率并减少错误，自动生成码能够保证代码的质量和一致性，确保了软件的质量；
（6）使用模型驱动架构时，功能和架构独立定义，针对新技术，能够利用原有的设计产生对应的实现，延长了系统的生命周期。

2、模型驱动架构的开发过程

（1） 使用平台无关模型从如何以最好的方式支持商业逻辑的角度对系统进行建模，开发人员根据用户需求和其他因素对平台无关模型进行精化，以使它能够更加精确地描述系统；
（2）将平台无关模型转换到一个或多个特定技术相关的平台相关模型，对于每种特定的技术都会生成独立的平台相关模型；
（3）根据技术特性对生成的平台相关模型进行修改以满足程序设计人员的要求，这些修改可以反映到平台无关模型中去；

（4） 对平台相关模型不断精化，以指导代码生成器生成质量更高的程序代码；
（5） 最后将每个平台相关模型转换到代码，进行后续的完善和系统测试。

微服务架构

微服务架构是SOA架构的升级，是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等中。

通过比较微服务架构和单体式架构。

微服务架构的主要优点有1）复杂应用解耦；2）独立；3）技术选型灵活；4）容错；5）松耦合，易扩展。

微服务架构的主要缺点有1）微服务架构分布式特点带来的复杂性。服务发现与服务调用链跟踪变得困难；分布式环境下的数据一致性更复杂；测试的复杂性，需要对服务间依赖进行测试。2）在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。

云原生架构

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

在代码中通常包括三部分业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码；“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库；“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步，从业务代码中剥离了大量非功能性特性（不会是所有，比如易用性还不能剥离）到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。

云原生架构原则

云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。

1、服务化原则

当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务（Mini Service）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。

分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非网络流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。

2、弹性原则

大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请、到供应商洽谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期，而这期间如果业务发生变化了，重新调整也非常困难。弹性原则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出（闲置成本），降低了企业的IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而“说不”，保障了企业收益。

3、可观测原则

今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM等系统提供的能力不同，前者是在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

4、自动化原则

技术往往是把“双刃剑”，容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator和大量自动化交付工具在CI/CD流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。

系统设计

设计模式的基本分类

创建型模式。创建型模式抽象了实例化过程，它们帮助一个系统独立于创建、组合和表示它的那些对象。创建型模式包括工厂方法、抽象工厂、生成器、原型、单例模式等。

结构型模式。结构型模式涉及如何组合类和对象以获得更大的结构。结构型模式包括适配器、桥接、组合、装饰、外观、享元、代理等。

行为模式。行为模式涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述了它们之间的通信模式。常用的行为模式有观察者、策略等。

常见的数据访问层设计技术

（1） 在线访问该模式是基本的数据访问模式，在软件系统中不存在专门的数据访问层，由业务程序直接读取数据，与后台数据源进行交互。
（2）Data Access ObjectDAO模式是标准J2EE设计模式之一，该模式将底层数据访问操作与高层业务逻辑分离开。具体的DAO类包含访问特定数据源数据的逻辑。
（3） Data Transfer Object DTO 是经典 EJB 设计模式之一。DTO 本身是一组对象或是数据的容器, 它需要跨越不同进程或者网络的边界来传输数据。这类对象通常本身不包括具体的业务逻辑, 对象内部仅进行一些诸如内部一致性检查和基本验证之类的方法。
（4） 离线数据模型是以数据为中心，数据从数据源获取后，将按照某种预定义的结构（如 IBM SDO 的 Data 图表结构或 ADO.NET 中的关系结构）存放在系统中，成为应用的中心。其特点是①离线，数据操作独立于后台数据源；②与 XML 集成，数据可以方便地与 XML 格式文档相互转换。
（5） 对象/关系映射（Object/Relation Mapping） ORM 是一种工具、中间件或平台, 它能够帮助将应用程序中的数据转换成关系数据库中的记录; 或者是将关系数据库中的记录转换成应用程序中代码便于操作的对象, 使得程序员在开发过程中仅仅面对一个对象的概念, 降低了对程序员数据库知识的要求, 简化了数据库相关的开发工作。

软件质量保证

质量保证是指定期评估项目总体绩效，建立项目能达到相关质量标准的信心。质量保证对项目的最终结果负责，而且还要对整个项目过程承担质量责任；质量控制是指监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。

软件质量保证（Software Quality Assurance，SQA）是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，这些活动贯穿于软件生产的各个阶段即整个生命周期。SQA由各项任务构成，这些任务的参与者有两种人，分别是软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。软件开发人员通过采用可靠的技术、方法和措施，进行正式的技术评审，执行软件测试来保证软件产品的质量。质量保证人员则辅助软件开发人员得到高质量的最终产品。

美国卡耐基梅隆大学软件工程研究所推荐了一组有关质量保证的计划、监督、记录、分析及报告的SQA活动，这些活动由一个独立的SQA小组执行。

（1） 制订 SQA 计划。SQA 计划在制订项目计划时制订，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动。有关该计划的详细内容，请阅读《系统分析师教程》20.2 节。
（2）参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与企业政策、内部的软件标准、外界所制订的标准以及项目开发计划的其他部分相符。
（3）评审。评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。
（4）审计。审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。
（5）记录并处理偏差。确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。
（6） 报告。记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。除了进行上述活动外，SQA 小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息

NoSQL

NoSQL，泛指非关系型的数据库。随着互联网Web0网站的兴起，传统的关系数据库在处理Web0网站，特别是超大规模和高并发的SNS类型的Web0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。

NoSQL的主要优势

（1） 避免不必要的复杂性;
（2）高吞吐量；
（3） 高水平扩展能力和低端硬件集群;
（4） 避免了昂贵的对象-关系映射。

NoSQL的缺点

（1） 数据模型和查询语言没有经过数学验证;
（2）不支持ACID特性；
（3） 功能简单;
（4） 没有统一的查询模型。

NoSQL数据库的四大分类

1、键值（Key-Value）存储数据库

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。例如Tokyo Cabinet/Tyrant，Redis，Voldemort，Oracle BDB。

2、列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如Cassandra, HBase, Riak。

HBaseHBase 是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的 Google 论文“Bigtable一个结构化数据的分布式存储系统”。就像 Bigtable 利用了 Google 文件系统（File System）所提供的分布式数据存储一样，HBase 在 Hadoop 之上提供了类似于 Bigtable 的能力。HBase 是 Apache 的 Hadoop 项目的子项目。HBase 不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是 HBase 基于列的而不是基于行的模式。

3、文档型数据库

文档型数据库的灵感是来自于 Lotus Notes 的办公软件，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如 JSON。文档型数据库可以看作是键值数据库的升级版，允许文档之间嵌套键值，而且文档型数据库比键值数据库的查询效率更高，如Couch DB，Mongo DB。国内也有文档型数据库 Sequoia DB，已经开源。

Mongo DB MongoDB 是目前在 IT 行业非常流行的一种非关系型数据库（NoSql）, 其灵活的数据存储方式备受当前 IT 从业人员的青睐。Mongo DB 很好的实现了面向对象的思想（OO 思想）, 在 MongoDB 中, 每一条记录都是一个 Document 对象。Mongo DB 最大的优势在于所有的数据持久操作都无需开发人员手动编写 SQL 语句, 直接调用方法就可以轻松的实现 CRUD 操作。

Sequoia DB Sequoia DB 是一款分布式非关系型文档数据库，可以被用来存取海量非关系型的数据，其底层主要基于分布式、高可用、高性能与动态数据类型设计。Sequoia DB 可以独立作为一款高性能可扩展的 NoSQL 数据库使用，也可与当前主流分布式计算框架 Hadoop 紧密集成。

4、图形（Graph）数据库

图形结构的数据库同其他行列以及刚性结构的 SQL 数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL 数据库没有标准的查询语言（SQL），因此进行数据库查询需要制定数据模型。许多 NoSQL 数据库都有 REST 式的数据接口或者查询 API。如Neo4J, InfoGrid, Infinite Graph。

NoSQL数据库在以下的这几种情况下比较适用

数据模型比较简单；
需要灵活性更强的IT系统；
对数据库性能要求较高；
不需要高度的数据一致性；
对于给定key，比较容易映射复杂值的环境。

Redis 数据分片方案

（1） 范围分片按数据范围值来做分片。如按用户编号分片，0-999999 映射到实例 A；1000000-1999999 映射到实例 B。
（2）hash分片通过对key进行hash操作，可以把数据分配到不同实例，这类似于取余操作，余数相同的，放在一个实例上。
（3） 一致性hash分片hash分片的改进，可以有效解决重新分配节点带来的无法命中问题。

软件测试中缺陷管理及其应用

软件缺陷定义

（1）软件未达到需求规格说明书的功能；
（2）软件出现了需求规格说明书指明不会出现的错误；
（3） 软件功能超出需求规格说明书的范围;
（4） 软件未达到需求规格说明书未指出但应达到的目标;
（5） 测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

缺陷类型

（1） 设计缺陷由于软件设计或代码实现所产生的功能或流程的问题。
（2）界面问题系统页面的展示的问题。
（3） 数据问题系统数据的来源，处理及处理结果的问题。
（4） 需求问题软件需求测试发现的问题，也包括之后需求变更的问题。
（5）安装部署软件安装部署过程的错误。
（6）性能问题软件性能相关的缺陷。
（7） 文档问题用户使用手册，软件帮助文档等出现的问题。
（8） 常识问题系统用户的正常使用相关问题。
（9） 安全问题系统漏洞安全问题。
（10） 优化建议针对操作过程逻辑或界面显示的优化性建议。
（11） 其他除前面分类的其他问题。

严重程度定义

优先级定义

正常处理过程

（1） 创建问题

在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项。

（2）指派问题

创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。

如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。

（3） 确认问题

通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。

当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。

如果问题确认指派次数大于6次时，需要进入“争议处理”流程。

（4） 解决问题

此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。

开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。

如果 Bug 无法解决或修改影响比较大，可申请进入“延期解决”流程。

（5）验证问题

创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

验证通过准则相同的操作步骤，进行一定次数的验证测试都没有发生。

验证不通过准则相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活 Bug。

（6） 关闭问题

通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。

如果关闭状态的 Bug 在之后版本又会发生，则激活此 Bug，系统将自动指派回给解决者。

特别处理过程

（1） 客户问题

客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到客户问题后，将确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。

创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。

（2）争议处理

当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。

项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。

（3）延期解决

当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较大等，可以说明原因或理由并指派给项目经理来确认。

项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。

面向方面的编程技术（AOP）

AOP（Aspect-Oriented Programming，面向方面编程），可以说是OOP（Object-Oriented Programming，面向对象编程）的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能，日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（cross-cutting）代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。

而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其命名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，以减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。AOP代表的是一个横向的关系，如果说“对象”是一个空心的圆柱体，其中封装的是对象的属性和行为；那么面向方面编程的方法，就仿佛一把利刃，将这些空心圆柱体剖开，以获得其内部的消息。而剖开的切面，也就是所谓的“方面”了。然后它又以巧夺天工的妙手将这些剖开的切面复原，不留痕迹。

使用“横切”技术，AOP把软件系统分为两个部分核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似，比如权限认证、日志、事务处理。AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。

AOP 应用程序包括以下三个主要的开发步骤

1、将系统需求进行功能性分解，区分出普通关注点以及横切关注点，确定哪些功能是组件语言必须实现的，哪些功能可以以 aspect 的形式动态加入到系统组件中。
2、单独完成每一个关注点的编码和实现，构造系统组件和系统 aspect。这里的系统组件，是实现该系统的基本模块，对于 OOP 语言，这些组件可以是类，对于过程化程序设计语言，这些组件可以是各种函数和 API。系统 aspect 是指用 AOP 语言实现的将横切关注点封装成的独立的模块单元。
3、用联接器指定的重组规则，将组件代码和 aspect 代码进行组合，形成最终系统。为达到此目的，应用程序需要利用或创造一种专门指定规则的语言，用它来组合不同应用程序片断。这种用来指定联结规则的语言可以是一种已有编程语言的扩展，也可以是一种完全不同的全新语言。

基于构件的软件开发方法

基于构件的软件工程（Component-Based Software Engineering，CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中构件可以是COTS（Commercial-Off-The-Shelf）构件，也可以是通过其他途径获得的构件（自行开发）。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低软件开发的费用。

用于CBSE的构件应该具备以下特征。

（1） 可组装型对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
（2）可部署性软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
（3） 文档化构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
（4） 独立性构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
（5）标准化构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。

CBSE过程是支持基于构件组装的软件开发过程，需要考虑构件复用的可能性，以及在开发和使用可复用的构件中所涉及的不同过程活动，成功的构件复用需要一个经过裁剪、适配的开发过程，以便在软件开发过程中包含可复用的构件。

CBSE过程中的主要活动包括（1）系统需求概览；（2）识别候选构件；（3）根据发现的构件修改需求；（4）体系结构设计；（5）构件定制与适配；（6）组装构件，创建系统。

构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式。

1、顺序组装

通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。顺序组装的类型可能适用于作为程序元素的构件或是作为服务的构件。需要特定的胶水代码，来保证两个构件的组装上一个构件的输出，与下一个构件的输入相兼容。

2、层次组装

这种情况发生在一个构件直接调用由另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。因此，被调用构件的“提供”接口必须和调用构件的“请求”接口兼容，如果接口相匹配，则调用构件可以直接调用被调用构件，否则就需要编写专门的胶水代码来实现转换。

3、叠加组装

这种情况发生在两个或两个以上构件放在一起创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。当创建一个系统时，可能会用到所有的构件组装方式，对所有情况都必须编写胶水代码来连接构件。

而当编写构件尤其是为了组装来写构件时，经常可能会面临接口不兼容的问题，即所要组装的构件的接口不一致。一般会出现3种不兼容情况。

（1） 参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
（2）操作不兼容。提供接口和请求接口的操作名不同。
（3） 操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。

针对上述不兼容情况，必须通过编写适配器构件来解决不兼容的问题，适配器构件使两个可复用构件的接口相一致；适配器构件将一个接口转换为另外一个接口。当用户选择组装方式时，必须考虑系统所需要的功能性需求、非功能性需求，以及当系统发生改变时，一个构件能被另一个构件替代的难易程度。

软件维护方法

一般系统架构的好坏，可维护性是一个重要方面，维护人员应参与架构的评审。

系统的可维护性可以定性地定义为维护人员理解、改正、改动和改进这个软件的难易程度，提高可维护性时开发管理系统所有步骤的关键目的。系统能否被很好地维护，可用系统的可维护性这一指标来衡量。系统的可维护性有如下几个评价指标可理解性、可测试性、可修改性。

依据信息系统需要维护的原因不同，系统维护工作可以分为以下4种类型更正性维护、适应性维护、完善性维护、预防性维护。

正确性维护指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。

适应性维护指使应用软件适应环境变化（外部环境、数据环境）而进行的修改。

完善性维护扩充功能和改善性能而进行的修改。

预防性维护为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。

某个维护目标确定以后，维护人员必须先理解要维护的系统，然后建立一个维护方案。由于程序的修改涉及面较广，某处修改很可能会影响其他模块程序，所以建立维护方案后要加以考虑的重要问题是修改的影响范围和波及面的大小。然后按预定维护方案修改程序，若测试发现重大问题，则要重复上述步骤。若通过，则修改相应文档并交付使用，结束本次维护工作。必须强调的是，维护是对整个系统而言的。因此，除了修改程序、数据和代码等部分以外，必须同时修改涉及的所有文档。

RUP

RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。

四个阶段的核心任务分别为

（1）初始阶段

明确地说明项目规模。这涉及了解环境及最重要的需求和约束，以便于可以得出最终产品的验收标准。

计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折中的备选方案。

综合考虑备选架构，评估设计和自制/外购/复用方面的折中，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在细化和构建阶段实现。

准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。

（2）细化阶段

快速确定架构，确认架构并为架构建立基线。

根据此阶段获得的新信息改进前景，对推动架构和计划决策的最关键用例建立可靠的了解。

为构建阶段创建详细的迭代计划并为其建立基线。

改进开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。

改进架构并选择构件。评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选架构构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计架构、考虑替代设计或重新考虑需求。

（3）构建阶段

资源管理、控制和流程优化。

完成构件开发并根据已定义的评估标准进行测试。

根据前景的验收标准对产品发布版进行评估。

（4）产品化阶段（交付阶段）

执行部署计划。

对最终用户支持材料定稿。

在开发现场测试可交付产品。

制作产品发布版。

获得用户反馈。

基于反馈调整产品。

使最终用户可以使用产品。

RUP最核心的3个特征是用例驱动、以架构为中心、迭代和增量。

制品（Artifact）——what 的问题制品是活动生成、创建或修改的一段信息。也可译为产品、工件等，和制品的意思差不多。

工作流（Workflow）——when 的问题工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

软件设计方法包括

（1） 模型驱动设计。

模型驱动设计是一种系统设计方法，强调通过绘制图形化系统模型描述系统的技术和实现。通常从模型驱动分析中开发的逻辑模型导出系统设计模型，最终，系统设计模型将作为构造和实现新系统的蓝图。

（2）结构化设计。

结构化设计是一种面向过程的系统设计技术，它将系统过程分解成一个容易实现和维护的计算机程序模块。把一个程序设计成一个自顶向下的模块层次，一个模块就是一组指令一个程序片段、程序块、子程序或者子过程，这些模块自顶向下按照各种设计规则和设计指南进行开发，模块需要满足高度内聚和松散耦合的特征。

（3） 信息工程。

信息工程是一种用来计划、分析和设计信息系统的模型驱动的、以数据为中心的但对过程敏感的技术。信息工程模型是一些说明和同步系统的数据和过程的图形。信息工程的主要工具是数据模型图（物理实体关系图）。

（4） 原型设计。

原型化方法是一种反复迭代过程，它需要设计人员和用户之间保持紧密的工作关系，通过构造一个预期系统的小规模的、不完整的但可工作的示例来与用户交互设计结果。原型设计方法鼓励并要求最终用户主动参与，这增加了最终用户对项目的信心和支持。原型更好地适应最终用户总是想改变想法的自然情况。原型是主动的模型，最终用户可以看到并与之交互。

（5） 面向对象设计。

面向对象设计是一种新的设计策略，用于精炼早期面向对象分析阶段确定的对象需求定义，并定义新的与设计相关的对象。面向对象设计是面向对象分析的延伸，有利于消除“数据”和“过程”的分离。

（6） 快速应用开发。

RAD是瀑布的高速变种，通过使用基于构件的开发方法获得快速的开发进度。

数据湖与数据仓库

数据仓库是一个优化的数据库，用于分析来自事务系统和业务线应用程序的关系数据。数据仓库技术需要事先定义数据结构和数据模式（Schema）以优化快速 SQL 查询，其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换，因此可以充当用户可信任的“单一信息源”。与数据仓库不同，数据湖能够同时存储来自业务线应用程序的关系数据，以及来自移动应用程序、物联网设备和社交媒体的非关系数据。在进行数据捕获时，无须定义数据结构或数据模式（Schema）。数据湖支持用户对数据使用不同类型的分析（如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习等），为企业智能决策提供支撑。

下面从主要数据来源、数据模式转换时机、数据存储成本、数据质量、面对用户和主要支撑应用类型等六个方面对数据湖技术和数据仓库技术进行比较

企业集成平台

集成平台是支持企业集成的支撑环境，包括硬件、软件、软件工具和系统，通过集成各种企业应用软件形成企业集成系统。由于硬件环境和应用软件的多样性，企业信息系统的功能和环境都非常复杂，因此，为了能够较好地满足企业的应用需求，作为企业集成系统支持环境的集成平台，其基本功能主要有

（1）通信服务

它提供分布环境下透明的同步/异步通信服务功能，使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置，而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。

（2）信息集成服务

它为应用提供透明的信息访问服务，通过实现异种数据库系统之间数据的交换、互操作、分布数据管理和共享信息模型定义（或共享信息数据库的建立），使集成平台上运行的应用、服务或用户端能够以一致的语义和接口实现对数据（数据库、数据文件、应用交互信息）的访问与控制。

（3）应用集成服务

它通过高层应用编程接口来实现对相应应用程序的访问，这些高层应用编程接口包含在不同的适配器或代理中，它们被用来连接不同的应用程序。这些接口以函数或对象服务的方式向平台的组件模型提供信息，使用户在无需对原有系统进行修改（不会影响原有系统的功能）的情况下，只要在原有系统的基础上加上相应的访问接口就可以将现有的、用不同的技术实现的系统互联起来、通过为应用提供数据交换和访问操作，使各种不同的系统能够相互协作。

（4）二次开发工具

二次开发工具是集成平台提供的一组帮助用户开发特定应用程序（如实现数据转换的适配器或应用封装服务等）的支持工具，其目的是简化用户在企业集成平台实施过程中（特定应用程序接口）的开发工作。

（5）平台运行管理工具

它是企业集成平台的运行管理和控制模块，负责企业集成平台系统的静态和动态配置、集成平台应用运行管理和维护、事件管理和出错管理等。通过命名服务、目录服务、平台的动态静态配置，以及其中的关键数据的定期备份等功能来维护整个服务平台的系统配置及稳定运行。

多源数据集成

1、数据预处理与清洗策略

数据预处理与清洗策略的核心任务有数据去噪、格式统一和缺失值处理。数据去噪是移除重复记录（如重复的订单信息）、错误数据（如年龄字段出现负数）或无效数据（如缺失关键字段的日志）。格式统一是将不同格式的数据（如CSV、JSON、XML）转换为统一结构。缺失值处理是通过插值（均值填充）、删除或预测模型（如回归算法）填补缺失值。

作用

提升数据质量为后续分析提供可靠的数据基础。

降低计算成本减少冗余数据对存储和算力的浪费。

2、数据映射与转换策略

数据映射与转换策略的核心任务有对数据进行模式映射、语义对齐和数据标准化。模式映射是建立不同数据源字段的对应关系（如“客户ID”映射到“用户编号”）。语义对齐是解决同名异义（如“销售额”在不同系统中可能包含/不含税费）或异名同义问题。数据标准化是统一单位（如货币转换为美元）、编码（如性别“男/女”统一为“M/F”）和取值范围。

作用

消除异构性解决多源数据的结构差异和语义冲突。

支持融合分析为跨数据源关联分析提供统一视图。

3、数据整合与验证策略

数据整合与验证策略的核心任务是将数据进行物理或逻辑整合、并对整合后的数据进行一致性验证。物理整合即通过数据仓库（如Hive）集中存储多源数据。逻辑整合即利用虚拟化技术（如联邦数据库）实现跨库查询。一致性验证是检查整合后数据的完整性（如关键字段是否缺失）和逻辑正确性（如订单金额是否与商品单价 $\times$ 数量一致）。

作用

构建统一数据资产打破数据孤岛，形成全局可用的数据池。

保障数据可信度防止错误数据进入下游业务系统。

4、数据冲突解决策略

数冲突解决策略的核心任务是冲突检测和冲突消解，冲突检测即识别多源数据中对同一实体的矛盾描述（如客户地址在CRM系统和物流系统中不一致）。冲突消解分两类，基于规则的冲突消解是按数据源优先级（如权威数据库优先）或时间戳（最新数据覆盖旧数据）自动处理；基于算法的冲突消解是使用投票机制（多数一致）或机器学习模型（如聚类分析）智能决策。

作用

维护数据权威性确保业务决策基于一致、准确的数据。

支持动态更新适应多源数据持续变化的场景。

单元测试

软件测试方法的分类有很多种，以测试过程中程序执行状态为依据可分为静态测试（Static Testing, ST）和动态测试（Dynamic Testing, DT）；以具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试、白盒测试和灰盒测试3类；从程序执行的方式来分类，可分为人工测试（Manual Testing, MT）和自动化测试（Automatic Testing, AT）。

（1）静态测试。静态测试是被测程序不运行，只依靠分析或检查源程序的语句、结构、过程等来检查程序是否有错误。即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等。
（2）动态测试。动态测试与静态测试相对应，是通过运行被测试程序，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。这种方法可简单分为3个步骤构造测试实例、执行程序以及分析结果。
（3）黑盒测试。黑盒测试将被测程序看成是一个黑盒，工作人员在不考虑任何程序内部结构和特性的条件下，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以量化才能够有效的保证软件的质量。
（4）白盒测试。白盒测试主要是借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。白盒测试是从程序结构方面出发对测试用例进行设计。主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。根据测试用例的覆盖程度，分为语句覆盖、判定覆盖、分支覆盖和路径覆盖等。
（5） 灰盒测试。灰盒测试介于黑盒与白盒测试之间。灰盒测试除了重视输出相对于输入的正确性，也看重其内部的程序逻辑。但是，它不可能像白盒测试那样详细和完整。它只是简单地靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结果正确的情况下可以采取灰盒测试方法。因为在此情况下灰盒比白盒高效，比黑盒适用性广的优势就凸显出来了。
（6）自动化测试。自动化测试就是软件测试的自动化，即在预先设定的条件下自动运行被测程序，并分析运行结果。总的来说，这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程。

从阶段上划分，软件测试可以分为单元测试、集成测试和系统测试，系统测试中又包含了多种不同的测试种类，例如功能测试、性能测试、验收测试、压力测试等。

其中单元测试主要是对该软件的模块进行测试，通过测试以发现该模块的功能不符合/不满足期望的情况和编码错误。由于模块的规模不大，功能单一，结构较简单，且测试人员可通过阅读源程序清楚知道其逻辑结构，首先应通过静态测试方法，比如静态分析、代码审查等，对该模块的源程序进行分析，按照模块的程序设计的控制流程图，以满足软件覆盖率要求的逻辑测试要求。另外，也可采用黑盒测试方法提出一组基本的测试用例，再用白盒测试方法进行验证。若用黑盒测试方法所产生的测试用例满足不了软件的覆盖要求，可采用白盒法增补出新的测试用例，以满足所需的覆盖标准。其所需的覆盖标准应视模块的实际具体情况而定。对一些质量要求和可靠性要求较高的模块，一般要满足所需条件的组合覆盖或者路径覆盖标准。

回归测试（Regression Test）是指在软件项目中，开发人员在修改了软件的代码以修复已经发现的Bug后，测试人员在需要重新测试前面已经测试过的内容，以确认此次修改没有引入新的错误。也就是说，回归测试的目的就是检查开发人员在修复已有Bug时是否又导致了新的Bug。

回归测试的策略集中体现在对于回归测试的测试用例的选择上面，一般来讲，总体分为两大类，一种是完全回归，一种是部分回归

1）完全回归（Retest all）完全回归是指测试时选择基线测试用例库中的所有用例进行回归测试，这是一种最为保险的策略，相对于部分回归策略，其可以将遗漏回归 bug（regression bug）的概率降到最低，但这种方式同时也是所有策略中成本最高的一种方式，尤其是越往后，随着测试用例的不断增多，最后完全回归所需要的时间和成本往往超出了预算。
2）部分回归部分回归是指在回归测试时选择基线测试用例库中的一部分用例进行归测试，而不是所有用例全部执行，相对于完全回归测试，这种测试策略效率很高，并且所需要的时间和成本比较少，但也没有完全回归覆盖率高（或者说遗漏回归bug的概率比完全测试高）。

软件维护

软件维护（software maintenance）是指在软件产品在交付之后，为改正错误、改进性能或其他属性，或者为了适应变化了的环境而对软件产品所进行的修改活动。

软件维护的类型

（1）纠错性维护改正测试阶段未发现的错误。
（2）完善性维护完善功能，对软件进行修改或开发。
（3） 适应性维护为适应外部新硬件和软件环境或数据环境发生的变化而进行修改软件。
（4） 预防性维护提高软件的维护性和可靠性。

软件维护过程如下

（1） 维护申请
（2）制定维护计划
（3）进行维护活动
（4） 建立维护文档
（5）复审/评价维护

提高可维护性的措施

（1） 结构化维护

存在软件开发各阶段的文档，这对于理解和掌握软件的功能结构、数据、接口和约束有很大帮助。

从需求文档弄清系统功能、性能的改变。

从设计文档检查和修改设计。

根据设计改动源代码，并从测试文档的测试用例进行回归测试。

减少维护人员的精力和花费，提高软件维护效率。

（2）通过技术途径

建立完整的文档，文档与产品演化具有一致性。

明确质量标准。

采用易于维护的技术和工具。

加强可维护性复审。

多模数据库

概念与特点

多模数据库，是一种能够同时处理多种数据模型和数据类型的数据库系统。与传统的单一模式数据库不同，它提供了一个统一的存储层，允许不同类型的数据在同一平台上进行存储、查询、分析和管理。这些数据模型包括常见的关系模型、文档模型、键值模型、图模型等，数据类型则涵盖结构化数据、半结构化数据和非结构化数据。

多模数据库的特点十分显著。它能够处理多种数据类型和模型，这使得企业无需为不同类型的数据分别搭建不同的数据库系统，大大降低了数据管理的复杂性。

多模数据库还提供了统一的接口，方便用户对不同类型的数据进行操作。开发人员不再需要针对不同的数据模型学习和使用不同的接口和工具，通过统一的查询语言（通常是扩展版的 SQL），就可以对关系数据、文档数据、图数据等进行查询和分析，大大提高了开发效率。

多模数据库优势

（1） 打破数据异构壁垒

现代企业的数据源复杂多样，数据来自不同的系统、应用和服务，包括传统的关系型数据库、文档数据库、日志系统、物联网设备、社交媒体等。这些数据形式和存储方式的差异，形成了数据融合和分析的障碍。而多模数据库通过统一的数据存储平台，消除了这些差异，提供了一个集成化的数据管理框架，能够同时处理不同数据类型和结构的需求。企业可以将关系型数据、文档数据、图数据等多种类型的数据存储在同一个数据库系统中，而不需要为每种数据模型维护独立的数据库实例。

（2）实现高效存储与灵活扩展

多模数据库能够根据不同的数据需求灵活选择最佳的数据模型，从而提高存储效率并降低存储成本。在存储结构化数据时，关系模型是不错的选择；而在处理非结构化或半结构化数据时，文档模型、键值模型或图模型更为合适。根据数据的特点选择合适的存储模型，有助于提高存储效率并优化资源利用。多模数据库通过为不同类型的数据提供专门的存储引擎，使得每种数据类型都能得到优化的存储方式。图数据模型适合存储节点和边的关系，文档数据模型适合存储嵌套结构的JSON数据等。

（3） 简化数据管理与开发

在多模数据库中，开发人员可以通过统一的API和查询语言访问不同的数据模型，而不需要为不同类型的数据选择不同的工具和技术栈。这种统一的管理和访问接口，极大地简化了数据的开发、运维和管理工作。开发人员不再需要为不同数据源编写不同的数据访问代码，而是通过多模数据库提供的统一查询语言来处理不同类型的数据，降低了开发难度和工作量。

（4） 提升数据分析能力

多模数据库的另一个重要优势是，能够提供更强的数据分析能力。由于多模数据库可以处理多种数据模型，企业能够在一个平台上执行各种复杂的分析任务，包括对关系数据、文档数据、图数据的联合分析。这种能力在大数据时代尤为重要，特别是在需要进行跨维度分析、数据挖掘和机器学习时，能够从多个数据源中提取有价值的信息。通过多模数据库，用户可以直接跨多个数据模型进行复杂查询和分析。可以同时查询关系型数据中的销售数据和图数据中的客户关系数据，发现不同数据模型之间的关联性，从而实现更为精确和全面的数据洞察。

典型多模型数据库案例星环科技ArgoDB、阿里云Lindorm、浪潮KaiwuDB。

AI测试用例生成

随着软件开发的快速发展和复杂性的增加，传统的手动编写测试用例方法已难以满足大规模、高效率的测试需求。人工智能（AI）技术的引入为测试领域带来了新的解决方案，通过自动化生成测试用例，可以显著提高测试效率和质量。

测试用例生成的流程

（1） 数据准备

收集并整理需求文档、用户故事、API文档等。

确保数据的准确性和完整性。

（2）模型选择与训练

根据项目特点选择合适的AI模型和算法。

使用历史测试用例作为训练集，训练模型。

（3） 生成测试用例

输入新的需求或变更描述，运行AI模型生成测试用例。

检查生成的测试用例是否符合预期，必要时手动调整。

（4） 执行与验证

将生成的测试用例集成到现有的测试套件中。

执行测试，记录结果，分析覆盖率和缺陷发现率。

（5）持续优化

根据测试结果反馈，不断调整和优化AI模型。

定期回顾和改进测试用例生成策略。

分布式系统设计

分布式事务及其解决方案

分布式事务是指跨越多个独立节点（如多个数据库、微服务或系统）的事务操作，要求所有参与者的操作要么全部成功提交，要么全部回滚，以满足ACID中的原子性（Atomicity）和一致性（Consistency）。

在分布式系统中，由于网络分区、节点故障等问题，传统单机事务的强一致性模型难以直接应用，需通过特定机制实现跨节点的协调。

分布式事务的核心挑战

（1）网络不可靠消息可能丢失、延迟或重复。
（2）节点故障部分节点可能宕机，导致事务状态不一致。
（3） 数据一致性如何在分布式环境下保证数据的最终一致性。
（4） 性能与吞吐量协调多个节点的成本可能影响系统性能。

常用解决方案

1、两阶段提交（2PC-Two-Phase Commit）

原理

（1） 准备阶段协调者询问所有参与者是否可以提交事务，参与者锁定资源并返回“同意”或“中止”。
（2） 提交阶段若所有参与者同意，协调者发送提交命令；否则发送回滚命令。

优点强一致性，实现简单。

缺点

（1）同步阻塞参与者等待协调者指令时资源被锁定。
（2）单点故障协调者宕机可能导致事务阻塞。
（3） 数据不一致协调者与参与者在第二阶段可能因网络问题状态不一致。

适用场景传统数据库集群（如MySQLXA协议）。

2、三阶段提交（3PC-Three-Phase Commit）

原理在2PC基础上增加预提交阶段，减少阻塞时间。

（1） CanCommit 协调者询问参与者是否具备执行条件。
（2） PreCommit 参与者预提交并反馈结果。
（3） DoCommit 最终提交或回滚。

优点降低阻塞概率，提高容错性。

缺点实现复杂，仍无法彻底解决数据不一致问题。

适用场景对可用性要求较高的场景（较少实际应用）。

3、TCC（Try-Confirm-Cancel）

原理通过业务层面的补偿机制实现最终一致性

（1） Try 预留资源（如冻结库存）。

（2） Confirm 确认操作（正式扣减库存）。
（3） Cancel 回滚预留（释放冻结的库存）。

优点高灵活性，适用于高并发场景。

缺点业务侵入性强，需为每个操作实现补偿逻辑。

适用场景电商订单、支付系统（如支付宝接口）。

4、Saga模式

原理将事务拆分为多个本地事务，每个事务完成后触发下一个事务，失败时触发逆向补偿操作。

（1） 正向操作依次执行各子事务（如创建订单 $\rightarrow$ 扣减库存 $\rightarrow$ 支付）。
（2）补偿操作逆向回滚（如取消支付 $\rightarrow$ 恢复库存 $\rightarrow$ 删除订单）。

实现方式

（1） 编排（Choreography） 各服务通过事件驱动自行协调。
（2）编排（Orchestration）由中央协调器（如工作流引擎）控制流程。

优点适合长事务，避免资源长期锁定。

缺点补偿逻辑复杂，可能产生“脏回滚”。

适用场景物流系统、跨微服务的长流程事务。

5、本地消息表（Local Message Table）

原理

（1） 业务与消息写入本地数据库（同一事务）。
（2） 后台任务轮询消息表，将消息发送到MQ。
（3） 消费者处理消息，失败时重试。

优点简单可靠，保证最终一致性。

缺点消息处理延迟，需维护消息表。

适用场景订单状态同步、异步通知。

6、事务消息（如 RocketMQ 事务消息）

原理

（1） 生产者发送“半消息”到MQ（对消费者不可见）。
（2） 执行本地事务，返回提交或回滚状态。
（3） MQ根据状态提交或丢弃消息。

优点解耦事务与消息，避免消息丢失。

缺点依赖MQ的事务支持。

适用场景跨系统异步事务（如积分发放）。

7、最终一致性（补偿事务）

原理接受短暂不一致，通过异步补偿达到最终一致。

示例订单支付成功后，若库存扣减失败，通过定时任务重试或人工介入。

优点实现简单，系统可用性高。

缺点业务需容忍延迟一致性。

适用场景对实时性要求不高的业务（如对账系统）。

系统可靠性分析与设计

可靠性评价

软件可靠性评价是软件可靠性活动的重要组成部分，既适用于软件开发过程，也可针对最终软件系统。在软件开发过程中使用软件可靠性评价，可以使用软件可靠性模型，估计软件当前的可靠性，以确认是否可以终止测试并发布软件，同时还可以预计软件要达到相应的可靠性水平所需要的时间和工作量，评价提交软件时的软件可靠性水平。对于最终软件产品，软件可靠性评价结合可靠性验证测试，确认软件的执行与需求的一致性，确定最终软件产品所达到的可靠性水平。

可靠性模型是通过数学方法描述系统各单元存在的功能逻辑关系而形成的可靠性框图及数学模型。其目的是定量分配、计算和评价产品的可靠性。

可靠性模型主要分为三类

（1） 串联模型在串联模型中，系统的可靠性取决于所有单元的可靠性。若任何一个单元失效，整个系统就会失效。
（2）并联模型在并联模型中，系统的可靠性取决于所有单元的可靠性。只有当所有单元都失效时，系统才会失效。
（3）串并混合模型一个或多个单元并联组成一个组件，多个组件之间串联，组件内部一个单元失效不会导致组件失效，只有组件内部所有单元都失效时才会导致组件失效，进而导致系统失效。

系统安全性和保密性设计

安全架构设计中鉴别框架和访问控制框架设计

鉴别（Authentication）的基本目的，就是防止其他实体占用和独立操作被鉴别实体的身份。鉴别提供了实体声称其身份的保证。鉴别有两种重要的关系背景一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系（如实体鉴别）；二是实体为验证者提供数据项来源。

鉴别的方式主要基于以下5种

1、已知的，如一个秘密的口令。
2、拥有的，如IC卡、令牌等。
3、不改变的特性，如生物特征。
4、相信可靠的第三方建立的鉴别（递推）。
5、环境（如主机地址等）。

访问控制（Access Control）决定开放系统环境中允许使用哪些资源、在什么地方适合阻止未授权访问的过程。在访问控制实例中，访问可以是对一个系统（即对一个系统通信部分的一个实体）或对一个系统内部进行的

区块链技术

区块链的核心技术主要有四个部分，分别是共识机制、分布式存储、智能合约以及密码学。每个技术，在整个区块链系统里都有它们各自的作用。

一、共识机制

共识机制，其实就是挖矿原理，因为区块链的分布式网络中，没有中央权威。因此，网络需要一个决策机制来促成参与者达成一致。而共识机制就是一种协调大家处理数据的机制。因为每个人都可以参与的话，记录下来的数据这么多，到底该用谁的呢？所以，共识机制就决定了这些数据中，谁获得数据的记账权。共识机制主要起到了数据的维护作用。目前比较常见的共识机制有工作量证明PoW（Proof of Work）、权益证明（Proof of Stake）以及委托权益证明（Delegated Proof of Stake）。

二、分布式存储

分布式储存，简单来说，就是一种将数据分散存储到多个地方的数据储存技术，而且存储的数据可在多个参与者之间共享，人人可以参与，并具有相同的权力，一起记录数据，主要起到了数据储存的功能。

分布式存储是一种数据存储技术，通过网络使用每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在网络中的各个角落。所以，分布式存储技术并不是每台电脑都存放完整的数据，而是把数据切割后存放在不同的电脑里。就像存放100个鸡蛋，不是放在同一个篮子里，而是分开放在不同的地方，加起来的总和是100个。对于比特币来说，它的交易记录必须要有地方存放，不然没人知道今天有哪些人做了交易，同时根据去中心化的思想，这些交易记录不能够只存在一台电脑里面，那么就只能存放在世界上所有的电脑里面（前提是电脑里面安装了比特币软件）。这样做的好处是虽然每个人的电脑硬盘容量有限，但是所有人的电脑硬盘加起来容量几乎是无限的，而且就算你通过黑客手段修改了自己计算机里面的交易记录，但是你没法修改全世界每台电脑的交易记录。

从表面上理解，上面说的这种存储方式很粗暴——每台电脑都存放世界上所有人的交易数据。但其实对于比特币来说，只有一些节点才会存放世界上所有人的交易记录，这些节点往往是那些挖矿的矿工，只有他们的电脑才能完整的记录下世界上所有的交易记录，大家不用担心矿工修改记录，因为世界上的矿工有很多，而且几乎相互都不认识。同时他们修改记录需要付出的代价非常大，几乎没有人能承担这个成本。

三、智能合约

智能合约，是一种旨在以信息化方式传播、验证或执行合同的计算机协议。有点像一种大家把规则都制定好，由机器自动去执行的技术。因为网络中存储和维护好的数据，总需要有人去执行的，而智能合约正好可以在没有第三方的情况下，也能进行可信的交易，而且这些交易可追踪且不可逆转。所以，智能合约在系统中，主要起到了数据的执行作用。

智能合约（Smart contract）是一种以计算机语言编写、由计算机自动验证和执行的代码化的合同，是纸质合同的数字化形式。智能合约概念于1994年由计算机科学家、法学家及密码学家尼克·萨博（Nick Szabo）首次提出。他对智能合约的定义是“一个智能合约是一套以数字形式定义的承诺（promises），包括合约参与方可以在上面执行这些承诺的协议。”智能合约概念面世后，自然面临如何落地的问题第一，谁来执行合约？显然，签署合约的双方不应成为执行人。这带来一系列问题如何激励他为你执行合约而不是违约？他如何保持公正和中立？他缺位、消失或者拒不执行怎么办？第二，如何通过计算机程序支付现金和资产？当时技术条件尚未成熟，无法解决上述问题，因此智能合约迟迟无法变为现实。

数字货币和区块链诞生以后，上述问题得以顺利解决

（1）执行智能合约的机制去中心化网络+共识机制+受激励的矿工
（2） 价值转移功能内生可编程的数字货币
（3）去中心化的永不停机的计算网络，保持中立、公平、永远工作，区块链不仅内嵌数字货币系统，而且可编程可扩展，具有去中心化、不可篡改、过程透明、可追踪等优点，天然适合于智能合约。

从此，智能合约才从理论构想变为落地的现实。区块链给智能合约提供了最佳的技术土壤，而智能合约功能也大大扩展了区块链的应用前景。目前一般认为，智能合约是基于区块链技术的自动执行的数字合约形式。

四、密码学

密码学，是一种特殊的加密和解密技术，区块链系统中，应用了多种多样的密码学技术，包括哈希算法、公钥私钥、数字签名等等，以此来保证整个系统的数据安全，并且证明了数据的归属。有了它我们才能在网络中证明“我是我”，才能证明这是我的比特币而不是你的比特币。

四大核心技术间的关系

1、分布式存储构建了区块链的基本初步框架

它相当于是一个分布式数据库，当一笔数据产生后，经大家处理，就会储存在这个数据库里面，所以分布式存储在区块链中起到了数据储存的作用。

2、共识机制在区块链中统筹节点行为、明确数据处理

因为分布式存储有着去中心化的特点，决定了区块链网络的结构呈现出分布式的状态，所以每个用户都可以自由地加入其中，共同参与数据的增删改查。但与此同时，就衍生出来了令人头疼的一个问题，即网络中参与的人数越多，全网就越难以保持相同诉求。这样就需要另一套机制来协调全节点账目保持一致了。这时共识机制就出现了，制定一套规则来明确每个人处理数据的过程，并通过争夺管理权的方式来完成节点间的意见统一，最后谁最终取得管理权，全网就用谁处理的数据进行统一。所以共识机制在区块链中起到了统筹节点行为、明确数据处理的作用。

3、密码学决定底层数据架构

数据进入分布式数据库中，并不是单纯地打包进来，底层的数据架构却是由区块链密码学来决定的。由数据库打包好的数据块，会通过密码学中的哈希函数处理成一个链式的结构，但因为哈希算法具备单向性、抗篡改等特点，所以只要在区块链网络中，数据一旦上链就不可篡改、且可追溯。另外账户也会通过非对称加密的方式进行加密，进而保证了数据的安全，验证了数据的归属。

4、智能合约负责数据的执行与应用

最后，可以在分布式存储的客观条件上，搭建起智能合约，当我们需要解决“信任危机”的时候，通过智能合约，能将用户之间的约定由代码的形式进行条件筛选，并通过程序执行，而区块链中的数据，则可以通过智能合约进行调用、分解。所以智能合约在区块链中起到了数据的执行与应用的功能。