Java面试题——微服务篇

1.微服务的拆分原则/怎么样才算一个有效拆分

1. 单一职责原则：每个微服务应该具有单一的责任。这意味着每个服务只关注于完成一项功能，并且该功能应该是独立且完整的。
2. 最小化通信：尽量减少服务之间的通信，服务间通信越少，系统越简单。
3. 可独立部署：服务应该可以独立部署，不应该依赖于其他服务。
4. 数据一致性：在设计服务时，要考虑好数据一致性的问题，避免因为服务拆分而带来的一致性挑战。
5. 性能考量：在拆分服务时，要考虑到性能的影响，避免不必要的服务拆分导致性能下降。

---

2.微服务的拆分方式

一般有两种方式：

1.纵向拆分 (垂直拆分)

        所谓纵向拆分，就是按照项目的功能模块来拆分。例如商城项目中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。

2.横向拆分 (水平拆分)

        而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。（类似于AOP思想）

---

3.微服务中常用组件

组件名称	功能概述	常用技术栈
服务发现(Service Discovery)	自动注册和发现微服务实例，支持动态扩展	Nacos、Consul、Zookeeper
API网关(API Gateway)	统一流量入口，提供路由、限流、认证、监控等功能	Gateway、Nginx
配置中心(Configuration Management)	管理分布式配置，支持动态更新与多环境管理	Spring Cloud Config、Nacos
负载均衡(Load Balancing)	均衡分发流量，提高系统响应速度	Ribbon、Nginx
服务调用(Service Invocation)	微服务间的通信机制，支持同步与异步调用	Feign、RestTemplate、gRPC
服务熔断(Circuit Breaker)	保护系统免受故障蔓延，提升容错能力	Hystrix、Resilience4j、Sentinel
消息队列(Message Queue)	实现服务的异步通信，解耦系统，提高可扩展性	Kafka、RabbitMQ、RocketMQ
服务安全(Service Security)	实现微服务的认证、授权和数据保护	OAuth2、JWT、Spring Security
分布式事务(Distributed Transaction)	保证跨服务的事务一致性	Seata、TCC、Saga

我自己项目中用到的：

1.注册中心/配置中心：Nacos            2.网关：Gateway、Nginx

3.负载均衡：Ribbon、Nginx             4.服务调用：Feign              5.服务保护：Sentinel

6.消息队列：RabbitMQ、Kafka        7.分布式事务：Seata

4.服务注册和发现是什么意思？如何实现服务注册和发现？

以Nacos为例(Eureka基本一样)

• 服务注册：服务提供者需要把自己的信息注册到nacos，由nacos来保存这些信息，比如服务名称、ip、端口等等。
• 服务发现：消费者向nacos拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
• 服务监控：服务提供者会每隔5秒(默认)向nacos发送心跳，报告健康状态，如果nacos服务15秒(默认)没接收到心跳，从nacos中剔除

追问：nacos和eureka的区别

---

①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式(服务向Nacos发送心跳检测)，非临时实例(可以设置)采用主动检测模式(Nacos主动检测非临时实例)

②临时实例心跳不正常会被剔除，非临时实例则不会被剔除

③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

④Nacos集群默认采用AP方式(高可用)，当集群中存在非临时实例时，采用CP模式(强一致)；Eureka采用AP方式

补：以上是作为注册中心二者的不同点。Nacos还可以作为配置中心！

---

5.Ribbon实现负载均衡

在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单。

当发起远程调用时，Ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询。

Ribbon负载均衡策略有哪些 ?

• RoundRobinRule：简单轮询服务列表来选择服务器。
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小。
• RandomRule：随机选择一个可用的服务器。
• ZoneAvoidanceRule(Ribbon默认策略)：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。

如何自定义负载均衡策略

提供了两种方式：

1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用。

2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，这个是局部生效，只是对配置的这个服务生效远程调用。