微服务架构面试题

1.单体架构到微服务架构的演化

单体架构->集群架构->垂直架构->SOA->微服务
最开始的时候项目是单体架构，在运行过程中，因为业务耦合度增加，项目关联度增加等原因，项目某些功能会出现卡顿。此时可以采用集群架构来缓解压力。
但是集群架构会出现一些问题，比如资源分布不协调。可能只有部分功能会存在该问题，那么水平扩容（增加应用的节点）可能导致资源的浪费。为了解决这个问你，则根据业务将系统进行拆分。不同的子系统使用不同的应用服务器，但是不会分库。
垂直架构会出现冗余的问题。比如不同子系统都会需要用到某个功能，比如获取用户信息，此时各个子系统都需要重复实现该功能，造成代码冗余。
为了垂直系统的问题，出现了面向服务架构SOA。将业务拆分为不同的服务，此时已经拆分了表。但是SOA架构耦合度非常高。
为了进一步降低耦合度，所以出现了微服务的架构。微服务的划分粒度更细，但是此时微服务还是没有解决耦合度的问题。为了解决该问题，出现了面向领域驱动设计DDD。根据重要性和业务进行划分。
DDD根据业务的重要性识别核心业务（即软件的最初的创建目的）。支撑模块（除核心模块和通用模块之外的功能）、通用模块（每个模块都需要的功能）。
注意：微服务最大的问题就是服务治理问题。

2.微服务的五大组件和三大配件

五大组件：网关（过滤器链）、注册中心（服务治理：服务注册、服务续约、服务获取、服务下线、服务调用、失效剔除、自我保护、服务同步）、配置中心（统一配置管理）、声明式服务调用（动态代理方式）、负载均衡（策略）
三大配件（小规模项目不建议使用）：断路器（并发情况下，服务的降级、熔断、限流）、链路追踪（相当吃资源）、日志监控报警（至少三台服务器，需要服务达到一定规模）

3.0-1项目建设

1指的是项目稳定且有含金量。从0-1过程中踩过的坑是有价值的。
0-1项目怎么聊？
分布式解决方案：分布式事务、分布式锁。
项目增长期：并发问题如何解决，中间件redis、MQ、ES 分库分表
稳定期：review 代码，并发编程、异步编排、锁、设计模式等
裁员期：性能优化、JVM、MySQL性能优化

4.CAP理论

C一致性：各个节点在统一时刻看到的数据是相同的。
A可用性：确保请求得到响应，但不保证数据是最新的写入。
P分区容错性：系统在通信失败时继续运行和提供服务的能力，容忍数据的丢失或通信节点的延迟。
CAP：三者不可兼得，只能三者取其中之二。
CA：当系统发生网络分区时，可能停止服务，直到网络恢复正常。传统的关系型数据库就属于这种。
CP：牺牲可用性，当网络分区发生时，会停止服务。
AP：牺牲一致性，当网络分区发生时，会继续处理请求。

5.BASE理论

基于CAP理论，BASE理论有三个核心要素：
1 基本可用：系统在出现故障或部分失效的情况仍然可以保证基本的可用性。通常允许系统在出现故障时，部分功能暂时失效，但其他功能仍可正常访问。
2 软状态：系统在一定时间内可以是不一致的，即系统中的数据副本可能存在短暂的冲突和不同步。系统通过后续处理来逐渐调整数据状态为一致（不保证时间）。软状态允许系统中的数据存在中间状态，并认为改状态不影响系统的整体可用性。
3 最终一致：系统的数据最终会达到一致的状态，但是在某个节点上可能存在不一致的情况。分布式系统中的不同节点可能具有不同的数据副本，而这些副本之间的同步需要一定的时间。但是系统在一定时间范围内能否达到数据的一致性。

BASE理论通过牺牲强一致性来获取可用性，并允许数据短时间内不一致，但最终达到一致状态。
实际场景中，BASE理论常用于一下场景：
A 电子商务网站
B 社交媒体平台
C 金融交易系统

BASE理论的优点：
提高了系统的可用行和灵活性
支持大规模分布式系统
缺点：
数据一致性难以保障
系统复杂度增加

6.如何解决架构的复杂度问题

架构分层
领域拆分
服务聚合
高度自治（每个微服务应具备独立运行、自我管理和自我决策的能力，无需过度依赖其他服务或外部系统。高内聚低耦合）
链路简单清晰

7.系统解耦的方式

1 事件消息机制：Event EventHandler
2 设计模式：策略模式、责任链模式
3 规则引擎：Drools
4 状态机

8.微服务划分原则

1 基于业务功能：适用于项目规模小的项目，虽然推进速度快，但是系统耦合度较高
2 基于数据域：适用于数据量足够大的情况，虽然业务逻辑清晰，数据一致性可控，但是数据冗余与同步成功高。
3 基于可拓展性：将服务划分为水平拓展单元，例如将前端划分为多个负载均衡的实例，每个实例都可以处理一部分流量。
4 基于可维护性：将服务划分为易于维护和更新的单元。

9.微服务架构设计的优缺点

优点：
灵活性高
独立拓展
支持多种编程语言
自动部署域持续集成工具集成
通用性
缺点：
处理故障难度高
部署工作量大
测试复杂度高
运营成本增加
发布风险高
分布性系统问题

10.微服务架构性能指标

1 响应时间
2 吞吐量
3 并发数
4 错误率
5 延迟分布情况
6 网络流量
7 系统资源利用率

11.线程池隔离

在高并发场景下，多个线程共享一个线程池。比如tomcat处理每个请求，都会复用线程池中的线程。如果某个功能请求数量远超其他功能，那么该功能就会占用更多的线程。导致其他功能的请求，获取不到线程。
为了解决上述问题，可采用线程隔离，即用一个独立的线程池，处理某个特定的功能的请求。所以在设计的时候，不要将所有并发请求都放到一个资源中去。例如不要将所有的并发都放到一个请求中去。

线程池隔离的作用：
1 对C端用户对于服务的访问，起到分流的作用。
2 信号量隔离：控制并发线程数

12.注册中心

12.1.服务注册

服务注册中心使用双层map（服务名：（实例名：元数据））来存储服务提供者的元数据。
注册中心通过服务续约机制（心跳）来实现判断服务提供者的存活状态。

12.2.服务获取

当服务提供者启动时会触发服务启动的事件，注册中心监听该事件。监听到事件后，注册中心要求服务提供者，将元数据注册到注册中心（观察者模式）。
消费者启动之后，通过rest请求，向注册中心获取服务注册表，将其缓存到本地。

12.3.服务续约

通过心跳，如果制定时间内没有收到心跳，则会将服务置为过期状态。

12.4.服务调用

服务调用者，通过本地的注册表副本获取服务提供者信息，通过动态代理实现。

12.5.服务下线

主动下线（正常关闭操作）：通过发送rest请求，注册中心主动将服务置为过期状态（nacos）。

12.6.失效踢除

注册中心会有一个定时器，扫描心跳过期的服务，并将其设置为过期状态。

12.7.自我保护

服务网络不稳定，但是需要注册中心不下线该服务。注册中心有一个计数器：一段时间内实际获得心跳/一段时间内应该有的心跳。一旦达到某个值，服务则会进入保护模式，不会被踢除。（一般不会开启）

12.8.服务同步

注册中心可分为高可用和强一致
强一致：比如zookeeper等，服务提供这的信息在所有注册中心都同步后才能，服务才能被使用。
高可用：当服务注册后，注册中心会将注册信息转发到其他注册中心。保证最终一致性，允许某个时间数据不一致。

12.9.注册中心技术选型

nacos eureka consul zk
架构特性：
nacos（CP、AP）
eureka（AP） 极强可用-适用于视频网站
sonsul：适合云服务厂商使用
ZK：对于数据一致性较高的场景，比如金融、金融供应链

eureka

心跳机制：客户端发送到服务端，30s一次心跳。每30s，会有一个服务同步和服务续约请求。如果服务规模大了，就会面临大量的请求。其可用性就会降低。
eureka多级缓存架构
如果只使用ConcurrentHashMap,会导致线程并发问题。所以eureka将内存划分出了一块只读缓存。但是就出现了数据同步的问题。所以此时又有了一块读写缓存。
所以读取顺序为，优先读只读缓存，只读缓存没有，则读读写缓存，还没有采取读注册表（ConcurrentHashMap）。
但是当服务提供者发生了变化(新增或者下线)，注册表不能直接同步到只读缓存中。因为这样没有解决并发更新的问题。
所以当注册表发生更新，会过期读写缓存。然后定时器过期只读缓存。当服务获取者，再次获取服务的时候，在通过读取多级缓存，同步数据。

nacos

nacos的Raft算法
Raft算法是一种分布式一致性协议，旨在解决分布式系统中的数据一致性和容错性问题。它通过将复杂问题分解为领导者选举、日志复制和安全性保障三个子问题，简化了Paxos等传统一致性算法的实现难度。
首先确定一个leader节点，leader负责接收外部的数据更新/删除请求。
然后通过日志复制到其他follower节点，同时通过安全性准则保证整个日志复制的一致性。
如果leader故障，那么followers重新选举一个新的节点作为leader。

如果followers在一段时间内没有收到leader的心跳，那么follower会作为候选者Candidate参与选举，决出一个leader。然后其他节点就变成了follower。
选举投票过程的三个约束：
1 在同一任期内，单个节点只能投一票
2 候选人知道的信息不能比自己少
3 先到先得
选举的结果：
1 收到大部分（半数以上），赢得选举，成为leader
2 被告知别人已经当选，自行成为follower
3 一段时间内没有收到半数以上的投票，保持Candidate状态，重新选举。

13.配置中心

13.1.推送方式

动态监听
主动推送：服务端主动推送给客户端（服务器必须保持长连接，消耗内存）
pull方式：客户端定期拉取数据

Nacos长轮询机制：
定期轮询，发起长连接（超时时间设置为30s）。发起连接之后，如果配置有更新会直接推送更新后的数据。如果没有更新则将请求挂起29.5s。在这29.5s内，如果配置发生更新，那么会直接推送给client。如果没有更新则在最后0.5s内将数据返回给client。
为什么0.5s？因为超时时间是30S，所以29.5+0.5保证不超时。而且不采用1s，2s是因为0.5s占用的资源更少。

14.微服务限流方式

14.1.滑动窗口法

过程参考网址：
https://computerscience.unicam.it/marcantoni/reti/applet/SelectiveRepeatProtocol/selRepProt.html
根据服务端的处理能力来协调客户端发送请求的并发数。每个窗口的大小即为服务端对客户端的最大承载请求并发数。

14.2.计数器算法

通过对单位时间内相应的请求进行计数，如果数量超过了设定值，那么直接不响应请求，直至下一个单位时间。
该算法存在一个问题：

如果上一个周期的末尾来了峰值数的请求，下一个周期的开始来了峰值数的请求，此时服务器相当于要同时处理两倍的峰值数的请求（超过了最大并发承载能力）。

14.3.漏桶法

设置一个最大请求数（桶的最大容量），当请求数小于桶容量时，接受并处理请求。当请求数超过桶容量时，直接丢弃多的请求。
可以将多的请求暂存到redis中，然后异步从redis中读取处理。

14.4.令牌桶法

瞬时并发，能够通过预先存储的令牌来解决，但是如果流量平稳的量大，那么令牌生成的速度可能跟不上。