1.微服务的拆分原则/怎么样才算一个有效拆分
- 单一职责原则:每个微服务应该具有单一的责任。这意味着每个服务只关注于完成一项功能,并且该功能应该是独立且完整的。
- 最小化通信:尽量减少服务之间的通信,服务间通信越少,系统越简单。
- 可独立部署:服务应该可以独立部署,不应该依赖于其他服务。
- 数据一致性:在设计服务时,要考虑好数据一致性的问题,避免因为服务拆分而带来的一致性挑战。
- 性能考量:在拆分服务时,要考虑到性能的影响,避免不必要的服务拆分导致性能下降。
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,在客户端的配置文件中,可以配置某一个服务调用的负载均衡策略,这个是局部生效,只是对配置的这个服务生效远程调用。