架构方面的面试题

架构类型

单一应用架构

将所有功能都放在一个服务中，适合快速开发功能，并可以减少部署节点和成本。

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

缺点：任何功能升级都要部署整个应用。

传统垂直架构

传统垂直架构是指将整个应用程序按照功能或业务模块划分为多个独立的层（如表示层、业务逻辑层、数据访问层），每个层都在单独的服务器上运行的架构方式。

优点：易于理解与开发，相比单一应用可以根据不同功能选择不同的服务器提供更好的性能

缺点：

  • 耦合性高-单个功能模块出现故障可能会影响整个系统的使用；
  • 扩展性差-不能根据业务种类通过增加节点分担负载
  • 成本增加-相比单一应用架构增加了服务器成本

 

 

分布式服务架构（RPC架构）

分布式架构是将系统拆分为多个独立的服务，这些服务进行独立部署共同为整个项目服务。

分布式架构是一种系统设计，包括各种实践方式（架构风格）如微服务架构、SOA服务化架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

RPC（Remote Promote Call） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。

RPC框架如：dubbo

分布式服务设计原则：

cap原则：是分布式服务设计的基本原则，即一致性、可用性、分区容错性，因为cap不可能完全达到，一版都是保证分区容错性，出现故障时的核心功能的可用性，及最终一致性。

另外分布式系统设计时要考虑到可扩展性（增加节点）、负载均衡等。

 

分布式架构举例：

  • 用户界面层：负责接收用户的请求并展示网页内容。
  • 应用层：处理用户请求，包括验证用户身份、处理业务逻辑等。
  • 数据层：负责存储和管理系统的数据，可以使用分布式数据库或分布式文件系统。
  • 缓存层：用于缓存热门数据，提高系统的性能。
  • 消息队列：用于解耦不同的组件，实现异步通信。
  • 服务发现和负载均衡：用于管理和调度不同的服务实例，实现高可用和负载均衡。

优点：

  • 容错性-当一个组件出现故障时，其他组件还可以继续工作
  • 可扩展性-当组件负载增加时，可以通过扩展组件的节点来分担负载，提供系统性能
  • 灵活性-每种组件独立开发与部署，可以单独进行开发与升级而不影响所有功能。

缺点：

  • 复杂性增加-开发时需要保证数据一致性、分布式事务等问题
  • 性能问题-多个组件独立部署相互间通信相比单体应用会增加性能消耗和延时
  • 部署和维护成本-如果一次升级涉及到多个组件，就需要进行多次部署升级
  • 服务器成本-组件独立部署会占用更多的服务器

流动计算架构（SOA服务化架构）

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

在SOA架构中，服务被视为一个独立的功能单元，可以远程访问并独立运行与更新。

 

SOA有两个层面的定义：

从应用的角度定义：SOA是一种应用框架，它着眼于日常的业务应用，并将他们划分为单独的业务功能和流程，及所谓的服务。

从软件的基本原理定义：SOA是一个组件模型，它将应用程序的不同功能单元(服务)通过这些服务之间定义良好的接口和契约联系起来。这里说的就是这意思

 

soa的实现：可以使用dubbo

 

微服务架构

原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。每个服务都有自己的独立数据库，并通过轻量级的通信机制来实现服务之间的通信。

微服务架构也可以把公共的组件提取出来做成微服务供其他微服务使用

特点：

  • 服务拆分：微服务架构将应用程序拆分成多个小型的服务，每个服务都专注于特定的业务功能。
  • 独立部署：每个微服务都可以独立部署
  • 松耦合：微服务架构通过轻量级的通信机制进行通信

优点：

  • 松耦合：微服务是独立部署的且使用轻量级的通信机制，可以进行独立升级，而不影响其他微服务。
  • 灵活性：可以根据业务的访问量灵活分配微服务的部署节点数量，也可以灵活选择技术栈对微服务进行开发
  • 容错性：一种业务的微服务出现故障，其他微服务还可以正常对外提供服务

缺点：

  • 复杂性-每个微服务都要单独开发配置一些通用的功能，也要单独进行部署与维护，涉及都多个服务的功能测试复杂性也增加。
  • 数据一致性问题：多个微服务相互调用需要保证数据的一致性
  • 运维难度增加-微服务多了，需要监控更多的服务、数据库等，解决方案是使用k8s来管理服务和监控服务的状态
  • 成本增加-微服务多了会占用更多的服务器，而且往往每个微服务有单独的数据库，成本增加

 

微服务概念：

微服务是一种架构风格，它以业务功能为核心进行服务设计。每个服务都具有自主运行的业务功能，并通过对外开放、不受语言限制的API（最常用的是HTTP）进行通信。

 

分布式架构

CAP原则

CAP原则是对分布式系统设计的一个基本指导原则，但并非绝对。在实际应用中，可能会根据具体业务场景和技术实现进行权衡和调整。

 

CAP原则：

  • 一致性（C：Consistency）、
  • 可用性（A：Availability）、
  • 分区容错性（P：Partition Tolerance）

 

一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

分区容错性：指系统在面对网络分区时，仍然能够正常运行。网络分区是指由于网络故障或其他原因，系统中的节点之间无法相互通信，导致系统被分割成多个独立的子系统。每个子系统内的网络是正常的，但子系统之间无法进行信息交换。

 

分布式系统不可能同时满足，最多只能同时满足其中两项。分区容错性是一定要保证的，对于一个分布式系统，得保证在网络出现分区后，分布式系统仍然能工作,只不过当出现网络分区后，整个分布式系统如果想要保证数据一致性，那么就要损耗系统可用性，或者如果想要保证系统的可用性，就不能保证系统的一致性，这里说的是强一致性，因为如果网络出现问题，分布式系统中的数据就无法进行及时的同步，如果要求强一致性，那么就只能等网络好了之后，数据同步好了之后，才能提供给用户使用，同理，如果要求网络出现后问题，系统要能使用，那就可能数据会不一致，所以对于一个分布式系统，目前来说只能保证CP或AP。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

 

分区容错性要怎么保证：

  1. 数据复制：将数据项复制到多个节点上，这样即使出现网络分区，数据也可能分布到各个区域中，从而提高了分区容忍性。但是，数据复制会带来一致性的问题，因此需要结合一致性协议进行处理。
  2. 一致性协议：为了解决数据复制带来的一致性问题，需要采用一致性协议。常见的协议如Raft和Paxos等，通过节点间的投票和日志复制等机制，确保在出现分区的情况下，系统仍然能够保持数据的一致性。这些协议通常会在牺牲一定的可用性来保证一致性，或者在牺牲一致性来保证可用性之间做出权衡。
  3. 故障检测与恢复：通过定期的心跳检测机制，系统可以及时发现节点故障或网络分区。一旦检测到故障或分区，系统可以采取相应的恢复措施，如重新选举领导节点、修复网络连接等，以确保系统的正常运行。
  4. 分区感知：设计系统时，使其能够感知到分区的存在，并据此调整其行为。例如，当系统检测到分区时，可以选择暂时降低一致性要求，以确保服务的可用性，或者在分区解决后再进行数据同步。
  5. 业务逻辑适配：在某些业务场景中，可能可以通过调整业务逻辑来适应分区。例如，对于一些非关键业务，可以允许在分区期间出现一定程度的数据不一致，待分区解决后再进行数据同步。

 

一致性详细说明

数据一致性是指在分布式系统中的所有节点在同一时间看到的数据是一致的。在数据一致性中，有几个重要概念：
  • 强一致性： 所有节点在同一时间看到的数据是相同的，即数据更新后立即对所有节点可见。
  • 弱一致性： 允许系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。即使过了所谓的“不一致时间窗口”，后续的读取操作也不一定能保证得到更新后的值。
  • 最终一致性： 系统保证在一段时间内最终会达到一致状态，即数据更新后最终会在所有节点上达到一致。最终一致性则是弱一致性的一种特殊形式，特别适用于大型分布式系统，它允许系统在一段时间内存在不一致性，但最终会收敛到一致状态。弱一致性和最终一致性的主要区别在于对后续读取操作的保证。弱一致性即使在过了不一致时间窗口后，也不能保证读取到的是更新后的值，而最终一致性则保证在没有新的更新的情况下，所有的读取最终都会是最后更新的值。

不同的应用场景可能需要不同级别的一致性保证。强一致性可以提供最高级别的数据一致性，但可能会影响系统的性能和可用性；而弱一致性和最终一致性可以在一定程度上提高系统的性能和可用性，但需要在应用程序中处理可能出现的数据不一致情况。

 

BASE理论

BASE理论则是CAP原则权衡的结果。来源于大规模互联网的分布式实践总结。

BASE是指Basically Available（基本可用的）,Soft state（软状态）,Eventual consistency（最终一致性）。

Basically Available是指在分布式集群节点中，若某个节点宕机，或者在数据在节点间复制的过程中，只有部分数据不可用，但不影响整个系统的整体的可用性。

Soft state是指软状态即这个状态只是一个中间状态，允许数据在节点集群间操作过程中存在存在一个时延，这个中间状态最终会转化为最终状态。

Eventual consistency是指数据在分布式集群节点间操作过程中存在时延，与ACID相反，最终一致性不是强一致性，在经过一定时间后，分布式集群节点间的数据拷贝能达到最终一致的状态。

很多分布式系统的问题解决方案都是对BASE理论的应用

具体来说，当分布式系统出现不可预知的故障时，BASE理论允许损失部分可用性，以保证核心功能的可用性。同时，它允许系统中存在中间状态（软状态），这个状态不影响系统可用性，并允许数据在一段时间内是不一致的，但最终会达到一致状态。

BASE理论为分布式系统设计提供了一种权衡一致性和可用性的方法，使得系统可以在保证核心功能可用的同时，也能够处理网络分区和数据不一致的情况。

 

分布式架构和微服务架构区别

微服务架构是分布式架构的一种实现方式；分布式架构是一种更广泛的架构范式，可以涵盖多种形式的分布式系统设计，包括微服务架构。

 

微服务与SOA区别

微服务是细粒度的SOA组件。换句话说，某单个SOA组件可以被拆成多个微服务，而这些微服务通过分工协作，可以提供与原SOA组件相同级别的功能

 

RPC

（Remote Promote Call）

远程过程调用, 一种进程间通信方式。允许像调用本地服务一样调用远程服务。

 

RPC框架

RPC框架中主要有三个角色：服务提供者，服务中心，服务消费者

服务提供者：暴露服务的服务提供方

服务消费者：调用远程服务的服务消费方

服务中心：提供服务注册与发现的注册中心

 

服务提供者启动后主动向注册中心注册机器ip、port以及提供的服务列表；

服务消费者启动时向注册中心获取服务提供方地址列表

 

注册服务中心：

可选技术：

* Redis

* Zookeeper

* Consul

* Etcd

 

开源的RPC框架：

阿里巴巴 Dubbo：https://github.com/alibaba/dubbo

springCloud:

新浪微博 Motan：https://github.com/weibocom/motan

gRPC：https://github.com/grpc/grpc

rpcx ：https://github.com/smallnest/rpcx

Apache Thrift ：https://thrift.apache.org/

springCloud如何提供Rpc功能的

springCloud通过集成和封装一些现有的RPC框架或技术来实现的，OpenFeign可以作为RPC的一种实现方式。它利用了HTTP协议进行通信。

 

openFeign和Dubbo比较

openFeign采用的http的方式进行系统之间调用，没有强依赖关系

dubbo需要调用双方之间定义rpc的接口才能调用，有强依赖关系

使用dubbo进行通信双方会保持长连接，使用openFeign默认是采用短连接的，一旦响应完成，连接通常会被关闭。

如果你对性能和吞吐量有较高要求，并且需要构建大规模的分布式微服务体系，那么dubbo可能是一个更好的选择。而如果你主要关注服务的轻量级和易于上手，那么openfeign可能更适合你。

 

微服务的优点

是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。

可以由一个小团队负责更专注专业，相应的也就更高效可靠。

微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

微服务开发框架

目前微服务的开发框架，最常用的有以下四个：

Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）

Consul、etcd&etc.（微服务的模块）

如何设计高并发、高可用、高性能的系统

对于高并发我们可以使用网关限流防止流量太多、使用消息队列异步处理请求、使用分布式锁避免线程安全问题

对于高可用我们可以服务做集群故障转移、数据做备份、负载均衡等处理。

对于高性能我们可以使用缓存提高查询性能，使用分布式共同提供系统功能。

说一下大数据

大数据是指大数据集，这些数据集经过计算分析以揭示与数据的某个方面相关的模式和趋势。

大数据的处理过程

主要包括：

数据采集：本本系统或互联网上的数据采集到我们系统中

数据导入和清洗处理：筛选出有用的数据并保存

数据统计和分析：分类汇总这些数据

数据挖掘应用：分析数据背后的联系，提出预测来运用数据

大数据与云计算

云计算为大数据提供技术支持

做大数据需要那些技术

Linux服务器运维:

Linux操作系统、Linux常用命令、Linux常用软件安装、Linux网络、防火墙、Shell编程等。

内存数据库redis

分布式协调服务zookeeper

 

hadoop体系涉及的技术：

Hadoop Common：

Hadoop体系最底层的一个模块，为Hadoop各子项目提供各种工具

HDFS：

是Hadoop应用程序中主要的分布式储存系统

MapReduce：

用以海量（TB级）数据的处理

Apache Hive

Apache Hive是Hadoop的一个数据仓库系统

Apache Pig

Apache Pig是一个用于大型数据集分析的平台

Apache HBase

Apache HBase是Hadoop数据库，一个分布式、可扩展的大数据存储。

Avro：

avro用来做hadoop的RPC

Sqoop:

Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具，可以将一个关系型数据库中数据导入Hadoop的HDFS中，也可以将HDFS中数据导入关系型数据库中。

Mahout:

Apache Mahout是个可扩展的机器学习和数据挖掘库

 

分布式与集群与负载均衡区别

分布式: 不同的服务器做不同的事情(相当于是任务分工)

集群: 不同的服务器做同样的事情(分担任务量,相当于是量的分工)

负载均衡: 相当于是根据服务器的配置, 划分任务量。

 

 

负载均衡分类

把任务量根据操作单元的配置合理分配相符合的任务量

根据软/硬件分：

软负载均衡：

是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡。目前比较流行的就三类软件负载均衡，LVS、Nginx和HAProxy。用的最多的还是LVS和Nginx这两种。

硬负载均衡：

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，比较主流的几类产品：F5 BIG-IP负载均衡器（LTM），思科，Radware的AppDirector系列，梭子鱼负载均衡

 

服务治理的概念

对服务化架构的管理的一系列行为

服务治理的活动有那些

总结：管理服务的生命周期，监控服务性能，制定服务调用规则

（服务治理的一些关键活动包括：

 1.对开发新服务和升级现有服务的计划

 2.管理服务的生命周期：确保升级服务不会影响目前的服务消费者制定方针来限制服务行为：

 3.制定所有服务都要遵从的规则，确保服务的一致性

4.监控服务的性能：由于服务组合，服务停机和性能低下的后果是严重的。通过监控服务的性能和可用性，当问题出现的时候能马上采取应对措施。

5.管理由谁来调用服务、怎样调用服务）

posted @ 2023-02-02 10:26  星光闪闪  阅读(152)  评论(0)    收藏  举报