2025系统架构师（一考就过）：案例之二：架构总结（单体架构、垂直架构、分层架构、事件驱动架构、微内核架构、分布式架构、SOA面向服务架构、微服务架构、模型驱动架构、高可用架构、高安全架构）

本文链接：https://blog.csdn.net/yinweimumu/article/details/144682146

在这里插入图片描述

四、架构模式：单体架构、垂直架构、分层架构、事件驱动架构、微内核架构、分布式架构、SOA面向服务架构、微服务架构、模型驱动架构

**问题：**以下关于操作系统微内核架构特征的说法，不正确的是( )。

A：微内核的系统结构清晰，利于协作开发

B：微内核代码量少，系统具有良好的可移植性

C：微内核有良好的伸缩性、扩展性

D：微内核的功能代码可以互相调用，性能很高

答案：D

解析：

微内核(Micro Kernel)是现代操作系统普遍采用的架构形式。它是一种能够提供必要服务的操作系统内核，被设计成在很小的内存空间内增加移植性，提供模块设计，这些必要的服务包括任务、线程、交互进程通信以及内存管理等。而操作系统其他所有服务(含设备驱动)在用户模式下运行，可以使用户安装不同的服务接口(API)。

微内核的主要优点在于结构清晰、内核代码量少，安全性和可靠性高、可移植性强、可伸缩性、可扩展性高；

其缺点是难以进行良好的整体优化、进程间互相通信的开销大、内核功能代码不能被直接调用而带来服务的效率低。

1、架构对比

架构模式对比表
单体架构	定义	将应用程序作为一个整体部署和运行在单一的软件实体中。在单体应用架构中，应用的各个功能模块紧密地耦合在一起，共享相同的运行环境和数据库。
	优点	简单、易用、开发快、成本低
	缺点	耦合度高、扩展性差、难以适应复杂需求
	适用场景	简单、小规模的应用场景：如内部管理系统、小型电子商务网站等。
	架构图
	补充知识点
垂直架构（烟囱式架构）	定义	将一个应用程序按照功能或业务垂直划分的架构模式。在垂直应用架构中，每个功能模块或业务模块由一个独立的组件或服务来处理，它们之间通常通过接口进行通信。
	优点	方便水平扩展、系统拆分、相互独立实现了流量分担及高并发、容错率高
	缺点	①拆分后的各模块通信可能带来延迟和性能问题 ②模块化的架构可能导致模块之间的依赖关系复杂 ③不同业务模块可能需要重复的功能，可能带来代码冗余、资源浪费
	适用场景	一些复杂的应用场景，特别是需要特定功能集成或者需要处理大量业务逻辑的场景：如整个电商项目可以拆分为：电商交易系统、后台管理系统、CMS管理系统等。
	架构图
	补充知识点
分层架构	定义	将系统分成不同的层次，每一层都有明确的职责和功能，通常包括表示层、业务逻辑层、数据访问层等。
	优点	职责分离：不同模块分开；易于扩展：在特定层次上扩展
	缺点	性能开销：每层之间的交互可能引入额外性能开销；不够灵活：某些复杂场景中，层与层之间的严格分离可能导致无法处理跨层需求
	适用场景	适用于大多数传统的企业级应用，尤其是那些包含明显的业务逻辑层次结构的系统
	架构图
	补充知识点
事件驱动架构	定义	一种异步的架构风格，通过发布和订阅事件来实现不同模块之间的解耦和交互。。
	优点	高扩展性：增加事件处理器可以快速增加系统功能；高性能：异步事件使系统能够处理大量并发
	缺点	调试困难：异步导致排查困难；复杂的事件流管理：需要处理复杂的事件流，特别是当事件之间有依赖时
	适用场景	高并发、大规模数据处理的系统，常见于实时处理系统、消息队列系统以及互联网大规模服务中
	架构图
	补充知识点
微内核架构	定义	也被称为插件架构，这种风格的核心思想是通过一个小型的核心系统与众多可插拔的插件来扩展系统功能。。
	优点	核心系统与插件分离，插件可独立开发、部署，可灵活扩展，适应变化
	缺点	核心系统复杂性：需要设计稳定且功能强大的核心系统；插件之间的依赖管理：插件之间的依赖复杂时，可能会增加系统复杂性
	适用场景	需要频繁扩展、模块化开发的系统，尤其是产品型软件（如IDE、浏览器）或插件化框架。
	架构图
	补充知识点
基于构件的架构（CBSE）	定义	基于构件的软件工程(CBSE)是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE 体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于己有构件的组装。
	优点	提高复用性和开发效率：复用构件；易于集成：构件组装；提高软件质量：构件库中的构件经过严格设计、测试和封装
	缺点	构件开发成本高：构件的开发、测试和维护成本高；构件库的管理：构件数量的增加增加了复杂性
	适用场景	企业级应用、嵌入式系统、跨平台应用、软件产品线开发
	架构图
	补充知识点	相关论文：基于构件的软件开发构件是一个独立的软件单元，可以与其他构件构成一个软件系统。软件构件是部署、版本控制和替换的基本单位。构件又称为组件，是一个自包容、可复用的程序集。 CBSE的构件应该具备以下特征： (1)可组装型：所有外部交互必须通过公开定义的接口进行。 (2)可部署性：软件必须是自包含的，构件总是二进制形式，无须在部署前编译。 (3)文档化：用户根据文档来判断构件是否满足需求。 (4)独立性：构件应该是独立的 (5)标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。构件模型定义了构件实现、文档化以及开发的标准。主流的构件模型是Web Services 模型、Sun公司的EJB 模型和微软的.NET模型。 CBSE六个过程：(1)系统需求概览；(2)识别候选构件；(3)根据发现的构件修改需求；(4)体系结构设计；(5)构件定制与适配；(6)组装构件，创建系统。构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。面向构件的编程(COP)是关注如何构建面向构件的解决方案的编程方式。基于 OOP 的 COP 的定义包含以下四个基本要素：多态性表示同一类型的不同实例对象可以具有不同的行为，可以相互替代，是构件之间互换性和可重用性的关键；模块封装性表示将构件内部的实现细节和高层次的信息隐藏起来，只对外暴露必要的接口，可以防止构件被错误地使用，同时提高构件的可维护性；后期的绑定和装载指的是在构件部署时进行绑定，从而实现构件的部署独立性，可以使构件更加灵活和易于部署；安全性则是确保构件的类型和模块安全性，以避免构件被非法访问或使用，可以保护系统的完整性和稳定性。面向构件的编程会涉及到的问题：异步、多线程、多语言支持、调用者封装软件构件的组装模型：商用构件的标准规范：CORBA、J2EE和Microsoft 的DNA。 1) CORBA 公共对象请求代理架构(Common Object Request Broker Architecture, CORBA) 主要分为3个层次：对象请求代理、公共对象服务和公共设施。最底层的对象请求代理(Object Request Broker,ORB) 规定了分布对象的定义(接口)和语言映射，实现对象间的通信和互操作，是分布对象系统中的“软总线”；公共对象服务在ORB之上定义了很多公共服务，可以提供诸如并发服务、事务(交易)服务、安全服务等各种各样的服务；最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，以及协作规则。 CORBA 是一种面向对象的远程调用技术。 2) J2EE 在J2EE 中，SUN给出了完整的基于Java 语言开发面向企业分布的应用规范。其中，在分布式互操作协议上， J2EE 同时支持远程方法调用(Remote Method Invocation,RMI) 和互联网内部对象请求代理协议(Internet Inter-ORB Protocol,IIOP), 而在服务器端分布式应用的构造形式，则包括了Java Servlet、JSP、EJB 等多种形式，以支持不同的业务需求。其中， EJB 给出了系统的服务器端分布构件规范，这包括了构件、构件容器的接口规范以及构件打包、构件配置等的标准规范内容。 EJB 是企业级 Java Beans的缩写，主要包含三种类型：会话 Bean、实体 Bean 和消息驱动 Bean。会话 Bean 负责维护会话，可有状态或无状态，用于实现业务逻辑，可访问数据库。实体 Bean 用于处理事务，使用 O/R 映射将数据库表记录映射为内存中的实体对象，与数据库的状态保持同步。消息驱动 Bean 基于 JMS 消息，用于异步处理客户端请求。 3) DNA Microsoft 的DCOM / COM / COM +技术在D N A 2 0 0 0 分布计算结构基础上，展现了一个全新的分布构件应用模型。首先， DCOM / COM / COM +的构件仍然采用普通的构件对象模型(Component Object Model,COM)。
分布式架构（集群架构/水平扩展架构）	定义	将一个应用程序的不同功能模块或服务分布在多台独立的计算机或服务器上的架构模式。这些功能模块通网络进行通信和协作，共同完成应用程序的业务逻辑。在分布式架构中，按业务性质会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。集群是一种实现分布式系统的方式
	优点	松散耦合：服务之间通过协议通信；提高复用性：服务以接口为粒度，可以被多个系统复用；高性能：可水平扩展、负载均衡；
	缺点	①复杂性增加：服务拆分和管理的比较复杂。 ②性能开销：服务之间通过网络通信 ③网络通信带来的一致性、可靠性问题
	适用场景	需要处理高并发、大规模数据处理和需要高可用性的应用场景。例如，电子商务平台、社交媒体平台、大数据处理系统
	架构图
	补充知识点
SOA 面向服务架构（共享式架构）	定义	将系统功能拆分为多个服务的架构风格，每个服务都是独立的，可以通过标准协议进行通信。
	优点	重用性、松散耦合、可组合性
	缺点	复杂性：服务通信；性能问题：网络延迟；一致性问题：服务自治，可能导致数据一致性
	适用场景	复杂的企业应用（企业应用划分为多个自治服务）、跨平台集成（不同平台、技术栈集成到一个服务中）、业务流程自动化（可复用的服务）
	架构图
	补充知识点
微服务架构	定义	将应用程序拆分为多个小型、独立服务的架构风格，每个服务都可以独立开发、部署和扩展。并通过轻量级的通信机制（通常采用HTTP或消息对列）相互协作。微服务架构是从SOA架构演变而来的，主要区别在于规模和粒度。微服务将SOA中的服务进一步细分，将每个服务划分为更小、更独立的服务单元，强调服务的自治性和可独立部署性。同时，微服务架构采用轻量级的通信机制，如HTTP和消息队列，与SOA中的重型中间件相比，减少了开销和复杂性。
	优点	高扩展性：微服务独立扩展；故障隔离：某个微服务故障不会影响其他服务；技术异构：不同微服务可以采用不同技术栈；
	缺点	运维复杂度高：微服务的拆分增加了运维复杂性；通信开销大：服务之间的通信、协调、数据一致性问题等。
	适用场景	大规模复杂应用、高并发应用、跨团队开发
	架构图	微服务架构微服务架构-服务层
	补充知识点	1、微服务设计约束有哪些？（1）微服务个体约束每个微服务应专注于特定业务域，相互独立，允许不同的技术栈和语言选择，提升开发效率。微服务应遵循单一职责原则，确保修改或发布一个微服务不会影响其他微服务的交互。（2）微服务之间的横向关系服务间需具备自动感知能力，利用服务注册中心实现服务的动态发现。服务间调用应使用与语言无关的协议（如REST或基于IDL的二进制协议），并建立独立的元数据中心存储服务信息，促进服务解耦。引入限流、熔断、负载均衡等机制增强服务韧性，同时可利用协程、异步调用等手段提升系统性能。（3）微服务与数据层之间的纵向约束微服务的数据应为私有资产，所有访问通过API进行，以避免数据层耦合。读写分离，通常采用CQRS模式提升性能。采用无状态设计，尽量实现微服务的无状态，方便在不同容器间调度，并对有状态服务采用计算与存储分离策略。（4）全局视角下的分布式约束建立全自动化的CI/CD流水线，支持蓝绿、金丝雀等发布策略，确保发布稳定性。实现全链路、实时、多维度的可监控能力，汇聚和分析事件数据，提升故障发现的效率和准确性。 2、主要微服务技术有哪些？ ①Apache Dubbo 高性能RPC框架，支持透明接口的RPC、智能负载均衡、自动服务注册和发现、高扩展性。阿里巴巴开源的多个组件（SpringCloudAlibaba、Nacos、Sentinel、Seata、Chaosblade）增强了Dubbo的生态竞争力。在v3中引入服务网格（Service Mesh），支持Envoy协议，持续改进服务治理与负载均衡。 ②Spring Cloud 提供分布式系统所需的配置管理、服务发现、断路器、智能路由等多种能力和开发工具，简化微服务开发。 ③Eclipse MicroProfile 定义企业Java微服务的标准，提供指标、API文档、运行状况检查、容错与分布式跟踪等功能，支持云原生微服务的部署。 ④Tars 腾讯内部使用的微服务框架的开源版本，支持多语言开发（C++、Java、Golang等）。包含完整的开发框架与管理平台，旨在提高开发效率与运维能力。 SOFAStack** 蚂蚁金服开源的中间件，专为金融级分布式架构设计，提供最佳实践。MOSN作为服务网格数据平面代理，功能类似Envoy，支持Envoy和Istio的API。
服务网格架构	定义	服务网格是一种专门用于管理微服务间通信的基础设施层，能够以非侵入的方式处理微服务架构中的服务发现、负载均衡、安全性、故障恢复、度量和监控等问题。在Sidecar模式中，“边车”与父应用程序（即业务服务）是两个独立的进程，“边车”附加到业务服务，并为应用提供支持功能，如微服务架构中的基本通信。 Service Mesh 的核心组件是数据平面和控制平面。数据平面由一系列轻量级的代理组成，这些代理通常被称为 Sidecar（边车）。Sidecar 与应用程序一起部署，负责拦截和处理服务间的通信流量。控制平面负责管理和配置数据平面的 Sidecar。控制平面通常提供一个集中的管理界面，管理员可以通过这个界面配置 Service Mesh 的各种功能，例如服务发现、负载均衡策略、安全策略等。
	优点	可观察性、流量控制、安全：服务网格是一个专用的基础设施层，所有的服务间通信都要通过它；
	缺点	复杂性增加：微服务本身已经很复杂，又引入代理、sidecar 等；需要专业知识：在容器编排（K8s）之上添加Istio之类的服务网格需要运维称为这两种技术的专家；平台依赖性、流量劫持、性能损耗问题
	适用场景	微服务架构、多云环境（提供负载均衡）、容器化环境（自动注入代理，提高可扩展性）、遗留系统集成（非侵入式的方式来实现服务间通信的管理）
	架构图	服务网格-边车 Proxy Service Mesh （Istio + enovy 架构）其中深色的是我们平时工作中接触最多的业务微服务，旁边蓝色的被称为边车Sidecar服务。 Sidecar作为业务微服务的“代理”，处理与其他业务微服务sidecar之间的非功能需求，如网络通信、安全、监控、流量控制等。多个Sidecar之间的连接和交互组成了：网格mesh。
	补充知识点
Serverless无服务器架构	定义	Serverless架构，又称为无服务器架构，是一种基于云计算平台的一种"即付即用"的服务模式。基础设施全托管（无须关心维护、扩容等），开发人员只需编写函数（Function）或者服务（Service），云服务提供商会自动管理和调度底层的服务器资源。一般由BaaS（后端即服务）和Faas（函数即服务）实现。
	优点	事件驱动架构的延伸、简化了开发模式、Serverless是不可变基础设施的最佳实践、加快交付、高可伸缩性
	缺点	厂商绑定、性能问题：可能有“冷启动”问题、花销难预测：可能出现大流量、让开发者更专注业务，但数据传输安全不可见
	适用场景	物联网等
	架构图
	补充知识点
云原生架构	定义	一种基于云原生技术的架构原则和设计模式，旨在剥离应用中的非业务代码，使云基础设施能够接管非功能特性（如弹性、韧性、安全、可观测性、灰度等），具备轻量、敏捷、高度自动化的特点。一般认为云原生由容器、微服务、服务网格、不可变基础设施和声明式API组成。
	优点	可伸缩性、敏捷、高度自动化、安全等
	缺点	复杂性：微服务本身就复杂，较多的微服务的隔离、管理、兼容等更复杂；可观测性数量繁多：随着云原生的敏捷性，可观测性数据（指标、日志、跟踪、事件）爆炸式增加
	适用场景	微服务架构、容器应用、自动化部署、运维、持续交付和持续集成
	架构图
	补充知识点	1、云原生技术部分依赖于传统云计算的哪3层概念？基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。 SaaS（软件即服务）：通过浏览器/服务器架构提供应用和数据，用户无需管理基础设施。 PaaS（平台即服务）：提供开发平台和部分中间件，支持应用的构建和部署。 IaaS（基础设施即服务）：提供基础环境，用户需自行安装和管理各种软件（如阿里云）。 2、云原生的代码通常包括哪三部分？业务代码、三方软件、处理非功能特性的代码。业务代码指实现业务逻辑的代码；三方软件是业务代码中依赖的所有三方库，包括业务库和基础库；处理非功能性的代码指实现高可用、安全、可观测性等非功能性能力的代码。三部分中只有业务代码是核心。 3、云原生架构的设计原则有哪些？服务化原则：通过拆分为微服务等，使用微服务架构进行系统开发。弹性原则：可以根据业务自动伸缩或者扩容。韧性原则：面对异常的抵抗能力。自动化原则：通过自动化运维工具进行部署。可观测原则：通过日志、链路追踪和度量，确保能实时监控和分析。零信任原则：默认不信任内部或者外部的任何人/系统/设备，基于身份进行访问控制。架构持续演进原则：业务高速迭代的情况下架构与业务的平衡。 4、云原生架构模式有哪些？（1）服务化架构模式：典型代表微服务，服务拆分使维护压力大增。（2）Mesh化架构模式: 把中间件框架 (RPC、缓存、异步消息) 从业务进程中分离，由Mesh进程完成。（3）Serverless模式：非常适合于事件驱动的数据计算任务（4）存储计算分离模式：各类暂态数据 (如session) 用云服务保存。（5）分布式事务模式：解决微服务模式中多数据源事务问题。（6）可观测架构：包括Logging、Tracing、Metrics三个方面。（7）事件驱动架构：本质上是一种应用/组件间的集成架构模式 5、有哪些典型云原生架构反模式？（1）庞大的单体应用，需要多人开发的业务模块，考虑通过服务化进行拆分，并让组织与架构匹配，缺乏模块化，导致高耦合和责任不清，影响迭代效率和稳定性。（2）单体应用“硬拆”为微服务， (服务拆分要适度)小规模软件的服务拆分 (为拆而拆)、数据依赖(服务间数据依赖)、性能降低。（3）缺乏自动化能力的微服务，手动维护大量微服务是不现实的，工作量增大，增加软件的开发成本。云是对计算机集群及IT基础设施的一种形象比喻，每一计算机集群包括几十万、甚至上百万台计算机，就好像天上大朵大朵的云团。计算是指计算机的交付、使用与服务。云计算是分布式计算技术的一种，它的原理是通过网络“云”，将所运行的巨大的数据计算处理程序分解成无数个小程序，再交由计算资源共享池进行搜寻、计算及分析后，将处理结果回传给用户。云连接着网络的另一端，为用户提供了可以按需获取的弹性资源和架构。用户按需付费，从云上获得需要的计算资源，包括存储、数据库、服务器、应用软件及网络等，大大降低了使用成本。云计算在最基本的意义上，就是一个大型的储存服务，在计算机的概念上，就是系统计算，计算资源像云一样聚集在一起，为用户提供按需访问的服务。，故称为“云”。现阶段所说的云服务已经不单单是一种分布式计算，而是分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗杂和虚拟化等计算机技术混合演进并跃升的结果。所以，现在的“云”可以理解为一种网络资源的共享池，其中包括了服务器、存储设备、网络设备等硬件资源，以及操作系统、应用软件等软件资源。这些资源通过虚拟化技术被整合在一起，形成一个庞大的资源池，用户可以根据自己的需求灵活地使用这些资源。举个例子就是，我有很多东西，家里放不下了，放到一个特定的地方存着，随时提取，别人碰不了，保质保量。“东西”一般是指数据、软件、服务等，而“特定的地方”就是云。” 云原生 “云原生”来自于 Cloud Native 的直译，拆开来看， Cloud 就是指其应用软件是在云端而非传统的数据中心。Native代表应用软件从一开始就是基于云环境、专门为云端特性而设计，可充分利用和发挥云平台的弹性+分布式优势，最大化释放云计算生产力。云原生并不是某种技术、框架或者软件，而是一套构建和运行应用程序的方法，是一套技术体系或方法论。云原生的关键，不是在哪里部署应用，而是如何构建应用。举个例子，如果还是用传统应用的开发方式，自己买了服务器部署在自己的机房，然后安装对应的操作系统和应用，上面部署了容器，然后用Kubernetes来管理，那就是云原生吗？并不是，因为它缺乏弹性、API自动化部署和运维的能力。应用的构建思维还是用传统方法，并没有发挥云服务的优势。云原生，更看重的是应用的弹性，业务敏捷度、扩容性、开发持续交付等，这些都指向一个灵活、弹性。与传统开发的固化，死板相对应。即，能够做到灵活、弹性、持续，这才称得上云原生。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。想象一下，你要设计一座豪华大别墅。云计算就像是一座现代化的城市，提供了所有必要的基础设施，如道路、水电、天然气等。你只需在城市中购买一块土地，然后在上面建造你的别墅。而云原生就是你的别墅，它充分利用了云计算的基础设施和服务，并且采用了一系列先进的建造和管理技术，即容器化、微服务架构、动态编排、DevOps实践。
模型驱动架构	定义	通过模型的方式来指导整个软件开发过程。其核心理念是将业务逻辑与平台技术分离，强调由领域业务模型驱动系统的部分或全部的自动化开发。 MDA的建模方法：统一建模语言（UML）、元对象工具（MOF）：UML的子集，表达重要的模型公共仓库元模型（CWM）：标准化了数据仓库应用程序的生命周期（如设计、构建和管理） MDA主要包含三个核心模型及一个Code：计算无关模型（CIM）：关注于业务环境和需求，不考虑计算环境，通常由业务人员创建，展示系统的业务模型（系统需求）平台无关模型（PIM）：考虑在计算环境中业务逻辑的表示，但不关注具体的实现平台，通常由系统架构师创建，展示系统的分析模型。平台相关模型（PSM）：关注如何在特定平台实现业务逻辑，为设计模型。代码（Code）。模型驱动架构开发过程： CIM->PIM->PSM->实现代码 ①基于MDA的开发过程，通过业务领域分析和建模构造CIM以描述需求 ②结合相关的标准规范将CIM转换为PIM ③在PIM基础上，针对不同的实现环境，构造不同的PSM ④将PSM转换成目标代码，完成开发过程
	优点	可维护性和可移植性：业务逻辑和技术分离，应用逻辑能在多个平台复用；提高开发效率：通过模型转换和自动化工具快速生成代码；促进标准化：遵循一致的设计和实现标准
	缺点	转换复杂性：从CIM到PIM转换到PSM再到代码的过程可能会非常复杂；学习曲线：需要学习MDA的相关方法、工具、标准；工具依赖性：强烈依赖于支持MDA的建模工具和代码生成工具
	适用场景	跨多个平台部署且业务逻辑复杂，需要频繁更新的大型企业级应用：企业信息系统、金融服务系统等
	架构图
	补充知识点
高可用架构	定义	系统或服务在给定的时间内能够持续提供服务的能力，通常通过冗余组件、备份机制、故障转移策略等手段来实现，以确保在出现问题时能够快速恢复，减少或避免服务中断的时间。高可用性是衡量系统健壮性的重要指标之一。
	优点	提高用户体验、业务持续性、提高可用性
	缺点	成本较高、复杂性着增加、数据一致性问题
	适用场景	金融服务等
	架构图
	补充知识点
安全架构	定义	安全架构是架构面向安全性方向上的一种细分，安全目标是控制和管理主体(含用户和进程)对客体(含数据和程序)的访问。安全性体现在产品上，通常由产品安全架构、安全技术体系架构和审计架构组成。安全架构应具备可用性、完整性和机密性等特性。这里所说的可用性（Availability）是指要防止系统的数据和资源丢失；完整性（Integrity）是指要防止系统的数据和资源在未经授权情况下被修改；机密性（Confidentiality）是指要防止系统的数据和资源在未授权的情况下被披露。
	优点	安全、可追溯性
	缺点	复杂、成本高
	适用场景	金融服务等
	架构图
	补充知识点	可以从物理安全（物理设备）、系统安全（操作系统、应用）、网络安全（访问控制、通信加密、入侵检测）、应用安全（资源共享和信息存储）和管理安全等5个方面开展分析和设计工作。可分为数据层、功能层、展现层。数据层主要对企业数据进行统一管理，按数据的不同安全特性进行存储、隔离与保护等；功能层是系统安全防范的主要核心功能，包括可信性监控、服务支持和安全性监控。可信性监控主要实现网络安全、系统安全和应用安全中的监控能力；服务支持主要针对安全管理功能而设计的，实现安全管理平台的大多数功能；安全性监控主要针对系统中发现的任何不安全现象进行相关处理，涵盖了威胁追溯、安全域审计评估、授权、认证等，以及风险分析与评估等；展现层主要完成系统安全架构的使用、维护、决策等功能的实现。

2、SOA VS 微服务

	通信协议	是否中心化	服务自治性	是否分层	粒度	设计理念
SOA	基于XML的消息格式和基于SOAP的通信协议	中心化，ESB负责服务之间的通信转发和接口适配	服务不强调业务领域的自治性	强调分层，通常会分为表示层、业务层、总线层和数据层	粗粒度	SOA的设计思路是把一些组件和服务，通过服务总线组装，形成更大的应用系统（从小到大）；
微服务	REST和JSON	去中心化，通过API网关技术来负责服务接口转发	调基于领域的服务自治性	服务更松散	细粒度	微服务的设计思路是把应用拆分成独立自治的小的服务（从大到小）。

从上述的对比来看，二者的区别基本上都在实现方式上。微服务与SOA本质上是同一种设计思想在不同时代的不同实现。过去在容器、K8S技术没有出现的年代，造就了SOA的实现方式。

3、Serveless VS 微服务

在这里插入图片描述

4、私有云 VS 公有云 VS 本地化部署

	私有云	公有云	本地化部署
定义	为一个客户单独使用而构建的，具有数据安全性高、定制化程度高、可控性强等特点。私有云可部署在企业数据中心的防火墙内，云端为企业单独设置其属性，是企业专有资源。	指第三方提供商为用户提供的云服务，公有云一般可通过 Internet 使用，成本低廉，易于管控。公有云的属性是共享资源服务，可在当今整个开放的公有网络中提供服务，根据需求弹性拓展。	运行在用户所在经营场所计算机系统内的软件，即自购的在本地公司营业场所运行的系统。本地化部署的特点是数据完全掌控，系统稳定性高，定制化程度高，通常基于比较成熟的硬件和软件架构。
经济性	低，机房、设备、运行维护费用	低，购买服务的费用	高，系统搭建、机房、设备、运行维护费用
安全性	较安全，数据由内部网络获取，第三方很难获取	一般安全，通过运营商网络访问，可以对数据进行加密	更安全，数据储存在本地，第三方无法获取
灵活性	灵活性较好，定制化程度较高	灵活性差，无需运营，但灵活性受限	灵活性最好，可根据需求进行本地开发

5、云原生架构知识点补充

1、云计算架构有哪几个层?分别是什么？

云计算架构主要分为五个层次，分别为管理层、应用层、用户访问层、平台层和资源层。

**管理层：**提供对所有云计算服务层的管理功能，确保资源的有效利用和监控。

**用户访问层：**方便用户使用云计算服务，提供相应的访问接口，支持用户与云服务的互动。

**应用层（SaaS）：**提供软件服务，涵盖各类应用，如财务管理、客户关系管理和商业智能等，用户无需管理底层基础设施。

**平台层（PaaS）：**提供开发平台及中间件服务，支持应用的构建、部署和管理，简化开发流程。

**资源层（IaaS）：**提供虚拟化资源，隐藏物理资源的复杂性，如服务器和存储，为用户提供灵活的基础设施。

2、云原生架构相关技术有哪些？

容器化：容器就像是一种移动的房屋模块，包含了你别墅的所有必需品，如墙壁、门窗、家具等。你可以将这些容器化的模块制作好，然后组装起来。容器化是云原生的基石，它将应用程序与其依赖项和配置信息一起打包，使得应用程序能够在不同的环境中一致地部署和运行。

**微服务架构/技术：**微服务就像是别墅里的不同房间，各自独立、功能明确，有的负责接收外部的数据，有的负责响应前台的操作……其中一个出问题了，其它的还能正常对外提供服务。将应用程序拆分为多个小型、独立服务的架构风格，每个服务都可以独立开发、部署和扩展。并通过轻量级的通信机制（通常采用HTTP或消息对列）相互协作。

动态编排：大别墅都有了，必须要再配备一个智能的管家，能够自动化管理各种任务，如清洁、修理等。在云原生世界里，这个管家就是容器编排系统，比如Kubernetes。它负责动态调度和管理容器化的应用程序，自动化任务如容器部署、扩展、负载均衡和自愈，确保应用程序高可用和资源利用率。

**DevOps实践：**想要别墅的建造能够顺利进行，就少不了设计师和建筑工人之间的紧密合作，就像云原生开发和运维团队之间的协作和自动化。**通过自动化的持续集成/持续部署（CI/CD）流程，实现快速交付和频繁的软件更新。**DevOps实践使得开发和运维之间的协作更加高效，加快了应用程序的迭代和发布速度。

服务网格：一种专门用于管理微服务间通信的基础设施层，能够以非侵入的方式处理微服务架构中的服务发现、负载均衡、安全性、故障恢复、度量和监控等问题

发展背景：微服务架构解决了单体应用的复杂性，通过松耦合的方式提高了开发和迭代的效率。

设计约束：强调微服务的独立性、可发现性与可交互性、数据层的隔离，以及全局视角下的运维需求。

主要技术：提到了一系列微服务框架（如 Apache Dubbo、Spring Cloud 等），强调了其在不同领域的应用和生态。

无服务器架构/技术：是一种基于云计算平台的一种"即付即用"的服务模式。基础设施全托管（无须关心维护、扩容等），开发人员只需编写函数（Function）或者服务（Service），云服务提供商会自动管理和调度底层的服务器资源。一般由BaaS（后端即服务）和Faas（函数即服务）实现。

3、Kubernetes 容器编排的核心能力是什么？

Kubernetes 已成为容器编排的事实标准，广泛用于自动化部署、扩展和管理容器化应用，提供了分布式应用管理的核心能力。

**（1）资源调度：**根据应用需求（如 CPU、内存、GPU），选择适合的节点运行应用。

**（2）应用部署与管理：**支持自动发布、回滚和配置管理，并自动化存储卷的编排，与容器的生命周期关联。

**（3）自动修复：**监测宿主机状态，故障时自动迁移应用，简化运维管理。

**（4）服务发现与负载均衡：**通过 Service 资源和 DNS，实现容器间的相互通信及负载均衡。

**（5）弹性伸缩：**监测业务负载，自动扩容以应对 CPU 利用率高或响应时间长的情况。

控制平面组件：APIServer、Controller、Scheduler 和 etcd 是 Kubernetes 的核心组件。

**（6）声明式 API：**允许开发者专注于应用，而非执行细节，支持多种资源类型（如 Deployment、StatefulSet、Job）。

**（7）可扩展性架构：**所有组件基于开放 API，支持通过 CRD/Operator 扩展，提升能力。

**（8）可移植性：**通过抽象（如负载均衡服务、CNI、CSI）屏蔽底层基础设施差异，实现灵活迁移。

4、什么是Istio服务网格？

Istio 是一个开源的服务网格平台，旨在简化微服务应用的管理和安全。它通过将网络流量管理、服务发现、负载均衡、故障恢复、安全、监控和可观察性等功能集中到基础设施层，帮助开发者专注于业务逻辑，而不必担心服务间的通信和治理问题。

（1）主要组件

数据平面（Data Plane）：由 Envoy 代理组成，负责处理微服务间的通信。每个微服务实例旁边运行一个 Envoy 代理，负责流量管理、负载均衡、故障注入等。

控制平面（Control Plane）：负责管理和配置数据平面。主要组件包括：Pilot：负责流量管理和服务发现。

Mixer：提供政策管理和遥测功能。

Citadel：提供服务间的安全通信和身份管理。

Galley：负责配置管理和验证。

（2）核心功能

流量管理：支持路由控制、负载均衡、故障恢复（如重试和熔断）等。

安全性：通过 mTLS（相互传输层安全）提供服务间的安全通信，支持身份验证和授权。

监控和可观察性：自动收集指标、日志和跟踪信息，支持集成与 Prometheus、Grafana 等工具，提供服务调用链的可视化。

策略管理：支持灵活的流量控制和访问策略，例如基于用户、请求属性等条件的策略。

（3）优势

无侵入性：Istio 通过代理模式与应用解耦，不需要修改应用代码。

灵活性和可扩展性：支持不同的基础设施和环境，易于集成现有的 CI/CD 流程。

增强的可观察性：通过全面的监控和跟踪能力，帮助开发和运维团队快速识别和解决问题。

（4）使用场景

微服务治理：在复杂的微服务架构中，通过 Istio 实现高效的服务治理。

多云和混合云环境：支持跨不同云平台的服务连接和管理。

安全敏感应用：在金融、医疗等行业中，确保服务间通信的安全性和合规性。

6、高可用架构补充

高可用架构的几种模式对比

	工作模式	区别/注意
主备模式	主服务器（Active）：处理所有的业务请求，并将数据写入共享存储。备用服务器（Standby）：监控主服务器的状态，通过数据复制机制保持数据的一致性。在主服务器发生故障时，备用服务器会接管业务处理。	主备不同时工作
主从模式	主服务器（Master），负责处理所有的写操作，另一台或多台作为从服务器（Slave），负责处理读操作。	主从都同时工作，而且工作的任务不一样
双机互备模式	两个相对独立的应用在两台机器同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性，但对服务器的性能要求比较高。	“两个相对独立的应用”通常指的是两台服务器上运行的不同业务或服务。这些业务或服务在功能上是独立的，但它们可以是相同类型应用的不同实例，也可以是完全不同的应用程序。这种模式的目的是在其中一台服务器出现故障时，另一台服务器能够接管并继续提供服务，从而保证业务的连续性和系统的可用性。
双机双工模式	集群的一种形式（主+主，负载均衡），两台服务器均处于活动状态，同时运行相同的应用，以保证整体系统的性能，也实现了负载均衡和互为备份，通常使用磁盘柜存储技术。Web服务器或FTP服务器等用此种方式比较多。
集群模式和分布式	集群模式就是复制多份应用服务，放在不同的服务器上，执行相同的业务，为了提高性能，客户端通常使用负载均衡技术来访问不同的主机	负载均衡常用算法：加权轮询（根据服务器的权重来分配请求，权重高的服务器分配更多的请求）、加权最少连接（根据服务器的权重和当前连接数来分配请求）、IP哈希（通过计算客户端IP地址的哈希值来决定使用哪台服务器）、动态性能分配（根据服务器的实时性能指标（如CPU和内存使用率）动态分配请求）、资源利用率（根据服务器的资源利用率来分配请求，以避免过载）

如何设计高可用架构

1、研发规范的高可用

研发的规范化是研发和维护一个高可用的系统的起点。需要遵循统一的代码规范、依赖管理、版本控制、测试规范、文档编写规范。

2、应用服务的高可用

①负载均衡设计

采用微服务框架（如 springcloud），基于框架的服务发现和负载均衡机制（如服务注册于发现、智能流量分配、健康检查以及自动故障剔除等）确保是系统的高可用核心组件。

②弹性扩缩容设计

采用容器化技术（如K8s）进行应用部署。

③异步解耦和削峰设计（消息队列）

采取分层和模块化的方法。这种设计策略不仅有助于系统的维护和扩展，而且通过在各模块之间实施异步处理和解耦，可以显著提高整个系统的稳定性和可靠性。异步处理和解耦的目的是确保各个组件能够独立运行，不会因为相互依赖而影响整体的可用性。

在架构层面，异步解耦可以通过引入消息队列来实现，例如Kafka。

④故障和容错设计

使用服务等级协议（SLA）来衡量服务的可用性，以“几个9”来表示，比如99.99%的可用性，即所谓的“四个9”。

遵循“为失败而设计”（design for failure）的原则：

快速失败（Fail Fast）：

快速失败原则强调在主流程中一旦检测到问题，就应该立即终止流程并返回错误。这种做法有助于避免错误扩散，减少可能的负面影响。通过快速识别和响应问题，我们可以防止小问题演变成大问题。

自我保护机制：

当系统依赖的外部服务出现故障时，系统应具备自我保护的能力。这包括及时实施降级策略和兜底方案，以防止问题蔓延，避免因连锁反应导致整个服务瘫痪。例如，如果依赖的数据存储服务出现问题，系统不应持续重试，因为这可能导致服务完全不可访问。相反，系统应该能够优雅地退回到一个安全的运行状态，或者提供一个备选的服务路径。

⑤过载保护设计（限流、熔断、降级）

限流：通过控制请求的速率来保护系统不被过多的请求压垮。

使用Nginx、Redis限制每个用户的请求频率，如每秒不超过20次。
在服务端，使用Guava的RateLimiter限制对数据库的访问频率。

熔断：当系统下游服务不可用时，自动“断开”服务调用，避免系统过载。

使用Hystrix为关键服务（如支付、库存查询）实现熔断机制。
当服务失败次数超过阈值时，自动进入熔断状态，拒绝调用。

降级：是在系统部分功能不可用时，提供备选方案，以保证核心功能的正常运行。

预设降级策略，如当库存查询服务不可用时，返回最近的缓存数据。
在服务调用失败时，自动切换到降级策略，保证用户体验。

3、数据存储的高可用

确保数据在任何情况下都能被访问和使用。

数据冗余：

镜像：在不同的物理位置存储数据的多个副本。
RAID（独立磁盘冗余阵列）：在多个硬盘上分布数据，以提供容错能力。

分布式存储系统：

使用如HDFS（Hadoop Distributed File System）、Ceph、GlusterFS等分布式文件系统，它们能够在多个节点上存储数据，并且能够在节点故障时自动恢复。

数据库高可用架构设计：

主备模式、主从模式、双工模式等，一致性方案；容灾方案；

4、运维部署高可用

确保IT基础设施和服务在面对故障时能够持续运行。

①自动化部署：

使用自动化工具（如Ansible、Chef、Puppet、Terraform等）来自动化部署流程，减少人为错误。

②容器化：

使用Docker、Kubernetes等容器技术来封装应用及其依赖，实现快速部署和扩展。

③持续集成/持续部署（CI/CD）：

建立CI/CD流程，自动化测试和部署，确保软件的快速迭代和高质量发布。

④蓝绿部署：

使用蓝绿部署策略，同时运行两个生产环境，一个用于当前版本，另一个用于新版本，以减少部署风险。

⑤滚动更新：

实施滚动更新，逐步替换旧版本实例，减少服务中断。

⑥监控和警报：

实施全面的监控系统来监控服务状态和性能指标，并设置警报机制。

⑦备份和灾难恢复：

定期备份关键数据和配置，并测试恢复流程，确保在数据丢失或灾难情况下能够快速恢复。

⑧定期演练：

定期进行故障演练和压力测试，验证高可用性策略的有效性。

⑨反馈和持续改进：

收集运维部署的反馈，不断优化和改进部署流程。

5、异常应急高可用

确保在面对突发事件或系统故障时，系统能够快速恢复并继续提供服务。

①制定应急预案：

制定详细的应急预案，包括各种可能的故障场景和相应的响应措施。

②建立应急响应团队：

组建专门的应急响应团队，负责在发生故障时快速响应和处理。

③监控和警报：

实施全面的监控系统，实时监控系统状态，一旦发现异常立即发出警报。

④故障模拟和演练：

定期进行故障模拟和应急演练，提高团队的应急处理能力和系统的恢复速度。

⑤快速切换和故障转移：

配置快速切换和故障转移机制，确保在发生故障时能够迅速切换到备用系统。

⑥灾难恢复计划：

制定灾难恢复计划，包括数据备份、系统恢复、业务连续性计划等。

⑦通信和协调机制：

建立有效的通信和协调机制，确保在发生故障时，所有相关人员能够及时沟通和协作。

⑧定期审查和更新预案：

定期审查和更新应急预案，确保预案的时效性和有效性。

⑨持续改进和反馈：

收集应急响应的反馈，不断优化和改进应急预案和响应流程。

总结：冗余设计、负载均衡、监控与报警、自动化运维

7、安全架构补充

安全面临的威胁

在网络与信息安全风险中，最重要的是人为蓄意破坏威胁，可分为被动性攻击和主动性攻击。

被动性攻击主要是收集信息、破坏保密性为主，不主动进行攻击，常见的攻击：

窃听	用合法/非法手段窃取信息资源和敏感信息
非法登录	在未经授权的情况下，通过非法手段访问或使用某个系统或账户的行为
业务流分析	通过对系统进行长期监听，利用统计分析方法对诸如通信频度、通信的信息流向、通信总量的变化等参数分析，从而发现有价值的信息和规律

主动攻击主要进行主动攻击，如中断（破坏可用性）、篡改（破坏完整性）、伪造（破坏真实性）等：

假冒	非法用户假冒合法用户、权限小的用户假冒权限大的用户
抵赖	否认自己发布过的信息、伪造对方来信
DOS拒绝服务	破坏可用性，对信息等资源的合法访问进行无条件拒绝
重放攻击	截获某次合法的信息数据，并且处于非法目的重新发送，使用时间戳可以识别重放攻击
XSS跨站脚本攻击	利用网页开发时留下的漏洞，注入恶意指令代码
缓冲区溢出攻击	利用缓冲区溢出漏洞进行攻击
SQL注入攻击	攻击者将SQL命令插入Web表单中七篇服务器执行恶意的SQL命令
旁路攻击	攻击者利用系统的安全缺陷或安全性上的脆弱之处获得非授权的权利或特权。例如，攻击者通过各种攻击手段发现原本应保密，但是却又暴露出来的一些系统“特性”利用这些“特性”，攻击者可以绕过防线守卫者侵入系统的内部。
重放	所截获的某次合法的通信数据备份，出于非法的目的而被重新发送。